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.


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

Discuss-gnuradio mailing list

Reply via email to