Subject: Re: [Fwd: [linux-audio-dev] info point on linux hdr]
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Wed Apr 19 2000 - 06:27:12 EEST
>> 2) Why am I not having any of these problems ? Unlike Benno's code, I
>> have a working application that runs just fine. I get smooth
>> throughput from the disk subsystem too.
>
>What do you mean exactly with "unlike Benno's code" ?
>My code just tries to simulate the operation of a busy harddisk recorder
>using the sorting algorithm to support variable speed.
>I read in 256kb chunks too therefore I don't see a big difference between
>my code and yours form a disk IO subsystem POV.
In your own words, your code "simulates the operations of a busy
harddisk recorder". Mine *is* a busy harddisk recorder. There's lot of
stuff in my code that isn't in yours because I have a bunch of real
world stuff like a tape transport mechanism, extra intra-thread
communication, MTC delivery, an audio thread event/play list, and
more. Yet, despite all this, I have never run into the problems you
describe. As Stephen has noted, this may very well be because of my
use of SCSI h/w.
>Therefore it would be useful if you could run my benchmark on your
>disk to see if your (or my approach) gets better performance out of the disk,
>and with how much buffer utilization.
When I get a minute or 30, I will.
>> In both cases, without O_SYNC, or anything else but preallocation
>> and careful design, I seem to be able to get smooth disk throughput
>> at significantly above the rate I need (9MB/sec; I get up to
>> 17MB/sec from the UltraStar)
>
>17MB/sec using hdparm or linear large reads/writes ( large cat / cp etc) or
>17MB/sec within your harddisk recording app where
>num_tracks * datarate_of_each_track = 17MB/sec
>(it if's the latter then I doubt it because seek kills some of the throughput,
>that's almost unavoidable, at least on my EIDE UDMA disks)
No, I do mean the latter: 17MB/sec from within ardour. You can doubt
it all you want, but I get it regularly. Actually, the real numbers
look more like (from memory, each line is one iteration of disk i/o
across all tracks, so 24*256kB of data):
15MB/sec
450MB/sec
10MB/sec
14MB/sec
567MB/sec
16MB/sec
19MB/sec
8MB/sec
378MB/sec
The super-high numbers, I assume, are because of the read-ahead being
done by the kernel, which helps us out every so often. Remember, these
files are as contiguous as I can make 'em with ext2. And keep in mind
that my disks have a maximum transfer rate of 35MB/sec (nothing to do
with U2W - just that they are just about the latest disks).
I have a very small, standalone single-threaded test app that gets
similar rates, even though it does random sized seeks across the whole
disk. I've posted that program before on LAD, and so I trust the
numbers.
--p
This archive was generated by hypermail 2b28 : Wed Apr 19 2000 - 07:02:35 EEST