auyeung@iris.ucdavis.edu (Tak (UlTech) AuYeung) (11/08/89)
Greetings to all the pros in AmigaLand! I'm not even close to
a pro in ALand, and this is why I have to ask for YOUR help!
I noticed that disk accesses are mostly delayed by the seek time
of the disk head (vs. the actual transfer time), especially in
a multitasking environment. Even if you use a disk optimizer,
two processes trying to access data on different cylinders will
make the disk seeking mechanism very busy. For hard disks
owner, this problem may be minute, but for most floppy-only
Amigans, the seek operation is noisy, slow and bad for the
media (floppy disks).
So are there any alternative disk drivers that optimizes seek
operations so that the disk head scans through the cylinders
in a smoother manner? For example, we can keep a SeekQ sorted
by the cylinder number and the driver always pick the next
SeekRequest that is closest to the current one first in
decreasing order until it hits the tail of Q, and then in
increasing order until it hits the head of Q. This eliminates
starvation for the de/increasing order is monotonic. Of
course, there are more elegant scheduling algorithms, but this
simple one is all I can think of now. E.g., we may serve all
the requests in the neighborhood first, then go on to the
next district...
If there is no existing s/w to do this, could any one of you
pros write a PD smooth disk driver? I think a lot of amigans
will appreciate your kind contribution!
Thanks for your attention!
--Tak
# # ===== everything's only what it seems to be
# # # # ===\ /=== # # >>>>> auyeung@iris.ucdavis.edu
# # # # ----X #---# >>>>> Tak-Ying (UlTech) AuYeung
\===/ \=== # ===/ \=== # # >>>>> Logical Entity in Netlandlimonce@pilot.njin.net (Tom Limoncelli) (11/08/89)
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). 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!"
UH2@PSUVM.BITNET (Lee Sailer) (11/08/89)
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!"
filbo@gorn.santa-cruz.ca.us (Bela Lubkin) (11/09/89)
In article <5850@ucdavis.ucdavis.edu> Tak (UlTech) AuYeung writes: >I noticed that disk accesses are mostly delayed by the seek time >of the disk head (vs. the actual transfer time), especially in >a multitasking environment. Even if you use a disk optimizer, >two processes trying to access data on different cylinders will >make the disk seeking mechanism very busy. For hard disks >owner, this problem may be minute, but for most floppy-only >Amigans, the seek operation is noisy, slow and bad for the >media (floppy disks). Transfer rate is not an insignificant problem either: since Amiga-format floppies don't use sectors, an entire track must always be read. At 360 RPM, that's 1/6 second. (Or is it 300 RPM and 1/5 sec?) I suspect that trackdisk.device also waits for start-of-track before beginning to read, adding another 1/12 sec average latency. The point so far is: if you had a magic drive with 0 seek time you would still wait an average of 1/4 (3/10?) sec for each competing disk access. Anyway, what you (and I) want is a track cache. Why try to speed up the seeking when it isn't necessary? Most of that back-and-forth seeking is reading the same two tracks alternately as the 2 processes each read the next data. If trackdisk.device cached just 2 tracks for each drive (the previous one and the current one), much of the contention would go away. Not all of it, but enough to make me much happier... Proposal: trackdisk.device should cache a user-settable number of tracks for each drive. The cached tracks should be in data format (i.e., after being run through the blitter) and should optionally be storable in fast memory (at the expense of using the 68000 to move them there). Just a sanity check here: I don't THINK "AddBuffers" does this. It sure sure SEEMS as if AddBuffers buffers contain only logical "sectors" which have already been read, which are exactly those that are NOT going to be reread when 2 processes are fighting over a drive for sequential access. Likewise, though ASDG's FACCII helps, it caches sectors, not tracks, and does not seem to keep sectors that were read because a different part of the track was needed. The documentation does not say anything about it; perhaps Perry or someone else from ASDG can comment? Anyway, I'd rather have a simple two-track cacher than FACCII; ARes does most of what I would need a floppy cacher for and a 2- or 3-track cacher would handle the rest... {Don't you hate it when your first 3-4 lines match up so neatly that you just HAVE to finish the rest of the message that way? ;-} Bela Lubkin * * // filbo@gorn.santa-cruz.ca.us CompuServe: 73047,1112 @ * * // ....ucbvax!ucscc!gorn!filbo ^^^-VERY slow [months] R Pentomino * \X/ Filbo @ Pyrzqxgl +408-476-4633 & XBBS +408-476-4945
ccplumb@rose.waterloo.edu (Colin Plumb) (11/10/89)
In article <81.filbo@gorn.santa-cruz.ca.us> filbo@gorn.santa-cruz.ca.us (Bela Lubkin) writes: > Transfer rate is not an insignificant problem either: since Amiga-format > floppies don't use sectors, an entire track must always be read. At 360 > RPM, that's 1/6 second. (Or is it 300 RPM and 1/5 sec?) I suspect that > trackdisk.device also waits for start-of-track before beginning to read, > adding another 1/12 sec average latency. 300 RPM; 200 ms. To make sure it gets all 11 sectors, the trackdisk.device actually reads about 1.1 revolutions, 220 ms. Since worst-case seek is 79*3 = 237 ms seek time +15 ms settling time = 252 ms is not much worse than the time to actually read a track, I came to the conclusion that it's important to get a lot out of a track, but after that, which track it is isn't terribly important. > Anyway, what you (and I) want is a track cache. Why try to speed up the > seeking when it isn't necessary? Most of that back-and-forth seeking is > reading the same two tracks alternately as the 2 processes each read the > next data. If trackdisk.device cached just 2 tracks for each drive (the > previous one and the current one), much of the contention would go away. > Not all of it, but enough to make me much happier... Apparently, it's being added. The original 0.95 (or whatever it's called) trackdisk.device cached multiple tracks, but then they decided that was too memory-hungry. Since memory is getting cheaper, the feature is coming back. > Just a sanity check here: I don't THINK "AddBuffers" does this. It sure > sure SEEMS as if AddBuffers buffers contain only logical "sectors" which > have already been read, which are exactly those that are NOT going to be > reread when 2 processes are fighting over a drive for sequential access. AddBuffers doesn't do this. Addbuffers is AmigaDOS' cache, and it doesn't know that the trackdisk.device has already done all the work of reading in all the other sectors on this track, so AmigaDOS doesn't think to cache them. The result, when two reads are being interleaved, is that it reads one sector from each track before seeking to the next, resulting in less than 1/11 of the maximum transfer speed. Bad news. Read-ahead could also alleviate the problem to a degree. -- -Colin
new@udel.edu (Darren New) (11/10/89)
In article <81.filbo@gorn.santa-cruz.ca.us> filbo@gorn.santa-cruz.ca.us (Bela Lubkin) writes: >Just a sanity check here: I don't THINK "AddBuffers" does this. I think AddBuffers adds buffers to the FILESYSTEM cache, not the hardware driver cache. Thus, this would help if (say) two processes were doing the "dir" command. >Likewise, though ASDG's FACCII helps, it caches sectors, not tracks, and >does not seem to keep sectors that were read because a different part of >the track was needed. I noticed that -- that's why I never bought FACCII. Of course, now I have a hard drive so I never will. It seems like it would be easy to add a "from here to end of track/cylinder" cache to FACCII just by translating such a request into a sequence of requests. -- Darren
auyeung@iris.ucdavis.edu (Tak [UlTech] AuYeung) (11/10/89)
In article <81.filbo@gorn.santa-cruz.ca.us> filbo@gorn.santa-cruz.ca.us (Bela Lubkin) writes: > >Transfer rate is not an insignificant problem either: since Amiga-format >floppies don't use sectors, an entire track must always be read. I thought you have to scan thru half of the track on the average in order to locate one sector (even if you have sectors). >At 360 >RPM, that's 1/6 second. (Or is it 300 RPM and 1/5 sec?) I suspect that >trackdisk.device also waits for start-of-track before beginning to read, >adding another 1/12 sec average latency. Thanks, I didn't know that. >[...] >Proposal: trackdisk.device should cache a user-settable number of tracks >for each drive. The cached tracks should be in data format (i.e., after >being run through the blitter) and should optionally be storable in fast >memory (at the expense of using the 68000 to move them there). > Good idea! Thanks for your response! --Tak # # ===== everything's only what it seems to be # # # # ===\ /=== # # >>>>> auyeung@iris.ucdavis.edu # # # # ----X #---# >>>>> Tak-Ying (UlTech) AuYeung \===/ \=== # ===/ \=== # # >>>>> Logical Entity in Netland