🚀 go-pugleaf

In article <Nov.7.16.24.25.1989.5022@pilot.njin.net>, limonce@pilot.njin.net
(Tom Limoncelli) says:
>
>Figure a SeekQ for two processes each reading one file (the
>description that you described, which is a VERY typical one).
>Now do that calculation for the same senerio but use a SortedSeekQ.
>
>Notice that the total seek time was the same.  (Even if sorting took
>no time to perform).
>

Yes, but...

What happens if process A reads a couple of blocks from track 1, and then
process B reads a couple of blocks from track 50, and then A needs a couple
more blocks from track 1, again.  Under the current system, does track 1
get read in again?  If that is so, that is the source of much of the floppy
gronking.

Also, what about some sort of twofer algorithm?  Keep track of the last three
tracks read, say t1, t2, and t3.  If the time between the requests is small,
and t1 and t3 are close together relative to t2, and the next request t4 is
close to t2, then satisfy t3, wait a moment to see if another request near
t3 shows up.  If so, satisfy it before going on to t4.

I know.  I should try to spell this out in more detail, but this is really
not my area of expertise (I say that a lot.  I don't really have one, you
see 8-).

        lee
>I think Tannembaum's OpSys book has this question almost EXACTLY in
>one of the chapter reviews.  (Good book, by the way).
>
>Basically, on single-user machines, you'll find that it doesn't help.
>Of course, it would be nice if AmigaDOS did it anyway, just for the
>one or two times that you're running 100 processes and they're all
>doing disk i/o.  :-)  :-)
>
>-Tom
>--
>Tom Limoncelli    -- limonce@pilot.njin.net        Standard Disclaimer
>CM 1060           -- tlimonce@drunivac.bitnet
>P O Box 802       -- ...!rutgers!njin!drew!tlimonce
>Madison, NJ 07940 -- 201-408-5389
>  "I do not like green eggs and spam, I do not like them, Sam I am!"