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: Paul Davis <email@hidden>
- Date: Mon, 4 Jan 2010 06:06:45 -0500
On Sun, Jan 3, 2010 at 10:47 PM, Ross Bencina
<email@hidden> wrote:
> Paul Davis wrote:
>>
>> this is highly subject to the
>> specific filesystem you are using and specific settings of the kernel
>> buffer cache mechanism, whose semantics vary between (say) Darwin (OS
>> X), Solaris, Linux and FreeBSD.
>
> I'm interested in an answer to the original question too.
>
> 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. 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). obviously, we
have to break this rule when flushing out the last little bits of a
capture buffer, and at a few other times. my heuristic has been that
we need to focus on optimizing the streaming case, not the seeking
case, because failure (buffer under/overruns) during streaming are
much worse than being a little slower (we're talking fractions of a
second, typically) when seeking. this might not be true of an app that
knows that its streaming requirements are well within the bounds of
the OS/hardware capabilities.
> 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 :) 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. this is both unfortunate and liberating. i
don't know for sure, but i would have a strong intuition that OS X
filesystems are likely to be as unpredictable.
_______________________________________________
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