Latency on TX for low data rate systems

GNU Radio
#1

Hello,

I have a very low data rate FSK system (<100 bps). The problem is the
enormous latency introduced by the inter-block buffers. (I am running
in
ms windows). The buffer granularity is apparently 64kB. I
upsample/interpolate the data to around 500 kHz before sending it to
hardware. The buffers get filled up on startup from the data source,
and
any new data takes forever to come out. (64k/100 = 600sec!) Is there a
way to make the inter-block buffers MUCH smaller? Or, at least make
them
different size depending on the actual sample rate? What other options
can anyone propose?

Thanks.

#2

On Mon, Dec 03, 2007 at 11:31:03AM -0800, Eugene Grayver wrote:

can anyone propose?
Under Linux (and most other systems) you can reduce the buffering
down to 4KB (the page size). The windows API we’re using only allows
us to map an area of memory on a 64KB boundary, thus the high amount
of buffering.

However, you may want to reduce the rate at which you’re generating
data. From your description, it sounds like you have an unthrottled
source feeding a small pipe. Are you transmitting continously or are
there bursts/packets/frames of bits?

Eric

#3

Hi Eric,

I cannot reduce the sample rate at the sink since there are additional
signals being added to the FSK. The FSK transmitter is bursty – there
will be no data for long periods of time, followed by a few bits of
data.
E.g. a udp packet comes in and needs to be sent out. I was considering
using the gr_throttle block, but it will not give me the desired result.
Even if the throttle rate is slightly different than the actual TX rate,
the intermediate buffers will eventually either underflow (unacceptable)
or fill up, resulting in the same latency issue.

I am considering a minor change to the gr_single_threaded_scheduler such
that the min_available_space returns not the actual available space, but
a
min(min_available_space, max_buffer_depth), where max_buffer_depth is a
block-specific parameter. Naturally, I would rather not do major
surgery
on the runtime blocks, but I can’t think of any other solutions.

Thanks,
Eugene.

Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274

Eric B. [email protected]
12/03/2007 12:16 PM

To
Eugene Grayver [email protected]
cc
[email protected]
Subject
Re: [Discuss-gnuradio] Latency on TX for low data rate systems

On Mon, Dec 03, 2007 at 11:31:03AM -0800, Eugene Grayver wrote:

Hello,

I have a very low data rate FSK system (<100 bps). The problem is the
enormous latency introduced by the inter-block buffers. (I am running
in
ms windows). The buffer granularity is apparently 64kB. I
upsample/interpolate the data to around 500 kHz before sending it to
hardware. The buffers get filled up on startup from the data source,
and
any new data takes forever to come out. (64k/100 = 600sec!) Is there a
way to make the inter-block buffers MUCH smaller? Or, at least make
them
different size depending on the actual sample rate? What other options
can anyone propose?

Under Linux (and most other systems) you can reduce the buffering
down to 4KB (the page size). The windows API we’re using only allows
us to map an area of memory on a 64KB boundary, thus the high amount
of buffering.

However, you may want to reduce the rate at which you’re generating
data. From your description, it sounds like you have an unthrottled
source feeding a small pipe. Are you transmitting continously or are
there bursts/packets/frames of bits?

Eric

#4

On Mon, Dec 03, 2007 at 01:14:29PM -0800, Eugene Grayver wrote:

I am considering a minor change to the gr_single_threaded_scheduler such
that the min_available_space returns not the actual available space, but a
min(min_available_space, max_buffer_depth), where max_buffer_depth is a
block-specific parameter. Naturally, I would rather not do major surgery
on the runtime blocks, but I can’t think of any other solutions.

Thanks,
Eugene.

OK, that makes sense.

Eric