Question from the Customer:
We are using the Beagle USB 480 Protocol Analyzer and Data Center Software to sniff Full-speed USB data. We observed that data is displayed first on the DUT display and displayed on the Data Center Software afterwards. This was not expected. In our setup, data should be displayed on the Data Center Software before reaching the display of the destination device.
This makes us wonder about time from the data arriving at the hardware edge of the Beagle USB 480 analyzer to being displayed in the Data Center Software. How can we reduce the latency of data being delivered via the USB port?
Can you please let us know what affects the time required for data to travel from the USB port to the Data Center Software? This will help us to assume some delta in our calculations to determine the time required for data to travel from the source to the destination.
In our setup, the Data Center Software is set to Auto Detect and Real Time mode.
Response from Technical Support:Thanks for your questions! The Beagle USB 480 analyzer contains a 64 MB on-board buffer, which stores incoming data before it is displayed. The data is processed, decoded, and then displayed in the GUI or API functions. It is possible that there is a latency or other delay that affects the arrival of data during sniffing due to GUI software, computer OS, and other system-related overheads and delays.
This latency cannot be changed in the Data Center Software. However, to decrease the latency, Beagle Software API Software can be used instead.
How to Decrease Latency with API
The API supports multiple operating systems (Windows, Linux, and Mac) and programming languages (C, Python, Visual Basic, and C#). Software examples are provided with the API package, as well as instructions to run and execute the software examples.
Buffer Settings and Recommended API Commands
The API command bg_latency() sets the capture latency to the specified number of milliseconds. The capture latency effectively splits up the total amount of buffering into smaller individual buffers. The amount of buffering is set with the API command bg_host_buffer_size().
After one of these individual buffers is filled, the read function returns. Therefore, in order to fulfill shorter latency requirements, these individual buffers will be set to a smaller size. Setting a small latency can increase the responsiveness of the read functions. If a larger latency is requested, then the individual buffers will be set to a larger size.
For more information about API commands, please refer to the section API Documentation in the Beagle Protocol Analyzer User Manual.
How Buffer Size Affects Latency and Overhead
There is a “fixed cost” of processing each individual buffer that is independent of buffer size; there is a trade-off. Using a small latency increases the overhead per buffered byte. A large latency setting decreases that overhead, but it also increases the amount of time that the library must wait for each buffer to fill before the library can process their contents.
Please note, this setting is distinctly different than the timeout setting; therefore, the latency time should be set to a value shorter than the timeout time. You can also affect the delivery time of the data with the selection of how data is captured.
Data Center Software Modes for Capturing Data with Reduced Latency
If you are capturing the traffic using the Packet view in the Data Center Software, we recommend changing to Sequential mode; the data captures will be much faster. Apart from any OS processes running in the background, with no other USB link traffic, packets are monitored at the speed of 40Mbps, with a lag of 1 packet (~250us). For more information about capture modes, please refer to the section Capture View in the Data Center Software User Manual
We hope this answers your questions. Additional resources that you may find helpful include the following:
More questions? You can send us your questions via sales@totalphase.com. You can also request a demo that applies to your application.