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: Marcus Leech
Subject: Re: [Discuss-gnuradio] Detecting underflows with uhd_usrp_sink
Date: Mon, 10 Jun 2013 14:13:02 +0000 (UTC)

I believe that they are all dropped, but Josh can comment more definitively.

 
on Jun 10, 2013, Sean Nowlan <address@hidden> 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?

"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

reply via email to

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