Subject: Re: [Fwd: [linux-audio-dev] info point on linux hdr]
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Mon Apr 17 2000 - 17:50:05 EEST
On Mon, 17 Apr 2000, Stephen C. Tweedie wrote:
>
> Preallocation will make little difference. The real issue is that the
> buffer cache is doing write-behind, ie. it is batching up the writes into
> big chunks which get blasted to disk once every five seconds or so,
> causing large IO request queues to accumulate when that happens.
>
> That's great for normal use because it means that trickles of write
> activity don't tie up the spindles the whole time, but it's not ideal
> for audio recording.
>
> Try opening the file with open(O_SYNC), and write the data in 128k chunks
> or so. Alternatively call fsync() every so often to force the data to
> disk (though fsync is not particularly efficient on large files with
> 2.2).
>
> The down-side of O_SYNC is that the application blocks until all the
> data is on disk, but the benefit is that the IO queue size is much more
> controlled. If you have a dedicated thread doing the disk IO, then the
> latency of blocking while the IO happens is irrelevant.
>
> --Stephen
Stephen, I tried all possible combinations , in my hdrbench code.
http://www.linuxdj.com/hdrbench
I suggest you to try it out (it's a simple console app), because you can really
stress your filesystem/buffercache with this app.
And you can hear at any moment if your HD is able to deliver the needed
performance.
I discovered that SMP helps a bit, perhaps because the kernel is able to
multithread disk buffer updating or so.
Basically I am reading/writing 256kb at time for 30-40 files simultaneously
I tried:
-fsync() on all write descriptors at regular intervals ranging from 1sec to
10sec
- fdatasync() on all write descriptors , same as above
- sync()
- opening output files with O_SYNC
NO LUCK AT ALL. :-(
I can only tell you that I gave up, because the performance
in terms of number of simultaneous tracks ( 180KB/sec * number_of_tracks)
went down with ANY of these attempts.
I think the performance drop happens because the disk is forced to seek more in
the above combination, since synching of buffers will interfere with files
which are just being read.
(for example if you fire up even a short find /usr during a hdrbench session,
and then press CTRL-C , after a few secs, the metadata updating
( st_atime updating ?) causes nasty peaks in the buffer utilization curves.
like this , look at the 60sec mark
http://www.linuxdj.com/hdrbench/graph-36-4.gif
I think the buffer cache does a good job from a thoughput performance POV, but
unfortunately hdrecording need both throughput AND low filesystem latency.
Again I think O_DIRECT is the only way which will allow us to use smaller
buffers, but we will gain almost nothing in terms of total delivered MB/secs.
PS: very probably I will have the chance to test my app on a software RAID5
UW SCSI linux box and a SGI O2 box ( long live O_DIRECT :-) )
If I get interesting graphs I will post them here.
Benno.
This archive was generated by hypermail 2b28 : Mon Apr 17 2000 - 19:15:38 EEST
