Hard Disk Bottleneck

GNU Radio
1

Hi everybody,

just a quick question: has anybody managed so far to provide the usrp
with the 8 Complex Msps needed to transmit an 8 MHz wide band?

My problem is that such a bandwidth yields a 32MiBps throughput and,
even if the USB2 bus and the CPU speed of my machine are all right with
this, it looks like my IDE HARD DISK cannot provide such a data rate.

Can anyone please confirm whether he’s been successful in something
similar, and, if so, with what kind of HD?

thanks

vincenzo

2

Vincenzo P. wrote:

similar, and, if so, with what kind of HD?
[email protected]
Discuss-gnuradio Info Page

You can successfully store data at those rates using SATA-II drives. You
can also set up a RAID-O configuration with IDE drives and should get
enough bandwidth. Actually we are using a more intensive system here
with 8 SATA-II drives using an areca PCI-E card with a RAID-5
configuration and achieve continuous rates close to 200MBPS - so I know
it can be done.

If you format your IDE drive and use a benchmarking program, you will
typically see that, as the disk fills, data write speeds decrease
linearly due to your position on the disk. You can sometimes look at the
numbers and then create a smaller partition that can maintain these
speeds.

Also, using isolated drives for data is important and we find the XFS
filesystem to outperform all other filesystems for continuous writing.

Ryan

3

On Fri, Feb 09, 2007 at 10:11:48AM +0100, Vincenzo P. wrote:

similar, and, if so, with what kind of HD?

thanks
vincenzo

Buy a new disk and controller :wink:

Lots of commodity 7200 RPM SATA drives can sustain 40 - 60 MB/sec,
no problem. Take a look at the Seagate Barracuda 7200.10

Zipzoomfly.com has the 300GB version for $100.
http://www.zipzoomfly.com/jsp/ProductDetail.jsp?ProductCode=101457

Eric

4

Has there been much discussion on building a modulator into the FGPA?
That would obviously reduce down the bandwidth required for
transmission of some very wideband signals.

Brian

5

similar, and, if so, with what kind of HD?

The real point here is that you can generate signals on the fly much
faster than you can read them from a disk. We have no trouble
generating the 32 megabytes per second of FM, PSK, or whatever else, in
real time. Do you really need to store these files to a disk?

Matt

6

Brian P. wrote:

Has there been much discussion on building a modulator into the FGPA?
That would obviously reduce down the bandwidth required for
t

Why build it into the FPGA when you can do it in software? He’s running
into a bottleneck in the disk->computer link, not the computer->USRP
link. A modulator in software solves the first, a modulator in hardware
solves the second.

Matt

7

Vincenzo P. wrote:

similar, and, if so, with what kind of HD?

thanks

vincenzo
If I have to read/send signals I can’t process in realtime I allways do
one of the following.

Small files: use a ramdisk
Big files: use a dedicated partition at the very start of the
drive, formatted with a fast filesystem (non-journalling) with nothing
further on it.

I have a 2.5 GB fat32 partition at the start of my drive (/dev/hda1).

For RX this can just keep up with 32 MiB/sec.

For TX I never have been able to get more then 16 MiB/sec, even when
using a ramdisk or using a null_source.

I don’t know why there is a difference between TX and RX. Maybe there is
a subtle buffering, timing or other difference in the communication
with the usrp.

Has anobody else have been able to do more then 16 MiB/sec on the TX
side?

Greetings,
Martin

8

The fastest thing you can do is make a dedicated partition and read and
write it directly. This is very simple (open(), read(), write(),
seek(), etc). I typically dedicate the first 1024 blocks to storing
info about the files. I use one block per file and the first block
stores info about the number of files stored. Something like this:

block0000[0]=10 //10 files
block0001[0]=1024; //file 1 starts at block 1024
block0001[1]=1001023; //file 1 ends at block 1001023 (for a total of 512
megabytes as each block is 512 bytes)

…

block0010[0]=xxx //file 10 starts at block xxx
block0010[1]=xxx //file 10 ends at block xxx

This gives you a very fast simple sequential file system.

If you only need to use one file you could dd it to the partition. In
your code use open() to open the partition and read() the data. If you
want to test to see if a dedicated raw partition is going to be fast
enough you can use dd with /dev/zero or /dev/null to test sequentially
read and write speed. You can vary the read/write size in dd to figure
out the optimal read or write size.

-Jim