I am implementing stratum first up as I believe going forward that it is the better suited protocol for pool mining based on a number of things I won't go into again here. The major disadvantage to stratum is that it needed a rewrite of great chunks of cgminer to work as it worked outside the bounds of all the machinery cgminer had in place for http communication and the very complex network scheduler that I had written into cgminer to make it scale. GBT is yet another competing standard which seemed to be designed  as a drop-in replacement for getwork that shared some of the ideas with it, and in the process, took on some of its disadvantages. So in actual fact it's less work to implement GBT, and while it claims to offer a lot more "features", none of those features are remotely relevant to how most of us mine. So I'm implementing stratum first as a show of support for what I believe is the better protocol.

Now Luke-jr has claimed, in his usual FUD way, that stratum is "bad for bitcoin" which is right up there for his standard of crap accusations. It seems the only reason he's so vehemently against stratum is that it was a competing protocol to what he was working on, and therefore anything he didn't do must be wrong in his eyes. As I said above, any extra features of GBT are going to be largely irrelevant to miners and there is not any point implementing them. On the other hand, GBT is yet another communication protocol that some pools are already supporting (basically because they're using his pool software so they get it by default). So in the future, after I release a stratum supporting version of cgminer, I will be implementing my own GBT support for the purposes of maintaining maximum compatibility with pools. Provided I have the time, I'm not planning on taking his code if I can help it.

Now you can try and hold Luke-jr to task over this and if he firmly believes stratum is bad for bitcoin, then he should not try and copy my implementation of it into his hostile fork and actually differentiate his software from mine, withholding support for stratum. However, he has shown that with scrypt for example, even though he was firmly opposed to litecoin mining, he took my implementation of it into his software because he was afraid he would lose his audience.

Within a few milliseconds of posting this I expect him to come and spam my forum thread with all sorts of bullshit rebuttal for what I just posted but he will do precisely what I predicted with pulling in my stratum code regardless. I have him on ignore in this forum, as I find wasting energy dealing with him absolutely pointless.


As for the selection of work, cgminer can detect stratum from either the way you input it ( stratum+tcp:// ) or if you put a stratum url in by mistake as http:// or with no prefix it will test to see if it's a stratum url first, or if the pool advertises stratum support in the getwork response it will automatically switch to it by itself. So if it all goes according to plan it should all just happen automatically.

I simply kept the poclbm name in that kernel because that's where it evolved from. The poclbm kernel in cgminer is nothing like poclbm's own kernel any more.

As expected, implementing stratum was very much a huge change affecting multiple areas of cgminer.

Summary so far:

After a week of hacking on it, it's about 1000 new lines of code in its first rough cut working version. It's been a lot of work to implement, and rather rewarding to see it working in action. There is currently a stratum branch in the git repository which includes the changes to date for the brave who wish to give it a go. Given the magnitude of changes, breakage is likely so it will be a while before the code settles down enough for me to feel comfortable releasing a version of cgminer including it.

https://github.com/ckolivas/cgminer/tree/stratum

Making it halfway through the stratum protocol, I've decided that each mining notify message will be counted as the equivalent of a getwork. Of course efficiency is increasingly becoming a figure that is of not much use to miners and pool ops alike, but perhaps a target efficiency will be the endpoint of tuning what variable diff to set it to.

This may well be the most important  part of the argument. If it's of no detriment to the pool, and is only the effort required to implement it, and it's of benefit to the miner, then I can only see an advantage. No need to set the protocol in stone at this early a stage. I'll implement whatever it is, but as I said earlier, I saw it kano's way.

Should yes, but it will take some experimenting to get the parameters correct.

All I can say is

http://www.youtube.com/watch?v=BNsrK6P9QvI

http://www.youtube.com/watch?v=j_oUjMxR0YU

To be fair, I had exactly the same discussion with Eleuthria but I had bigger fish to fry and stopped caring about it. He or slush can come and defend why they think it's ok. I'll work around the protocol whatever it is.

Just had to correct it for you

This is how to engage the community with good will, and since good hardware deserves and is dependant on good software, appreciating the value the free software developers provide is critical. Well done.

scrypt is very memory intensive and the response to changes in clock speeds will be unpredictable. You may find keeping your memory clock at full speed and lowering engine clock will lower temps without affecting hashrate as much. Scrypt gpu mining is weird voodoo.

Same code manages dynamic on scrypt so theoretically should work just as well.

If you set the 7950 to dynamic intensity mode, you will be able to game without a problem without needing to disable it.

That's what I was referring to.

I haven't decided what to do with the efficiency metric. Either I'll make up something or just not use it.

You  do not mine with the hardware itself... you use it to attach FPGAs to mine with.

Oh I see.  Maybe has a shorter rolltime set, dunno. Anyway soon with stratum and friends all these statistics become irrelevant.

You missed the point then. If your average difficulty is 9 then your effective efficiency is 356.4 * 9.

If you're mining at higher difficulty, you need to take that into account because at diff 3 for example you'll be getting 1/3 the accepted amount and that's normal.

Regarding stratum, I have been working on it. It is very much a non-trivial task to do in c so it's taking a while and I'm progressing very slowly and cautiously. Furthermore, the work generation is totally orthogonal to the current cgminer network scheduler I spent so much time creating, so it needs to rip great big holes into the current code to circumvent it. There's a stratum branch in my git tree if people want a peek but it's just code in progress and unusable.

Much appreciate the donation

My own server is not a problem, it's me sending heaps of uploads there that is the rate limiting step and no matter where I send them the same issue occurs. Thanks though.

Yes there is, but you will need to use a combination of parameters to these options: -d, --remove-disabled, --gpu-platform and --gpu-map. Start with 'cgminer -n' to read  what cgminer finds and then read the advanced section on gpu-map in the readme.