3 ms·

USB bulk packets have a 16 bit CRC.

amelius 2y ago
Interesting. I recently tested a 6ft USB3 cable and an attached drive. The transfer of a 1TB file failed a few times (not sure of the details). This is strange, since the cable couldn't have been that bad (?) and the 16-bit CRC should have caught those errors (assuming an error will trigger a resend of data). Any ideas what the issue could have been? Does Linux provide a way to view the error rate?
- em3rgent0rdr 2y ago
  https://wiki.wireshark.org/CaptureSetup/USB https://wiki.wireshark.org/CaptureSetup/USB says "Software USB capture captures URBs (USB Request Blocks) rather than raw USB packets." So Wireshark couldn't give you the CRC, which would be stripped away. You could hypothetically use a really-really high bandwidth oscilloscope (like 2 GHz to view 480 MHz USB HS signals), but those are expensive. So you would have to resort to using external USB sniffer...out of curiosity I found someone made a sniffer that is basically a USB-capable microcontroller plus an FPGA and a USB PHY: https://hackaday.com/2023/06/13/cheap-usb-sniffer-has-wireshark-interface/ https://hackaday.com/2023/06/13/cheap-usb-sniffer-has-wiresh...
- topspin 2y ago
  > the 16-bit CRC should have caught those errors I believe your confidence in the 16-bit CRC is excessive. There is a 1 in 65536 chance of a 16 bit CRC failing for certain types of corruption in 512 byte bulk USB packets, and there are about 2 billion packets in a 1TB transfer. If the BER is high, corruption of the transfer is not surprising. A 6ft cable should be fine, assuming it is well designed, manufactured correctly, in good condition, and not in close proximity to high noise sources, such as SMPS. If any of those factors are compromised the BER will increase, and you will then be testing the rather limited capabilities of 16 bit CRC. USB4 has 32 bit CRC for data payloads for a reason. In the mean time, the #1 thing you can do is use short, high quality cables.
  - amelius 2y ago
    Yes, perhaps you are right, that's why I was asking about a way to see the error rate. I think it is also a failure of the USB standard then, to allow a transfer to happen if the BER (according to the CRC) is so high. Glad to see that USB4 is fixing things but one thing I worry about is if this 32 bit CRC is a mandatory part of the standard that cannot be turned off or ignored by manufacturers. Especially since it apparently is not transparent to users.

Interesting. I recently tested a 6ft USB3 cable and an attached drive. The transfer of a 1TB file failed a few times (not sure of the details). This is strange, since the cable couldn't have been that bad (?) and the 16-bit CRC should have caught those errors (assuming an error will trigger a resend of data). Any ideas what the issue could have been? Does Linux provide a way to view the error rate?

em3rgent0rdr 2y ago
https://wiki.wireshark.org/CaptureSetup/USB https://wiki.wireshark.org/CaptureSetup/USB says "Software USB capture captures URBs (USB Request Blocks) rather than raw USB packets." So Wireshark couldn't give you the CRC, which would be stripped away. You could hypothetically use a really-really high bandwidth oscilloscope (like 2 GHz to view 480 MHz USB HS signals), but those are expensive. So you would have to resort to using external USB sniffer...out of curiosity I found someone made a sniffer that is basically a USB-capable microcontroller plus an FPGA and a USB PHY: https://hackaday.com/2023/06/13/cheap-usb-sniffer-has-wireshark-interface/ https://hackaday.com/2023/06/13/cheap-usb-sniffer-has-wiresh...
topspin 2y ago
> the 16-bit CRC should have caught those errors I believe your confidence in the 16-bit CRC is excessive. There is a 1 in 65536 chance of a 16 bit CRC failing for certain types of corruption in 512 byte bulk USB packets, and there are about 2 billion packets in a 1TB transfer. If the BER is high, corruption of the transfer is not surprising. A 6ft cable should be fine, assuming it is well designed, manufactured correctly, in good condition, and not in close proximity to high noise sources, such as SMPS. If any of those factors are compromised the BER will increase, and you will then be testing the rather limited capabilities of 16 bit CRC. USB4 has 32 bit CRC for data payloads for a reason. In the mean time, the #1 thing you can do is use short, high quality cables.
- amelius 2y ago
  Yes, perhaps you are right, that's why I was asking about a way to see the error rate. I think it is also a failure of the USB standard then, to allow a transfer to happen if the BER (according to the CRC) is so high. Glad to see that USB4 is fixing things but one thing I worry about is if this 32 bit CRC is a mandatory part of the standard that cannot be turned off or ignored by manufacturers. Especially since it apparently is not transparent to users.