Do late packets always get dropped by the USRP? What happens if its
buffers get filled up with samples, all of which are late?
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
See this post in context
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2012-September/005352.html
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
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
The bursts will be dropped as they are consumed by the VITA deframer.
This deframer sits between the TX buffering and the transmit DSP. So
yes, there will be some amount of buffered samples in the device, which
will need to be dropped.
Anything that is due for transmission that is several orders of
magnitude >> ethernet latency should probably stay in the host
application. 
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.
Because the DSP is upstream of the framer. The framer can drain samples
out of the buffering at the rate of the FPGA clock, this is ~100Msps for
the N210.
-josh
On 06/10/2013 01:17 PM, Josh B. 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:
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.