[USRP-users] Detect and react to underflow in gnu radio

Claro Noda noda at complexperiments.net
Fri Oct 2 15:34:23 EDT 2015


Dennis,

you may want to increase the master-clock-rate to help avoid b210's
internal buffers become full.

You may consider defining clock rate in UHD manually, only to improve
serial communication, while maintaining dsp_rate/sample_rate = even.
Alternatively, let uhd do it automatically, but pick a sample rate
that maximizes dsp_rate.

For example, samp_rate=75e5 forces the dsp clock to 60e6
(dsp_rate/sample_rate = 8). While samp_rate=8e6 leads to dsp_rate=32e6
(dsp_rate/sample_rate = 4). The first configuration brings
significantly better serial performance (e.g. very rare overflows over
USB 2) compared to other combination with smaller ratio, near the
upper end of what is possible.

An easy trick you can try before beefing-up your host.

regards,
Claro.


On 2 October 2015 at 19:33, Dennis Zollo via USRP-users
<usrp-users at lists.ettus.com> wrote:
> Martin,
>
> Are there any tricks to using the async message block?  Does anyone out
> there have a code snippet? I tried to send the messages to a file sink with
> the snippet below, but it didn't seem to work. I don't get anything in my
> file even when see the "U" and "L" in stdout due to underflows.  I'm also
> not sure what the first argument should be to uhd.amesg_source - I though it
> would be the identifying string for the device, but now I'm not so sure.
>
> uhd_amsg_source = gr.msg_queue(2)
>
> msg = uhd.amsg_source("name=MyB210", msgq=uhd_amsg_source)
>
> block_msg_src = blocks.message_source(gr.sizeof_gr_complex*1, uhd_am
> sg_source)
>
> msg_sink = blocks.file_sink(gr.sizeof_gr_complex*1, "outfile", False    )
>
> msg_sink.set_unbuffered(True)
>
> self.connect((block_msg_src,0),(msg_sink,0))
>
>
> For some background, I'm getting the underflows when streaming two streams
> over USB3.0 to each channel of a b210.  I have a fast machine and a solid
> state disk in Raid1.  The configuration is below for some more background:
>
> - bitwise packed files (8 bits per byte)
> - sample rate of 16368000.0 hz
> - clock rate of 16368000.0 hz
> - reading the source file in 16 megabytes chunks
> - debian with 4.1 kernel
> - UHD 003.009.000
> - I get occasional underflows
>
> Also, I seem to have fewer underflows when I run with two separate B210s,
> rather than each channel on the same device.  Is this expected behavior, or
> would I expect two channels on one device to operate more or less the same
> as two separate cards?
>
> Best,
> Dennis
>
>
>
> On Fri, Oct 2, 2015 at 9:22 AM, Martin Braun via USRP-users
> <usrp-users at lists.ettus.com> wrote:
>>
>> On 01.10.2015 15:09, Dennis Zollo via USRP-users wrote:
>> > Hello users,
>> >
>> > I am trying to detect the 'U' and 'L'  (underflow & late packet)
>> > messages from transmit on a USRP b210 connected over USB 3.0 and
>> > controlled by gnu radio and python.  I would merely like to know
>> > programmatically that a U or L has occurred and react.  In our case,
>> > this means we should halt our test and invalidate the results.
>> >
>> > Does someone have an example of how to do this?  Should I be using the
>> > asynch message source block?  Should I be registering a stdout callback
>> > through the C++ api?
>>
>> If you're in GNU Radio, you can use the async message block. The only
>> problem is that is uses the legacy message queue model, but it's better
>> than parsing output.
>>
>> > Also, what are some strategies to avoid these "late packet" or
>> > "underflow" errors and or tune them out of a system?
>>
>> Underflow is hard to avoid (other than beefing up your system), late
>> packets can usually be avoided, though. What's causing them in your setup?
>>
>> M
>>
>>
>> _______________________________________________
>> 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
>




More information about the USRP-users mailing list