Subject: Re: [linux-audio-dev] HD-recording frustration: linux makes it almost impossible :-(
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Mon Apr 10 2000 - 15:30:34 EEST
>I fully agree here, but unfortunately the delay between two read() or
>write() request is the minor issue.
Maybe right now, for you. But once you deal with whatever is causing
your big stalls, you'll find that the occasional extra 20msec of delay
in scheduling the butler thread can reduce your disk throughput quite
dramatically.
>> Well, the problems on my system came from using non-contiguous files,
>> too small chunk size for i/o and other things that all led to not
>> having the buffers filled in time. Once I got that solved, its been
>> easy since then (bar the read/write ordering issue, and I think thats
>> easily solved by throwing more memory at the problem).
>
>Yes, with 4MB per track it would even work without inode preallocation,
>but 50 x 4 = 200MB = quite a bit of memory , not worth to waste it
>as mere track buffers (the disk latencies aren't 6 secs big :-) )
I use less than 1MB per track.
>No problem Paul , I thought about this issue while designing my algorithm:
>it is really simple, just limit the maximum read/write size:
>if the extremely empty track has 2MB space in it, I don't read the whole 2MB,
>but I limit the upper size to 256kb for example, that ensures a fast service
Right, its just that this wasn't specified in your original algorithm,
and its an absolutely critical part of the method.
Oops, my daughter is awake. Talk to you later.
--p
This archive was generated by hypermail 2b28 : Mon Apr 10 2000 - 21:46:20 EEST