The latest version (2011-08-04) has a major problem that I can see.

The assumption that there won't be more than 1 valid nonce per kernel execution is very wrong. At aggression 14 for example each kernel execution tests 2^30 nonces. The chance that there will be more than 1 valid nonce in any given kernel execution in this case is going to be about 2.5% (if I did the math right) This effectively causes a net loss in performance compared to the previous version at high aggression. At lower aggression values (10 and below) this is less of a problem since the performance loss in these cases will be much less than 1%.

Phoenix 1.5 includes the phatk kernel by default, unlike 1.4. Just use the included one. If you want more performance, phatk r112 from the Phoenix SVN is even faster.

I would start with the RPC code, including the modified Twisted.web library. I run my miners through MMP, and I usually run them for weeks at a time with >100,000 accepted shares between restarts. I don't see any performance problems or memory leaks running with MMP.

Phoenix is designed for Python 2.6/2.7. That is most likely the cause of your issue.

Odd, I'm running phatk r112 on 4 5870s and a 5830. The hashrate is slightly higher than what I get with r111.

I didn't make these particular changes to phatk, see this thread:
http://forum.bitcoin.org/index.php?topic=25860.0

Keep in mind that OpenCL kernel changes have NO effect on stale shares (aside from the VERY small difference in time it takes to run 1 execution of some number of hashes) All nonces found by the kernel to satisfy H == 0 are verified on the CPU prior to sending. Shares are also checked against the current known block before sending, in case new work was received while the kernel was executing. Basically this means that every share sent to the server is valid as far as the miner is concerned. If the OpenCL kernel is returning bad work it will never be sent to the server, and instead you will get "Unusual behavior from OpenCL. Hardware problem?"

That said, changes to the python portion of a Phoenix kernel can increase stale shares if badly implemented. (see: FASTLOOP excessive stales with high aggression in older versions of Phoenix)

The rewrite for the RPC protocol is finished, and has been uploaded to the SVN.

It works fine in my testing, but more feedback would be great before pushing this as a new version. This SHOULD definitively fix the idle problem, since that was related to the old RPCProtocol.

Nice work! With these changes I was able to finish a complete RPCProtocol including long polling. Let me know what address you want payment sent to.

I don't like how poclbm works, since it sends and recieves work in the same thread. This means that if sending results stalls for even a few seconds, the miner is unable to get more work. This is made worse by the fact that poclbm lacks a queue, so it doesn't have a buffer of work for when this occurs.

This is one of the main reasons I decided to make another miner.

Well, I have no idea what's going on there. If you were having the problem described above your CPU load would be pegged at 50% (1 core out of 2 at 100%) regardless of miner settings. I don't know how it can end up using more CPU at higher aggression, since there are fewer kernel executions per second. On miners without the 100% problem the most CPU usage I have seen is 2-3%

Are you mining on a pool with long polling?

If not, then that explains things. Phoenix doesn't have an askrate by default, so without long polling slow miners end up wasting a ton of time on stale work. The fix is to alter the command line to use an askrate.

example:

-u http://name:password@pool.com:8332/;askrate=10

This would set an askrate of 10 seconds.

I'm not sure how to do this in GUIminer though.

That might be tough since phatk doesn't work very well on older SDK versions. It was designed to be used with SDK 2.4, and on 2.1 I get better results with poclbm. The Ma() changes also apply to poclbm, so you won't see a gain there.

The keep-alive connections are required for stable operation on some pools due to anti-DDoS protection. Without keep-alive the miner makes a new connection for each getwork() as opposed to re-using the existing one. A good example is Slush's pool, which many users were having problems with prior to adding keep-alive. The current RPCProtocol implementation uses the Twisted.web library, which does not support keep-alive. CFSworks "hacked-in" keep-alive support for Twisted.web so that we could continue to use it. However, I suspect that the idle issues people have been having with Phoenix are caused by a bug in this modification. All my miners run through MMP and I have yet to see a single idle problem, which eliminates the rest of the components as the source of the problem.

Basically, what I want is a new RPCProtocol that doesn't use Twisted.web.

Nothing can be done on my end. For Windows if you have more than 1 ATI GPU installed each instance will peg one CPU core at 100%. There is some stupid event loop in ATI's driver. The best way to minimize the problem is to change the process affinity so that all the instances run on the same CPU core. This doesn't reduce hashrate at all.

My post was mainly intended to clarify that stale shares are not a good measurement for kernel changes.

A much more reliable test would be to count the total number of shares submitted over a long period (say 24 hours or so) This includes stales, since the goal is to test how many shares the kernel finds, not how many the server accepts. If this number is higher than without the kernel modifications, you know that it's helping.

For the past week I have been working on a new RPC implementation for Phoenix since the current one has several issues I have not been able to fix. It doesn't help matters that the original RPC code author, CFSworks, has been MIA for awhile now.

So I decided to rewrite the RPC code, without using the Twisted.web library. I think most of the issues with the current RPC protocol are due to the hacked-in support for keep-alive.

Anyway, what I have right now is basically an adaption of poclbm's RPC code to Phoenix's interface. It makes use of the Twisted library, but only for handling threads/deferreds.

The 6 BTC bounty will go to whoever can write code that meets the requirements below. You can use what I have or write it from scratch, so long as it meets the requirements. The current code successfully connects and gets work, but it doesn't correctly send shares back. Obviously the code must be distributed under the X11 license like the rest of Phoenix. The bounty is payable immediately to the address of your choice once I can confirm that the code meets the requirements.

Requirements:
1. Calls to requestWork() and sendResult() must not block while sending/receiving requests from the RPC server. (these don't need to be thread-safe, they are always called from the main thread)
2. For sent work, a boolean must be returned to the caller of sendResult() indicating accepted/rejected.
3. Sending and receiving work should use separate connections. (but only 1 each, to keep pool load down)
4. Sending and receiving work must not block each other.

Existing code:
http://xp-dev.com/svn/phoenix-miner/branches/NewRPC/RPCProtocol.py

Networking code isn't a strong point of mine, and I just don't have the time to do this myself.

Stales have nothing to do with GPU errors in Phoenix. All results returned by the GPU are verified before being sent to the server, which means if the kernel finds invalid shares you will get "Unexpected behavior from OpenCL. Hardware problem?" instead of the share being submitted. If you are not getting any of these errors there is NO WAY a kernel change can affect the number of stale shares. It might affect the total number of shares submitted in a given time period, but every share sent to the server by Phoenix is verified to be H == 0 on the CPU beforehand.

There is no point trying to run phatk on pre-2.4 SDK versions. It will just end up being slower than the poclbm kernel.

For mining I see only 2 real options:
SDK 2.1 with poclbm
SDK 2.4 with phatk

2.2 is slower than 2.1 on poclbm and doesn't work well with phatk either.
2.3 is even slower than 2.2 on poclbm, but all I know with phatk is that it's slower than with 2.4

Anyway, getting the output from the compiler is very simple. You just need to comment out the try/except block surrounding self.loadKernel().

This isn't exactly a fair comparison since phatk was specifically targeted at VLIW5 GPUs on SDK 2.4. A better comparison would be against phatk without this modification.

This has been on the SVN since Monday, and since kernels are not part of the compiled binary I'm not planning another release until I finish the RPC re-write.