Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!vsi1!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: comp.sys.amiga.hardware Subject: Obsessive Multitasking and Amiga File I/O Scheduling Keywords: needs work Message-ID: <1990Sep8.050725.14384@zorch.SF-Bay.ORG> Date: 8 Sep 90 05:07:25 GMT References: <6499@sugar.hackercorp.com> <1159@mpirbn.mpifr-bonn.mpg.de> <14260@cbmvax.commodore.com> Organization: SF Bay Public-Access Unix Lines: 62 jesup@cbmvax (Randell Jesup) writes: > p554mve@mpirbn.UUCP (Michael van Elst) writes: [...] >>On the other side, the Amiga (the filesystem) is very slow when dealing >>with concurrent tasks. The filesystem deals with requests in >>first-come-first-served order and concurrent accesses lead to heavy >>thrashing of the disk. This is because there is no buffer cache, no >>read-ahead and no "elevator"-algorithm. But it is not necessary most >>of the time since the Amiga is a single user system and only few users >>will put stress on the disk by loading several programs or files at once. [...] > Elevator only helps in the case of 3 or more tasks making >accesses at the same time. Read-ahead does help in multiple-access >situations, but more and more SCSI drives have built-in read-ahead. Your >points on single-user are on-target. Remember, though, that a lot of >Unix machines are effectively single-user and rarely have multiple-accesses >occurring (though more often than AmigaDos). I didn't think my use patterns were that unusual, but maybe so. Yesterday, in a fairly typical setup, I had half a dozen shells open on the (A2000,1.3) workbench, doing various combinations of zoo -add, zoo -extract, lharc a, lharc x, interactive dir-s and info-s and list-s to make sure I wasn't clobbering Rad:, and on another screen, vt100 running to do downloads. Slow as molasses, on a 68000, but productive as heck, since I could read news and mail between downloads, and just flip back to the workbench every once in a while to get a new process going in the next window. I sorted through ten megabytes of email and refiled it on floppies this way, while catching up on yet more correspondence. I bought my first Amiga, and this latest one, to *multitask*, and I spend lots of days like the above. Of course, poverty and indolence keep me running out of Rad:, but I'm really upset to find out that a machine whose internal OS is multitasking all the way has such uneven/unbalanced support for it overall that I'd be really unhappy trying to do the same thing from a hard disk. Is there a better disk I/O scheduling algorithm in 2.0, or at least one in work? As Randall notes, the solutions are well known, and should be "in there" by now. It's been over five years, after all. Along with the deadly repeated "key error, backup, reformat and reload" problems reported here so often, this is another market killer for the business marketplace (which surely won't tolerate the unreliable hard disk problem like a crowd of hackers/students ready to do the "repairs" themselves will), and both need fixes Really Soon. Buying a machine that advertises multitasking, and then hearing your disk drive attempt to self destruct when you try to do so is almost as unimpressive as having your _whole_ file system go gaga and need a long, frustrating recovery to be done, every time a program dies in mid-write. Fsck is overdue for AmigaDOS. So tell me, am I the only one multitasking this sucker within an inch of its life as a regular way of doing work? Or is this the general problem I perceive it to be? Kent, the man from xanth.