[USRP-users] USRP B210 RX Overflow

Younes KHADRAOUI younes.khadraoui at telecom-bretagne.eu
Tue Apr 28 09:53:45 EDT 2015


Marcus, 

I tried also the USB 2 ports, this time the overflow occurs quicker :s

Regards,
Younes

----- Mail original -----
De: "Marcus Müller" <marcus.mueller at ettus.com>
À: "Younes KHADRAOUI" <younes.khadraoui at telecom-bretagne.eu>
Cc: usrp-users at lists.ettus.com
Envoyé: Mardi 28 Avril 2015 15:50:01
Objet: Re: [USRP-users] USRP B210 RX Overflow

Hi Younes,

I don't know the Wellsburg chipset; but this means you have two USB2
controllers and one USB3 controller. Can you try one of the black USB ports?

Greetings,
Marcus

On 04/28/2015 03:46 PM, Younes KHADRAOUI wrote:
> Hello Marcus, 
>
> Thank you for your answer. Here is the result of lspci|grep -i usb:
>
> 00:14.0 USB controller: Intel Corporation Wellsburg USB xHCI Host Controller (rev 05)
> 00:1a.0 USB controller: Intel Corporation Wellsburg USB Enhanced Host Controller #2 (rev 05)
> 00:1d.0 USB controller: Intel Corporation Wellsburg USB Enhanced Host Controller #1 (rev 05)
>
> It does not look like the ones cited bu Ettus ! what do you think ? 
>
> Regards,
>
> ----- Mail original -----
> De: "Marcus Müller via USRP-users" <usrp-users at lists.ettus.com>
> À: usrp-users at lists.ettus.com
> Envoyé: Mardi 28 Avril 2015 15:38:30
> Objet: Re: [USRP-users] USRP B210 RX Overflow
>
> Hi Younes,
>
> that is actually a rate that you should be able to do with USB2.
> Thus, it's probably really your USB3 controller behaving massively
> erratically -- you can find out what model it is by executing
>
> lspci|grep -i usb
>
> Greetings,
> Marcus
>
> On 04/28/2015 12:46 PM, Younes KHADRAOUI via USRP-users wrote:
>> Hello usrp community, 
>>
>> I'm trying to run some software with a USRP B210 card. I'm using a Dell T5810 with a Processor Intel Xeon E5-1650 v3 (3,5GHz, six cores, 15Mo cache memory, Turbo, HT). The USRP is connected to a USB 3.0 port. I'm using the last UHD release (UHD_003.009.git-144-g407e3086). I also disabled all power management features in the BIOS and in the kernel.
>>
>> The software runs correctly for a while (few seconds) but the UHD does not reply fast enough and the software crashes and prints a "RX overflow" message. Here is the benchmark:
>>
>> $ sudo /usr/lib64/uhd/examples/benchmark_rate --tx_rate 7.68e6 --rx_rate 7.68e6 --args "master_clock_rate=30.72e6"
>>
>> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.009.git-144-g407e3086
>>
>>
>> Creating the usrp device with: master_clock_rate=30.72e6...
>> -- Operating over USB 3.
>> -- Initialize CODEC control...
>> -- Initialize Radio control...
>> -- Performing register loopback test... pass
>> -- Performing register loopback test... pass
>> -- Performing CODEC loopback test... pass
>> -- Performing CODEC loopback test... pass
>> -- Asking for clock rate 30.720000 MHz... 
>> -- Actually got clock rate 30.720000 MHz.
>> -- Performing timer loopback test... pass
>> -- Performing timer loopback test... pass
>>
>> UHD Warning:
>>     The requested decimation is odd; the user should expect CIC rolloff.
>>     Select an even decimation to ensure that a halfband filter is enabled.
>>     decimation = dsp_rate/samp_rate -> 123 = (30.720000 MHz)/(0.250000 MHz)
>>
>> UHD Warning:
>>     The requested interpolation is odd; the user should expect CIC rolloff.
>>     Select an even interpolation to ensure that a halfband filter is enabled.
>>     interpolation = dsp_rate/samp_rate -> 123 = (30.720000 MHz)/(0.250000 MHz)
>>
>> UHD Warning:
>>     The requested decimation is odd; the user should expect CIC rolloff.
>>     Select an even decimation to ensure that a halfband filter is enabled.
>>     decimation = dsp_rate/samp_rate -> 123 = (30.720000 MHz)/(0.250000 MHz)
>>
>> UHD Warning:
>>     The requested interpolation is odd; the user should expect CIC rolloff.
>>     Select an even interpolation to ensure that a halfband filter is enabled.
>>     interpolation = dsp_rate/samp_rate -> 123 = (30.720000 MHz)/(0.250000 MHz)
>> Using Device: Single USRP:
>>   Device: B-Series Device
>>   Mboard 0: B210
>>   RX Channel: 0
>>     RX DSP: 0
>>     RX Dboard: A
>>     RX Subdev: FE-RX2
>>   RX Channel: 1
>>     RX DSP: 1
>>     RX Dboard: A
>>     RX Subdev: FE-RX1
>>   TX Channel: 0
>>     TX DSP: 0
>>     TX Dboard: A
>>     TX Subdev: FE-TX2
>>   TX Channel: 1
>>     TX DSP: 1
>>     TX Dboard: A
>>     TX Subdev: FE-TX1
>>
>> Testing receive rate 7.680000 Msps on 1 channels
>> Testing transmit rate 7.680000 Msps on 1 channels
>>
>> Benchmark rate summary:
>>   Num received samples:    76801256
>>   Num dropped samples:     0
>>   Num overflows detected:  0
>>   Num transmitted samples: 76866664
>>   Num sequence errors:     0
>>   Num underflows detected: 0
>>
>>
>> Done!
>>
>> I also checked that my usb host controller is not one listed here http://www.ettus.com/kb/detail/usrp-b200-and-b210-usb-30-streaming-rate-benchmarks. Here is the result of lsusb: 
>>
>> Bus 002 Device 002: ID 8087:8002 Intel Corp. 
>> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>> Bus 001 Device 002: ID 8087:800a Intel Corp. 
>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>> Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
>> Bus 003 Device 003: ID 413c:2107 Dell Computer Corp. 
>> Bus 003 Device 002: ID 046d:c077 Logitech, Inc. 
>> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>>
>> As the software is running, I also checked the CPU frequency and they were all at the maximum. 
>>
>> I'm stuck here for several weeks now. Any suggestion about what can be the reason of the overflow ?
>>
>> Thank you in advance,
>>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>


-- 
Younes Khadraoui
PhD Student, Network Security and Multimedia Department.
IRISA/Telecom Bretagne.




More information about the USRP-users mailing list