[USRP-users] N210 Stops Transmitting

Marcus D. Leech mleech at ripnet.com
Sat Oct 18 12:23:17 EDT 2014

On 10/18/2014 10:25 AM, Marcus Müller via USRP-users wrote:
> The Realtek controller should work, and I don't know about the USB3
> adapter, so I'd blame your managed switch, but you said that you already
> tried without it...
> Using anything but Gigabit ethernet really won't help. And as the USRP
> *needs* Gigabit ethernet (it's not fast-ethernet compatible itself), you
> won't be able to directly connect your USRP to a fast ethernet
> controller. But since I haven't seen any laptop that has USB3 but only
> fast ethernet
> So, even at your rather low sampling rates, would you mind having a look
> at the output of "top", especially at the %CPU line?
> How much time does, while transmitting, your system spend in idle
> ("id"), how much in userland ("us")?
> The fact that GQRX works rather smoothly (ok, only up to 10MS/s, but
> that's quite an ok number considering we're doing FFTs and render the
> results in real time) but transmitting a few kS/s doesn't really is a
> mystery to me. Are you sure that not, for some reason, Ubuntu decides to
> reconfigure the network interface in the midst of operation? Do you
> really only have a signal source and a USRP sink in your flow graph?
> Does the tx_waveforms example that we ship with UHD work, e.g.:
> /usr/local/lib/uhd/examples/uhd_tx_waveforms --rate 250000 --freq
> <carrier freq>
> Greetings,
> Marcus
I would check to make absolutely certain that NetworkManager isn't 
reasserting its control over the ethernet device, and shutting it down when
   DHCP fails.

Also, check dmesg to see if there are any unusual error messages 
involving your ethernet interface.

> On 18.10.2014 14:43, Liwei wrote:
>> Hi Marcus,
>>      Thanks for the reply. I guess it is likely that the network
>> interfaces I've tried are buggy. Here's what you've asked for:
>>          01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
>> RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 07)
>>      I've also tried one of those new USB3 ethernet adapters (seeing
>> that the laptop only has fast ethernet):
>>          Bus 004 Device 013: ID 0b95:1790 ASIX Electronics Corp.
>>      And out of desperation, Wi-Fi:
>>          02:00.0 Network controller: Qualcomm Atheros AR9485 Wireless
>> Network Adapter (rev 01)
>>      I'm going to try a different linux distribution today.
>> Regards,
>> Liwei
>> On 18 October 2014 19:49, Marcus Müller<usrp-users at lists.ettus.com>  wrote:
>>> Hi Liwei,
>>> "SU" is bad, because
>>> "U" stands for underflow, which means the USRP hasn't gotten enough
>>> samples in time and ran out of things to transmit.
>>> The "S" represents a sequence error, which can only happen if for some
>>> reason network packets got lost or reordered.
>>> I haven't seen these errors very often, and in the few cases, it was due
>>> to either a heavily underpowered PC, being so busy with signal
>>> processing that the kernel just had to drop network packets, or due to a
>>> horribly buggy network card, but you seem to achieve reasonable
>>> throughput, so I'm a bit out of ideas here. Nevertheless, could you
>>> share what
>>> "lscpi|grep -i ethernet"
>>> tells you?
>>> Greetings,
>>> Marcus
>>> On 18.10.2014 12:06, Liwei via USRP-users wrote:
>>>> Hello list,
>>>>      Anyone with any suggestions? I understand that a "U" in the debug
>>>> output indicates an underflow, but am not sure why that should cause
>>>> gnuradio to stop sending samples.
>>>> Thanks
>>>> On 9 October 2014 01:10, Liwei<xieliwei+usrp at gmail.com>  wrote:
>>>>> Hello list,
>>>>>      This may have been asked before (I vaguely remember seeing an
>>>>> email with a similar issue some time back), but what causes UHD to
>>>>> stop sending transmission packets to an N210?
>>>>>      With a simple flowgraph [signal source] ->  [uhd sink] at 200k
>>>>> sample rate over gigabit ethernet, I get up to about 3 seconds of
>>>>> transmission before everything suddenly goes silent.
>>>>>      Here's what I see logged:
>>>>> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.002-107-g0ca4b4f8
>>>>> -- Opening a USRP2/N-Series device...
>>>>> -- Current recv frame size: 1472 bytes
>>>>> -- Current send frame size: 1472 bytes
>>>>> SU
>>>>>      Nothing else after "SU".
>>>>>      Interestingly, if I add a receive + fft chain in the same
>>>>> flowgraph, the receive stream works fine even after the transmission
>>>>> has stopped. In fact, if I loop the TX and RX ports on the N210
>>>>> together (with an attenuator in between) I can see, in the received
>>>>> signal fft, the frequency peak for the few seconds the N210 is able to
>>>>> transmit.
>>>>>      Gqrx also works well receiving FM radio stations all the way up to
>>>>> about 10MHz sampling rate, after which samples start to get dropped.
>>>>>      I'm running on a fresh install of Ubuntu 14.04, with everything
>>>>> installed using pyBOMBS. I've tried switching to yesterday's 3.7.3
>>>>> maint branch but no difference. Firmware and FPGA image were updated
>>>>> after each version switch.
>>>>>      Attached is a screenshot in Wireshark showing the sudden
>>>>> transmission stop. Note that only packets originating from the
>>>>> computer is shown.
>>>>>      Also attached is the output from uhd_usrp_probe.
>>>>>      $ uname -a
>>>>> Linux Ubuntu 3.15.0-031500rc2-generic #201404201435 SMP Sun Apr 20
>>>>> 18:36:18 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
>>>>>      It may be due to a buggy ethernet adapter, but I've achieved over
>>>>> 900MBits/s for both TX and RX over iperf. I've also tried another Fast
>>>>> (instead of gigabit) ethernet adapter and even Wi-Fi, but no
>>>>> difference. There is currently a Dell managed switch in-between the
>>>>> computer and N210, but I've tried directly connecting both together
>>>>> with no difference in results either.
>>>>>      Also, the current setup works flawlessly with a B210 which I have on hand.
>>>>>      At this point, any hint would be great!
>>>>> Thanks
>>>>> Liwei
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> USRP-users at lists.ettus.com
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users at lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

More information about the USRP-users mailing list