> On Mar 11, 2015, at 9:07 PM, Paul Davis <[email protected]> wrote: > > On Wed, Mar 11, 2015 at 10:57 PM, Hamilton Feltman <[email protected] > <mailto:[email protected]>> wrote: > > > We know by existence proof (aka Logic) that the system can handle 128 or > > more tracks. > > Yep, the tests you posted confirm it’s possible. Just double your buffer size > from 65536 to 131072. Half the number of seeks, and track count goes from 49 > to 100. > > True, except that using dtrace while running logic shows that something is > only reading 64kB at a time (and apparently the kernel, suggesting that logic > is using mmap). Can't prove this without source, however.
Either something is wrong with the test, or logic is background caching. We’ve just proven that this drive can't do more than 50 tracks, with a 64kb read size. It doesn’t matter what the os is using. It is physically impossible for the drive to seek any faster when reading that blocksize. The only possiblity is that more time is being taken, i.e. background caching. > I can say with almost absolute certainty that the usual dtrace tools show > Logic doing absolutely no (direct) audio file I/O during playback at all. Logic is background caching as soon as the song is opened? You could test this by closing logic, clearing the file cache, opening logic and immediately starting playback while watching the trace. If it’s still reading in 64kb blocks, it’s going to stall, there are no two ways about it. > > But it isn't that simple: increasing the block size makes it much more likely > that you'll encounter a very large drop in minimum sustained streaming rate, > in addition to a substantial increase in maximum sustained streaming rate. > You don't see this in your results, but we've seen it in all of ours so far. > We didn’t see it in the results you posted. But this would still be a separate issue from the raw drive speeds. One possibility, if the filesystem is doing the readahead (thereby increasing the block size), it’s possible that the OS is ejecting the cached readahead pages when under memory pressure. Regards, Hamilton
_______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to [email protected]
