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" <mle...@ripnet.com> 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 >Discuss-gnuradio@gnu.org >https://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
