[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: Murphy, John
Subject: Re: [Discuss-gnuradio] UHD USRP Source for B2x0 overflows File Sink
Date: Thu, 7 May 2015 14:57:52 -0400

Hi Marcus,

I am using num_recv_frames=512 but I have no idea why 512 or what the
ideal value should be for a system that has a lion's share of 16 GB of
RAM to burn.
In terms of the disk hardware sequential writes are up to 520
MBytes/sec. While there may still be some moments where things fall
behind, I expect some buffer somewhere, if properly set up (which I
believe is the issue but I do not know where or how), to be able to
take up the slack and prevent overruns.
Surely there must be poeple that do this all the time without O's,
given a proper setup?

- John

On Thu, May 7, 2015 at 2:27 PM,  <address@hidden> wrote:
> Leave "unbuffered" = OFF.   This flag was added for "slow" file-sinks, when,
> for example, you're writing slow data to an external process via somehthing
> like FIFO, and you don't want the default stdio buffering to get in the way.
> The default, if you leave it off, is to use stdio buffering.
> The "bursts of O" behaviour is to be expected, depending on how much RAM the
> kernel allocates to write-behind buffers, and how fast your disk subsystem
> is.   Your writes get posted to the kernel.  The kernel throws them into a
> usually-immense, write-behind cache.  When its I/O scheduler decides its
> time to commit those writes, things slow down.
> You might try also using num_recv_frames on the device arguments (if you
> aren't already), to try and smooth out the flow from the USB controller.
> You might also compare what you're doing with something that doesn't use Gnu
> Radio at all, such as rx_samples_to_file.

reply via email to

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