Re: [Discuss-gnuradio] Detecting underflows with uhd_usrp_sink

[Marcus D. Leech]

> 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