Hardware buffer overflow

[blueoce]

The 2.0 USB drive passed the test without any issues, but the 3.0 USB drive encountered errors during testing。Hardware buffer overflow

[ataradov]

This sniffer can only capture USB2 traffic, so USB3 devices would operate in a USB2 mode. There are a couple possible reasons for the differences - your USB3 device is much faster in USB2 mode than the real USB2 device, or the system enumerates it differently and allocates more bandwidth to it.

What does the speed test say about your connection speed? In both cases with the drive connected and not.

Try different combinations for USB ports for the the sniffer and the target device.

[blueoce]

Here are the test results without the USB drive plugged in.

[blueoce]

Below are the test results with the USB drive plugged in.

[ataradov]

This is quite good. Assuming that it does not change with USB drive plugged in, there is no real way to avoid those overflows. Long capture is bound to overflow at some point, since USB sniffer captures the same data, but also needs to carry additional information on the timestamps and line states. So, capturing any device that is efficient at utilizing the bandwidth will have overflows.

You have a few KB of the combined MCU and FPGA buffering that can capture the data fast. Anything past that may overflow and there is not much you can do about it.

[ataradov]

Also, Wireshark itself may slow things down a lot. So, you can try to run the software from the command line and capture it that way, then open the resulting pcapng file in Wireshark. You may see some improvement. It is less interactive, but you are avoiding simultaneous decoding and capture.

[blueoce]

What methods can I employ to enhance the transfer speed, as illustrated in the aforementioned diagram? What considerations should I take into account to achieve an improvement?

[ataradov]

As I said, run the capture from the command line. The same way you run the speed test. This sniffer does not need Wireshark to run, it can capture into the pcapng file from the command line. Then open that file in Wireshark.

Run "usb_sniffer -h", it will show you the help message. You will need to run something like this: "usb_sniffer -s hs -c -f capture.pcapng"

[blueoce]

It seems that it's still not working. Could it be due to the excessive amount of data?

[ataradov]

The overflows will happen, this is inevitable. Your goal with the command line test is to see if you get fewer of them compared to the Wireshark. So, just looking at the filtered result is not helpful.

The maximum 4 ms processing time is pretty good. If you don't see values much higher than that, then your processing is fast enough.

It is physically impossible to capture all data and send it along with the meta information over the channel with the same bandwidth as the captured channel.

This sniffer is not meant to capture all the data. This is a debugging tool. When debugging basic transfers, you should setup a test where short files are transferred. And when debugging some long running issue, you can assume that data in the packets is correct, and missing the exact value is fine.

The other alternative is to slow down the transfer. Use a separate PC for the target device connection with a slower USB performance. It is hard to tell what may work exactly here. But using some very low power device, like Raspberry Pi or similar may help. This way target USB will not be as fast and it will not fully utilize USB bandwidth.

Also, was your speed test with USB drive plugged in while the large file was transferred? Or just the drive plugged in doing nothing? You need to recreate the same conditions as would be present during capture.

[blueoce]

Just plug in the USB drive without performing any operations.

[blueoce]

Perform the operation of reading the USB drive, specifically checking the properties of the files within it.

[ataradov]

Do the speed test while a big file transferred to/from USB drive.

Just plugging in the drive should not cause this many overflows, unless OS does some big reads right after.

[blueoce]

After formatting the USB drive, inserting it no longer results in errors.

[blueoce]

Even when writing content less than 1MB, a substantial amount of overflow occurs.

[ataradov]

On a low level of USB transfers, formatting does not mater. It is likely that formatting just removed the files and OS no longer needs to read them. It is hard to tell what it was doing exactly. It may have been thumbnail generation for videos and images, or virus scan, or search indexing.

The guaranteed buffers are just a few KB. Anything else may overflow. This is normal and expected. If you want full capture, you will have to use a much more complicated equipment with USB 3.0 port of the capture side and much bigger buffers.

Do the speed test while transferring large file over USB. You may have a port that is shared by the same host controller, which will reduce the bandwidth available to the sniffer. And OS may prioritize scheduling of transfer for the flash drive.

If the speed drops during that tests, then you will need to experiment with using different USB ports. And the best case is to use a separate PCs for the capture and for the target.

[blueoce]

Two computers have already been tested, with one dedicated to the sniffer for data capture and the other for reading and writing to the USB drive. However, even when simply plugging in the USB drive, there are still a substantial number of error messages being reported.

[blueoce]

Two computers have already been tested, with one dedicated to the sniffer for data capture and the other for reading and writing to the USB drive. However, even when simply plugging in the USB drive, there are still a substantial number of error messages being reported.

[ataradov]

There is not much you can do if the target device is faster (or the same speed) than the capture port. The only thing that may help is using way slower computer for the target (like RPi) and hope that it can't schedule USB transfers as fast.

Or just deal with the missing frames. When debugging, you can infer that there was a large frame, which is likely a data frame. And when debugging issues with individual data frames, you are not likely to look though GBs of data, you really need to setup an experiment where you can capture the fault quickly. Ans when debugging a custom device, there is a trigger input to enable capture only at critical moments.

This tool was never intended to be able to capture all the data. It is simply impossible without massive local buffers or using USB3 for the sniffer port.

[blueoce]

I've just conducted a test, and it appears that using a USB hub doesn't help either; the speed remains high, which still leads to frequent errors.

[ataradov]

Hubs are pretty efficient, they won't slow things down a lot. You will need a host that is not as good as scheduling transfers. And that is not easy to setup.

[desowin]

To slow down the transfer use high-speed hub and plug multiple devices to hub downstream ports:

• the device-under-test (monitor the link between hub and device-under-test)
• high-speed device(s) that use IN isochronous or interrupt transfer. If you get device that does high-bandwidth 3 * 1024 periodic transfers on every microframe that device alone will consume around 48.5% of total bandwidth, essentially depriving the device-under-test from that bandwidth.

Note that OUT transfers won't help you because these will be visible on the device-under-test link. The IN transfers (and ACKs in case of interrupt transfers) for the other device will still be visible but the data response won't be visible. The goal is to have as many IN DATA packets with 1024 bytes payload as possible.

A less effective alternative is to get large USB 3 capable SSD (significantly larger than available RAM on host), connect it to the high-speed hub and issue while true; do dd if=/dev/sdX of=/dev/null; done. There will be significantly more unwanted data from host, but it might do the trick. That way you get quite some IN DATA packets with 512 bytes payload.

If you just want to force full-speed operation of device-under-test (note: the device might not implement all the functionality at full-speed) just connect it to host via ADUM3160 isolator or similar.