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. On Thu, Jun 14, 2012 at 2:15 PM, Phelps Williams <phel...@gmail.com> wrote: > 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? > > > On Wed, Jun 13, 2012 at 5:58 PM, Josh Blum <j...@ettus.com> wrote: >> >> >> On 06/13/2012 05:15 PM, Phelps Williams wrote: >>> 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? >>> >> >> 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. >> >> -josh >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
