discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Detecting underflows with uhd_usrp_sink


From: Josh Blum
Subject: Re: [Discuss-gnuradio] Detecting underflows with uhd_usrp_sink
Date: Mon, 10 Jun 2013 13:17:34 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6


On 06/10/2013 09:43 AM, Sean Nowlan wrote:
> Do late packets always get dropped by the USRP? What happens if its buffers 
> get filled up with samples, all of which are late?

The stream args have a policy parameter. Also, these args can be set
from a parameter in the USRP GRC blocks, as well as the constructor for
the gr-uhd blocks themselves.

This should be helpful:
http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1stream__args__t.html#a4463f2eec2cc7ee70f84baacbb26e1ef

-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
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]