4 ms·
Presumably if it's a mass storage device with block-addressible storage then the host's fs driver should be able to (if it has its own file checksums) transpare
by treyd 3y ago
Presumably if it's a mass storage device with block-addressible storage then the host's fs driver should be able to (if it has its own file checksums) transparently identify the corruption and re-read the block, right? Or at least bubble up to the user and fail the operation instead of allowing silent data corruption.
- amelius 3y agoPerhaps in case of storage devices (although it would be far less efficient to do it that way). But this approach doesn't apply to e.g. high speed industrial cameras. In any case, it's USB's job to transfer the data, so imho the responsibility lies there.
- lxgr 3y ago> Perhaps in case of storage devices (although it would be far less efficient to do it that way). That's in fact how it works for USB bulk transfers: The host learns about the checksum error having occurred and it will retry until it passes. That doesn't seem inefficient to me, given the low error rates involved (many flavors of Ethernet do the same, for example) – are you saying there should be FEC? > But this approach doesn't apply to e.g. high speed industrial cameras. These usually use isochronous transfers, where errors are indeed only detected (and reported), but no retransmission is attempted.
- lxgr 3y agoThat's how it works, as far as I understand: USB indicates the error, and the host driver can retry if it makes sense – and for storage devices, it definitely does.