Subject: Re: [linux-audio-dev] Re: More results and thoughts on disk writing performance
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Fri Apr 21 2000 - 03:55:20 EEST
>>
>> Incidently, on the systems I tested it appears that preallocation *slows dow
>n*
>> data writing. Paul, have you compared your system with and without using
>> preallocation? What speed difference do you see?
>
>EXACTLY !
>I am experiencing the same !
>After Paul praised the preallocation so much, I decided to test it, and I
>get about 20% performance slowdown over the case when running without
>preallocation.
.
.
.
>I can't explain why we do experience the slowdown with preallocation.
No big suprise here. Suppose you write the files in 256kB chunks, and
re-read them in the same way. If ext2 behaves the way I would expect (*)
it to, you end up with somewhat-to-totally block-interleaved files
that are read with no-or-little seeking (because the read pattern will
exactly match the write pattern).
The problem with not preallocating occurs only on the first write, and to
be honest, my preallocation scheme should be changed to mirror the
actual actions of a true "first write" by block-interleaving the files
instead of aiming for complete per-file contiguity. The one difficulty
with this is that if you change the size of the i/o requests, you may
get *worse* performance. At one time, I imagined this size to be
rather fluid, but it now appears to be likely to assume a fairly
constant value across all disks on all systems (and certainly on any
particular system). This removes my only real objection to
block-interleaving the files.
I will change the way the files are pre-allocated and see if it speeds
things up even more.
Again, just in case anyone missed it: I have never encountered the
problems Benno has had (or at least, not the same underlying causes -
I used to have disk i/o performance problems), probably due to my use
of SCSI h/w, and ardour is working multichannel hard-disk recorder.
>No you are wrong here:
>the audio thread requires higher priority because it nneds finer granularity,
>(we want low-latency response from our HD recorder).
>The audio thread releases the CPU during blocking write()s to the audio device
>,
>giving the disk thread all the time it needs to perform large disk I/Os which
>blocks the disk thread almost all the time.
>Therefore you gain NOTHING (=zero disk performance increase) by giving the dis
>k
>thread higher priority than to the audio thread, except that the audio will
>drop-out sometime.
Fully agreed.
--p
(*) ext2 filesystems have a pre-allocate distance which someone
mentioned. I am hoping that allocating 256kB at a time makes this
figure irrelevant, but I am not sure at all that this is true.
This archive was generated by hypermail 2b28 : Fri Apr 21 2000 - 04:32:35 EEST