[USRP-users] B210 bad packet errors with sc8 wire format

Ian Buckley ianb at ionconcepts.com
Thu Apr 30 12:48:53 EDT 2015


Tyler I've taken note of your (and others) SC8 notes and data and either I or someone else will take a look at this soon. SC8 is a supported wire format for B210 so it's possible there's some form of regression with newer UHD code.
-Ian

On Apr 30, 2015, at 9:40 AM, "Marcus D. Leech via USRP-users" <usrp-users at lists.ettus.com> wrote:

> Both the USB hardware stack and the USB driver stack are completely, utterly different within the kernel, although they may both use the same PCIe interface, the "dynamics" are different.  For one, USB has small, limited, transaction sizes, which leads to unnecessarily high interrupt overhead, depending on controller implementation, whether it aggregates bulk transfers, how good its DMA machinery is, etc.
> 
> Also, the USB "stack" in most operating systems hasn't really had the same amount of aggressive-optimization "love" that the network stack has had over the years, where performance was a concern early-on, driven by large Web servers, etc.  One could argue "what about disk drives over USB", but nobody who cares about disk performance is likely to be putting disk drives on USB.  They'll be on a RAID-capable SATA-III controller right on the PCIe bus, so that's where the optimization has happened, not in USB land.
> 
> There is also the fact that USB-3.0 is relatively "new" in the market, and many controller manufacturers rushed their controllers to market using only high-speed webcams, and relatively-slow disk drives as their testing base.  This doesn't tend to "drive" the performance envelope of the controller and driver stack.
> 
>  
>  
>  
>  
> On 2015-04-30 12:30, Weaver, Tyler wrote:
> 
>> I understand your point about UHD not knowing if the hard drive can swallow the data fast enough.  However, I am able to run rx_samples_to_file with a N210 on the same computer(s) with a rate of 50e6 with no overflows.  That's what has me confused.
>>  
>> tyler
>>  
>>> On Apr 30, 2015, at 10:18 AM, mleech at ripnet.com wrote:
>>> 
>>> I'll comment on your second point.  The rx_samples_to_file example isn't heavily optimized, in particular, it isn't multi-threaded, so
>>>  that filesystem writes aren't decoupled from vacuuming up samples from the hardware.  If you specify /dev/null as the file to write in
>>>  rx_samples_to_file, you'll probably notice that the point at which you start getting 'O' is moved further out.
>>> 
>>> From a 10K-foot perspective the USRP device is like Niagara Falls.  It throws data at you at whatever rate you ask for.  Just as Niagara Falls has no idea how big the bucket is at the bottom you're trying to capture it with, neither does the USRP know or care.  The UHD drivers are roughly as optimized as they can be, given that this stuff is running on a general-purpose operating system, where the OS produces latencies, and buffering and scheduling behavior that are entirely outside of the control of UHD.   And emergent throughput and scheduling
>>>  behaviors on general-purpose, multi-user OSes are hard to control and predict.
>>> 
>>> Now, examples, like rx_samples_to_file *could* be better-optimized, but they're just examples.  They aren't really intended as production applications.  The range of application of USRP hardware is *immense*, there's no way that the UHD team could possibly produce optimized examples that cover all those application domains.  Having said that, rx_samples_to_file *could* be optimized to use multiple threads, and that input has already gone into Ettus R&D.  No prediction on if/when something will happen on that front.
>>> 
>>> For your first point, I'll comment that I use 8-bit mode myself on a B210 at 2 X 11.5Msps on an Odroid XU3.  It works well most of the time, with only an occasional sample drop, but what I *do* find is that 'O' are nearly always accompanied by some vrt packet errors as you observe. I'm hoping that someone from R&D can comment on this.
>>> 
>>>  
>>> On 2015-04-30 12:05, Weaver, Tyler via USRP-users wrote:
>>> 
>>> searching through the list I see that others have problems with sc8 on the b210.  if this is the case and it's not supported, then why doesn't uhd return an error to that affect.  Also, why does it seem to work on the benchmark_rate application?
>>>  
>>> Secondly, this still doesn't explain the overflow errors.  Is there a better method than what is in rx_samples_to_file to get samples form the radio and not result in overflow errors?
>>>  
>>> tyler
>>> 
>>> On Apr 30, 2015, at 8:53 AM, Weaver, Tyler <tweaver at lgsinnovations.com> wrote:
>>> 
>>> Hello,
>>>  
>>> I am getting bad packet errors, the exact error is below when doing sc8 wire format reads with rx_samples_to_file however I get no errors when running benchmark_rate.  What could cause this?
>>>  
>>> I have tested this on 4 separate computers, all with similar specs, i7, 16gig ram, solid stated hard drives on fedora 21, mac OS X, and ubuntu LTS.  In all cases I get the same result.  Also, sc16 with rx_samples_to_file writing to null results in overflow errors on all computers, yet no errors when run with benchmark_rate.  When an overflow error is returned is there a way for me to know how many samples were lost so I could just insert zeros to keep timing accurate?  Also, I don't believe writing to the hard drive is too slow as I have a N210 that I can run rx_smaples_to_file at a rate of 50MS/s with no errors.
>>>  
>>> All of the computers are running UHD 3.8.2 built from source.
>>>  
>>> Thank you for your help.
>>>  
>>> tyler
>>>  
>>>  
>>> $ ./rx_samples_to_file --rate 28e6 —null --args "master_clock_rate=56e6" --freq 2e9 --stats --wirefmt sc8
>>> Mac OS; Clang version 6.0 (clang-600.0.56); Boost_105500; UHD_003.008.002-0-unknown
>>>  
>>>  
>>> Creating the usrp device with: master_clock_rate=56e6...
>>> -- Operating over USB 3.
>>> -- Detecting internal GPSDO.... Found an internal GPSDO
>>> -- 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 56.000000 MHz
>>> -- Actually got clock rate 56.000000 MHz
>>> -- Performing timer loopback test... pass
>>> -- Performing timer loopback test... pass
>>> -- Setting references to the internal GPSDO
>>> -- Initializing time to the internal GPSDO
>>> 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
>>>  
>>> Setting RX Rate: 28.000000 Msps...
>>> Actual RX Rate: 28.000000 Msps...
>>>  
>>> Setting RX Freq: 2000.000000 MHz...
>>> -- Successfully tuned to 2000.000000 MHz
>>> -- 
>>> Actual RX Freq: 2000.000000 MHz...
>>>  
>>> Waiting for "lo_locked": ++++++++++ locked.
>>>  
>>> Press Ctrl + C to stop streaming...
>>>  
>>> UHD Error:
>>>     The receive packet handler caught an exception.
>>>     ValueError: bad vrt header or packet fragment
>>> Error: Receiver error: ERROR_CODE_BAD_PACKET
>>>  
>>>  
>>> 
>>> _______________________________________________
>>> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150430/e37377e9/attachment-0002.html>


More information about the USRP-users mailing list