Re: [Discuss-gnuradio] Detecting underflows with uhd_usrp_sink

[Josh Blum]

> 
> Ok, makes sense. So lets say I scheduled 20 minutes of bursts (1 second
> period with 50/50 duty cycle) and I started the flowgraph 10 minutes
> late. With the "next_burst" policy, could I rely on the USRP to
> dutifully drop all late bursts? Are the packets dropped in the Ethernet
> buffer or does the TX sample buffer fill up first? If it's the latter


The bursts will be dropped as they are consumed by the VITA deframer.
This deframer sits between the TX buffering and the transmit DSP. So
yes, there will be some amount of buffered samples in the device, which
will need to be dropped.

Anything that is due for transmission that is several orders of
magnitude >> ethernet latency should probably stay in the host
application. :-)

> case, my scenario implies that the TX buffer will have to be filled and
> emptied multiple times until there are no more late packets, and normal
> transmissions begin. This would happen at the sample rate times the
> number of samples sent.
> 

Because the DSP is upstream of the framer. The framer can drain samples
out of the buffering at the rate of the FPGA clock, this is ~100Msps for
the N210.

-josh

> I suppose I'd also want to implement a message handler to drop the flood
> of "L" symbols before they get piped to STDERR/STDOUT.
> 
> Do I have the right understanding of this process? Thanks!
> 
> --sean
> 
> P.S. -- Copying to USRP list since this could be relevant to people there.
> 
>> -josh
>>
>>> "Marcus D. Leech" <address@hidden> wrote:
>>>
>>>>> L = late packet, there was a time on the packet which was>  time on
>>>>> device when
>>>>>
>>>>>
>>>> There are two different "cases" for late packets happening.
>>>>
>>>> The first is that you haven't sent your packet far enough in advance to
>>>> account for latency variations on the host.  Unfortunately, on a
>>>> general-purpose
>>>>    OS like Windows or Linux, latency variability can be extreme, and
>>>> for
>>>> long-running flow-graphs you might need to develop a good model to
>>>> determine
>>>>    what the worst-case is and account for that.
>>>>
>>>> The second is that the clock on the USRP and the clock on the host will
>>>> tend to drift apart over time, particularly if both of them are "free
>>>> running".
>>>>    So when you schedule timed bursts far enough in advance during the
>>>> start of a "session", it's entirely possible that after quite some
>>>> time, the
>>>>    two clocks have drifted apart unfavourably in terms of allowing you
>>>> to schedule things far enough in advance, relative to the USRP clock.
>>>>    PC clocks are *terrible* by themselves.  They'll drift significant
>>>> fractions of a second on a daily basis without any outside steering.
>>>>   The USRP
>>>>    clock, even free-running, is typically much, much better.
>>>>
>>>>
>>>> -- 
>>>> Marcus Leech
>>>> Principal Investigator
>>>> Shirleys Bay Radio Astronomy Consortium
>>>> http://www.sbrac.org
>>>>
>>>>
>>>> _______________________________________________
>>>> Discuss-gnuradio mailing list
>>>> address@hidden
>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio