[email protected] (Tony Harminc) writes: > In the real world, PCI would be used to modify the channel program on > the fly. It would presumably be copying the data to another device > (tape or disk), and as long as that output device could keep up, > there's no reason for this to be a theoretical-only scheme. > > Much the same thing, on a smaller and slower scale (though perhaps not > much smaller relative to the hardware of the day) was done by APL\360 > with its terminal I/O. The terminal read channel program was unending, > with new buffers being chained in based on PCI interrupts.
re: http://www.garlic.com/~lynn/2013o.html#6 "hexadecimal"? http://www.garlic.com/~lynn/2013o.html#10 "hexadecimal"? http://www.garlic.com/~lynn/2013o.html#12 "hexadecimal"? with the advent of virtual memory and EXCP no longer executing the passed channel program ... but a copied that had been swizzled (replacing virtual addresses with current real addresses, virtual addresses possibly contiguous ... but the corresponding pages in real storage no longer contiguous, etc) ... the PCI appendage wouldn't be modifying the channel program actually in use EXCPVR was created for authorized code to create real CCWs with real addresses (doing the necessary work to deal with real addresses rather than real addresses) http://pic.dhe.ibm.com/infocenter/zos/v1r12/topic/com.ibm.zos.r12.idas300/efcprs.htm#efcprs from above: Fix the data area containing your channel program, the data areas referred to by your channel program, the PCI appendage (if your program can generate program-controlled interrupts), and any area referred to by the PCI appendage including the DEB, IOB, etc. To fix these areas, build a list in your PGFX appendage containing the addresses of these virtual areas. Any area that you know already is in fixed storage for the duration of the I/O can be omitted from the page fix list. ... snip ... cp67 & vm370 might do long, channel program with multiple page transfers ... especially fixed-head devices. For really long channel programs, I would add periodic PCI interrupts to allow more timely processing of pages already transferred ... w/o waiting for the complete channel program to end (but it didn't involve modifying channel programs in progress). original cp67 delivered to the univ. had a FIFO queue of page i/o requests and would do single transfer per channel program. This achieved peak throughput of approx. 80 page transfer per second on 360/67 with 2301 fixed-head drum (avg. half revolution delay per page transfer). As an undergraduate in the 60s, I modified that to chain together all requests for arm position (or all queued requests for 2301 fixed-head drum) to maximize transfers per revolution. This could get very close to theoritical max. 270 page transfers second (3600rpm, 60rps, nine 4k pages formated per pair of tracks, two revolutions per 9 4k page transfers). For 2311 & 2314 moveable arm disks, cp67 originally also did FIFO queue processing ... at the same time I did the multiple request chaining ... i also added ordered arm seek queueing. The combination significantly increased loaded I/O throughput ... and also made degradation under heavy load much more graceful. -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
