Phoenix - Efficient, fast, modular miner

[[Tycho]]

Looks like you aren't receiving private messages from me, so i'm writing here.

Your miner inherited an old poclbm bug (or just recreated it) - reading pool's answer takes very long time with your miner, about ~200 ms and up to 2 sec in some cases - i see this in my pool's log. When we discussed this with m0mchil, he managed to fix it and now this delay is close to 0 ms.

Two possible causes of this:
1) Python bug - reading HTTP headers by one byte at a time ( http://bugs.python.org/issue1542407 )
2) TCP_NODELAY not used (looks like the main cause).

This may also help:
http://code.google.com/p/httplib2/issues/detail?id=91
http://code.google.com/p/httplib2/issues/detail?id=28

I'm not sure which one was the fix, but something should help :)

[Posidon]

A bit of a noob question here, but is there a particular directory in Windows 7 that Phoenix must be extracted to in order for it to function.  I can't seem to get the program to open properly, it just flashes the command prompt and closes.  I currently have it extracted to my desktop.

[[Tycho]]

A bit of a noob question here, but is there a particular directory in Windows 7 that Phoenix must be extracted to in order for it to function.  I can't seem to get the program to open properly, it just flashes the command prompt and closes.  I currently have it extracted to my desktop.

There is no GUI, you should supply some command-line arguments for it to work.
Start a command prompt (cmd) or some FAR-like file manager and try to run it from there.

[Dezeer]

Should the command line report finished workunits when solo mining, like poclbm-gui does or does it only show output when it finds a block? Now it looks like it's doing "nothing" as it only shows the hashrate.

[anatolikostis]

From 266 mhash to 296 mhash - not bad, not bad !
 

[Littleshop]

Windows 7 64 bit problem here:

I extracted to c:\ph and am running the command with arguements but I get Failed to connect, retrying....

Are there other components required?

The only software on the machine is the full ATI drivers and GUIminer (which I have closed)

[stillfire]

Trying to get it to run on Mac OS X. It worked once with DEVICE=0 VECTORS AGGRESSION=7 but after stopping it to try other parameters it stopped working with the error "[25/04/2011 15:59:52] FATAL kernel error: Failed to compile OpenCL kernel!". Looking in the generated crash log there's this:

Code:

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000101fc3000
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libSystem.B.dylib                   0x00007fff87fa7506 strtol_l + 75
1   ...pple.ATIRadeonX2000GLDriver      0x000000011502632f glrCompDeleteProgram + 4895
2   ...pple.ATIRadeonX2000GLDriver      0x0000000115026535 glrCompDeleteProgram + 5413
...

[Posidon]

A bit of a noob question here, but is there a particular directory in Windows 7 that Phoenix must be extracted to in order for it to function.  I can't seem to get the program to open properly, it just flashes the command prompt and closes.  I currently have it extracted to my desktop.

There is no GUI, you should supply some command-line arguments for it to work.
Start a command prompt (cmd) or some FAR-like file manager and try to run it from there.

Looks like I figured out how to do it through the command prompt.  Thanks.

[jedi95]

Trying to get it to run on Mac OS X. It worked once with DEVICE=0 VECTORS AGGRESSION=7 but after stopping it to try other parameters it stopped working with the error "[25/04/2011 15:59:52] FATAL kernel error: Failed to compile OpenCL kernel!". Looking in the generated crash log there's this:

Code:

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000101fc3000
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libSystem.B.dylib                   0x00007fff87fa7506 strtol_l + 75
1   ...pple.ATIRadeonX2000GLDriver      0x000000011502632f glrCompDeleteProgram + 4895
2   ...pple.ATIRadeonX2000GLDriver      0x0000000115026535 glrCompDeleteProgram + 5413
...

OSX uses its own OpenCL implementation, which might cause problems if you try to use VECTORS or BFI_INT. Try running without those and see if it works.

Windows 7 64 bit problem here:

I extracted to c:\ph and am running the command with arguements but I get Failed to connect, retrying....

Are there other components required?

The only software on the machine is the full ATI drivers and GUIminer (which I have closed)

What command line arguments are you using?

[stillfire]

Oddly, I can't seem to get it to work without using VECTORS. I get a segmentation fault/bus error without it. The other weird thing is that I can't run Phoenix twice without deleting the compilation output. E.g.

Code:

$ python phoenix.py -v -u XXX DEVICE=0 VECTORS AGGRESSION=2 FASTLOOP
[25/04/2011 16:44:12] FATAL kernel error: Failed to compile OpenCL kernel!

$ rm kernels/poclbm/*.elf
$ python phoenix.py -v -u XXX DEVICE=0 VECTORS AGGRESSION=2 FASTLOOP
[25/04/2011 16:44:45] Connected to server
[25/04/2011 16:44:45] Server gave new work; passing to WorkQueue

Exactly the same command seems to work if I first delete *.elf. Very mysterious. Almost like there's a bug in pyopencl on the Mac where it fails to delete the previous object file or something like that.

Anyhow now I got it to work but unfortunately it runs at or around 50 Mhash/s instead of while Diablo miner hits 80 Mhash/s on my Radeon HD 4870. The upside is that with AGGRESSION=2 it is possible to run it in the background - with Diablo even -f 120 renders the system very jerky indeed. So maybe I'll run with phoenix for a while even at a slower rate since it's much less annoying.

Thanks for writing this. The code looks great.

[Littleshop]

Windows 7 64 bit problem here:

I extracted to c:\ph and am running the command with arguements but I get Failed to connect, retrying....

Are there other components required?

The only software on the machine is the full ATI drivers and GUIminer (which I have closed)

What command line arguments are you using?

c:\ph>phoenix.exe -u http://littleshop@miner1:mypasshere@btcmine.com:8332/ -k poclbm DEVICE=0 AGGRESSION=3
[25/04/2011 14:51:18] Failed to connect, retrying...
[0 Khash/sec] [0 Accepted] [0 Rejected] [RPC]

[stillfire]

Turns out I can get 60Mhash/s with AGGRESSION=3 on my Mac Pro without making the desktop too jerky. Feels like a nice compromise.

[BitLex]

just did a quick test on XP Cat10.12/SDK2.2

HD5570 @750MHz
poclbm -f 5 -w 128 -v gives ~72Mhash/s
phoenix VECTORS AGGRESSION=10 ~68.5Mhash/s

HD5850 @775MHz
poclbm -f 40 -w 128 -v gives ~262Mhash/s
phoenix VECTORS AGGRESSION=10 ~257.5Mhash/s

not really faster it seems,
setting Aggro higher on either card just makes the system unusable, but doesn't improve speed much.

phoenix1.1 test using WORKSIZE=128 and BF_INT

HD5570 ~76Mhash/s
HD5850 ~286Mhash/s

which is a nice improvement on that 5850,
however, the downside is a real bad ratio of 'Rejected' hashes,
>2% on the 5850 and 10% on the 5570.
 
another quick test on a different system/card (5850@900MHz) didn't improve speed at all (~313Mhash/s on both, poclbm and phoenix), which also seems kinda strange.

 

[grndzero]

another quick test on a different system/card (5850@900MHz) didn't improve speed at all (~313Mhash/s on both, poclbm and phoenix), which also seems kinda strange.

That is really wierd. My 5850's went from 317 @ 900/1000 to 343 by just changing from poclbm to phoenix.

Try dropping the worksize. I just added it to mine and it slowed it down.

[Raulo]

jedi95,

Are you going to create a git repository for phoenix? It would be much easier to track changes. I also did some local modifications (e.g., I run the miner with difficulty 1) and it would be much easier to apply them with git.

[ghost]

I was just going to mention the usefulness of a git repo. +1 from me

[TenthReality]

Seeing a much higher rejection rate here, most specifically when the LP hands off a new piece of work.   More than 50% of the time when that happens my first result is rejected. The same appears to be holding across 6 cards (5970 down to 5830's).  Copy/paste of results w/ pruning is as follows:

Code:

[25/04/2011 16:59:38] Result: 6a71879e accepted
[25/04/2011 16:59:57] LP: New work pushed
[25/04/2011 17:00:06] Result: 01b8fa68 rejected
[25/04/2011 17:00:13] Result: bf28fa45 accepted
*snip*
[25/04/2011 17:02:06] Result: 13646ef1 accepted
[25/04/2011 17:02:16] LP: New work pushed
[25/04/2011 17:02:26] Result: 9bc866ef rejected

[JWU42]

I am at about .7% rejected -- more than I would like to see 

[TenthReality]

Math wise, the extra rejected are being massively offset by the increased speeds of the hashing.  Still seeing about 11% over just poclbm even with the rejection rates.

[CFSworks]

Looks like you aren't receiving private messages from me, so i'm writing here.

Your miner inherited an old poclbm bug (or just recreated it) - reading pool's answer takes very long time with your miner, about ~200 ms and up to 2 sec in some cases - i see this in my pool's log. When we discussed this with m0mchil, he managed to fix it and now this delay is close to 0 ms.

I'm the primary maintainer of all the code in the minerutil package, which looks like it may be the culprit. Did you send me a PM too? I didn't get one either.

Two possible causes of this:
1) Python bug - reading HTTP headers by one byte at a time ( http://bugs.python.org/issue1542407 )
2) TCP_NODELAY not used (looks like the main cause).

What's interesting is RPCProtocol doesn't use any Python HTTP libraries, it's all done through Twisted;
so while it could be a problem in Twisted, I don't think the linked bug is the answer.

The lack of TCP_NODELAY is interesting. Doesn't that only disable Nagle's algorithm, which affects sends?
How would it delay received data?