Article: 236 of comp.sys.cdc From: greg@lewis.ucs.indiana.edu (Gregory Travis) Newsgroups: comp.sys.cdc Subject: Re: Ethernet and I/O channels Date: Tue, 31 Jul 2001 16:55:36 +0000 (UTC) Organization: A poorly-installed InterNetNews site Lines: 152 Message-ID: <9k6nu8$1et$1@lewis.ucs.indiana.edu> References: <3b66bc37$1_3@news.iglou.com> NNTP-Posting-Host: lewis.ucs.indiana.edu Path: news.meer.net!sea-read.news.verio.net!dfw-artgen.news.verio.net!dfw-peer.news.verio.net!news.verio.net!stl-feed.news.verio.net!news.cc.ukans.edu!newsxfer.eecs.umich.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!howland.erols.net!vixen.cso.uiuc.edu!news.indiana.edu!lewis.ucs.indiana.edu!not-for-mail Xref: archive.mv.meer.net comp.sys.cdc:236 In article , Mike Schaeffer wrote: >On Tue, 31 Jul 2001, Douglas H. Quebbeman wrote: >> Except that you should not show a fixed, static association of PP to >> channel, >> but rather something that implies a dynamic assignment from a pool. > >Hmmm.... > > +-----------+-->I/O Channel > +-->PP-->+ + >CPU---+ ... + 'switch' + ... > +-->PP-->+ + > +-----------+-->I/O Channel > >[-- Main Computer Parts ---][-- Expansion 'Slots' --] > >Where the 'switch' is a device that links PP's to channels, and is >configurable at startup? Configurable at RUNTIME. Every PP could request ANY channel. Each PP could perform the following functions on any (half-duplex) channel: Tests to see if the channel is about to or has begun data transmission: AJM m d - Jump to location m in PP memory if channel d is active (active means the channel is busy with a device) IJM m d - Same but for INACTIVE channel FJM m d - Jump to location m in PP memory if channel d is full (full means at least 1 12-bit word of data has been sent from a device but not read by the PP or sent by the PP but not yet accepted by thed device) EJM m d - Same but for EMPTY channel Prepare a channel for data transmission: ACN d - Activate channel d. Must precede IAN/IAM/OAN/OAM instructions! NOTE: Activating an already active channel HANGS the PP. DCN d - Deactivate channel d. Initiate data transmission on a channel: IAN d - Transfer a word (12 bits) from channel d to the PP's A register (A register is 18 bits. Upper 6 are cleared). Using this instruction is roughly equivalent to doing PIO to the device. IAM m d - Input (A) words from channel d to the PP's memory starting at location m. The A register gives the number of words to transfer. Roughly equivalent to doing DMA to the device. OAN/OAN {m} d - Same as IAN/IAM but for OUTPUT from the PP to the channel Perform a function on a channel: FAN d - Perform a function on a channel. Functions are non-data operations such as disk seeks, equipment select (when more than one piece of equipment is on a given channel, etc.). Function to be performed is contained in PP A register. Do not execute if the channel is active or the PP will HANG. FNC m d - Same as FAN except the function code is inline as m. In addition to channel operations, PPs also had instructions to read/write central memory in both word-at-a-time and block mode: CRD d - Central read from (A) to d. PP's A register contains the address in central (CPU) memory. d is the address in the PP's memory. Transfers a single 60-bit word from the (CPU) main memory to five consecutive 12-bit PP memory words starting at PP mem location d. CRM m d - Central read m words from (A) to d. PP's A register contains the starting address in central (CPU) memory. d is the starting address in the PP's memory. Transfers m 60-bit words from central memory to PP memory starting at d. Note my comments above with regard to PPs getting hung. It was critical that there be a mechanism whereby PPs could reserve channels prior to trying to activate or perform functions on them lest they become HUNG (which, IIRC, required a deadstart to clear). PP0 always ran a program called MTR (monitor) which implemented the nucleus of the OS. Whenever a random PP wanted a channel it would communicate with PP0 through central memory and request the channel. Some time later MTR would signal the PP with the indication that the channel was reserved for it. Here's a general flowchart for a disk read operation: 1. Program running on the CPU requests a disk read operation by putting the request code ("CIO") in location 1 of its memory space. 2. MTR notices that location 1 of the program's memory space is non-zero, finds a free PP, and asks that PP to load CIO into itself. 3. The free PP loads CIO into itself 4. CIO determines where the file lives (channel, device, etc.) 5. CIO asks MTR to reserve the channel for it.* 6. MTR grants the request.* 7. CIO in the PP performs whatever functions are necessary to position the heads/etc. on the disk. (FAN instruction) 8. CIO activates the channel (ACN instruction) 9. CIO transfers a sector (or more?) from the channel/disk into the PPs memory (IAM instruction)** 10. CIO disconnects the channel (DCN instruction) 11. CIO signals MTR it is done with the channel* 12. CIO transfers the data from PP memory to central memory for the CPU program (CWM instruction)** 13. CIO signals MTR that it is exiting (i.e. the PP is again free for assignment) and exits. I'm sure others will clear up any mistakes on my part but that's the general gist. *Note that PPs could communicate with each other not only through common message areas in central memory (and CRM/CWM instructions) but also through channels. PP1 could request channel 1 for read use while PP2 could request channel 1 for write use. Once connected thus the PPs could exchange information between each other through IAN/IAM<->OAN/IAM instructions without having to go through central memory. **One of the "improvements" in the 7600 was additional instructions which allowed a channel to input directly to central memory. This eliminated the need to first input to PP memory and then copy out of PP memory and into central memory. greg -- Gregory Travis Advanced Network Management Lab (ANML) 812-855-5091 gtravis@indiana.edu Article: 238 of comp.sys.cdc From: greg@lewis.ucs.indiana.edu (Gregory Travis) Newsgroups: comp.sys.cdc Subject: Re: Ethernet and I/O channels Date: Tue, 31 Jul 2001 20:30:16 +0000 (UTC) Organization: A poorly-installed InterNetNews site Lines: 94 Message-ID: <9k74go$2eq$1@lewis.ucs.indiana.edu> References: <9k6nu8$1et$1@lewis.ucs.indiana.edu> NNTP-Posting-Host: lewis.ucs.indiana.edu Path: news.meer.net!sea-read.news.verio.net!dfw-artgen.news.verio.net!dfw-peer.news.verio.net!news.verio.net!stl-feed.news.verio.net!news.cc.ukans.edu!newsxfer.eecs.umich.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!howland.erols.net!vixen.cso.uiuc.edu!news.indiana.edu!lewis.ucs.indiana.edu!not-for-mail Xref: archive.mv.meer.net comp.sys.cdc:238 In article , Mike Schaeffer wrote: >On Tue, 31 Jul 2001, Gregory Travis wrote: > >> PP0 always ran a program called MTR (monitor) which implemented the >> nucleus of the OS. Whenever a random PP wanted a channel it would >> communicate with PP0 through central memory and request the channel. Some >> time later MTR would signal the PP with the indication that the channel >> was reserved for it. > >So, how were reservations bounded? If I reserve a channel, and forget to >release it, is there a mechanism for automatically releasing it when the >requesting process finishes? I don't believe they were bounded. If your PP program grabbed a channel and never gave it back I think the channel was hosed until deadstart. There was also a warmstart which may have been a way to keep things going. I don't remember the particulars of a warmstart but I think it was simply a master reset of the hardware w/out a central and PP memory reload. The system could continue as-is after the warmstart with a few exceptions. Card readers had to be re-loaded, print jobs restarted, tape jobs restarted, etc. I'm really reaching into my memory for this one though. Remember that user code didn't run in PPs. Only system code. It was "supposed" to always be right! > >> Here's a general flowchart for a disk read operation: >> >> [flowchart snipped] > >It actually suprises me that it made sense to allocate a PP, find a >channel, and load a program into the PP for each sector read. I guess with >so many PP's, it was possible to do a bunch of 'em at once. Well, that was a worst-case. Most transfers were multi-sector in nature. In KRONOS the smallest physical disk unit was referred to as a "PRU" or "Physical Record Unit." I believe that PRUs were the logical representation of sectors on the disk. Each PRU was 64 words long (640 6-bit characters). However, disk allocation was done in multiple PRU units. For instance, on the 844 disk drive allocation (block) size was 107 PRUs which meant that your files were allocated in 107*640 character = 68,480 character blocks. The PPs could not read consecutive sectors on disk - there wasn't enough time to terminate the first read and set up the next before the sector passed under the heads. Therefore PPs read every other sector which led to the design decision to base allocation on disk on "half-tracks" (really "half-cylinders." I believe, but am not 100% sure, then that a single 844 cylinder was 68,480*2 characters in size. Here's how a real-world read might go: 1. CPU program requests a 40PRU read. 2. (bunch of setup stuff omitted. See my earlier post). 3. CIO sets "n" to the sector location of the first PRU on the disk's cylinder. 3. CIO does a read of sector "n" the PP's memory. 640 characters/ 64 CPU words/320 PPU words. 4. CIO transfers the 64-word PRU (CPU words) from PP memory into CPU memory. CIO updates the CPU program's circular buffer pointers to reflect the new data. (Remember, the CPU program is free to run asyncronously. It does not need to block for the entire 40PRUs). 5. CIO increments "n" by two. 6. CIO decrements the total PRU count by one 7. If not zero, go to stop 3. 8. Done! 9. Exit the PP >Thanks for your time answering my questions. The CDC's I/O subsystems >seem like a pretty amazing piece of work. The ability of the CPU program to run asyncronously with the PPU programs was a big performance win. greg -- Gregory Travis Advanced Network Management Lab (ANML) 812-855-5091 gtravis@indiana.edu