1. Multiple USB transfers are queued by UHD and they pull the data into host memory as quick as they can. The transfers are re-queued when the data is retrieved by the application calling recv(). Overruns occur when all transfers are complete, data is queued in the memory, and the application fails to call recv() quick enough to retrieve the data and re-queue the transfers. You can increase the number of transfers by setting the num_recv_frames in the device args. I believe the default is 32, but we sometimes recommend setting it much higher (like 256 or 512). But more buffering will not help if the application cannot keep up with the rate. If you can live with lower resolution, you can try using sc8 samples. That will cut the bandwidth on the USB transport in half. 2. The recv timeout is the maximum time to wait for the requested data to arrive. It is mainly a function of sample rate and the number of samples requested in the recv() call. I would not expect changing it to have much of an effect for the use case you describe. For best performance, the number of samples requested should be aligned to the maximum number of samples per frame and the timeout should be set to the number of samples divided by the sample rate plus some margin. The benchmark_rate example included with UHD is a good reference for sizing the buffer and setting the timeout value for optimal performance.
Regards, Michael On Tue, Jun 26, 2018 at 11:59 AM, GhostOp14 via USRP-users < usrp-users@lists.ettus.com> wrote: > I think I found the fix. On the USB2 bus, backing the USRP sample rate > down from 8 MSPS to 7.4 MSPS made the issue go away. This is just > speculation on my part, but even though there was no IP-based traffic to > the LTE card, it was still communicating with the host (status, keepalive, > something). The 8 MSPS rate was probably the max that the setup could > handle and the added LTE USB communications was just enough to disrupt the > USRP recv transfer. Backing the recv size down gave a little more > bandwidth back to the bus to avoid the overrun. I wasn't running into it > on the other systems since they had a more capable CPU and had USB3 buses. > > So this brings up a couple of questions... > 1. When a stream recv is requested is it held in a memory buffer on the > USRP such that the recv call retrieves it in bulk blocks? Or does it truly > need to be processed by the recv loop within a fixed time window so the > stream can continue to operate on the USRP (hence the overruns)? > 2. I had adjusted the recv timeout from the default (0.1) to 0.2 to try to > give it more time for the transfer but that hadn't helped. Given the > scenario above what does that timeout actually adjust? > > I think I have my solution but any insights would be great. > > Thanks! > > > On Mon, Jun 25, 2018 at 12:28 AM, Ian Buckley <i...@ionconcepts.com> > wrote: > >> Perhaps try 'sudo lsusb -v' with and without the LTE modem plugged in and >> see if that reveals any more clues? >> Does uhd_usrp_probe work when the LTE modem is plugged in? >> >> >> On Jun 24, 2018, at 7:14 PM, Marcus D. Leech via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >> On 06/24/2018 10:08 PM, GhostOp14 wrote: >> >> Hi Marcus, tried that too. No luck. Powered the USRP separately, then >> tried powering the LTE separately. Same result. It's as if it can't read >> block data on the USB bus when the LTE is connected. There's no data going >> through the LTE so I'm not sure how that's possible. Especially since it >> works fine as soon as I pull the LTE adapter out. >> >> Well, I'm going to go with "it's the LTE adapter". >> >> >> >> On Sun, Jun 24, 2018 at 5:24 PM, Marcus D. Leech via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> On 06/24/2018 04:25 PM, GhostOp14 via USRP-users wrote: >>> >>>> Hi folks, >>>> >>>> I have a weird issue I've been attempting to troubleshoot for a bit and >>>> I'm stuck. >>>> >>>> So setup: >>>> USRP B205 connected to a Raspberry Pi 3 (so USB 2 mode) >>>> Huawei E3372 USB LTE adapter connected as well >>>> Running the latest Raspbian (stretch) >>>> >>>> Problem: >>>> I'm using C++ code to read stream blocks from the device (800,000 >>>> samples with the USRP set to 8 MSPS, so basically 1 ms of data). Without >>>> the LTE it works fine, I get only infrequent overruns and the rest of the >>>> logic works fine. As soon as the LTE is plugged in and the corresponding >>>> ethernet interface is up, the recv call can't get a whole block of data >>>> (recv returns 0 bytes). If I ifconfig down the interface or unplug the LTE >>>> it goes back to working just fine. Plug it back in or ifconfig up the >>>> interface, problem returns. Of note, there is another network connection >>>> up on the wifi so the LTE is getting a lower priority in the routing table >>>> and there isn't any data going across it (I confirmed it with the >>>> statistics in ifconfig for that interface). >>>> >>>> So troubleshooting so far: >>>> I'm running the latest UHD code (3.11.1 - Just git pulled the latest >>>> today and rebuilt it). >>>> Works fine on Ubuntu 16.04. No issues with both connected (so it's not >>>> my code :)) >>>> There doesn't appear to be any firmware updates to apply to the Huawei >>>> (always worth a shot) >>>> The huawei_cdc_ncm linux driver doesn't appear to have had any updates >>>> in the past couple years (so doesn't look like a linux driver update) >>>> Nothing showing up from dmesg or in /var/log/syslog or >>>> /var/log/messages related to failed recv's. >>>> Made sure there wasn't any data going over the LTE to rule out it's >>>> doing large data transfers >>>> I tested with other USB devices in place of the LTE. Works fine. So >>>> not the port or a general USB issue. >>>> I tried opening the device with num_recv_frames=1024 to see if that >>>> would help, no luck. >>>> I also tried increasing the timeout from the default 0.1 to 0.2 on the >>>> recv call with no luck there either. >>>> >>>> Any suggestions? >>>> >>>> So, two thoughts: >>> >>> The rPi USB power supply isn't really up to the task of supply >>> spec-maximum power to each power. Perhaps your LTE device (combined with >>> B205) is drawing too much power. >>> >>> The USB bus bandwidth is *per controller*, and perhaps there just isn't >>> enough aggregate bandwidth left to service both devices. >>> >>> The B205 has no external-power input, as I recall, but it's mostly >>> designed for USB3.0, where the per-port power is higher. >>> You might try one of those "power booster" USB2.0 "Y" cables, and plug >>> the "power only" plug into a 5.0V USB power supply. >>> >>> >>> >>> _______________________________________________ >>> USRP-users mailing list >>> USRP-users@lists.ettus.com >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>> >> >> >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >> >> > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
