[USRP-users] N210 Stops Transmitting

Ralph A. Schmid, dk5ras ralph at schmid.xxx
Sun Oct 19 07:37:38 EDT 2014


Just as a side note, more and more tablet PCs and ultra slim notebnook come without any Ethernet interface, and the Ethernet surrogate often enough is something like a flimsy USB adapter with 100 or (if lucky) 1000 Mbps, not to mention the Ethernet jack in the power supply - that is fed via WLAN from the notebook :( They really sell crap for its weight in gold sometimes. 

Bad times for those who want lightweight travel systems. 

At least my new MS Surface 3 pro has a docking station with a Gbit interface that seems to be a real one.

Ralph.


-----Original Message-----
From: USRP-users [mailto:usrp-users-bounces at lists.ettus.com] On Behalf Of Marcus Müller via USRP-users
Sent: Saturday, October 18, 2014 4:25 PM
To: Liwei
Cc: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] N210 Stops Transmitting

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141019/441c6619/attachment.sig>


More information about the USRP-users mailing list