Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!jato!vsnyder From: vsnyder@jato.jpl.nasa.gov (Van Snyder) Newsgroups: comp.sys.atari.st Subject: Re: Multitasking Message-ID: <1991Feb16.004202.26343@jato.jpl.nasa.gov> Date: 16 Feb 91 00:42:02 GMT References: <74457@bu.edu.bu.edu> <1991Feb11.151210.4010@informatik.uni-erlangen.de> <1976@lee.SEAS.UCLA.EDU> Reply-To: vsnyder@jato.Jpl.Nasa.Gov (Van Snyder) Organization: Jet Propulsion Laboratory, Pasadena, CA Lines: 74 From 1968 to 1984, I used an Univac 1108, which had 262144 words of 36 bits each of memory (about 1 MB). The operating system used about 32k of this for code, and another 32k for data (heap), leaving 1bout 196k words for users. We ran with 50 interactive users, 10 active batch (background) jobs, and queues of up to 50 or so background jobs. Plus input and output spooling. The machine had 11 4ms drums, each with 262144 words, for swapping. It was expensive, but gave better response than a 6Mhz AT (although the user interface sucked). The key to the performance was that Univac knew how to build a machine that could handle interrupts quickly (2 cycles, because there was an entire duplicate set of registers for the OS), and, more importantly, the operating system KNEW HOW TO USE INTERRUPTS. If you implement multitasking by ticking the clock every k (say 10) milliseconds, and going around asking "are you ready to run", your performance will be more like Unix (30% penalty at least). The switching algorithm used in 1100 OS was what OS theorists call "inverse of remainder of quantum:" Each process has a priority and a "time quantum". A process is NOT interrupted by the clock until its time quantum has expired. Other interrupts, e.g. I/O completion, external event (keystroke or mouse movement), etc may make a higher priority process eligible for execution. If a process willingly relinquishes control, e.g. to wait for disk or console I/O, before using 1/2 of a quantum, its quantum is halved, and its priority increased. If a process willingly relinquishes control after using more than half but less than all of its quantum, neither quantum nor priority change. If a process loses control by its quantum expiring, the quantum is doubled and the priority decreased. By this scheme, the OS overhead for a compute-only task rapidly approaches zero. If your processor and OS both know how to handle interrupts, and the task dispatcher uses decent data structures for keeping track of task priorities, and you don't piss away 1/3 of the cycles fooling with the clock unnecessarily, the performance of a multitasking OS supporting one interactive process should also approach zero. Another thing the 1100 OS knew how to do EXCEEDINGLY WELL was disk and tape I/O. There were five basic I/O interfaces: overlapped IO, synchronized later by explicit WAIT request; I/O with the OS causing you to wait to get control until the I/O completed (but somebody else got to use the processor); over- lapped I/O with pseudo-interrupt at termination; I/O with wait and pseudo- interrupt at completion; and I/O with task termination and pseudo-interrupt at the end. The last has pretty much the same effect as the second, but with less overhead. One might argue that I/O with overlap causes the machine to slow down because of contention between the channels and processors, but if the BIOS sits there and says "hey, are you done? hey, are you done? hey, are you done? ..." a million or so times per I/O, the effect is to have much worse performance than if even half of the processor's cycles get stolen by the channel. On the ST, unfortunately, there's only one DMA for both the hard and floppy disks, so the most interesting overlapped I/O opportunities can't be realized. But I/O to the disk and printer, for example, could proceed concurrently with computing IF ONLY THE OS WERE CLEVER ENOUGH. Even if TOS/GEMDOS/BIOS/XBIOS never learns how to multi-task, I'd like to have overlapped I/O to the floppy disks, ACSI, printer, RS-232 and MIDI at least. At the BIOS level, I'd like to give a SCSI block (yes SCSI, not ACSI), and a memory address if necessary. This would make it trivial to write support for tape, ethernet, toasters, etc. on the ACSI channel. I'd be happy to have only "start I/O and return immediately with I/O proceeding concurrently" and "wait for I/O to complete" interfaces to the BIOS. At the GEMDOS (file I/O) level, I'd like to add both of the above to the present "start I/O and don't continue until it's done" interface. Of course, I'd like the same for the rest of the devices. It would also be nice to be able to use interrupts, but that may require something more like a multitasking kernel. Enough of a tirade for now. Maybe more later. In general, I don't think TOS/GEMDOS/BIOS/XBIOS preclude intelligent I/O, or even multitasking. One doesn't need all the clanking machinery of Unix. [Aside: The hackers who invented Unix were rebelling at the size of Multics. Unix is now about 5 times the size of Multics, and doesn't do more than a few extra things (mostly networking stuff).] Van -- vsnyder@jato.Jpl.Nasa.Gov ames!elroy!jato!vsnyder vsnyder@jato.uucp