Phoenix - Efficient, fast, modular miner

[jedi95]

How should I use this with deepbit.net pool, where usernames are emails? The @ symbol in email conflicts with @ separator between user/password and hostname.

You can just use the email without worrying about the conflict.

The following works:
-u http://address@site.com:password@deepbit.net:8332

[1713303214]

1713303214

[1713303214]

1713303214

[bolapara]

*985/900*
poclbm with f=1, ws=128: 385MH/s
phoenix 1.0 with agg=12: 377MH/s
phoenix 1.01 with agg=13 ws=128: 380MH/s

*985/300*
poclbm with f=1, ws=128: 327MH/s
phoenix 1.01 with agg=13 ws=128: 386MH/s (!!!)

ubuntu 10.10, 5870, 2.1 sdk, vectors

I was able to finally drop my memory to 300MHz without negatively impacting MH/s.

Nice work!

[eleuthria]

1.01 fixed performance issues thanks to adding worksize.  It's now performing on-par (hard to say if more/less) with poclbm, with the exception of memory underclocking!  Just like bolapara, I was able to drop memory clocks from 975/600 to 975/300 without hurting my MH/s!

UPDATE:  Gains of about 3 mHash/sec per 5870 while being able to drop memory from 600 to 300!

[Syke]

DEVICE=ID - Sets the OpenCL device to use. This isn't needed if you only have a single device.

So this miner requires you to run multiple instances for multi-gpu configurations? Why not just use all available devices by default?

[CFSworks]

DEVICE=ID - Sets the OpenCL device to use. This isn't needed if you only have a single device.

So this miner requires you to run multiple instances for multi-gpu configurations? Why not just use all available devices by default?

In the (not-too-distant) future, we'll add support for multiple kernels in a single process, like this:
-k poclbm DEVICE=1 -k poclbm DEVICE=2 -k poclbm DEVICE=3 -k poclbm DEVICE=4

It's on the agenda for me to look at, either tomorrow or Tuesday, but the kernel API supports this already.

[allinvain]

I'm wondering if there are any plans to write a guy front end for this miner? Or maybe the same folks that wrote poclbm-gui can add support for this miner?

I'm mining in a windows environment and I'd much prefer to have a GUI frontend that I can hide in the system tray instead of having a bunch of command prompts taking up space in the start menu. I know some of you will come up with arguments that I can hide the command prompts or group them, but in my opinion having the miner hidden in the system tray is a far superior solution.

[CFSworks]

I'm wondering if there are any plans to write a guy front end for this miner? Or maybe the same folks that wrote poclbm-gui can add support for this miner?

I'm mining in a windows environment and I'd much prefer to have a GUI frontend that I can hide in the system tray instead of having a bunch of command prompts taking up space in the start menu. I know some of you will come up with arguments that I can hide the command prompts or group them, but in my opinion having the miner hidden in the system tray is a far superior solution.

Yes, we had plans for a GUI from the beginning. We're concentrating on speed optimizations first, though. We'll get to a GUI in about a week.
If the poclbm-gui author(s) are interested, we'd love to work with them.

[allinvain]

I'm wondering if there are any plans to write a guy front end for this miner? Or maybe the same folks that wrote poclbm-gui can add support for this miner?

I'm mining in a windows environment and I'd much prefer to have a GUI frontend that I can hide in the system tray instead of having a bunch of command prompts taking up space in the start menu. I know some of you will come up with arguments that I can hide the command prompts or group them, but in my opinion having the miner hidden in the system tray is a far superior solution.

Yes, we had plans for a GUI from the beginning. We're concentrating on speed optimizations first, though. We'll get to a GUI in about a week.
If the poclbm-gui author(s) are interested, we'd love to work with them.

Cool stuff Yes it would be awesome of the poclbm-gui people got involved!

I agree that performance optimizations should come first. I'll be keeping a very close eye on this thread.

Best of luck with your project!

[Raulo]

I've just run it on testnet and it seems that although it correctly submits a valid solution, the hash is printed incorrectly. I've generated hash:
0000000016706426
and printed was:
[25/04/2011 8:20:18] Result: 26647016 accepted

It seems calculateHash is doing something incorrectly.

Regarding hashrate, it is not faster than poclbm on my 5850/Linux/SDK2.1/Cat10.12 at stock speed but surprisingly the fastest hashrate is with 300 MHz clock, where it is quite competitive to the poclbm stock speed and it runs much cooler (poclbm slows quite a lot at this mem speed).

Edit: The calculateHash is correct but the endianness is wrong. 26647016 = 16706426 in reverse endianness.

[jedi95]

Version 1.1 released!

This version brings a major improvement in the form of BFI_INT support. BFI_INT is a hardware instruction on newer ATI cards that allows for a 5-20% increase in hashrate. Phoenix 1.1 implements BFI_INT in the poclbm kernel by patching the binary after it's compiled, since BFI_INT is not accessible from OpenCL.

To enable BFI_INT support just add BFI_INT to the kernel arguments.


@Raulo
Thanks for the heads-up, this will be fixed in the next version.

[bolapara]

Holy crap.  Initial results are good...  But, well, I'll wait until tomorrow to tell you how effective BFI_INT (and some more OCing) are, as long as they are stable.

Feature request: it'd be nice if we had a report of the # of HW failures in the status bar as well.  Now that I'm able to push the memory speeds down I'm trying to push the GPU speeds up further and it'd be nice to see those over time.

[kindle]

Hi can this miner be used for solo mining? If so what is the command to place the ip address of the server? ie 192.168.1.2?

[CFSworks]

Hi can this miner be used for solo mining? If so what is the command to place the ip address of the server? ie 192.168.1.2?

Try this as your URL: http://rpcuser:rpcpassword@192.168.1.2:8332/;askrate=15
(Replacing rpcuser and rpcpassword, of course.)

Feature request: it'd be nice if we had a report of the # of HW failures in the status bar as well.  Now that I'm able to push the memory speeds down I'm trying to push the GPU speeds up further and it'd be nice to see those over time.

That's a very good idea, and I'd certainly like to see it myself. jedi95 and I are currently discussing the most "correct" way to do this internally (and how to manage limited status bar space, and other challenges like that)

[jkminkov]

I recommend for win7 x64 users

5870@950/600

desktop use:

poclbm -f 16 -w128 -v

hasrate 355.9
gpu usage @ 99%

phoenix -u -k poclbm DEVICE=0 VECTORS AGGRESSION=7 -v FASTLOOP BFI_INT

hasrate 382.6
gpu usage @ 97%

phoenix -u -k poclbm DEVICE=0 VECTORS AGGRESSION=7 -v FASTLOOP

hasrate 348.5
gpu usage @ 97%

request feature: instead xx Accepted can you add in output - Expected Shares Per Hour(xx Accepted)

[grndzero]

I had to escape the ;askrate on linux or else OpenCL would say it couldn't find the device.
phoenix -u http://USERNAME.WORKERNAME:PASSWORD@mining.bitcoin.cz:8332/\;askrate=12 -k poclbm DEVICE=2 VECTORS AGGRESSION=12

Standard poclbm/poclbm-mod were giving me 317Mh/s.
Phoenix was giving me 310Mh/s.
That went up to 343.5Mh/s with BFI_INT!

If you're using askrate make sure to set it properly. Calculate (type into Google) 2^32 divided by your hashrate. So mine would be 2^32/343500000=12.5035438 (so 12)

[allinvain]

Has anyone tried this on a 5970 yet? I'm presuming that since a 5970 is roughly nothing more than 2 5870s on the same PCB that this miner should work just as well. I could confirm this for myself but I'm wondering if anyone has beat me to it.

[jedi95]

Has anyone tried this on a 5970 yet? I'm presuming that since a 5970 is roughly nothing more than 2 5870s on the same PCB that this miner should work just as well. I could confirm this for myself but I'm wondering if anyone has beat me to it.

It should work no problem on a 5970, and with similar speed gains from BFI_INT. 

[Garrett Burgwardt]

Apparently your miner doesn't take the argument --platform, which is something that some people need (chooses old or new version of AMD APP). Once that's fixed I'll take a look at using your miner.

[jedi95]

Apparently your miner doesn't take the argument --platform, which is something that some people need (chooses old or new version of AMD APP). Once that's fixed I'll take a look at using your miner.

We don't use --platform, instead it's passed as a kernel argument.

Example of running 2 miners on the same host with different platforms: (my primary computer has 2 GTX 580s and a 5870)

For GTX 580 GPU0:
phoenix.py -u http://jedi95:password@192.168.1.2:8332 -k poclbm FASTLOOP PLATFORM=0 DEVICE=0 AGGRESSION=4

For ATI 5870:
phoenix.py -u http://jedi95:password@192.168.1.2:8332 -k poclbm FASTLOOP VECTORS BFI_INT PLATFORM=1 DEVICE=0 AGGRESSION=8

[jedi95]

I had to escape the ;askrate on linux or else OpenCL would say it couldn't find the device.
phoenix -u http://USERNAME.WORKERNAME:PASSWORD@mining.bitcoin.cz:8332/\;askrate=12 -k poclbm DEVICE=2 VECTORS AGGRESSION=12

Standard poclbm/poclbm-mod were giving me 317Mh/s.
Phoenix was giving me 310Mh/s.
That went up to 343.5Mh/s with BFI_INT!

If you're using askrate make sure to set it properly. Calculate (type into Google) 2^32 divided by your hashrate. So mine would be 2^32/343500000=12.5035438 (so 12)

Nice to see that BFI_INT is working for you!

As for askrate, it's not necessary with Phoenix because it maintains a work queue and only requests work when needed. Phoenix also ignores the askrate setting automatically for RPC servers with long polling support.