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:
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.
Discuss-gnuradio mailing list
Discuss-gnuradio mailing list