Re: High bandwidth disk management techniques
Re: High bandwidth disk management techniques
- Subject: Re: High bandwidth disk management techniques
- From: philippe wicker <email@hidden>
- Date: Mon, 2 May 2005 14:47:21 +0200
On May 2, 2005, at 12:33 PM, Mark Gilbert wrote:
Thanks Doug !!
This gives me quite a bit to chew on !
- I have now implemented all this, including async reads (which are
currently forcing a wait for completion, whilst I plan a proper async
architecture). I can't really force the 4096 boundries, but I am not
worried about extra file system CPU or memory overhead - its the disk
access I am trying to optimise.
- Currently I am reading each file into a general buffer (which may be
multichannel interleaved), waiting for completion, then move this data
into a set of mono channel buffers. Then I loop around and do the
same for the next file. After all this I move on with my full set of
mono buffers. its all basically sync in practice at the moment, and
as such it behaves pretty much how it always has.
So - would there be any benefit in starting ALL the async reads one
after the other, then wait for all the callbacks (one for each read)
to complete, and them move onto my deinterleaving code ? Is there
potential benefit to having 64 async reads scheduled ? Will the file
system take advantage of efficiency opportunities ?
Some times ago (OS X 10.2.x) I tried to bench the simultaneous disk
accesses to a number of files. For the little story, these files were
25 MBytes segment of a MacOS X update. I did that using two methods.
The first one was to sequentially access a 64KByte chunk in each file.
The second method was to trigger the access to each file in a different
thread (one thread dedicated to a given number of files), this method
is a variant of multiple asynchronous reads. The results were really
surprising and unexpected (at least for me): the "threaded" access gave
a twice worse - yes worse - performance on the internal drive than the
"sequential" method, and an equivalent result on an external FW400
drive. I don't have a definitive explanation for these results, it
appears like if the OSX disk scheduler and/or the disk driver and/or
the disk firmware do not attempt to optimize by rescheduling physical
sectors read. I didn't try using several spindles. The result may have
been different in this case.
Philippe
_______________________________________________
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