[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] UHD USRP Source for B2x0 overflows File Sink

From: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] UHD USRP Source for B2x0 overflows File Sink
Date: Thu, 07 May 2015 17:35:57 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

On 05/07/2015 04:12 PM, Murphy, John wrote:
So /dev/null works, I do not know what that really says about this
though. Is there a difference between using dev/null and just running
any non-disk-write flowgraph? Because I know I can run a flowgraph at
16 MS/s decimated to 8 MS/s, with never a single O even for hours of
Writing to /dev/null actually exercises your kernel write code.

Just sticking a "null sink" in your flow-graph doesn't, so you don't get as much information out of the experiment.

With 16 GBytes of RAM one can't somehow in GR buffer up the 64
MBytes/sec data flow during one of those hiccups?
What do all those "min output buffer" and "max output buffer" params
on the advanced tabs of the blocks do?
- John
The kernel is already doing that--Linux kernels have always used RAM for write-behind buffering unless there's other pressure on it, like
  lots of disjoint processes with large working sets.

The buffering parameters that you refer to are to do with the Gnu Radio scheduler, and have little application to the problem at hand.

The basic problem is that if the long-term-average offered-load on your write medium (your SSD in this case) is higher than it can sustain, it doesn't matter how much buffering you add in front of it, eventually, the piper has to be paid. Buffering is useful to meeting short-term short-falls in throughput capacity. They *cannot* help if offered load, on average, exceeds the long-term capacity of the resource. Now, having said that, if you only need to record for a short time, consider adding more RAM, and creating a ramdisk, then stage the ramdisk out to your hard disk. But this ONLY WORKS if you don't need to record continuously, otherwise, you're back to the buffering issue....

But at 8Msps, and 4-bytes per sample, that's 32Mbyte/second, you have about 30 seconds/gigabyte.

On Thu, May 7, 2015 at 3:43 PM,  <address@hidden> wrote:
I looked at their blurb on that drive, and its *sustained* rate comes out to
about 69Mbyte/second.  Sure, it'll take bursts at screaming-fast rates,
because, like the Linux kernel, it has a whacking great write-behind buffer.
Try specifying a filename of "/dev/null", which will bypass your disk
subsystem entirely, and give you some idea of what you can sustain in the
absence of actual disk-subsystem writes.
Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]