To get the best of both worlds, if difficulty rises, cgminer submits all jobs from the previous stratum base at the previous lower difficulty. If difficulty drops, cgminer submits *all* work at the new lower difficulty. That way the miner can't lose any shares that the pool might accept, at the risk of one or 2 extra rejects.

Who said cgminer doesn't do this already?

I'm in agreement difficulty not being tied with work on stratum is a problem. However the harm in it is greatly alleviated on other pools which quickly converge to one difficulty target. I think I confused EMC's behaviour with stratum with its GBT behaviour, so ignore that claim about it on GBT, sorry.

I found after a physical move I had to readjust all my overclocking settings. Not sure why but the settings which used to be stable no longer are. I find the less I disturb the rig itself and the less downtime it has, the more stable it is. Starting it up again after downtime is the most precarious time of all and when I've had hardware failures as well.

There is no guarantee of serialising of data sent/received so the mining software has to handle it asynchronously and should be able to cope with a few queued messages at once. Most pools currently implementing stratum do give difficulty changes back to back with new work information. The only vardiff pool which currently seems to have its variable difficulty fluctuating wildly is EMC. The others seem to be solid after a very short period of adaptation. I did ask Inaba about hysteresis in his calculations for var diff and he insisted it was there, but the amount of diff changes I see on EMC have been enough for me to not mine stratum there. As far as I can see, this problem occurs on EMC with GBT as well.

In cgminer's case, if the difficulty has risen, it still submits the shares of lower difficulty if it was already work in progress. This ends up creating a little burst of rejects when diff rises. If the difficulty has dropped since the work was done, cgminer retargets to the new difficulty. Regardless, the separation of work and difficulty means there are still issues, but I have tried my best to alleviate the loss to miners in cgminer.

EMC is local work of both GBT and stratum
Bitminter has local work of GBT in testing and stratum under development

Thanks for testing

New version - 2.9.4, 19th November 2012

Bugfixes. This should push this version up to the status of current stable release.


Human readable changelog

Fixed the elusive stratum disconnect windows crash bug.
Fixed mining stratum on EMC.
Fixed mining GBT on bitminter.
Provided preliminary support for balance and loadbalance with stratum and GBT.
Provided support for numeric IPV6 stratum support.
Don't shoot GPU speed up to max when the temperature drops dramatically.
Quieten the pool not responding messages for backup pools.
Flush more work on longpoll that we may have been leaving behind.
Fixes to build on windows.
Support for fractional diff values with stratum.


Full changelog

- Provide rudimentary support for the balancing failover strategies with stratum
and GBT by switching pools silently on getwork requests.
- Convert remaining modminer and bfl uses of usleep to nmsleep.
- Convert libztex to nmsleep where possible.
- Convert unreliable usleep calls to nmsleep calls in ztex driver.
- Support workid for block submission on GBT pools that use it.
- Provide rudimentary support for literal ipv6 addresses when parsing stratum
URLs.
- Work around libcurl cflags not working on hacked up mingw installations on
windows.
- Only increase gpu engine speed by a larger step if the temperature is below
hysteresis instead of increasing it to max speed.
- Convert pool not responding and pool alive message on backup pools to verbose
level only since they mean a single failed getwork.
- Update work block on the longpoll work item before calling restart threads to
ensure all work but the longpoll work item gets discarded when we call
discard_stale from restart_threads.
- Do not attempt to remove the stratum share hash after unsuccessful submission
since it may already be removed by clear_stratum_shares.
- Check against a double for current pool diff.
- Support for fractional diffs and the classic just-below-1 share all FFs diff
target.

Hmm under " Submitting shares" on https://en.bitcoin.it/wiki/Getblocktemplate#For_developers I see no mention of a  workid value. What is this workid value?

EDIT:  We discussed this on IRC and came to a resolution. cgminer 2.9.4 should be good to go with GBT on bitminter.

A workid with what? With the block submit? There is an id sent, and it matches that which the request for a template went out with. Yes, it's always zero... is that the problem? The data is all completely reconstructed for a block submit so the actual id of where the template came from doesn't seem to be relevant to any other pool. Is this the issue for you? I'm just trying to understand...

Thanks 

Try one of these builds again:
http://ck.kolivas.org/apps/cgminer/temp/

Interestingly if this is the actual bug, it should be possible to hit it on linux as well, but it seems to be much harder to hit because linux can easily tell when the socket has dropped out.

It's a long shot but try the latest builds here (without verbose):
http://ck.kolivas.org/apps/cgminer/temp/

That is most interesting guys, and at least gives me a lead! I appreciate your testing and input. This is what free software and open development is about.

Well, anyone got any bright ideas about windows and stratum? Disabling threading didn't help, debug versions spit out no debug info, and it's not like I can just tell people to fuck windows off and start mining only on linux. Even after ASICs arrive, someone somewhere will still want to mine with windows.

Windows people, any ideas? Was there a version with stratum that was stable for you across multiple disconnections?

How is this thread different to https://bitcointalk.org/index.php?topic=120214.0 ?

Actually yasm is a red herring. It does nothing on windows builds since it is only for 64 bit linux cpu mining support.

The libcurl requirement DID change at around 2.8, due to new requirements for stratum support, but they're not the problem you're running in to. The real issue is that support for compilation on *BSD was added recently to cgminer, and unfortunately that broke compilation directly on windows mingw32 compilation. I didn't notice because I now compile the mingw binary via a cross-compiler on linux. So it's not a problem at your end. When I can get back to code soon I will try and address this issue... but then there are other problems with cgminer on windows in 2.9.x, to which I do NOT have a good explanation for yet... God I hate windows.

Your stratum and dynamic difficulty appear to be working very nicely. Well done. The nice thing about your vardiff is that once it has found the right difficulty it does not fluctuate. This is important with stratum because of the potential for lost work +/- rejects across difficulty changes, which I see alot of with EMC for example. You also seem to have made good inroads into the speed of block change detection closing the gap on slush markedly.

The clock raising to the max was put in there to workaround a problem with the driver where it drops to low power during any relatively idle period and even if you try to set it to high speed it ignores you, and the return values from the driver reporting back its current speed get stuck at low speed confusing the feedback mechanism.

I'll think about a possible workaround, when time permits me to code once more.

Doesn't really cut if for spilling of work to all the backup pools and other failover strategies. If the shit going on at the moment ever calms down I'll look to just do it silently and not call the backup pools dead visibly.