When developing an FPGA project that involves an interface with a PC computer, it’s usually important that it works with a variety of computers, and not just the one against which it’s developed. In other words, XillyUSB did nothing to provoke these situations, so similar behavior is expected with any SuperSpeed device. The low-level packet exchange has been analyzed to ensure that the XillyUSB device behaves correctly around any odd situation, and XillyUSB's diagnostic tool was run during these tests to ensure that no low-level errors were detected by either side. The issues displayed on this page are not XillyUSB specific. Any application that is based upon BULK endpoints, XillyUSB included, must be able to tolerate such data flow pauses. It may be daunting to read the detailed description of the test settings as well as some USB protocol related discussions below, and neither is really necessary: All you need to know is that the peaks in the graphs shown on this page mean a stop of the data flow, and that the height of the peak is the duration of that halt. This is important in particular in data acquisition applications. The lesson to be learned is that if halting the application data stream randomly and arbitrarily breaks its functionality, significant buffering is required on the device (i.e. They are of course allowed to do so, and yet it might be surprising how each controller behaves differently.

To make that point, test results on several USB 3.x controllers show how the data flow is halted randomly and inconsistently by these controllers, each with its own specific pattern. This page says what should be obvious: USB BULK endpoints don't guarantee neither bandwidth nor latency.

Via xhci driver windows 10 vl805