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

[Mario Rossi]

Ok, I believe I have made up my mind. Since that I'm looking at a packetised 
burst transmission system, the best way I have to remove latency from the 
system is to flush the buffers in the gnuradio flowgraphs.

I can do this easily on the receiver side: once that I finish receiving my RF 
data and I sent the IF samples down the pipe to gnuradio to process, I can just 
add however many padding bytes are needed to have GR finish processing the 
actual RF samples I care about. Packet synchronisation is going to take care of 
discarding the padding/flushing bytes. Latency is then going to depend on my 
CPU speed. That's good enough.

On the transmission side though, things are slightly more complicated. I could 
send the same packet continuously and from the flowgraph output, sample 2 or 3 
times the (known) packet length. This will ensure I have a IF modulated version 
of at least 1 or 2 copies of the same packet. This is not perfect, but it 
should be good enough. 

Are they any blocks I could use to better synchronise the data input on my 
transmitter flowgraph to its RF modulated output? For example, would the meta 
file sink/source blocks help me with this? Can I use them to tell me "those 
many input bytes are responsible for those many modulated bytes"?

Thank you,
Mario

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On April 5, 2018 10:41 PM, Mario Rossi <address@hidden> 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