# Buffer size with timed packets

**URL:** <https://www.ruby-forum.com/t/buffer-size-with-timed-packets/242263>\
**Category:** GNU Radio\
**Created:** [June 10, 2015, 7:24pm UTC](https://www.ruby-forum.com/t/buffer-size-with-timed-packets/242263 "2015-06-10T19:24:39Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Detlef\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@Detlef\_R](https://www.ruby-forum.com/u/Detlef_R)\
**Post date:** [June 10, 2015, 7:24pm UTC](https://www.ruby-forum.com/t/buffer-size-with-timed-packets/242263/1 "2015-06-10T19:24:39Z")

</div>

Hi all,

I have a question regarding the timed packets with UHD. Basically I’m  
sending packets from a burst tagger into my UHD sink with a tx\_time tag,  
but after a while I’m getting L’s (late packet, if I’m not wrong) at the  
output.

I tried changing both the packet size and the sample rate of my  
flowgraph  
and, even though the effect is reduced, the L’s are occasionally still  
coming up. More than finding a exact solution (that I’d clearly like to  
get), I want to understand what is happening in there. The time that I’m  
applying for my tx\_time tag is calculated as follows:

future\_time = first\_UHD\_time + delay + relative\_time

where the first UHD time is captured by a parallel rx\_time tag, the  
relative time is the actual sample position (or offset) divided by my  
sample rate, and the delay is user defined. I used a sample rate up to  
400k, but still the same behavior is present.

Our idea to overcome this Late packets here in the lab was at first to  
change the buffer size of the burst tagger (or the UHD sink), so that it  
would be filled with just one packet and then sent right away. However,  
for  
so long I’ve read in other questions, this can reduce like “horse-power”  
of  
out application and also maybe flexibility for future implementations. I  
would gladly hear some opinions about this idea.

I see that the device is waiting for the times given on the tag before  
sending, so that part is working fine. However with delays up to 2  
seconds,  
the L’s still appear. That is where the “stacked” timed packets  
hypothesis  
appeared. The ideal delay is yet to be calculated (I’m experimenting  
first), but a smaller delay (so far) leads to more L’s at the output

Any comment about how to overcome the lateness is welcomed.

Thank you in advance!

Nicolas.