Re: Building a fast pc (1)

My 2 cents:

    There are many factors to consider.

    1. Size of the files being accessed.
    2. Access pattern (random/sequential,/strided/backwards)
    3. Size of the typical transfer.
    4. Single stream or multiple stream access.
    5. Size of any NVRAM in the I/O subsystem.
    6. Cache line size of the NVRAM.
    7. RPM of the disks.
    8. Average head seek time of the disks.
    9. Number of disk controllers.
    10. Transfer rates of the disks and the controllers.
    11. File system block size.
    12. If using RAID, the RAID stride size, number of disks,
          and RAID level. (0,1,5)

    Things that might help one answer the question of which
    is faster.

    1. Get a system call trace of the application that is being
        targeted. Then extract the I/O behaviors.
    2. Try using Iozone (http://www.iozone.org) and test the
        configurations.  Use -a for auto testing of single stream
        performance, and -t #, for testing throughput performance.

    Notes: When using Iozone, be sure to specify file sizes that
    are larger than the amount of RAM in the system. Use transfer
    sizes that you have found from your system call trace. Use
    sub tests that represent the application's behavior. (sequential,
    or random)

Enjoy,
[EMAIL PROTECTED]


"Eric Sosman" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> "Martin (news.tele.dk)" wrote:
> >
> > Building a fast pc (1)
> >
> > We'r trying to build a fast pc (w2k) for GIS (Geographcal Information
Systems). We'r looking at RAID 0, since data is allready backed up, and
Speed is 1'st priority. We are going for a Ultra320 RAID, but might fall
back on a SATA RAID.
> >
> > My question: Which is faster, 2x73Gb discs or 4x36Gb disks?
>
>     Back-of-the-envelope analysis: For a "random" (as opposed
> to sequential) I/O load, the slowest part of the I/O path is the
> disk access arm.  Hence, spreading the load across four access
> arms instead of two will almost certainly be faster.
>
>     Details like the relative frequency of reading and writing,
> the size and nature of NVRAM caches (if any), the O/S' attempts
> to optimize the I/O (for example, by pre-fetching) can alter
> the picture substantially.
>
> -- 
> [EMAIL PROTECTED]