Re: [Discuss-gnuradio] gnuradio transmission delay

[Rick Graham]

On Thu, Jun 14, 2012 at 5:15 PM, Phelps Williams <address@hidden> 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 <address@hidden> 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio