Buffer sizes, timing and overflows

GNU Radio
#1

Hi,

I am writing a simple program that stores USRP sampled data and stores
it on disk continuously in 1s sized files. I have made a new sink for
this purpose, which is almost identical to gr_filesink, except that
mine blocks in work() while the file is closed and a new one is
created.

I have only been using USRP for a couple of days, so I have some
hopefully simple questions:

  1. I would like to get as accurate timestamp as possible to the
    beginning of the dump to make later analysis easier. What would be the
    best way to estimate the time delay between fg.run() and the moment
    when the first sample comes out of the down converter?

  2. I have managed through trial and error to get a fairly reliable
    8MHz sampling system using the following parameters:
    fusb_nblocks=32768,fusb_block_size=1024. Is this a good way to make a
    large buffer or should I use some other gnuradio block to create a
    large buffer in RAM? I am hoping to write the data at 8MHz on a
    networked RAID array and this will cause even larger waiting times for
    my filesink, even though the average bandwidth is large enough.

  3. Another question: is there any way to query the driver if a buffer
    overflow has occurred and maybe throw an exception? I am going to
    sample continuously for long durations and it would be nice to be able
    to restart sampling automatically if an overflow is detected due to
    some reason.

  4. What happens in an overflow situation? Do I still get the correct
    amount of samples, albeit with wrong samples, or are the missing
    samples just tossed away?

Gnuradio and USRP is great! I really prefer your system to labview.

Best regards,
juha

#2

Juha V. wrote:

I am writing a simple program that stores USRP sampled data and stores
it on disk continuously in 1s sized files. I have made a new sink for
this purpose, which is almost identical to gr_filesink, except that
mine blocks in work() while the file is closed and a new one is
created.

Blocking in work() is bad. The current GNU Radio runtime scheduler is
single threaded, so while your filesystem call is blocking, you’re not
reading from the USRP. Depending on how long you’re blocked, this could
result in dropped data.

  1. I would like to get as accurate timestamp as possible to the
    beginning of the dump to make later analysis easier. What would be the
    best way to estimate the time delay between fg.run() and the moment
    when the first sample comes out of the down converter?

You’ll have to find a way to empirically measure it. Alternatively,
when the “in-band signaling” code is ready, the received data from the
USRP will be timestamped.

  1. I have managed through trial and error to get a fairly reliable
    8MHz sampling system using the following parameters:
    fusb_nblocks=32768,fusb_block_size=1024. Is this a good way to make a
    large buffer or should I use some other gnuradio block to create a
    large buffer in RAM? I am hoping to write the data at 8MHz on a
    networked RAID array and this will cause even larger waiting times for
    my filesink, even though the average bandwidth is large enough.

While this may work, you’re addressing a symptom, not the root problem,
which is calling fclose() in work().

Could you stream samples to a single file and cut it up into 1s samples
afterwards?

  1. Another question: is there any way to query the driver if a buffer
    overflow has occurred and maybe throw an exception? I am going to
    sample continuously for long durations and it would be nice to be able
    to restart sampling automatically if an overflow is detected due to
    some reason.

You can call usrp.source_c.noverruns() to get a count.

  1. What happens in an overflow situation? Do I still get the correct
    amount of samples, albeit with wrong samples, or are the missing
    samples just tossed away?

They are tossed away.

Gnuradio and USRP is great! I really prefer your system to labview.

Thanks.

–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com

#3

On Mon, Sep 17, 2007 at 08:59:35PM +0300, Juha V. wrote:

8MHz sampling system using the following parameters:
fusb_nblocks=32768,fusb_block_size=1024. Is this a good way to make a
large buffer or should I use some other gnuradio block to create a
large buffer in RAM?

I wouldn’t recommend this.
This forces the kernel to lock down 32MB of RAM, which seems like
total overkill. Do you really need 1 second worth of locked down
buffer?

Use something like fusb_nblocks=2048, fusb_block_size=4096.
Increasing the block size to 4k reduces the overhead; setting
nblocks to 2048 gives 8MB of buffer (== 250ms)

You could also enable real-time scheduling using
gr.enable_realtime_scheduling().

I am hoping to write the data at 8MHz on a
networked RAID array and this will cause even larger waiting times for
my filesink, even though the average bandwidth is large enough.

This will probably work.

Gnuradio and USRP is great! I really prefer your system to labview.

Thanks!

Eric