Quote from: zefir on June 06, 2012, 07:18:01 PM

Quote from: Epoch on June 06, 2012, 05:44:39 PM

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.

Hi Epoch,

I had similar estimates in a different thread and did some further digging to get a more solid understanding.

Bottom line is, if the BFLS is not throttling, you will get some long term hash rate of (system clock - 14) MH/s, that is a device with 864MHz firmware will deliver 850MH/s at most. The loss is taken for the communication to/from device. Converting it down based on a nonce time of ~5.2s, the idle time is around 80ms per cycle. That matches the real numbers for cgminer operation, that are:

baudrate of 9600 => ~1ms (937.5 us exactly) to read/write a single character
submitting work: write ">>>>>>>>[32 bytes midstate][last 12 bytes of block header]>>>>>>>>" => 56ms
polling for shares: after work submission, first wait 4.5 seconds, then poll every 10ms by writing "ZFX" => 8ms average delay
reading shares: read "NONCE-FOUND:1234ABCD,2468EFAB,1111BBBB" => (11 + #nonces * 9) ms => 18.7ms average

One could maybe implement some pre-fetching of work and caching of nonces functionality to add the potential 12MH/s - but at the same time maybe the FPGAs need this small idle time to cool down a little bit.

I get 857 and some change mh/s with the 864 firmware.