Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!apple!vsi1!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: comp.sys.amiga Subject: Re: Multitasking (was re:Powermonger etc.) Message-ID: <1990Dec15.071054.16200@zorch.SF-Bay.ORG> Date: 15 Dec 90 07:10:54 GMT References: <9012130059.AA08767@ucbvax.Berkeley.EDU> Organization: SF-Bay Public-Access Unix Lines: 91 i0046145@WATER.FIT.QUT.EDU.AU (Lukacz Alex) writes: > I've been having major problems with multitasking lately, anyone care > to tell me what exactly is happening or a fix? > 1) When using DiskMaster (V1.4) and NComm (V1.9) I often copy files or > unarc just-downloaded files while online. Trouble is, when I try to > get a directory (through the 1.3 'List' or 'Dir' commands) whilst > unarcing is taking place, the disk drive managed to 'crunch, crunch' > back and forth for MINUTES. > I think what is happening here is that the dir command is trying to > get to the tracks around 880 for the list of files whilst the arcing > program is still trying to unarc the program which would be spread > over the tracks of the disk. > Now I think this is rather silly. Surely one task should take priority > over the other, so the 'dir' could intercept the unarcing and get the > list of files and then let arc get back to work. > I have tried changing the task priority of 'dir' and 'list' but it > doesn't seem to have much (read: any) effect. Well, the problem is that the size of the time slice for multitasking is _much_ smaller than the time needed to do do a DIR on a fairly large directory, so what you are hearing looks like this: Start arc .. Start dir .. arc is sleeping waiting for a disk i/o head is moving toward arc's block dir asks for a directory block, gives up control, goes to sleep head continues for arc block arc block is found, read, arc is marked ready to run head starts toward next request, dir's directory block arc is ready to run, arc processes a little, is preempted dir is still waiting for a block arc wakes, processes, is preempted, etc arc has completed a read or ready to write block, asks for disk i/o, sleeps head continues for dir's directory block, reads it, dir is marked ready to run head starts toward next request, arc's block dir is ready to run, processes a dir block, asks for next block, goes to sleep head continues toward arc's block go to top The alternative would be to completely lock out one or the other process until the higher priority process was done. The problem is that, once the head starts toward an i/o block, that process is not (nor should it be) interruptable. The net result is that you are getting blocks alternately for the two running tasks. > 2) When online a BBS or the VAX/UNIX, the text output to my monitor > slows down IMMENSELY if I'm doing disk-accesses at the same time. For > example, I'm looking for a particular file which I wish to upload. I > am certain it is on one of two disks sitting in my disk-mailer. I wish > to get a directory of both disks so I can find out which one the file > is on. I change windows to the CLI window and then issue 'dir'. Click > back to the NComm window and SHAZAAM! - text output is slowed to an > annoyingly slow rate. This happens both at 2400 and 9600 baud. > I have absolutely no idea of what is going on here. OK, when you aren't doing anything at all, but your host site is a bit slow, watch the idiot lights on your modem, and you will notice a perceptible delay between the flicker indicating data passing through your modem, and the characters showing up on your screen. There is a considerable amount of work done to draw the characters. For sure, having the processor busy cuts down the time it has to draw characters on your screen. Beyond that, if the character display is being done with the blitter, then the disk MFM decoding is fighting with the character display over the use of the blitter. Since directory blocks are scattered across floppies, and since reading a single block from an Amiga floppy involves reading and decoding a whole track, every time a directory block is on a new track, the blitter is _very_ busy during a DIR command. >Any hints/solutions (no flames, send 'em to /dev/null) would be appreciated. You have my best guesses; better data takes a better author. /// It's Amiga /// for me: why Kent, the man from xanth. \\\/// settle for \XX/ anything less? -- Convener, ongoing comp.sys.amiga grand reorganization.