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, <mle...@ripnet.com> 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
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
