I have a simple bpsk transmitter setup with a custom udp source block
which outputs a fixed pattern if no data is available from the socket.
I have instrumented the block to indicate when data is read from the
socket inside of work().
My radio looks like this:
Custom UDP Source -> DPSK Mod (DBPSK, 10 samp/sym) -> Multiply Const
(0.3) -> UHD: USRP Sink
My sample rate is 1e6.
I can tell from my instrumented UDP Source that udp traffic is handled
by work and passed on almost immediately. However I can tell from
both monitoring the spectrum and the receiver output on the other side
that the data takes between 7 and 10 seconds before I see the expected
output from the N200. I thought this could be improved by reducing
the maximum socket buffer size (sudo sysctl -w
net.core.wmem_max=5000000) but that didn’t seem to make a difference.
I went as low as wmem_max=10000 with no difference in delay. My goal
is to get the total delay to < 1sec.
What else could be adding delay to my transmission path? Are there
other buffers I can tweak? Where else should I be looking?
What else could be adding delay to my transmission path? Are there
other buffers I can tweak? Where else should I be looking?
Well the usrp only has a megabyte of buffering, as does the socket. At
that rate, you couldnt not be buffering more than half a second’s worth
in the post-gnuradio part of the chain.
I bet you have produced a lot of data all at once, filled up all of the
gnuradio buffering, and you are simply measuring the time it takes to
drain these buffers at a rate of 1Msps.
If thats the case, you might pace your inputs. Or not transmit when you
have nothing to transmit, this lets things flush out and idle.
I am not throttling the amount of data generated by my custom udp
source. I am generating enough output to match noutput_items passed
as the first argument to work(). My understanding is that
noutput_items is the number of bytes the main event loop is requesting
from my block for it to prevent an underrun. What establishes this
demand? How is this noutput_items value generated?
I notice in the first two calls to work() noutput_items == 32768.
After those first two cycles it settles down to match the expected
data rate. I think the correct solution is to change the total amount
of buffering that is driving that demand rather than institute
throttling in my core which will surely not be quite in sink with the
UHD throttling source.
Running the same test with a normal udp source results in the data
being instantaneously modulated as I would expect. It seems clear
that large buffers resulting in a large noutput_items is the source of
this issue.
Any idea on how to modify these per block buffer sizes?
I found that I can specify max_noutput_items when calling
top_block::start(). This however doesn’t appear to do anything but
delay the onset of this large amount of latency as the various blocks
will still seem to request the maximum available. Setting this to the
exact rate I expect the radio to consume results in a steady flow of
UHD buffer underruns but enough data gets through for me to confirm
the latency has disappeared.
My problem still remains however, I need to reduce the amount of
buffer each block is attempting to maintain.
Because this is universal to the build and not radio specific it does
present performance issues at higher rates. Is it possible to modify
this allocated block buffer size when building the flowgraph?
I’m a virtual noob here, but this issue is interesting.
When there is actual UDP source, there is essentially no latency issue,
right?
Could the synthesized output with no input consumption be “confusing”
the
scheduler? When the scheduler calls forecast/work and there is no
input,
what happens?
Do you call produce or produce_each directly after synthesizing output?
If you set the environment variable GR_SCHEDULER to STS, do you see the
same symptoms.
of buffering that is driving that demand rather than institute
throttling in my core which will surely not be quite in sink with the
UHD throttling source.
Running the same test with a normal udp source results in the data
being instantaneously modulated as I would expect. It seems clear
that large buffers resulting in a large noutput_items is the source of
this issue.
If “the same test with a normal udp source results in the data being
instantaneously modulated”, how are the buffers to blame? The normal
UDP
source uses the same buffers, right? Or have I missed something here?