|
From: | Sean Nowlan |
Subject: | Re: [Discuss-gnuradio] Detecting underflows with uhd_usrp_sink |
Date: | Mon, 10 Jun 2013 13:58:13 -0400 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 |
On 06/10/2013 01:17 PM, Josh Blum wrote:
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
Ok, makes sense. So lets say I scheduled 20 minutes of bursts (1 second period with 50/50 duty cycle) and I started the flowgraph 10 minutes late. With the "next_burst" policy, could I rely on the USRP to dutifully drop all late bursts? Are the packets dropped in the Ethernet buffer or does the TX sample buffer fill up first? If it's the latter case, my scenario implies that the TX buffer will have to be filled and emptied multiple times until there are no more late packets, and normal transmissions begin. This would happen at the sample rate times the number of samples sent.
I suppose I'd also want to implement a message handler to drop the flood of "L" symbols before they get piped to STDERR/STDOUT.
Do I have the right understanding of this process? Thanks! --sean P.S. -- Copying to USRP list since this could be relevant to people there.
-josh"Marcus D. Leech" <address@hidden> wrote:L = late packet, there was a time on the packet which was> time on device whenThere 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_______________________________________________ Discuss-gnuradio mailing list address@hidden https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Prev in Thread] | Current Thread | [Next in Thread] |