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