Re: [Discuss-gnuradio] the best file system for reading fast

[Eric Blossom]

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.

> 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

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