Subject: Re: [linux-audio-dev] design question for HDR
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Mon Apr 03 2000 - 22:09:38 EEST
Some interesting numbers from a test program. The test program opens a
file (preferably an entire disk), does a seek to a random location on
the disk, then reads a block of data. It does this in a loop until a
certain amount of data has been read.
Test Procedure:
1) "clear" the buffer cache by reading 500MB from a disk with dd(1)
2) run test program, specifying block size to read and total amount
of data to read (always 100MB), along with a disk (/dev/sdX) that
is *NOT* the one used in step 1.
3) get results
4) repeat with different blocksizes
==========================================================================
Seagate Cheetah 4.5GB Quantum Viking II 4.5GB
--------------------- ---------------------
Block size: 65536 Block size: 65536
MB/sec: 5.311 MB/sec: 3.892
sec/MB: 0.188 sec/MB: 0.257
Block size: 131072 Block size: 131072
MB/sec: 8.028 MB/sec: 5.817
sec/MB: 0.125 sec/MB: 0.172
Block size: 262144 Block size: 262144
MB/sec: 10.971 MB/sec: 7.870
sec/MB: 0.093 sec/MB: 0.127
Block size: 1048576 Block size: 1048576
MB/sec: 15.006 MB/sec: 10.642
sec/MB: 0.067 sec/MB: 0.094
==========================================================================
Conclusions:
1) Buy faster disks. The seagate is rated as a 5.7ms seek time, the
quantum a 7.5ms disk, and the numbers show this very clearly.
2) Use right blocksize for your program
3) Design your programs correctly
4) Run them with the right parameters
Commentary:
Clearly, at all but the 64K blocksize on the Quantum drive, the Linux
disk/filesystem can provide the necessary data rate for 24 track
playback of 32bit/48kHz data. At the same time, an application that
doesn't use the system in the right way will lose.
Mea culpa. I am going to the steam room to think about to get ardour
to use big block sizes, and thus gets lots of breathing
space. Actually, given the state of my nose, breathing space is
another reason for me to go.
--p
This archive was generated by hypermail 2b28 : Mon Apr 03 2000 - 22:08:09 EEST