Re: [Discuss-gnuradio] Ways to improve latency of a low bandwidth stream

[Mario Rossi]

Johannes,

Thank you, those were good inputs and I tried running some tests with it. Yes, 
I'm using an SDR in that loop (hackrf). I fixed a problem with my code and got 
rid of most of the jitter, the latency is now stable around 60-70 milliseconds.

I tried measuring latency of a file source, unpack k bits and file sink blocks 
back to back. There is no throttle block and the transmitter is sending one new 
packet every 6 milliseconds. At the receiving end, the read operation is 
blocked for 50 milliseconds at the time and I then receive the packets created 
in the previous 50 milliseconds, with the last packet being only 6 milliseconds 
late. To rephrase, every 50 milliseconds the read operation on the output queue 
becomes available and I get packets with latencies 6, 12, 18, etc. ms up to 
~50ms. I believe this means 128 bytes it the minimum buffer gnuradio will 
process somewhere in one of those blocks, and all my data gets processed at 
once when that happens. By lowering the time between transmitted blocks to 1 
ms, I of course receive them still in chunks of 8, 1 ms apart.

I then tried merging my tx and rx flow graphs into one, removing the pipes 
where the SDR was, and I got down to 20-60 ms as a latency. Not that much of an 
improvement! Somehow the receiver isn't blocked anymore for 50 ms at the time 
and I now get the packets in a consistent flow, they are just all late. Anyway 
this means that the latency added by the tx/rx hardware is in the order of 
10-20 ms, that is acceptable for now and I should be able to tune later.

By increasing baud rate 5 times, minimum latency in the same setup went down to 
around 10 ms, but average and maximum latency stayed around 40-60 ms.

Here is my flowgraph, even if I don't find it that interesting: 
https://i.imgur.com/DaimCjD.png

I don't know, but I believe hacking gnuradio's scheduler (telling it to empty 
buffers much, much sooner than it is) might be one of the simplest options 
here. Or maybe moving to a faster computer might work just as well. I don't 
understand the difference in latency between the first two tests, as in why I 
get this fixed 128 bytes buffer with the simple flowgraph, but a granular 
output with the more complex one? Anyway, I will keep working on this, see if I 
can find anything to improve.

Thanks again,
Mario


On April 6, 2018 8:38 AM, Johannes Demel <address@hidden> wrote:

> Hi Mario,
> 
> to sum it up
> 
> -   your packet duration is:
>     
>     128bit(in your case also symbols)/50kBaud/s = 2.56ms
>     
> -   Your "device" sample rate is 50kBaud/s * 20 = 1MSps.
>     
>     First, do you use any hardware? Or is this just a simulation for now?
>     
>     If it is a simulation, do you use a throttle block?
>     
>     In case it is a simulation (no hardware) and you don't use a throttle
>     
>     block, the above mentioned calculations are meaningless because in this
>     
>     case all calculation will be performed as fast as possible.
>     
>     In order to figure out your latency bottleneck, I'd suggest to figure it
>     
>     out as follows:
>     
> -   start with your stream pipe blocks back-to-back. Measure latency.
> -   Add mod/demod blocks one after the other and see how latency increases
>     
>     (or does not).
>     
> -   This should help you to identify the bottleneck in your system.
> -   Also, a full flowgraph would be helpful for the discussion here.
>     
>     In case your bottlenecks are your pipes, you can investigate these
>     
>     blocks operations and potentially fix them. I'm sure any addition to
>     
>     make these blocks perform better are welcome.
>     
>     The maximum output buffer sizes are usually aligned to memory pages. In
>     
>     most cases page sizes are 4kB.
>     
>     I hope I could give you a hint on how to narrow down your problem. I'm
>     
>     curious where the bottleneck is.
>     
>     Cheers
>     
>     Johannes
>     
>     On 05.04.2018 23:41, Mario Rossi wrote:
>     
> 
> > Hello list!
> > 
> > I'm using named pipes to stream data that I want modulated to gnuradio and 
> > I'm receiving modulated samples back using the same named pipes method. I 
> > then forward the modulated samples to a SDR via some low latency C 
> > implementation I wrote and perform the same operations in reverse at the 
> > receiving end.
> > 
> > I'm for now experimenting with a simple FSK modulator/demodulator running 
> > at 50 kbaud/s, with 20 samples per symbol and 16 bytes (128 symbols) packet 
> > sizes. By embedding a timestamp in the packets before sending them I'm 
> > measuring an end to end latency ranging from 50 to 250 milliseconds (with a 
> > lot of jitter).
> > 
> > This should mean that I have at least 300-1500 KB worth of buffers in my 
> > application (this was calculated using the data rate of the input/output 
> > data, it would be a much bigger number if I considered the modulated 
> > signal).
> > 
> > My understanding is that most of the latency is coming from my input/output 
> > pipes/sinks, as once the signal is modulated each byte of my data in/out 
> > becomes 8 (bits per byte) * 20 (samples per symbol), so that each gnuradio 
> > block working with the modulated signal, in a worst case scenario where 
> > 4096 samples are processed at the time, only corresponds to 25 bytes worth 
> > of buffered, unmodulated data at any given time (4096/(8*20)). Since that 
> > my buffer is at least 100 times that and I don't have 100 blocks, that 
> > shouldn't be the issue.
> > 
> > Now on to my ideas on how to decrease latency for the input/output 
> > pipes/blocks:
> > 
> > 1.  Add padding bytes after the packet before sending it to the pipe/input 
> > file source block. Add a block after the file source dropping those padding 
> > bytes, that would probably require writing a custom block but should 
> > effectively eliminate any latency due to pipes and the file source block. A 
> > similar method can be used for the file sink block.
> >     
> > 2.  Use gr-eventstream to implement some version of the above. Not sure if 
> > this would be of any use though, I haven't spent much reading about it.
> >     
> > 3.  Hack the input/output sink blocks to (for example) allow a maximum 
> > output buffer lower than 4096 (I'm met with an error when I try to set the 
> > output buffer of my file source block to anything less than that).
> >     
> > 4.  Same as the first idea, but don't drop the padding bytes/data. Instead 
> > leave the blocks running with junk at the end, so that the output will be 
> > what you want and junk there after. This isn't a problem at the receiver 
> > because of how packet synchronisation works, but you would need to somehow 
> > know what's going on with your output IF pipe in your transmitter stream. 
> > This would also get rid of all the buffers/latency from all of gnuradio.
> >     
> > 
> > Any other ideas, or suggestions on what is the most feasible path?
> > 
> > I hope this email isn't too confusing, I know I don't have a gift for 
> > writing.
> > 
> > Thank you.
> > 
> > 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