Phoenix - Efficient, fast, modular miner

[jedi95]

Version 1.50 has been released.

This should fix the miner getting stuck idle. I added a workaround for now since I am not 100% confident that I fixed the underlying problem.

Changes:
1. Fixed long poll crashing when the server disconnects the miner with a message
2. Fixed QueueReader error when stopping the kernel
3. Several RPC protocol changes to reduce occurrence of idle miner problem
4. When idle the miner will now request more work every 15 seconds (this should eliminate idling in cases where the connection isn't lost)
5. LP now works in cases where the URL uses a query string (thanks to error for the patch, see page 30 for details)


@SchizophrenicX

You need to add the port after the server:

http://username.workername:workerpassword@api.bitcoin.cz:8332

[1714212424]

1714212424

[1714212424]

1714212424

[1714212424]

1714212424

[BitMinerN8]

Version 1.50 has been released.

Thanks! I'll start updating the farm. 

[Nachtwind]

I tried it...

Code:

2011-06-15 02:29:22: Wird ausgeführt: E:\bitcoin\guiminer\guiminer\phoenix.exe -u http://xxxx:xxxx@btcguild.com:8332 PLATFORM=0 DEVICE=0 VECTORS  AGGRESSION=5 -v FASTLOOP=true  BFI_INT -k phatk 
2011-06-15 02:29:22: Listener für "btc" gestartet
2011-06-15 02:29:26: Listener für "btc": [15/06/2011 02:29:26] Finding inner ELF...

From that moment onwards there was 5 minutes with nothing happening (yet still showing MHASH in the Gui(miner 06-09). ALso the MH was at about 180 compared to 200 with the 1.48 release...

System Specs:
Intel COre 2 Duo 2160
1x ATI 6850
4GB RAM
Windows 7 x64

Guess i will stick with the previous version and hope this might post was useful ,0)

[jedi95]

I tried it...

Code:

2011-06-15 02:29:22: Wird ausgeführt: E:\bitcoin\guiminer\guiminer\phoenix.exe -u http://xxxx:xxxx@btcguild.com:8332 PLATFORM=0 DEVICE=0 VECTORS  AGGRESSION=5 -v FASTLOOP=true  BFI_INT -k phatk 
2011-06-15 02:29:22: Listener für "btc" gestartet
2011-06-15 02:29:26: Listener für "btc": [15/06/2011 02:29:26] Finding inner ELF...

From that moment onwards there was 5 minutes with nothing happening (yet still showing MHASH in the Gui(miner 06-09). ALso the MH was at about 180 compared to 200 with the 1.48 release...

System Specs:
Intel COre 2 Duo 2160
1x ATI 6850
4GB RAM
Windows 7 x64

Guess i will stick with the previous version and hope this might post was useful ,0)

That's odd, the BFI_INT patcher hasn't been changed since 1.0 so I don't see how updating could break it. Does it work if you don't use the BFI_INT flag?

[BitMinerN8]

I tried it...

Code:

2011-06-15 02:29:22: Wird ausgeführt: E:\bitcoin\guiminer\guiminer\phoenix.exe -u http://xxxx:xxxx@btcguild.com:8332 PLATFORM=0 DEVICE=0 VECTORS  AGGRESSION=5 -v FASTLOOP=true  BFI_INT -k phatk 
2011-06-15 02:29:22: Listener für "btc" gestartet
2011-06-15 02:29:26: Listener für "btc": [15/06/2011 02:29:26] Finding inner ELF...

From that moment onwards there was 5 minutes with nothing happening (yet still showing MHASH in the Gui(miner 06-09). ALso the MH was at about 180 compared to 200 with the 1.48 release...

System Specs:
Intel COre 2 Duo 2160
1x ATI 6850
4GB RAM
Windows 7 x64

Guess i will stick with the previous version and hope this might post was useful ,0)

That's odd, the BFI_INT patcher hasn't been changed since 1.0 so I don't see how updating could break it. Does it work if you don't use the BFI_INT flag?

For testing I have put this on a number of rigs (4 of 12) in my farm and am not having any issues like you are describing. I am not using GUIMiner though, just running it through command prompt/script. All my mining rigs are extremely clean, just Win7 x64 w/SP1, the ATI Drivers with only the AMD APP/SDK selected, then I use ATI Tray Tools for the OC. Set to autologin and run the scripts. Options:
-k phatk PLATFORM=0 DEVICE=1 VECTORS BFI_INT FASTLOOP=false WORKSIZE=128 AGGRESSION=11

[Clipse]

Heres a pickle, I seem to get 3mhash on the dot less on 4 rigs i just updated with 1.50 from 1.48 with same arguments used.

Retried with 1.48 and hashrate went up exactly 3mhash o_0

Is there a reason for the slight drop, or is 1.48 reporting wrong hashrate ?

[brunoshady]

I tried it...

Code:

2011-06-15 02:29:22: Wird ausgeführt: E:\bitcoin\guiminer\guiminer\phoenix.exe -u http://xxxx:xxxx@btcguild.com:8332 PLATFORM=0 DEVICE=0 VECTORS  AGGRESSION=5 -v FASTLOOP=true  BFI_INT -k phatk 
2011-06-15 02:29:22: Listener für "btc" gestartet
2011-06-15 02:29:26: Listener für "btc": [15/06/2011 02:29:26] Finding inner ELF...

From that moment onwards there was 5 minutes with nothing happening (yet still showing MHASH in the Gui(miner 06-09). ALso the MH was at about 180 compared to 200 with the 1.48 release...

System Specs:
Intel COre 2 Duo 2160
1x ATI 6850
4GB RAM
Windows 7 x64

Guess i will stick with the previous version and hope this might post was useful ,0)

try the command like this, yours is very confused...


phoenix -v -u http://xxxx:xxxx@btcguild.com:8332 -k phatk DEVICE=0 VECTORS BFI_INT AGGRESSION=5

[innervisi0nn]

[14/06/2011 22:23:17] Phoenix 1.50 starting...
[14/06/2011 22:23:17] Connected to server
MSG: upstream RPC error
[14/06/2011 22:23:40] Disconnected from server
[14/06/2011 22:23:54] Warning: work queue empty, miner is idle
[0 Khash/sec] [0 Accepted] [0 Rejected] [RPC]

getting that issue...only with 2 pools tho, any idea?

[d.james]

new version works flawlessly with the phoenix rising guiminer here

[Nachtwind]

Ok, started without BFI_INT and with commands put together like suggested:
It seems to be doing "Something".

Code:

2011-06-15 08:36:09: Listener für "btc" gestartet
2011-06-15 08:36:10: Listener für "btc": [15/06/2011 08:36:10] Phoenix 1.50 starting...

Then nothing (no more console output) - but my shares on BTCGuild are increasing. Yet without BFI_INT i have a performance drop of roughly 20% to 25%

Now with BFI_INT and commands put together in the new order there is still no console output but it seems to work with about 5% less MH (compared to 1.48).



In case you dont see a reason for your software behaving that odd - i have a shitload of SDKs on this PC and there might be something interfering somewhere... wouldnt be the first software...

[niooron]

Sometimes I still get stale shares after a LP notification. Is the queue bug still unfixed?

[jedi95]

Sometimes I still get stale shares after a LP notification. Is the queue bug still unfixed?

This can happen if the share was already being sent when the LP request returned a new block. Shares are checked against the current block before being sent, but after that there are no further checks.

[bongo]

1.50 works well , stales have come down a bit 

[SchizophrenicX]

Version 1.50 has been released.

This should fix the miner getting stuck idle. I added a workaround for now since I am not 100% confident that I fixed the underlying problem.

Changes:
1. Fixed long poll crashing when the server disconnects the miner with a message
2. Fixed QueueReader error when stopping the kernel
3. Several RPC protocol changes to reduce occurrence of idle miner problem
4. When idle the miner will now request more work every 15 seconds (this should eliminate idling in cases where the connection isn't lost)
5. LP now works in cases where the URL uses a query string (thanks to error for the patch, see page 30 for details)


@SchizophrenicX

You need to add the port after the server:

http://username.workername:workerpassword@api.bitcoin.cz:8332

Nope. Didn't work. seriously. am I the only one kept having problems keeping a dedicated rig running 24/7 I really need some help

[RedLine888]

Much less stales after update! Thanks!

What is so unique in hashskill that makes it faster than Phoenix+Phatk?

[jedi95]

Much less stales after update! Thanks!

What is so unique in hashskill that makes it faster than Phoenix+Phatk?

My guess is that hashkill has less overhead from host <--> device transfers:

Another thing is (don't know if that's possible with pyopencl) - don't use clenqueuereadbuffer() (or whatever it's equivalent is). Use clenqueuemapbuffer() instead. It's noticably faster. Hm really started wondering about modifying some python miner to incorporate that kernel there, looks like a quick way to make it portable to windows. Besides, there are obvious problems with the non-ocl part which are due to code inmaturity.

I have looked at the hashkill OpenCL kernel in AMD's KernelAnalyzer and theoretically it should be the same speed as phatk on SDK 2.4

[Mousepotato]

Awesome! 1.50 totally eliminated the "miner is idle" lines I was seeing every so often!

Edit: I take that back.  I"m seeing the "miner is idle" lines again, although less frequent than before.

[dikidera]

Hmm, for me, i see a drop of 2 Mhash/s with 1.50. Not something to kill for, but 2 mhash/s more is the equivalent of 5 mhz overclock for me.

[jedi95]

Awesome! 1.50 totally eliminated the "miner is idle" lines I was seeing every so often!

Edit: I take that back.  I"m seeing the "miner is idle" lines again, although less frequent than before.

The problem that was fixed in 1.50 was the miner getting stuck idle due to a bug in the RPC protocol. You will still get "miner is idle" from time to time, but it shouldn't get stuck idle unless it can't connect to the server.

[Peao]

First, congratulations for keeping the good work jedi95! I already sent another donation.

I noticed a decrease in cases of miners remain stuck after a warning of "miner is idle".

But some still get stuck... Normally my rigs with Ubuntu (maybe it's a coincidence, but W7 rigs are running fine).