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
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
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