[USRP-users] USRP N310 Performance Issues
Marcus D Leech
patchvonbraun at gmail.com
Tue Jan 28 18:34:02 EST 2020
Let’s do some quick math, shall we?
5msps with 16-bit complex == 160Mbit/second
1.25msps with 16-bit complex samples == an additional 40mbit-second
Unless you have super reliable 1Gig wireless infrastructure, this just isn’t going to work.
Sent from my iPhone
> On Jan 28, 2020, at 6:23 PM, Austin Adam via USRP-users <usrp-users at lists.ettus.com> wrote:
> Hey Nate,
> Thanks for the quick response as always! I tried editing those files in the past, but I remember having issues because they were locked or I wasn’t able to actually save any changes that I made. Is there a way to do it directly via the jtag and using the screen command to speak with the N310?
> Also, unfortunately for the current project I am working on, we really need to have a wireless connection to the USRPs via the router. I am sure there is some way to make it work because we can still get data that looks good, it just starts to get clunky after a few seconds of streaming.
>>> On Jan 28, 2020, at 3:07 PM, Nate Temple <nate.temple at ettus.com> wrote:
>> Hi Austin,
>> The MTUs on your host and N310 must match. You should modify the systemd configuration on the N310 are restart the whole device or restart systemd-networkd
>> It is not recommended to stream over a wireless connection as the additional delay will cause flow control errors. It is also generally recommended to not have a switch in line as some switches can reorder packets. You should directly connect to the USRP for the streaming interfaces. On the N3xx, it's fine to access the RJ45 management port via a switch.
>> Nate Temple
>>> On Tue, Jan 28, 2020 at 2:52 PM Austin Adam via USRP-users <usrp-users at lists.ettus.com> wrote:
>>> Hi everyone,
>>> I have a very basic GNU script with just a USRP block and a time sink that when I run, there are tons of streaming errors with the tx and rx. In GNU, the console is being filled with 'D's and the console for the N210 is getting filled with 'U's and 'S's.
>>> My setup is just a USRP N210 connected to the RX LO ports of the N310. I am sending the following command to the N210:
>>> "sudo '/home/austin/workarea-uhd/uhd/host/build/examples/tx_waveforms' --args "addr=192.168.10.15,type=usrp2" --freq 3.90000e9 --ant "TX/RX" --subdev "A:0" --channels 0 --rate 1.25e6 --gain 29.5"
>>> The USRPs are connected to a router via cat 5e cables, and then my laptop is connected to the router via wifi. Something I noticed is that when I connect to the router via ethernet to my laptop, I don't get any of the performance issues. It seems to only happen over the wifi.
>>> When I run ifconfig on my laptop, my MTU is set to 1500, and on the USRP N310 the MTU on the sfp0 port that we are using is 8000. I wasn't able to change the MTU on the N310 because it said the device was in use, but those values seem to work fine over ethernet so I didn't look too much into it.
>>> The sample rate on my GNU script is set to 5M for now, and lowering it does seem to reduce the amount of 'D's that I get, but also negatively affects our data.
>>> Lastly, here is some output from the N210 that shows the error:
>>> austin at Austin-Blade:~$ sudo '/home/austin/workarea-uhd/uhd/host/build/examples/tx_waveforms' --args "addr=192.168.10.15,type=usrp2" --freq 3.90000e9 --ant "TX/RX" --subdev "A:0" --channels 0 --rate 1.25e6 --gain 29.5
>>> Creating the usrp device with: addr=192.168.10.15,type=usrp2...
>>> [INFO] [UHD] linux; GNU C++ version 8.3.0; Boost_106700; UHD_3.14.0.HEAD-0-g6875d061
>>> [INFO] [USRP2] Opening a USRP2/N-Series device...
>>> [INFO] [USRP2] Current recv frame size: 1472 bytes
>>> [INFO] [USRP2] Current send frame size: 1472 bytes
>>> Using Device: Single USRP:
>>> Device: USRP2 / N-Series Device
>>> Mboard 0: N210r4
>>> RX Channel: 0
>>> RX DSP: 0
>>> RX Dboard: A
>>> RX Subdev: SBXv3 RX
>>> TX Channel: 0
>>> TX DSP: 0
>>> TX Dboard: A
>>> TX Subdev: SBXv3 TX
>>> Setting TX Rate: 1.250000 Msps...
>>> Actual TX Rate: 1.250000 Msps...
>>> Setting TX Freq: 3900.000000 MHz...
>>> Setting TX LO Offset: 0.000000 MHz...
>>> Actual TX Freq: 3900.000000 MHz...
>>> Setting TX Gain: 29.500000 dB...
>>> Actual TX Gain: 29.500000 dB...
>>> Setting device timestamp to 0...
>>> Checking TX: LO: locked ...
>>> Press Ctrl + C to stop streaming...
>>> UUUSUUUU[ERROR] [USRP2] Control packet attempt 0, sequence number 470:
>>> RuntimeError: no control response, possible packet loss
>>> I appreciate any help that anyone has to offer!
>>> USRP-users mailing list
>>> USRP-users at lists.ettus.com
> USRP-users mailing list
> USRP-users at lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users