Hi Mathhias, On Thu, May 02, 2019 at 02:18:38PM +0200, Matthias Br??ndli via USRP-users wrote: > On some systems, we observe sporadic underruns. They occur in irregular > intervals, something like once a minute, sometimes rarer. Seen with both > USB2 and USB3 hosts, over several UHD versions. Until now we've mostly > been able to avoid the issue by selecting machines that don't show the > issue, but we hope we can find a mitigation in software.
The USB bus is managed using a USB hostcontroller that uses busmastering/ scatter/gather over PCI/PCIe to retrieve and store it's data. The USB 2.0 EHCI hostcontroller(s) are more straightforward than the XHCI hostcontroller used by USB 3, that has to deal with more complexity. If 480 mbps is more than enough for your stream (2048 MSPS ~ 8 MB/sec over a USB 2.0 bulk endpoint, using transactions of two times 512 bytes every 125 usec (8000 Hz USB framerate) could satisfy your bandwidth demands. You could even see these frames on a moderatly fast scope (500+ MHz), using a low-capacitance FET/active/differential probe and trigger on too much or a lack of them. Another option is using a powered USB 2.0 or USB 3.0 hub. Since USB hubs do not receive firmware updates, they should be very stable. If there is a problem with a USB enumuration timing/reset signalling or on the 5 gbps lanes, a hub might resolve an incompatibily in of one of the USB peers. For more in-depth USB debugging, there are external USB 2.0 and 3.x hardware bus analysers available, for example from the swiss company ellisys.com. These can log all USB traffic to a PC and filter the data, without interfering on the timing of the signals - ideal tools for USB device development and debug compatibility issues. For more in-depth PCIe transaction debugging of the USB host controllers, serialtek.com sells also PCIe 'AIC' hardware connector interposer cards that you can put between your motherboard and an external PCIe xHCI based USB hostcontroller. > Both the data source the modulator connects to and the USRP have a > disciplined time reference, implying there is no rate drift (plus, that > would trigger regular underruns, not sporadic ones). Some things can be very subtle, for example this (quite amazing) 2013 ethernet PHY bug: https://www.theregister.co.uk/2013/02/06/packet_of_death_intel_ethernet/ Very tough engineering by the affacted customer, who made it reproducable and fixed by a simple EEprom update from the vendor. Pure theory: What if this intermittent issue would be an issue with a certain sequence of packetlengths, some of them on the boundary of the maximum size for that endpoint and endpointtype, that are not handled properly at one or both sides, causing a glitch/retransmission/faillure, resulting in the application-level visible underruns ? How would you measure that ? How could you optimize the packetlengths so that the issue is quicker to reproduce ? Or avoid the issue by anticipating and avoiding such packetsequences ? > Could CPU frequency scaling lead to interruptions? It would leave that off - less interference with thermal peak management or other system management mode interrupts from your motherboard, most constant performance in outputing your samples. > [4] > https://files.ettus.com/manual/page_transport.html#transport_usb > > Default send_frame_size seems to be on line 85 of > https://files.ettus.com/manual/b200__impl_8hpp_source.html Best regards, Mark-Jan _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
