On Thu, Jun 14, 2012 at 5: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. > 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? > > 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 >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
