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