Luck went pretty bad during/after migration, so PPLNS hasn't moved much much.  We had 3 bad blocks - 1 hour between 19995 and 19996, 1 hour 40 minutes between that and 19997, 1 hour between that and 19998.  In that time frame we should have had 6-8 blocks.  

Restarting multiple times will definitely impact your estimated speed, since it uses 1 hour worth of data to estimate your speed and all that time lost restarting just means you're going to have to wait for the dead time to leave the average window.

As normal, my usual response:  The pool speed estimate uses the same data your workers do for their estimated speed.  As of this moment, it's showing 281 TH/s.  There's no way for the pool server to discriminate against you, so if there was an issue with the pool it would affect every user on that same server (or all servers if it was database related).  Obviously that isn't the case.

Finding a BTC block should always produce a matching NMC block assuming nothing was wrong in the NMC block creation (outdated NMC info/orphan).  The only time this wouldn't be the case is if NMC somehow had a higher difficulty than BTC.

That gap is because you have an extremely small payout.  The scripts limit the number of total payouts made with each batch.  If too many payouts are trying to trigger each hour, some are skipped and picked up on the next cycle.

The old chart data was not copied over, so it will take time to repopulate the data for them to start drawing again.  They should start showing up again in an hour or so.  Rankings were the same situation, but they've already started to regenerate.

Database migration is complete!  There's a little tidying up left to do, and a pesky time zone issue I need to fix, but for the most part everything is now complete.

Please send an email to webmaster@btcguild.com and I will try to respond as soon as the database migration is finished.



RE: Database migration.  Since this is a live move, there is going to be an extremely small window where shares are not counted when the servers get pointed to the new database.  I'm preparing all the SSH sessions so I can very rapidly restart the servers immediately after the snapshot is taken of the live PPLNS shift database.  The estimated loss of mining time is only a few seconds.

Website/Database Maintenance Reminder

The website and API will be unavailable for an estimated 1 hour of maintenance to migrate the database to a new server.  The pool servers will remain online during the migration, and experience a brief restart when the maintenance is finished.

This maintenance will start when the next shift is finished.  The goal is maintenance will be finished before the following shift is ready to close.


EDIT/UPDATE:  Maintenance has been pushed back to ~4 PM (when the next shift closes) due to one minor oversight that can be addressed prior to entering maintenance mode.

The 1230v2 CPU is just an amazing processor, and even better price.  I use them on all the newer stratum servers as well.  I talked with a lot of people who have experience with using SSDs in RAID for high volume servers, and the recommendation I got was Samsung 840 Pro SSDs.  These recommendations came from people who could have easily gone for enterprise drives, but the bang for your buck is that drive, and longevity issues can be easily handled with RAID and having a few spares to hot swap if one ever does have an issue.

Honestly, MySQL is so terrible when it comes to threading performance for large table queries that a dual core would work just fine, as long as it's clocked fast enough.  E3-1230v2 is 3.3 ghz (3.7 turboboost) per core, which is a more than 50% increase in raw clock rate than the current 2x quad core processors it's sitting on (also 6 year newer CPU architecture).  The new server is being tweaked in a lot of other ways too prior to the migration.

Reconnecting is normally transparent with modern mining software, a lot of the early issues where miners would never reconnect to Stratum have mostly been fixed.  I think the last time the pool servers were restarted the drop in hash rate from miners that failed to reconnect wasn't even measurable compared to the normal hash rate variance.

Same datacenter, just migrating to much better hardware for the database.  The current DB server was never intended to be running something like BTC Guild.  New server is a 1U SuperMicro, E3-1230v2, 32 GB ram, and an LSI 9260-4i with SSDs in RAID1.

Website/Database Maintenance

There will be a maintenance period tomorrow at approximately 3 PM Pacific Time.  During this time the website will be temporarily unavailable as the database is moved to the new server!  The pool servers will also have a brief restart once the new server migration is ready to be completed.

The website will simply have a placeholder message during maintenance notifying users that it is under maintenance, in order to make the migration as quickly as possible.  This transition will speed up website response times on data heavy pages, and significantly reduce the lag when major scripts execute.

Those prices are the cost for resellers to obtain the units.  There will always be a markup from resellers for shipping and a profit.

Block Erupter Coupons have now been distributed to any order placed above the current retail price.  These coupons have no expiration.  Currently coupons are limited 1:1 on past orders, but this will be extended as new inventory is received.

USB Block Erupter coupons (0.15/unit + 0.05 handling per order) will soon be extended to any order placed above 0.29 BTC, once the currently ordered units are packed & shipped.  This will probably be in the next 2-3 hours.

The new blades default to 1.2v according to everything I've read, and are overclocked as a result compared to the original models.

I haven't dealt directly with SoftLayer, but I was on a SoftLayer reseller (I think).  I was also at CoreXchange which primarily used Level3 peering for the traffic at the time.  Obviously a reseller adds another step in the chain for the connections to break, but normally traceroutes would reveal the problem outside of their system and somewhere at the peering to get out of the datacenter.


EDIT:  Let's clear this out of the pool thread going forward.  I'm sure people have had enough posts about dedicated servers/datacenters for one night .

Sadly, level3 is normally the cause of a lot of packet loss in my experience with all the dedicated servers BTC Guild has moved between over the years before it went to full colo in the US.

Most datacenters have good uptime, but I've yet to have one that didn't at least have periods of high packetloss once a month or so.  Additionally, the setup in Chicago has significant upstream filtering, fat pipes, and I'm able to push nullroutes for my IPs to their network during attacks as well.  99.9% is not enough, especially when they never count periods of very high packet loss as downtime.

I just question why people always seem to blame the pool, like it's discriminating against them specifically while the other 240-260 TH/s worth of users run without issue.  Code does not discriminate.  The problem is always user settings/hardware settings, otherwise it would be affecting thousands of other users.  You'd get a lot more than one person posting if that was the case.


That said, right now, there is a small problem on 1 of the EU servers .  Trying to route everybody to the other server right now until the problem is resolved (ETA: 10 minutes).  Looking into options for what to do with the EU servers right now, since those are the only ones having issues these days.  It's very tough to get a provider that matches the quality of our US datacenter, especially when you have no physical presence internationally.

It's called variance.  Other pools have it too unless you're on PPS.  It can be good or bad.  Last 50 shift luck: 71.026%, roughly 29% less than expected payout.  The only way to avoid variance (LUCK) is PPS.  Otherwise, you'll have bad times where you make less, and good times where you make more.  It evens out in the long run but most people can't seem to go more than a few days without bitching when it turns bad, then become blissfully unaware when it's the other way around and they're getting paid 30% more than they normally would because luck flipped around.