Re: [Discuss-gnuradio] Latency on TX for low data rate systems
From:
Eugene Grayver
Subject:
Re: [Discuss-gnuradio] Latency on TX for low data rate systems
Date:
Mon, 3 Dec 2007 13:14:29 -0800
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.
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?