Quote from: Cablez on June 06, 2012, 05:11:20 PM

That is very good information Epoch, I had come up with something similar for one my throttling 864 units. It is better to leave it at the higher firmware.

I was curious though, what is the reason why the test rates (seen in easyminer) are never achieved when in real use (cgminer in this instance)? Is this network related as in getting work efficiently?

I believe BFL addressed this question elsewhere. But basically when going through the full nonce range (2^32, of 4 billion hashes), a Single runs at its full speed of 832Mhps. It is able to do this in 5.16 seconds. After that it stops until the mining software give it another work unit. So the question is, how long does it take for the mining software (e.g. cgminer) to give it more work? Well, the miner needs to POLL the USB port to see when the Single is done, it needs to collect any difficulty-1 solutions found (typically 1), then it needs to send the next work. I believe the polling interval in cgminer is on the order of 100ms. The USB link to the Single seems to be only 9600 baud, which will add many more milliseconds to the sending of commands, collecting results, and feeding more work.

Let's assume the average delay between polls is 50ms (100ms polling interval means an average of 50ms delay); we'll assume the additional delay due to sending/receiving/processing commands is negligible. So the Single is running for 5.16 seconds at a speed of 832, then sitting 'idle' for 0.05 seconds. Another way of looking at this is that it takes (5.16+0.05) seconds to run through the entire nonce range. That would give it an effective speed of only 824Mhps, not 832.

This happens to be what cgminer reports for a full-bore 832-firmware Single (my 832-speed Singles are reported as 825 by cgminer). Perhaps my assumptions are a bit off, perhaps the polling interval is faster than 100ms ... maybe it is only 10ms. But then the overhead in transferring the serial commands becomes more significant and we're basically back to the same situation again.

You asked why EasyMiner reports a higher rate than cgminer. This is why. I think you already suspected as much. EasyMiner reports the raw rate only. That is, the rate at which a full 2^32 hash range is calculated at. It does NOT take into account the overhead of polling and command transfer over a longer period. cgminer does take this into account, which is why its reported rate will be lower.

It may be possible for BFL to tweak the firmware such that the next work could be queued in the device before it has completed its current work; that would essentially eliminate the polling delay and allow the device to operate at 100% efficiency. Currently that is not the case; we lose about 1% due to the polling and USB communication overhead.