Version 1.4 released.
Changes:
- Fixed bug that caused "Work queue empty, miner is idle" on block changes.
- Fixed bug with RPC+LP servers when using some older versions of Twisted.
- Askrate now defaults to 10 for RPC servers without LP (previously it would request work only when needed, which can be >30 seconds on slower hardware)
- Fixed a dumb bug in RPC where it would stop trying to reconnect if it lost connection to a LP enabled server.
- Fixed error in some cases when the kernel's work cache is cleared on block change.
Topic: Phoenix - Efficient, fast, modular miner - page 43. (Read 760839 times)
I just wanted to stop in and say that the phoenix miner kicks ass. I'm getting about 20+ Mhash/s more than our miner (poclbm-mod).
Again, I'm glad to see that someone else understands the concept of efficiency, and I love that fact that it support long polling with our pool.
Anyone using your miner is more than welcome in our bitcoinpool(.com).
Again, I'm glad to see that someone else understands the concept of efficiency, and I love that fact that it support long polling with our pool.
Anyone using your miner is more than welcome in our bitcoinpool(.com).
And they all have identical configuration. Both slaves are running from 8GB usb stick, which are exact copies of each other
Tell me that you changed IP addresses of slave nodes... And it's good to tell what is the distribution you're using on them.
otherwise they would not connect to master node and to my vtun lan. That's debian squeeze Linux min3 2.6.32-5-686 #1 SMP Fri Dec 10 16:12:40 UTC 2010 i686 GNU/LinuxEDIT: and diablo's runs just fine, for many months already.
And they all have identical configuration. Both slaves are running from 8GB usb stick, which are exact copies of each other
Tell me that you changed IP addresses of slave nodes... And it's good to tell what is the distribution you're using on them.
I'm using r52. Command line -k poclbm DEVICE=3 VECTORS AGGRESSION=12 BFI_INT to bitcoinpoool
I was watching my client when a block was found and this showed up:
[30/04/2011 05:34:29] Result: 2cc5cc87 accepted
[30/04/2011 05:34:41] Result: 7f1bf205 accepted
[30/04/2011 05:35:08] Warning: work queue empty, miner is idle
[0 Khash/sec] [3526 Accepted] [11 Rejected] [RPC (+LP)]Unhandled error in Deferred:
Traceback (most recent call last):
Failure: twisted.internet.error.TimeoutError: User timeout caused connection failure. [30/04/2011 05:35:52] LP: New work pushed
[30/04/2011 05:37:50] Result: 3c452343 accepted
[30/04/2011 05:38:15] Result: d748a495 accepted
[30/04/2011 05:38:17] LP: New work pushed
[30/04/2011 05:38:37] Result: d9857987 rejected
[360.61 Mhash/sec] [3555 Accepted] [16 Rejected] [RPC (+LP)]
On 2 of the clients they picked back up and kept on going. On the 3rd it just stopped processing. After 30s I stopped and restarted it manually and it started chugging away without a problem.
I was watching my client when a block was found and this showed up:
[30/04/2011 05:34:29] Result: 2cc5cc87 accepted
[30/04/2011 05:34:41] Result: 7f1bf205 accepted
[30/04/2011 05:35:08] Warning: work queue empty, miner is idle
[0 Khash/sec] [3526 Accepted] [11 Rejected] [RPC (+LP)]Unhandled error in Deferred:
Traceback (most recent call last):
Failure: twisted.internet.error.TimeoutError: User timeout caused connection failure. [30/04/2011 05:35:52] LP: New work pushed
[30/04/2011 05:37:50] Result: 3c452343 accepted
[30/04/2011 05:38:15] Result: d748a495 accepted
[30/04/2011 05:38:17] LP: New work pushed
[30/04/2011 05:38:37] Result: d9857987 rejected
[360.61 Mhash/sec] [3555 Accepted] [16 Rejected] [RPC (+LP)]
On 2 of the clients they picked back up and kept on going. On the 3rd it just stopped processing. After 30s I stopped and restarted it manually and it started chugging away without a problem.
I so far heard phoenix.EXE only. why u running phoenix.py. You using linux?
I run this:
./phoenix.py -u http://u:[email protected]:8332/ -k poclbm DEVICE=1 VECTORS AGGRESSION=13 BFI_INT WORKSIZE=64
yes, that's debian linux
What's odd is I have two identical computers. One will connect to slushes just fine, the other won't. I've tried using different workers and even creating a new worker on slushes website.
Here is the command I am running:
phoenix.py -u http://username.worker:[email protected]:8332 -k poclbm DEVICE=0 VECTORS=on AGGRESSION=10 WORKSIZE=64 FASTLOOP BFI_INT
Here is the command I am running:
phoenix.py -u http://username.worker:[email protected]:8332 -k poclbm DEVICE=0 VECTORS=on AGGRESSION=10 WORKSIZE=64 FASTLOOP BFI_INT
I have exactly the same problem. Except that I have three mining rigs, one head node and two slaves. They all connect through the head node to the internet and slush's pool. And it is so strrange that only one slave node can always connects to the pool, and others two have always connections problems. And it's always the same one that works.
And they all have identical configuration. Both slaves are running from 8GB usb stick, which are exact copies of each other. Their mobos+GPUs+CPUs+everything are identical.
so strange.
It's even more strange, that when I try running phoenix, the diablo miner (which runs on other GPUs on same machine) is immediately starting to have connection problems too! And neither phoenix, nor diablo can connect. When I stop phoenix then diablo reconnects and continues to run just fine.
I think it is something with the network protocol used by phoenix.
I so far heard phoenix.EXE only. why u running phoenix.py. You using linux?
What's odd is I have two identical computers. One will connect to slushes just fine, the other won't. I've tried using different workers and even creating a new worker on slushes website.
Here is the command I am running:
phoenix.py -u http://username.worker:[email protected]:8332 -k poclbm DEVICE=0 VECTORS=on AGGRESSION=10 WORKSIZE=64 FASTLOOP BFI_INT
Here is the command I am running:
phoenix.py -u http://username.worker:[email protected]:8332 -k poclbm DEVICE=0 VECTORS=on AGGRESSION=10 WORKSIZE=64 FASTLOOP BFI_INT
I have exactly the same problem. Except that I have three mining rigs, one head node and two slaves. They all connect through the head node to the internet and slush's pool. And it is so strange that only one slave node can always connect to the pool, and others two have always connections problems. And it's always the same one that works.
And they all have identical configuration. Both slaves are running from 8GB usb stick, which are exact copies of each other. Their mobos+GPUs+CPUs+everything are identical.
so strange.
It's even more strange, that when I try running phoenix, the diablo miner (which runs on other GPUs on same machine) is immediately starting to have connection problems too! And neither phoenix, nor diablo can connect. When I stop phoenix then diablo reconnects and continues to run just fine.
I think it is something with the network protocol used by phoenix.
Thanks CFSworks! Using your tool I was able to get some information in nice HTML format:
(to get fan speed and temperatures I hacked my version of WebServer.py in multiminer to get those stats for me).
(to get fan speed and temperatures I hacked my version of WebServer.py in multiminer to get those stats for me).
I see everywhere... is there an alternative, or a need to specify this when using phoenix?
No and no, but everybody just copies everybody elses setup, so this kind of thing spreads quickly. It's the same thing as the bat/cmd-file everybody makes to start the client even though a short cut would be easier. Code:
-k poclbm
I see everywhere... is there an alternative, or a need to specify this when using phoenix?
There's currently only one kernel supplied, poclbm. It's in the kernel directory.Code:
-k poclbm
I assume you could put your own kernels in that directory and select it with the -k switch.
I see everywhere... is there an alternative, or a need to specify this when using phoenix?
Code:
-k poclbm
poclbm
-w 64 --platform 0 -f 1
~340MH/s
Phoenix
-k poclbm VECTORS BFI_INT AGGRESSION=7 PLATFORM=0 DEVICE=1 WORKSIZE=64
~420-430 MH/s
-w 64 --platform 0 -f 1
~340MH/s
Phoenix
-k poclbm VECTORS BFI_INT AGGRESSION=7 PLATFORM=0 DEVICE=1 WORKSIZE=64
~420-430 MH/s
You know there's a new poclbm version out (20110428), which is matching phoenix' speed for me.
Competition is great!
Thanks to all coders, great work.
poclbm
-w 64 --platform 0 -f 1
~340MH/s
Phoenix
-k poclbm VECTORS BFI_INT AGGRESSION=7 PLATFORM=0 DEVICE=1 WORKSIZE=64
~420-430 MH/s
...
oO
-w 64 --platform 0 -f 1
~340MH/s
Phoenix
-k poclbm VECTORS BFI_INT AGGRESSION=7 PLATFORM=0 DEVICE=1 WORKSIZE=64
~420-430 MH/s
...
oO
Is there any way for an external script to query Phoenix about current/average hashrate, via some form of RPC? It would be great to monitor these.
Would love to know if that's possible as well. I just finished hacking together a special script in poclbm where it logs the performance stats every 10 seconds to a network shared file which I is parsed by my webserver for a portable status page on my iPhone. Works great, but I feel like I'm jumping through extra hoops.
You might be interested in my other project, Multiminer, which we use for our (jedi95 and I) cluster's status page. I have a Windows download here (or you can get the source off GitHub) and it's pretty easy to run:
multiminer --admin-user=admin --admin-pass=admin101 --web-port=80 --url=http://PoolUsername:PoolPassword@PoolHost:8332/
Then change your Phoenix URLs to mmp://admin:admin101@localhost?name=NameForThisWorker (Phoenix already supports the protocol)
And finally you can throw JSON-RPC requests at http://admin:admin101@localhost - try listconnections() to see your worker status.
You can also put an index.html in "www" and have it do some JQuery magic to view your workers.
The only drawback is Multiminer doesn't have its own logs (yet), but you will know it's working when your miners pick up work and start mining through it.
In windows if you don't want to use a dummy plug you can just switch the monitor cable from the primary to the secondary and the secondary card should then be immediately visible to OpenCL apps. I would build a dummy cable cause I'm lazy and don't want to be flippin cables....
Not working on Windows 7 and catalyst 11.4. The desktop is becoming blanj and you wont be able to start any program.
Odd. Then again I tried it with 11.3 - works fine. What happens when I switch the cable to the secondary card is I get a windows desktop. The catalyst drivers should detect the secondary display and create a secondary desktop. If not you may have to manually create a desktop. Also bear in mind this is WITHOUT crossfire enabled. Crossfire may introduce additional details into the picture.
Funny cause the problem gone in Windows and FreeBSD when putting the XFire bridge
So I'm trying to run this on one of my Windows boxes and it's giving me the error "Could not locate the specified kernel!" how do I specify where it should be looking and what do I need in the directory?
You need to open the command line window and change the directory to the folder you have phoenix in. Then just type in the commands and flags posted above for the pool you are using and your video card.
That's what I was doing. Removing the -k poclbm seems to have solved the problem. If you try to specify the kernel in the windows version, even if it's the default one, it will fail. Letting it default to poclbm seems to work fine though.
I deny this
phoenix.exe -u http://1KaSXG6ncuriX2MXpsFohT7eELNQJSiS1E:[email protected]:8337/ -k poclbm DEVICE=0 VECTORS BFI_INT AGGRESSION=10
This is what in the bat file which is in phoenix-1.3 folder & it runs perfectly for me.
Win7 32
That was just to show that I'd put my info there.
Well, that seemed to fix one issue (the window that told me that the kernel wasn't patched would disappear immediately), but I'm still getting "Failed to patch kernel".
What hardware are you running? The "Failed to patch kernel" error means that applying the BFI_INT patch failed. (likely because you are using unsupported hardware)
I'm running an HD 5850 with Cat 11.4.
That's what I was doing. Removing the -k poclbm seems to have solved the problem. If you try to specify the kernel in the windows version, even if it's the default one, it will fail. Letting it default to poclbm seems to work fine though.
I think this was the answer I was looking for.
Anyway, thanks for the help guys, but the guiminer now supports BFI_INT, so I won't have to change now. Maybe I'll be back if you make more improvements.
Is there any way for an external script to query Phoenix about current/average hashrate, via some form of RPC? It would be great to monitor these.
Would love to know if that's possible as well. I just finished hacking together a special script in poclbm where it logs the performance stats every 10 seconds to a network shared file which I is parsed by my webserver for a portable status page on my iPhone. Works great, but I feel like I'm jumping through extra hoops.
Is there any way for an external script to query Phoenix about current/average hashrate, via some form of RPC? It would be great to monitor these.
Jump to: