Quote from: GilesBathgate on August 03, 2013, 06:40:40 AM

So I am looking through the bfgminer driver: https://github.com/luke-jr/bfgminer/blob/bfgminer/driver-icarus.c

I can't see any evidence of error detection or correction on the protocol, no parity, no checksums, no resend.

The protocol just sends 4 bytes of nonce data. Ok maybe "the nonce *is* the checksum" since it will be checked by the host standard c sha256 routines. But all bfgminer does, in this case, is flag HW error and close/reopen the usb port. I would expect it might at least ask for the nonce again in case of transmission error.

As far as I know all the current mining hardware just passes along the nonce and then it is checked against sha256. None of the Asics on the market store the nonce for any amount of time as soon as it is generated it is passed along, if something happens in the process it is lost. When there are multiple asics communicating in a chain to a single micro if multiple nonces are generated at the same time they merge on the communication line and are lost. Correct me if I'm wrong but doesn't usb communication send parity check bits along with the data? It would seem that the silabs chip would handle some error checking on the usb layer but I may be wrong. I haven't dealt much with the software side of things when it comes to bitcoin mining. It seems like as long as error rates are less than 1% them nobody seems to bother reducing them further, I don't think I would bother either. However it would be good to know where these errors are coming from.