Miner statistics bug with the new backend ?
I had 2 of my miners go down due to a datacentre reshuffle, which saw some miners powered down and restarted.
On restart 2 units were mining suboptimally, an Oct jupiter hashing at about 1/4 speed (confirmed on http GUI and shell cgminer) and a Nov jupiter hashing at about 1/2 speed.
btcguild moved them from "idle workers" to "active workers" but despite multiple refreshes over a few minutes, the estimated speed was clearly incorrect 547.64 GH/s and 654.68 GH/s
I assume btcguild is displaying the old estimated speed before they became idle, rather than their current estimated speed.
I had 2 of my miners go down due to a datacentre reshuffle, which saw some miners powered down and restarted.
On restart 2 units were mining suboptimally, an Oct jupiter hashing at about 1/4 speed (confirmed on http GUI and shell cgminer) and a Nov jupiter hashing at about 1/2 speed.
btcguild moved them from "idle workers" to "active workers" but despite multiple refreshes over a few minutes, the estimated speed was clearly incorrect 547.64 GH/s and 654.68 GH/s
I assume btcguild is displaying the old estimated speed before they became idle, rather than their current estimated speed.
I'm assuming this already sorted itself out. The estimated speed has always used a large window to determine the average speed. If your miners disconnect for a while (restart) and you turn them back on, it will take about an hour before your estimated speed returns to normal, since you have a period of no hashing.
Absolutely *nothing* has changed on the frontend or backend mining servers. The server currently being used for testing is the validation server, which you're only connected to for a few seconds at most if you're running decent hardware.
Already sorted out. I don't know why some Jupiters hash poorly after restarting (And on occasion on forced pool change when bitminter went down). Bertmod did not reveal any obvious problem. Restarting cgminer from shell fixed the hashrate.
