Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Architectural implications of locate mode I/O
Date: Wed, 3 Jul 2024 21:18:19 +0000
Organization: Rocksolid Light
Message-ID: <063ba7a0449d8fe4e7d9966704b907c3@www.novabbs.org>
References: <v61jeh$k6d$1@gal.iecc.com> <v61oc8$1pf3p$1@dont-email.me> <HYZgO.719$xA%e.597@fx17.iad> <8bfe4d34bae396114050ad1000f4f31c@www.novabbs.org> <0001HW.2C3576BF001454603060E538F@news.individual.net> <20240703153406.00006ebe@yahoo.com> <DlhhO.1222$rF4c.905@fx04.iad> <v64903$2b182$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="2059172"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$LByguiSxINZWJrnQ.BNWeuHu0iYEAkV3qwoXON/.gse2BO/vbMYPG
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
Bytes: 4173
Lines: 69

Stephen Fuld wrote:

> Scott Lurndal wrote:
>
>> Michael S <already5chosen@yahoo.com> writes:
>>> On Wed, 03 Jul 2024 13:08:31 +0100
>>>Bill Findlay <findlaybill@blueyonder.co.uk> wrote:
>>>
>>>> On 2 Jul 2024, MitchAlsup1 wrote
>>>> (in article<8bfe4d34bae396114050ad1000f4f31c@www.novabbs.org>):
>>>>
>>>> > Once you recognize that I/O is eating up your precious CPU, and
>> you >> > get to the point you are willing to expend another fixed
>> programmed >> > device to make the I/O burden manageable, then you
>> basically have >> > CDC 6600 Peripheral Processors, programmed in
>> code or microcode.  >>
>>>> The EE KDF9 (~1960) allowed up to 16 connected devices at a time.
>>>> They all did DMA, interrupting only at the end of the transfer.
>>>> Slow devices accessed the core store for each character,
>>>> fast devices did so for each word.
>>>>
>>>> This was mediated by one of the KDF9's many state machines,
>>>> I/O Control, which multiplexed core requests from devices
>>>> and interrupted the CPU at the end of a transfer
>>>> if the transfer had been initiated by a program
>>>> of higherCPU priority than the one currently running,
>>>> or if there was a possibility of priority inversion.
>>>>
>>>> I/O Control also autonomously re-issued an I/O command
>>>> to a device that reported a parity error
>>>> if that device was capable of retrying the transfer
>>>> (e.g. MT controllers could backspace a block and re-read).
>>>>
>>>
>>> That sounds quite advanced.
>>> But when I try to compare with contemporaries, like S/360 Model 65,
>>> it appears that despite advances KDF9 was not competitive to
>>> maximally configured 65 because of shortage of main memory.
>>
>> The contemporaneous Burroughs B3500 I/O subsystem
>> fully supported asynchronous DMA transfers with no
>> CPU intervention.
>
>
> snipped description
>
> Yes, that is an example of the kind of thing to which I was referring
> in my response to Mitch's post.  A question.  Was all of this pure
> hardware, or was it microcoded?

S.E.L created a thing they called the RCU (Remote Control Unit).
It was basically a channel with writable microcode. NASA bought
a bunch of them because they had tapes from the deep space radio
telescopes where an entire 9-track tape contained 1 record. NASA
just started the tape and recorded satellite data until the end
of the tape, where they would start the next tape just before the
end of the previous tape.

So we programmed the RCU to read as much as the system memory
allowed, backed the tap up 1 second while dumping the data to
disk. Then we started the tape forward with the RCU watching
the pattern on the tape, when it detected 4096 bytes of the
last read, it would start streaming data in to memory again.

No other company could demonstrate that they could read one
of those tapes.

Presto, reading a whole 9-track tape with no inter record gaps !!

{{I may have the name of the unit wrong}}