Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!usc!snorkelwacker.mit.edu!paperboy!meissner From: meissner@osf.org (Michael Meissner) Newsgroups: comp.protocols.nfs Subject: Re: Offloading I/O [was:Incremental sync()s ...] Message-ID: Date: 19 Mar 91 16:57:39 GMT References: <3254@crdos1.crd.ge.COM> <19838@cbmvax.commodore.com> <1088@spim.mips.COM> Sender: news@OSF.ORG Followup-To: comp.protocols.nfs Organization: Open Software Foundation Lines: 82 In-reply-to: mash@mips.com's message of 18 Mar 91 05:13:53 GMT In article <1088@spim.mips.COM> mash@mips.com (John Mashey) writes: | 7. Make the IOP smart enough to distinguish between "ordinary" | characters which should be echoed, and stuck in an input queue, | and other characters and/or sequiences, which demanded response from | the CPU. The theory here, is that, for example, you sit typing text into | vi or emacs fairly efficiently, and still get the various control | sequences to do something, without making the IOP huge. | | Of course, since every program might well use different special sequences, | this may require more interaction with the main CPU. | I think this one has been done. In it's propriatary operating system AOS/VS (and AOS/VS-II), Data General has done this option for about 11-12 years. It started with one outboard processor to control all character devices and was called an IOP. As terminal counts got higher, it turned into one processor for every 8 or 16 lines called IAC's. I think the current high end system uses 4 68000's for an IAC instead of the wimpy bit-slice Nova or Eclipse sorta work alikes from hell that they had previously used. Originally, it would do just buffering, but later versions of the OS added the AOS command line editing that the CLI had originally done from user space. Finally, the OS put a full blown interpretter for it's word processing system in there. At the same time, the buffer sizes for the lines kept shrinking, and more stuff kept moving back to the host for processing to keep within the 64K memory requirements. After memory size issues, the main problem with this was inflexibility (partly due to memory requirements). The command line editing used fixed characters, based on the original DG terminals. With a great deal of care (ie, you had to patch the IAC binary), you could support maybe 10 different terminals, though in general only the 2 classes of DG terminals were fully supported. Also, only one copy of the interpretted bytestream could be downloaded per controller, which lead to the system call which downloaded the program not to be documented, which lead to only one application using it. Another problem with IAC's (before the 68000 based IAC's which I never used) was speed. These things were cheap, and very slow. You could not reliably use a comm program like uucp at full 9600 baud if memory serves, let alone more than one on the same IAC. Finally, you have the problem of imported software. If you bring software in from outside, it would typically drop down to single character I/O and do it itself. Because of the length between the serial line and the process getting the data, it would slow things down if the processor just woke up the host on every character. | One clear lesson: | When doing an IOP, be careful that the interface requirements don't | change on you, especially if they often force you into a | transparent pass-thru mode where the IOP really is doing nothing. Yep. | Another one: watch out if you trying to make the same IOP handle both | terminal I/O and fast serial lines to connect systems Yep. | I believe that most systems tend to use devices in groups 1-5 these days, | because the processing requirements have gotten complex enough that | you might as well just have the main CPU do it, irritating though it | may be. | | Anyway, those are a few samples. Maybe people would post examples | of these various approaches, or others, with comments on: | a) How well they worked They worked well in their original time frame, but were pushed beyond their original specs. | b) How long they lasted Still in use I believe. | c) What the weirder bugs and problems were -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Considering the flames and intolerance, shouldn't USENET be spelled ABUSENET?