Phoenix - Efficient, fast, modular miner

[harm]

Is the kernel 2.2 inlcuded in the latest phoenix-miner (r111)? I am getting the same results with miner r111 and r111+2.2: 403MHash on XFX HD 5850 @ 970/300

[harm]

By the way:
I am selling two XFX 5850;)
https://bitcointalk.org/index.php?topic=34882.msg434195#msg434195

[jedi95]

Is the kernel 2.2 inlcuded in the latest phoenix-miner (r111)? I am getting the same results with miner r111 and r111+2.2: 403MHash on XFX HD 5850 @ 970/300

The phatk 2.2 kernel is included with the latest SVN revision under the name phatk2. It is also used as the default kernel in the absence of the -k argument.

[TeaRex]

The RPC code in the newest SVN version r115 is still not working right. Connections go up and down all the time with lots of idles. Maybe revert it back for the time being? I can do that by hand of course if need be but it's a bit of a hassle to maintain.

FWIW, the phatk2 kernel is exactly as fast as the r115 phatk kernel on my 6990. I measured over 24 hours with one of them on the first and one on the second GPU core of that card; there was no significant deviation in the number of shares produced by each core, less than 10 shares difference.

[jedi95]

The RPC code in the newest SVN version r115 is still not working right. Connections go up and down all the time with lots of idles. Maybe revert it back for the time being? I can do that by hand of course if need be but it's a bit of a hassle to maintain.

FWIW, the phatk2 kernel is exactly as fast as the r115 phatk kernel on my 6990. I measured over 24 hours with one of them on the first and one on the second GPU core of that card; there was no significant deviation in the number of shares produced by each core, less than 10 shares difference.

I think I found the source of the memory leak in the previous RPCClient. If it works in my testing then I will be switching it back.

As for phatk2, it's faster than the phatk kernel for me using my 5870s, but keep in mind that the 69xx cards use VLIW4 instead of VLIW5.

[jedi95]

Version 1.6.0 has been released.

Changes:
1. Added the new phatk 2.2 kernel under the name phatk2 (use -k phatk2)
2. Default kernel changed to phatk2
3. Fixed RPC memory leaks and various other bugs
4. Added a timeout to ask() within the RPC code. This will definitively eliminate idling due to protocol bugs.
5. Moved project to GitHub
6. Small change to the version number scheme

The new GitHub URL for the project is here:
https://github.com/jedi95/Phoenix-Miner

Download:
Windows binaries
Source code/Linux release (requires Python, Twisted, and PyOpenCL)

[anty]

The 1.6.0 version crashes my Ubuntu on one of my 5850. When I use the kernel on the other card, everything works fine. I now mine with phatk2 on one card and phatk on the other. This combination works.
I think it has something to do with the video output. I have the screen plugged in on the card that i mine with phatk2 with. The other one, that crashes doesn't have a screen or dummy plug.

[nomnomnom]

[...]
3. Fixed RPC memory leaks and various other bugs
[...]

Thank you very very much, I am gonna send you a bitcoin 
But I am seeing a high rate of rejects now, not sure what is going on, but usually they were ~1%.

[12/08/2011 20:22:07] [317.82 Mhash/sec] [654 Accepted] [72 Rejected] [RPC (+LP)]
[12/08/2011 20:22:07] [318.03 Mhash/sec] [674 Accepted] [53 Rejected] [RPC (+LP)]

The 1.6.0 version crashes my Ubuntu on one of my 5850. When I use the kernel on the other card, everything works fine. I now mine with phatk2 on one card and phatk on the other. This combination works.
I think it has something to do with the video output. I have the screen plugged in on the card that i mine with phatk2 with. The other one, that crashes doesn't have a screen or dummy plug.

Interesting, I too have some problems since a few days on my 2x 5850 rig, one always locks up, sometimes after 2minutes
sometimes after 12 hours. (maybe since I changed to phatk 2.x?? this was also a few days ago...hmm)
Was already thinking I have some hardware problems, switched the 5850s to phatk 1 now, lets see if this is stable again.

[jedi95]

Thank you very very much, I am gonna send you a bitcoin 
But I am seeing a high rate of rejects now, not sure what is going on, but usually they were ~1%.

[12/08/2011 20:22:07] [317.82 Mhash/sec] [654 Accepted] [72 Rejected] [RPC (+LP)]
[12/08/2011 20:22:07] [318.03 Mhash/sec] [674 Accepted] [53 Rejected] [RPC (+LP)]

The 1.6.0 version crashes my Ubuntu on one of my 5850. When I use the kernel on the other card, everything works fine. I now mine with phatk2 on one card and phatk on the other. This combination works.
I think it has something to do with the video output. I have the screen plugged in on the card that i mine with phatk2 with. The other one, that crashes doesn't have a screen or dummy plug.

Interesting, I too have some problems since a few days on my 2x 5850 rig, one always locks up, sometimes after 2minutes
sometimes after 12 hours. (maybe since I changed to phatk 2.x?? this was also a few days ago...hmm)
Was already thinking I have some hardware problems, switched the 5850s to phatk 1 now, lets see if this is stable again.

I currently have 8 5870s running on phatk 2.2. (same version included in Phoenix 1.6.0)

I have not seen any crashes or lockups since switching, so I don't think the kernel itself is broken. It might be that it stresses the GPU more than the older phatk kernel, which could explain the stability issues.

Either way, I didn't write phatk 2.2 so you may want to consider posting in the phatk thread for help.

[TeaRex]

Hello jedi95,

first I'd like to thank you for going from SVN to Git and for today's fixes and addition.

With the current (as of the time of this posting) RPC code in Git I don't get the constant disconnects and reconnects as I had with the last SVN version; but I still get far more rejected shares, up from 1 or 2% to about 10%, compared to the code from SVN r101.

Also with the current RPC code the miner at some point just stopped mining, possibly because my Internet connection is behaving a bit like a moody child today. However this time it didn't reconnect when the line came back a short time later. Maybe your new idle timeout at work here? Or is this a misunderstanding on my part, I have to admit I haven't yet checked the code.

Keep up the good work!

[jedi95]

Version 1.6.1 released.

Changes:
1. BFI_INT now enabled by default for phatk/phatk2
2. Added automatic failover to backup server if specified with -b
3. Additional memory leak fix for client3420.py
4. Fixed persistent connections

Download:
Windows binaries
Source code/Linux release (requires Python, Twisted, and PyOpenCL)

Hello jedi95,

first I'd like to thank you for going from SVN to Git and for today's fixes and addition.

With the current (as of the time of this posting) RPC code in Git I don't get the constant disconnects and reconnects as I had with the last SVN version; but I still get far more rejected shares, up from 1 or 2% to about 10%, compared to the code from SVN r101.

Also with the current RPC code the miner at some point just stopped mining, possibly because my Internet connection is behaving a bit like a moody child today. However this time it didn't reconnect when the line came back a short time later. Maybe your new idle timeout at work here? Or is this a misunderstanding on my part, I have to admit I haven't yet checked the code.

Keep up the good work!

Could you run Phoenix with the -v option and post the last few log entries before the miner stopped working? The "idle timeout" simply ensures that ask() always returns after no more than 15 seconds. The idle issue on RPC was caused by a combination of the memory leaks and ask() never running its callbacks. By fixing the memory leaks and adding a timeout to ask() it should prevent the RPC protocol from hanging.

The increase in stale shares might be due to your internet connection not working normally. It also might be due to the keep-alive issue I just fixed in 1.6.1. Try 1.6.1 out once your internet connection is working normally again and see if you still have a high stale count.

Also, I am considering forcing a failover if the miner goes idle for more than 1 minute. This will make getting stuck idling impossible, (assuming the backup server is up) since the entire protocol object is destroyed and re-created when switching servers.

[d3m0n1q_733rz]

There appears to be a problem running the phatk2 kernel on an ATI HD5450 under Windows.  It crashes the program once it starts the kernel.  I can run the kernel on my CPU (only as a test) and it works without crashing.  Any thoughts on this?  Phatk kernel works okay on it, but I would like the extra speed boost.

[jedi95]

There appears to be a problem running the phatk2 kernel on an ATI HD5450 under Windows.  It crashes the program once it starts the kernel.  I can run the kernel on my CPU (only as a test) and it works without crashing.  Any thoughts on this?  Phatk kernel works okay on it, but I would like the extra speed boost.

Have you tried specifying a WORKSIZE? The problem with phatk2 is that the kernel needs to know the worksize before it can be compiled. This prevents automatically setting the worksize to the maximum supported because that can only be detected once the kernel has been compiled. I added some code to phatk2 which checks if the worksize is supported by the device after compiling the kernel. If the worksize specified is too large then it will show an error. If setting a smaller worksize fixes the problem for you, then I will include this change in the next version.

See if specifying WORKSIZE=64 allows the kernel to run.

[d3m0n1q_733rz]

There appears to be a problem running the phatk2 kernel on an ATI HD5450 under Windows.  It crashes the program once it starts the kernel.  I can run the kernel on my CPU (only as a test) and it works without crashing.  Any thoughts on this?  Phatk kernel works okay on it, but I would like the extra speed boost.

Have you tried specifying a WORKSIZE? The problem with phatk2 is that the kernel needs to know the worksize before it can be compiled. This prevents automatically setting the worksize to the maximum supported because that can only be detected once the kernel has been compiled. I added some code to phatk2 which checks if the worksize is supported by the device after compiling the kernel. If the worksize specified is too large then it will show an error. If setting a smaller worksize fixes the problem for you, then I will include this change in the next version.

See if specifying WORKSIZE=64 allows the kernel to run.

We have ignition!  Thank you so much!  I'll try to toss a donation your way...well, once I get enough to donate.  Worksize of 128 was max.

[TeaRex]

Could you run Phoenix with the -v option and post the last few log entries before the miner stopped working? The "idle timeout" simply ensures that ask() always returns after no more than 15 seconds. The idle issue on RPC was caused by a combination of the memory leaks and ask() never running its callbacks. By fixing the memory leaks and adding a timeout to ask() it should prevent the RPC protocol from hanging.

The increase in stale shares might be due to your internet connection not working normally. It also might be due to the keep-alive issue I just fixed in 1.6.1. Try 1.6.1 out once your internet connection is working normally again and see if you still have a high stale count.

Also, I am considering forcing a failover if the miner goes idle for more than 1 minute. This will make getting stuck idling impossible, (assuming the backup server is up) since the entire protocol object is destroyed and re-created when switching servers.

Did another git pull this morning, and the stale shares issue is gone now, back to well below 1% for the last few hours. Jood job.

The miner hasn't yet locked up again so I can't tell if whatever problem that caused it is also solved. I'll add a -v as soon as I'm back at my machine tonight and then we will see.

About failover... I'm pointing the miner at my local mining proxy (cdhowie) which lives on the same machine. What do you think, should I use the same address as backup url, so even if not actually switching servers it will still reset the protocol if it's idle? Of course that wouldn't help with the proxy itself going down, but in my experience the proxy is very well behaved once you've figured out how to configure the underlying Apache for more concurrent threads and longer timeouts.

EDIT: One more thing, the phatk2 kernel produces a warning about variable t1 being defined but never used in the kernel (line 153 I think) on start-up, but then works fine as it seems. Is that normal and expected behaviour? Or am I missing out on an optimization that way?

[jedi95]

Did another git pull this morning, and the stale shares issue is gone now, back to well below 1% for the last few hours. Jood job.

The miner hasn't yet locked up again so I can't tell if whatever problem that caused it is also solved. I'll add a -v as soon as I'm back at my machine tonight and then we will see.

About failover... I'm pointing the miner at my local mining proxy (cdhowie) which lives on the same machine. What do you think, should I use the same address as backup url, so even if not actually switching servers it will still reset the protocol if it's idle? Of course that wouldn't help with the proxy itself going down, but in my experience the proxy is very well behaved once you've figured out how to configure the underlying Apache for more concurrent threads and longer timeouts.

EDIT: One more thing, the phatk2 kernel produces a warning about variable t1 being defined but never used in the kernel (line 153 I think) on start-up, but then works fine as it seems. Is that normal and expected behaviour? Or am I missing out on an optimization that way?

The t1 variable in phatk2 is a dummy to make the compiler behave a certain way. I'm not quite sure why defining a dummy variable results in better performance, but if you need more information about the OpenCL level tweaks I recommend asking in the phatk thread:

https://bitcointalk.org/index.php?topic=7964

From kernel.cl:

Code:

	u W[124];
	u Vals[8];

	//Dummy Variable to prevent compiler from reordering between rounds
	u t1;
	
	//Vals[0]=state0;
	Vals[1]=B1;
	Vals[2]=C1;
	Vals[3]=D1;

[TeaRex]

The t1 variable in phatk2 is a dummy to make the compiler behave a certain way.

I figured as much; my question was more along the lines of, if the OpenCL compiler (I use the one from the Windows Catalyst 11.7 drivers) complains about it being unused, will it still "behave a certain way" then, or will t1 just be removed and the desired behaviour doesn't happen.

Whatever, just answers this if you feel like it, I don't want to steal more of your time. Thanks again for such a great miner.

[Remember remember the 5th of November]

So, i heard that phoenix checks all the 2^32 noncespace. However i feel that the "documentation" about it is scarce at best.

What exactly are these avg samples? What are the best settings for my 5870 so i can make phoenix really scan all the nonces.

[jedi95]

So, i heard that phoenix checks all the 2^32 noncespace. However i feel that the "documentation" about it is scarce at best.

What exactly are these avg samples? What are the best settings for my 5870 so i can make phoenix really scan all the nonces.

Phoenix will automatically scan the entire nonce space as long as the server you are connecting to has some way of pushing work. (either MMP or RPC + LP) This is the reason Phoenix has a queue. When the queue size falls below the value specified with -q the miner requests more work.

The average samples are just how many samples are used for the hashrate display. Higher values will give a more stable hashrate display while smaller values will show the fluctuations in hashrate better.

Recommended settings for a 5870 right now:

-k phatk2 VECTORS BFI_INT AGGRESSION=8

You can increase AGGRESSION if you don't plan on using the computer while mining. Higher values will improve hashrate, but also increase the amount of lag. You will also need to specify which OpenCL device to run on using DEVICE=X.

[carlo]

Hello,

the failover feature seems to be a bit slow, i tested it with a iptables drop. About 1-2 minutes than the miner switched the server.
Than i removed the iptables rule but the miner didnt switch back to the primary server, maybe i didnt wait long enough.
I would like to have a parameter that tells the miner: If there are more than X idles in the last Y minutes than switch for Z shares.

And there is another question: Is AGGRESSION=16 possible for a linux dedicated miner ? Whats the max value for AGGRESSION ?

Thx for the nice miner and your support.