Ok, I've figured out why I think people are reporting bad hashrates on Erupters with 3.2.0...
First, a summary: it's just your perception, it will take a few hours, at least, before the average hashrate displayed settles down.
This is due to the Erupter driver only reporting hash completion once every 12.8 seconds (the time it takes to find 1 share on average). During this time, the average is skewed because while the Erupter has been hashing, it hasn't reported its progress.
So for the first 12 seconds, the erupter has "completed" a total of zero hashes. So the average is 0 despite that it's been actually performing hashes the whole time.
For the next 12 nexts, it has "completed" 4 gigahashes (total, not per second), which are then divided across the 12 seconds (which gets an accurate 335 Mh/s average); but then across 13, 14, 15, etc seconds; by the time we get to 24 seconds, it's still using the same 4 gigahash "completed" number, so the average (of 4 Gh over 24 seconds) is 178 Mh/s.
Once the second 4 gigahash "completed" come back, now the total is up to 8 gigahash, and it once again shows the correct 335 Mh/s average. By 36 seconds, however, the same thing has happened again: we have 8 gigahash divided by 36 seconds now, which is only 238 Mh/s.
After a few hours, those last 12 seconds becomes less and less relevant, and your average should begin to settle on 335 Mh/s.
The reason this didn't affect 3.1 and earlier as much is that it was abandoning work when a share was found, thus cutting the 12 seconds down to 6 on average. Scanning the whole work is more or less the main thing responsible for reducing hardware errors in 3.2.
There are a few ways to fix this to get a usable average faster:
- Only count seconds for which completed hashes are known, when performing averages. This would change behaviour such that averages would not account for time a device is disabled or waiting on failover or other issues. Probably not a good idea IMO.
- Ignore the time after the last "hashes complete" report so long as a device is actively hashing. This is probably ideal, but I need to think what the best way to be sure the device is actively hashing reliably (shockingly enough, this isn't obvious yet internally).
- Upgrade the Icarus driver to the newer API so it can report progress more often. I need to do this eventually anyway, but there are some complex issues to handle on Windows when I do.
All of these solutions have potential to introduce new bugs, so I don't expect to implement them until 3.3 at the soonest.
Edit: Original post accidentally said 355 instead of 335.
? 
Assuming there's no limitation in storage space, is there any other issues you can foresee?
