There isn't much difference between the two other than latency.  Both of them are workin.  EU took a few extra minutes to fix due to the slower CPU on the validation server requiring more time to compile the new patch.

Having both of them added can help if you restart your miners or have frequent disconnects on your local connection.  Both VALIDATION servers have intermittent outages as botnets slam against them, occasionally causing packet loss or temporary additional DDoS filtering which may be likely to cause false positives.  This was part of why the EU server took a couple minutes longer to come back up as well.

Validation servers are back online.  The backends did not go down, but stratum.btcguild.com/eu-stratum.btcguild.com 3333 validation servers did due to an error in the patch to support > 2.1b difficulty on those two instances.  Re-patched and now back online.

Each stratum connection uses only a few bytes per second, plus ~2 KB per minute for work pushes.  So only a few megabytes per day. Speed doesn't matter due to vardiff.

That's the correct progression.  Next up is Eh/s (exahash) btw.

Servers have now been upgraded.  Sorry the downtime was a little longer than expected.  One specific function used by the server monitoring scripts was missed in changing network difficulty from a long to a double, so each time the script polled the server it was causing it to segfault/reboot.

Downtime to get the patch applied was ~4 minutes in total.

Yep, that's how everything should (and probably will work).  In my experience, it's normally embedded miners (like Avalons with their built in cgminer/router or ASICMINER blades) and stratum proxies that act up the worst on disconnects.

Ideally, restarts as fast as Guild's shouldn't cause problems.  But mining software is pretty unpredictable (see the cgminer crashes a few days ago).  Everytime there is a round of server restarts there tends to be a 5-10% drop in pool speed that lasts about an hour.  Some of that is probably just miners failing over and then coming back a few minutes later.  Some of that is almost certainly mining software/hardware failing to properly handle a disconnect.

There will be a server restart on all BTC Guild stratum servers at 0:00 GMT.  This restart is not to deploy new software, but to patch a bug that would arise at the next difficulty change.  The original (and still under use) stratum code for BTC Guild will not handle difficulties above 2.1b when it comes to Pay-per-Share recording.  This was a fix in the new pool software, but since that project has been scrapped, the fix is being rolled into the old software today.

Some people don't understand the bits of joy a computer geek gets when playing with hardware.  Number porn is awesome!

There's been quite a few server resets in the last 24 hours due to switching software and then reloading the load balancer to bring new servers online.  The speed average on BTC Guild and just about every pool will likely vary +/- 5 to 10%.

Make sure all your hardware is actually mining, a ton of ASICs have extremely poor firmware that have issues with reconnecting when servers disconnect them.  The servers haven't had any changes in the last 12 hours, and no other resets are expected any time soon.  If you're still seeing abnormal variation, the problem is on your end because the servers are *identical* to the setup they've been in for the last few months after yesterday's failed software upgrade was rolled back.


Also, it's virtually IMPOSSIBLE that slush is showing your exact speed within 1 GH/s if you're mining in the terahash range unless you got lucky as hell (and it would immediately show a very different speed a few minutes later).  All pools have a reasonable amount of variance in how they show your speed because they're based on share submission rates.  No miner is perfectly consistent in its submission rates, they always vary by percentages due to luck.

BTC Guild's average is 1-hour.  You can get 4-hour averages by looking at your 1-week charts.  You'll see on that page how your hash rate varies when measured over different intervals.  That's completely unrelated to the server, that's YOUR variance in share submissions.  If you see a *definitive* decrease when looking at your 1-week chart, that would be something to be concerned about, and means you should check your hardware/stratum proxies, or check the forum to see if there were any server issues during that time.

As much as I hate GHash.io (*nelson Ha-Ha*), curious why the post in this thread about them.

There was a small bug over the last 12 hours approximately affecting the interaction between the website and backend servers when modifying worker settings like names, payment methods, and minimum difficulty.  The load balancer and backends were updated to run twice as many server processes, but only the original set of processes were able to receive notifications from the website when updating worker settings.  As a result, your difficulty and payment method may be different depending on which backend you connect to.

If you're experiencing this (shares paid to the wrong method or difficulty starting higher/lower than it should), you can toggle your settings back and forth to force an update to the mining servers.


This bug only affects *changes* made in the last ~12 hours.  If you have not changed any settings, this would not have any affect on your miners.

Then it must be extremely rare, because I haven't seen any reports about it causing segfaults until 3.10.  BTC Guild has been using client.reconnect for a very long time.

I have no idea.  The only ASICs I have are USB Block Erupters.

Sounds like the solution for those having cgminer crashes is to downgrade to a non 3.10 version.  Quite curious what the hell he did to break such a basic feature that has been working flawlessly for the last 6 months.


EDIT:  You can connect to 'cgminer.btcguild.com:3333' as a temporary workaround.  This server may disappear with little (or even 0) notice once the bug is known to be fixed.

That's...interesting.  I can't think of anything that happened in the last 2 hours that could've caused such a crash.  Were all the machines behind the same router?  Have you been able to reconnect?

It's not uncommon for large pools (even slush has done it before) to have multiple bitcoind servers and pool servers.  It is actually possible, due to the inefficiencies of p2p transmission, for a pool to orphan its own block.  By default bitcoind ignores other blocks that come in if they already have a block at that height, so if one of GHash.io's servers saw slush's blocks before another Ghash.io block, it will build on Slush's block unless they have modified bitcoind to prioritize their own blocks in the event of a race.

It's unfortunate that the only way to find out the new stuff doesn't work is by putting it live.  Every local test I can do turns out fine, but there are so many thousands of hardware configurations, software configurations, and just plain VOLUME of network activity that you can't properly test in a sterile development environment.

For now, I think I might hang up this attempt at a rewrite and fall back to what I know at least one other pool has done to get better multi-core utilization:  Just run the server process multiple times on multiple ports and have a proxy split the load on the same machine over the different ports.  It feels like a cop out, but I noticed during the live testing that a significant load still hit one core:  The one used for the primary network IO processing, which is extremely difficult to split over multiple cores/threads without significant overhead in mutex locking.  I get the feeling it wouldn't be any more efficient than just running multiple instances of the server.

Anti-hopping methods don't actually hurt your income, so technically you can use just about any pool you want as a failover.   You'll just see varying amounts of fluctuation in how much your shares earn depending on the method you fallback to:


Score-based (Slush):  Extremely high variance.
PPLNS (low N value like p2pool):  High variance.
PPLNS (high N/shift-based like BTC Guild and BitMinter):  Lower variance [BTC Guild lower than BitMinter]

DGM:  Depends on the individual pool's settings.  My understanding is this should be safe as well, and can be high or low variance based on settings.



Obviously PPS means 0-variance during your failover, so it may be the preferred method.  But don't do it under the false assumption that you'll be penalized for inconsistent mining on unhoppable methods.  Most methods do not penalize inconsistent mining.

All problems are fixed now, every BTC Guild server (including validation server) has been reverted to the same software it was using for the last year.