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

[Marcus D. Leech]

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
> operation.
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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio