Quote from: jedimstr on September 05, 2013, 05:14:56 PM

Quote from: eleuthria on September 04, 2013, 06:35:43 PM

The new server for the database has been delivered to the colo this morning. The new server is planned to go online at 5 PM (PST) on Friday. This will require a brief restart on all pool servers in order to redirect them to the new database.

The website may have a few lag spikes during the next 24-48 hours as parts of the database are copied over to the new server. Once everything is moved, this should drastically reduce the current lag spikes that happen about twice per hour, and the minor lag spikes that happen about four times per hour as a result of all the scripts that are needed to keep the statistics updated.

Are the current site issues (refuse to load, not even cloud fire, or issues changing worker settings) related to today's dbase copying or is this another attack/site issue. Also when I was able to get in, the pool stats showed the US stratum server status as "Dead:105m". Related? From BFGMiner's status though, it looks like I've been able to hash away and submit status updates without failover on stratum.btcguild.com.

The website has had no issues on my side, but there have been issues changing workers, related to one specific server not acknowledging the requests. That should be over now. Mining software should have redirected to the alive servers fairly effectively (based on pool speed, that did happen successfully).

Just an update, there is a flaw in the Slush stratum mining proxy that was found recently. The first method a client is supposed to send with stratum is a mining.subscribe method. This tells the server to start sending you work at each update, and sends you the default server difficulty (1). Later on, slush added the ability for the proxy itself to authorize as a worker, rather than passing worker authorization from the software pointed at the proxy. This authorization happens BEFORE the mining.subscribe method is sent, and causes a conflict. When you auth the worker, it sends you the worker minimum difficulty and work to start on. THEN the proxy sent the subscribe, which by default sends server difficulty (1). This is confusing the mining proxy and causing significant lowdifficulty rejects.

A fix is being pushed out today to work around this flaw in the stratum proxy. A temporary workaround for users is to leave your minimum difficulty at 1, or simple don't run the proxy with '-cu and -cp' arguments.