Re: [linux-audio-dev] more preallocation vs no prealloc / async vs sync tests.

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] more preallocation vs no prealloc / async vs sync tests.
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Fri Apr 21 2000 - 18:05:21 EEST


>./hdtest 500 async trunc
>SINGLE THREADED: 5.856 MByte/sec
>MULTI-THREADED: 6.096 MByte/sec
>
>./hdtest 500 async notrunc (rewrite to preallocated files)
>SINGLE THREADED: 4.040 MByte/sec
>MULTI-THREADED: 4.766 MByte/sec
>
>./hdtest 150 sync trunc
>
>SINGLE THREADED: 1.442 MByte/sec
>MULTI-THREADED: 0.121 MByte/sec (floppy-like performance :-) )
>
>./hdtest 150 sync notrunc
>SINGLE THREADED: 4.788 MByte/sec
>MULTI-THREADED: 1.984 MByte/sec

>PS: Paul run it on your 10k rpm SCSI disk so that we can do some comparison.

I hope you are ready for some *very* different numbers.

/tmp/hdtest 500 async trunc
SINGLE THREADED: 12.788 MByte/sec
MULTI-THREADED: 12.788 MByte/sec

/tmp/hdtest 500 async notrunc
SINGLE THREADED: 6.096 MByte/sec
MULTI-THREADED: 6.168 MByte/sec

/tmp/hdtest 150 sync trunc
SINGLE THREADED: 11.292 MByte/sec
MULTI-THREADED: 12.233 MByte/sec

/tmp/hdtest 150 sync trunc
SINGLE THREADED: 5.437 MByte/sec
MULTI-THREADED: 6.383 MByte/sec

A few notes.

In the source you sent, you are not doing 256kB writes, but 1MB
writes, since you defined MYSIZE as (262144*4). This is puzzling.
However, changing it to 256kB doesn't change the results in any
significant way, as far as I can tell.

It troubles me that the ongoing rate display is always significantly
higher than the eventual effective speed. I understand the reason for
the initially very high rate, but I typically see final rates from the
ongoing display that are very much higher than in your effective rate
display (e.g. 13MB/sec versus 5.5MB/sec, 20MB/sec versus 12MB/sec).
I don't have the time to stare at the source and figure out why this
is.

Its very interesting that writing to pre-allocated files is 50%
slower for me. This is even though your pre-allocation strategy causes
block-interleaving of the files. I suspect, but at this time cannot
prove, that this is due (in my case at least) to fs fragmentation. I
will try the benchmark on a clean 18GB disk the next time I'm over at
the studio.

Stephen Tweedie or someone else would know the answer to my last
question: I am wondering if contiguous allocation of fs blocks to a
file reduces the amount of metadata updating ? Does metadata belong to
a fixed-sized unit, or an inode, or a variable-sized unit, or some
combination ? I ask this because I see some visual indication of the
disk stalls you have talked about when running your hdtest program (it
may just be paging issues, however - hard to tell), and I still have
not seen them in ardour. Assuming for a second that these are real
stalls, one obvious difference is that your preallocation strategy
does not produce contiguous files.

--p


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Fri Apr 21 2000 - 18:49:37 EEST