The best file system for reading fast

Hi all,

today I bought a 7200 rpm SATA HD
(a seagate barracuda, as Eric suggested some months ago)
in order to be able to sustain a complex 8Msps flow (32MB/s) towards the
usrp.

Once I formatted it with the XFS filesytem, following Rayan’s tip, it
looked like I was getting the appropriate throughput…

is anybody using any other high performance filesystem to do this kind
of things?

…just to know if other options exist…

thanks

vincenzo

Make a dedicated partition on the drive that you use exclusively for
recording data. You can either read and write the partition directly
(i.e. no filesystem) or you could format it with a filesystem (xfs,
reiser, ext2, ext3). Most people prefer keeping things easy by using a
filesystem so let’s consider that approach. Keep the partition empty.
The only file in the partition should be the file that is currently
being recorded. Once you have the file copy it to another partition if
you want to keep it. The point is to make sure the recording partition
is empty before starting a recording so the date file is contiguous on
the disk. File fragmentation can kill instantaneous recording speed. A
heavily fragmented filesystem may be able to average over 32 MB/s but
there will be times when the short-term transfer rate drops below 32
MB/s causing you loose samples. To compound the problem you probably
won’t know how many samples you lost.

For the absolute best performance put the recording partition at the
front of the disk. The beginning of the disk is much faster than the
end. I’ve tested recent SATA drives at over 60 MB/s at the beginning of
the disk. Toward the end of the disk the performance can drop below 30
MB/s. As and example suppose your drive is 500 GB. Make the first
partition 50 GB and the second 450 GB. Use the first partition as the
recording partition and the second for storage and whatever. At 32 MB/s
the 50 GB partition will hold 26 minutes of continuous data. This is
obviously a “purist” approach but doing it this way you will have a
RELIABLE recording setup.

-Jim

On Wed, Sep 05, 2007 at 02:06:51AM +0200, Vincenzo P. wrote:

is anybody using any other high performance filesystem to do this kind
of things?

…just to know if other options exist…

thanks
vincenzo

Jim’s ideas are good. I’d use a filesystem :wink:

I suspect that reading from ext2 or ext3 at 32MB/s should be OK on the
drive you bought. If you want to go faster, you can use RAID 0 to
stipe the data across two or more drives. This is easy to setup if
you use LVM2. Just tell it to stripe the logical volume (LV) across
the drives. There are examples of how to set this up in the LVM
HOWTO.

http://sourceware.org/lvm2

Every Linux distribution I know of ships with LVM2.

Eric

Vincenzo P. wrote:

Once I formatted it with the XFS filesytem, following Rayan’s tip, it
looked like I was getting the appropriate throughput…

ext3 could not keep up with 4e6 short complex samples/sec. ext2 could,
so I use ext2.

Chris

— Eric B. [email protected] wrote:

it

looked like I was getting the appropriate throughput…

is anybody using any other high performance filesystem to do this
kind
of things?

…just to know if other options exist…

I think XFS is the way to go if you need fast I/O. Use large blocks.
SGI invented XFS just for this purpose, performance. Still 32MB/Sec
is about the most you can expect on a single drive setup.

I’ve got a SATA drive in this iMac and I get about 32MB/Sec max.
Mac OS X is BSD UNIX based. Hate to say it but you are on the
borderline.

Chris Albertson
Home: 310-376-1029 [email protected]
Office: 310-336-5189 [email protected]
KG6OMK

  ____________________________________________________________________________________

Park yourself in front of a world of choices in alternative vehicles.
Visit the Yahoo! Auto Green Center.

I have the same problem here in our lab. I need faster I/O. We
have a Sun Sunfire V490 with 32GB RAM and 8 CPUs but poor performance.
I’m sure the answer will be to add more disks. Not faster disk but
more spindles. Possibly another disk controller too.

You can compute the maximum possible sequential I/O rate. It’s easy:
Look at how many blocks are in one track and how long it takes the disk
to make one revolution (at 7200 RPM) then you will know how many bits
per second fly under the read/write head. This places an upper bound
on the sustained I/O rate. The best way to go ftrs is to run multiple
drives in parallel. But then the bus or controller becomes the bottle
neck so on our Sunfire I think we might need another controler, ned to
run tests to get real numbers.

Look up the size of the track and the RPm and see if 32MB.Sec is
reasonable for your drive. You really want the drive to closer to 50%
or 70% of maximum. And yes you need your data recording drives for no
other purpose

Chris Albertson
Home: 310-376-1029 [email protected]
Office: 310-336-5189 [email protected]
KG6OMK


Building a website is a piece of cake. Yahoo! Small Business gives you
all the tools to get online.

On Wed, 5 Sep 2007, Jim P. wrote:

For the absolute best performance put the recording partition at the
front of the disk. The beginning of the disk is much faster than the
end. I’ve tested recent SATA drives at over 60 MB/s at the beginning
of the disk. Toward the end of the disk the performance can drop
below 30 MB/s. As and example suppose your drive is 500 GB. Make
the first partition 50 GB and the second 450 GB. Use the first
partition as the recording partition and the second for storage and
whatever. At 32 MB/s the 50 GB partition will hold 26 minutes of
continuous data. This is obviously a “purist” approach but doing it
this way you will have a RELIABLE recording setup.

I would suggest you use a completely separate disk then you won’t have
problems with random seeks stuffing you up.

You might want to consider higher performance disks too (although ISTR
10k & 15k RPM disks don’t get [much] more sequential throughput).

On Wed, Sep 05, 2007 at 08:51:35AM -0700, Chris Albertson wrote:

I have the same problem here in our lab. I need faster I/O. We
have a Sun Sunfire V490 with 32GB RAM and 8 CPUs but poor performance.
I’m sure the answer will be to add more disks. Not faster disk but
more spindles. Possibly another disk controller too.

Eventually you run into processor i/o bus bandwidth issues. Depends on
the architecture, and the chipset. Really depends a lot on the
south bridge, and for example, how many PCI buses there are, and
whether or not they are hierarchically connected, or all feed into the
“fast part” (north bridge) of the CPU.

reasonable for your drive. You really want the drive to closer to 50%
or 70% of maximum. And yes you need your data recording drives for no
other purpose

These days, the reality is that the number of sectors per track varies
across the platter as f(cylinder). All the disk geometry is hidden in
the controller. They’ll report some numbers, but the numbers are bogus
:wink:
Just check the drive’s data sheet. There’s usually some kind of
number for maximum sustained rate (but it’s usually only valid on the
outside cylinders). Best to just benchmark the drive.

Eric

Eric B. wrote:

Best to just benchmark the drive.

It’s kinda old school but the bonnie++ utility is dynamite for measuring
disk read/write performance under varying usage patterns.


Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com

first of all thanks to all the guys who provided very useful tips for
the the HD+File system setup.

I finally have a 7200rpm disk that does keep up very well with 32MBps
and, I guess, even much more…

is then this assumption correct?

8Msps with gr_complex data type ==> 8e6*8bytes per sample = 64 MB/s

8Msps with interleaved shorts ==> 8e6*2bytes per int * 2channels = 32
MB/s

I’m sure now that my drive can keep up with recording and replaying the
32 MB/s
and I guess that even 64 with my new, xfs formatted clean disk is fine

my problem is that in both cases ( both using complex and interleaved
shorts)

If I work with a 4 MHz bandwidth everything looks allright.
I can record and replay a 4 MHz fm band and perfectly listen to the
station at the center of it when sending it back to the receiver

but

when I try to go 8 MHz I can hear a noisy, extremely weak replica of my
signal, which is SLOW… like an old cassette player with flat batteries

and this is consistent with the fact that a file meant to last 10.717
secs @ 32MB/s, when played with usrp_interp= 16 (8MHz Bandwidth)
lasts MORE than 13 secs, while if played with usrp_interp=32 (4MHz),
it lasts exactly the double of the correct value ie: 10.717*2=21.434

has this ever happened to anybody… am I making huge mistakes that I
havent discovered yet?

thanks

vincenzo

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs