Sent you one BTC to cheer you up 

Likely unrelated but the only networking issues I have seen is when my switch got too hot.  I got 4 rigs in the garage running on their own switch.  I found that is room ambient temp got too hot the switch (fanless) would go "crazy" and make the miners drop from the network.  I "solved" it by putting the switch closer to the ground (cooler) and putting a small desktop fan next to it.

When your miners indicate the pool is unavailable can you still remote into them (SSH)?

Weird and weirder.  Only thing I could think of testing is on only one machine try making the pool (or maybe just backup pool) an IP address instead of domain name.  If it is DNS related that should indicate it.  Obviously not something you would want to keep long term but maybe it will help narrow it down.

Alright you stumped me.  The good news is we know what it isn't.

P4man have you tried a different miner?  I don't think it's a cgminer issue.  I had the same errors with other miners, cgminer just handles it better...up to 2.0.7 anyway.  I get huge latency jumps to any IP since a lightning strike hit the cable line.  I thought it was cleared up, but apparently I was just overlooking it because the miner recovers and keeps hashing.

This I see with anything after 2.0.7.  Otherwise it does take hours to recover, or a restart, but it does recover.

Does bitminter use phatk? The other miner I used also used phatk.

I still think it's some curl related issue.
Do the other miners use curl also?
If they do then I guess: see how they handle a 503 may be a possible option?

Anyway, the reason I actually made this post is this:
Is anyone interested in me making some changes to 3 programs and setting up a pool:
Adding a socket interface to bitcoind, a pool (whichever one I or someone else decides) and cgminer.
I also suspect it may resolve a long term issue of pool performance.

I'm probably gonna do some simple testing with bitcoind anyway since I have a web page of my own that already does a a 2016 block access to bitcoind (with a slightly modified getblockbycount) and also a program that reads the whole blockchain and caches it, again using getblockbycount.
Both of these will easily show if there is a major performance gain by using a simple socket interface like I used in the cgminer API instead of curl ... and the same on the bitcoind side
I suspect there will be a performance gain but I'll test it first to be sure
From the cgminer side it would simply be an extra option (something like "--sockets") to use that interface instead of the default standard curl interface to the pool (and for a different LP also)

Anyone be interested in this?
I wont be chasing a donation limit to do this - since I'm interested in at least doing the initial tests myself anyway
(but of course I'll happily accept donations to get it done anyway)
But I'm more interested in knowing if people would be interested in 2 things:
firstly helping with testing the code on a pool (obviously I'd need some reasonable hash rate to test it and find the problems that occur and implement what should be simple fixes for them)
secondly be interested in using such a pool permanently once it's up a working well

The options would be either some form of PPS or something like DGM (or I don't know what else)

So basically I'm interested in putting a simple socket interface from cgminer all the way through to bitcoind and see if it performs much better and is more reliable (than curl) and should have a VERY low stale/reject rate
(and the cgminer change would be an extra option to run the socket interface instead of the default curl interface - but not both at the same time)

If there is interest I'll start a separate thread on the subject, but I'm posting here first to see if the cgminer users are interested in it.
Also, the pool would of course be charging some small % fee and if ckolivas is interested I guess he can be part of that % so he is actually getting something a bit more than just trivial from all the people using cgminer

I don't know about windows, but with linux you need DISPLAY=:0 before your launch string if starting over vnc/ssh to detect the GPU's. 

I don't want to play Devil's Advocate, as I understand many people seem to be having issues with the latest release (2.1.1), but for me, my performance for Pool mining has actually increased.
The MH/s stats at my pool have never been higher than they are over the last 24 hours or so and my Share/minute rates are up a tiny bit.

What would have changed to allow this to happen ? ....as nothing has changed on my end.
The miner seems to be connecting to the pool more efficiently, as it were.
(Win 7 x64, all cards, Cat 11.9-11.10)

Any ideas ?