Nick, Thank you! Adjusting the niceness level did the trick, however after digging more into the files, I also figured out the fusb_block_size/nblocks commands, and have found a solution there as well. I can now sustain the full 32MB/s write to disk that the USB will allow.
For reference, here are my findings: gnuradio defaults to 1MB fusb buffer, FUSB_BUFFER_SIZE in fusb_sysconfig_linux.cc. At 8MB/s, 1/8th of a second, the buffer doesn't seem to be enough on my system for the scheduler at 0 niceness. Per the note in fusb_sysconfig_linux.cc, I have left fusb_block_size set to 0, or 4x1024. Latency is not an issue since I am spectrum recording, so I have adjusted my block size to be 2 secs (16MB, fusb_nblocks=4096). I played with this value quite a bit, and 2 secs seems to be a good compromise. I upped the transfer to 32MB/s (decimation of 16), increased fusb_nblocks to 16384, and it still records without any uO's. I know this can cause GUI responsiveness issues, and poor latency, but are there any other side affects I should be aware of? Thanks again, Neil On Wed, Jan 5, 2011 at 1:28 PM, Nick Foster <n...@ettus.com> wrote: > You're probably getting interrupted by some scheduler-chewing task. If > you don't mind risking locking your system up, try prefacing your > command with "sudo nice -n-20 " to give your process priority. > > You should also benchmark your HDD with hdparm or Bonnie to get a handle > on what you can actually write for sustained periods of time. > > If all else fails, create a ramdisk to save your samples: > > mount -t tmpfs /mnt/ramdisk -o -size=512m > > ...and copy them over to HDD when you're done streaming. > > --n > > On Wed, 2011-01-05 at 10:47 -0500, Neil Bedwell wrote: >> Hello, >> I am having overruns that I cannot get figured out, and I am on a time >> crunch to get this resolved. Any help would be appreciated. >> >> Problem: >> I seem to get uO's that appear irregularly, maybe every 20 seconds or so on >> average. >> >> Script in Python: >> USRP with 2 TVRx boards -> Decimation set to 64 (1MHz BW, also tried 128, >> with same result) -> Split Stream -> Store samples as two interleaved I/Q >> files (4MB/s per file) >> That data is what I expect out, so I don't suspect that the Python code is >> incorrect >> >> Computer: >> Core2 Duo >2GHz per core (runs at 1GHz while executing) >> Ubuntu 10.04 fresh install on Ext4 hard drive (Also tried 10.10, and have >> tried AHCI settings to both On and Compatibility in BIOS) >> USB benchmark succeeds at 32MB/s (8MB/s should not be an issue) >> Latest GNU Radio from git (also tried 3.3.0) >> High-speed hard drive, more than capable of 8MB/s writes (HD light only >> flashes every few seconds when script is running) >> I have tried playing with fusb_block_size/nblocks, but don't know a good >> configuration to set, and haven't had luck reducing the uO's >> >> Questions: >> What else can I try? >> Are there buffer sizes that I can increase on the computer so that there is >> room during the hard drive block writes? >> >> Thanks, >> Neil >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio