Re: preferred disk api for high bandwidth sample reading
Re: preferred disk api for high bandwidth sample reading
- Subject: Re: preferred disk api for high bandwidth sample reading
- From: "Ross Bencina" <email@hidden>
- Date: Tue, 5 Jan 2010 17:38:31 +1100
Paul Davis wrote:
On Windows you can set flags to disable OS level caching/buffering when
you
open a file handle (with the restriction of being required to perform IO
in
page aligned blocks).
the same thing is possible with unix/posix APIs too.
Can you give some links/keywords please? What do you currently use in
Ardour? read/write one buffer at a time using posix file io?
however, its not
clear to me that on machines with typically large chunks of RAM that
attempting to do your own thing is a win enough of the time to justify
doing it. in ardour, we work hard to chunk disk i/o into 256kB units
because we've found that this is roughly optimal with the filesystems
our users are mostly typically working with (optimal in the sense that
we get closer to the underlying hardware throughput).
Last time I benchmarked this on Windows (admittedly on older hardware,
perhaps in the 1Ghz era) I saved about 10% CPU usage (from memory with
50-100 streams) by disabling the OS level i/o caching. It doesn't make much
sense to incurr OS-level buffer copying and caching when a
streaming-sepecific application level buffering/caching layer is needed
anyway.
The other thing is to use some kind of
scatter gather i/o so that the OS level disk scheduler can queue up
multiple
i/o requests with the disk so that the head path accross the disk can be
optimized.
my own preference is to assume that the disk scheduler can do the
right thing without me having to work that hard :)
Except that unless the disk scheduler has multiple concurrent pending i/o
requests it has no way to choose the best operation to perform first.
i've done some
fairly low level analysis of how various linux filesystems distribute
blocks across the disk during recording, and my conclusion has been
that its pointless trying to believe that i (as an app developer) can
predict the block layout.
That's not what I'm suggesting. I'm happy to leave that to the OS disk
scheduler.
I'm just not sure what the best way is to queue multiple i/o requests to the
scheduler on OSX. Posix AIO? multiple io threads? some kind of non-blocking
ioctls? Mach async io (if there is such a thing).
Ross.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden