Yup, just like that.

Press CTRL+F5 or whatever to force a refresh. Maybe I'll create a real page some day .. :)

Veox selectively pulls from my branch, at least he used to when I was more active. Regardless, this is a minor change to the client and it is easy to implement.
I'm more worried about the stratum server software, if this exploit really is so widespread.

Regardless, I made a quick fix to my branch and the binaries on my page are also updated.
https://github.com/Kalroth/cgminer-3.7.2-kalroth/commit/d78f8c896010049a06275db13a2816c0e201e41e
http://k-dev.net/cgminer/

There's not much I can do other than disable the reconnect code, which several individuals already have done.
I'll do a quick update of my github and binaries soon enough.

From a quick glance, it looks like someone found a way to send a spoofed* JSON packet to stratum pools, which makes the pool send a redirect request to (some of?) its clients.
It does not look like it's a bug in the client software, merely an unfortunate feature.

* http://en.wikipedia.org/wiki/IP_address_spoofing

Compare your rejected percentage with the rest of the pool (the blue line in the reject graph).
You're not alone in seeing high rejects at the moment.

Well it would be spot checking every pool in the list, so it'd favor no pool really - and it would almost certainly not be properly balanced between the pools.

That is probably the closest you'll get to a fair measurement of pools - assuming the rigs are identical, stable and run from the same location.

Both sgminer and my custom cgminer fixes this issue - at least I think it does.
I assume you've got at least one R9 290 in your setup?

Load balancing is just a waiting connection to all pools in your pool list. Work is then round robin rotation based on pool work quota, meaning each pool simply takes a turn. But there are also other factors in the work quotas, a disconnect will reset the pools quota, and I believe it adjusts quota based on rejects too.

I used to run load balancing between two servers and it was never 50/50, even over a long period. If you want to measure pools correctly, the load balancing isn't going to work. You'll have to setup a separate cgminer instance for each pool, preferably with identical performing card for each pool.

From what I could gather earlier on IRC, the untracked stratum rejects are caused by a bug in cgminer and it doesn't not affect your accepted hashrate.
Terk checked some dudes stats, and even though said person had 40-50% rejects out of ~600Kh/s, his stats page showed ~600Kh/s accepted.

Check your statistics page and see if it matches what your client is saying.

I imagine you just specify --quota or -U instead of --url or -o. eg.
instead of

Did you set load-balance to true?

Yes, that config was to avoid using fail over (default pool setting) to see if it was the cause of the untracked shares.

I got a lot of those untracked shares when I was experimenting with a non-load balancing setup today.

You can emulate a fail over setup with load balancing by using zero quotas, like this:

With this setup, the pool with 1 quota will always be used, unless it fails - then it'll fall back to the 0 quota pool(s) in the list.
Remember to specify load-balance in your config (or command line parameters).

What I indicated was that the client will pick the settings if supplied from the server. If they are not sent by the server, then it'll of course roll back to local settings.
I am talking about this setting in particular: https://en.bitcoin.it/wiki/Getwork#rollntime

Likely because your ISP is sending your packets through a shoddy route.
I get a 27ms ping and without any time outs.

You can try monitoring the route with something like WinMTR: http://winmtr.net/

You can safely delete all three settings from your configuration file. At least until someone proves me wrong. :)

I get my information straight from the source code.

If you open util.c and find the function named json_rpc_call(), there's a parameter named rolltime. That is an outgoing parameter is set by a server-side value from the JSON RPC.
Now back to cgminer.c, where you can then follow "work->rolltime" around in the code and see how it's being compared to both the expiry setting and scan-time setting and in both cases, the server-side value is chosen over the local setting as long as it is largest.

This is all based on the source code, but I have of course also tested the settings with different values myself and I found no measurable differences.

http://en.wikipedia.org/wiki/Correlation_does_not_imply_causation.

I'd like to see if anyone else here gets 35% higher WU and half their reject ratio just by changing the default settings. Or to reverse it, if people get a 35% lower WU and double the reject ratio by using the default settings. Because those values sound a little suspicious to me - but seeing as I know nothing about your setup or testing methodologies, I can't really refuse them.

I don't know the inner workings of Terks pool setup, it is likely be something entirely else. There is a lot of work going on behind the scenes; multiple coin stratum servers with a proxy redirecting people to the right internal server, adjusting worker count based on coin difficulty, storing share results, importing exchange trades, etc. etc. I've got very little experience when it comes to the actual operation of a mining pool, so all I really can do is to make a bunch of assumptions and that won't help anyone.

All I do know is that Clevermining gives me a higher reject ratio than anywhere else and there isn't much that I can do about it on my side. But in the end it's the payouts that matter. :)

For what it's worth, my Linux rig with 280Xs is currently sitting at a 3.15% reject rate - with all three settings at default.
My Windows rig with 290s is over double that, at ~8% in the same time span and from the same connection - also with all three settings at default.

On Wafflepool I saw around 0.5% on the 280X rig and ~1-2% on my Windows rig. On a regular non-switching mining pool those numbers are cut in half, nearly zero on the 280X rig and below 1% on my Windows rig. With the exact same settings that gives me 3-8% on this pool.

I'm not entirely certain why there is a difference between the two systems, but I suspect the issues may lie within the differences between both OS' TCP configuration. At least I know there's been issues with Windows and it's TCP implementation previously. There's also been several fixes* for online games previously, another genre that also requires a fast and stable internet connection. Note that this last paragraph is just a wild guess on my part - I'm merely curious and raising the question, I haven't done any leg work yet.

* http://www.sk-gaming.com/content/15500-Smart_fix_allows_you_to_drop_your_ping_by_150
* http://www.justanswer.com/computer/3du1a-rid-200ms-delay-tcp-ip-ack-windows.html