From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 9582 invoked from network); 3 Jun 2020 19:20:28 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 3 Jun 2020 19:20:28 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 4A9779CA4F; Thu, 4 Jun 2020 05:20:24 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 11B8B9C96B; Thu, 4 Jun 2020 05:19:56 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="brkqzM2i"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 9C5B59C96B; Thu, 4 Jun 2020 05:19:54 +1000 (AEST) Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52]) by minnie.tuhs.org (Postfix) with ESMTPS id 1951B9C1C8 for ; Thu, 4 Jun 2020 05:19:54 +1000 (AEST) Received: by mail-vs1-f52.google.com with SMTP id o2so2095698vsr.0 for ; Wed, 03 Jun 2020 12:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=E7c/GN7mhw3MT1JAjHM7fWI+FkBPUMdgWszPHDec8Y8=; b=brkqzM2iSt2hFTFPPaHAo7zBi9XWHimhcUbNA7dW4NeSw4UPPcio3fiI1XLNmUYLrp myEvD1327DubBHy6/pqhpFUrRf+lq2zqiCILgld0YFAkIDBJjrSBtrqqv6J8MeiFsAfA T0HYPbrhJsp8+PvHU1EFBCMmC25ZnZzJLLGb1Y/5P2nGsdoYRGt7EfehnWEMlefEZt7D C4oLOe/VaCfgKChJKzGt9xx3M87+Z9TOHCvvlcZNlIZvDAgO/DK0wu3oXliQKCy/g+xg 2y564JjV6nzaR+tZD3QExC1CIMiUlkOOgO7tqgSbc6+5XDI53AQiU5sQZBLPg/P1G7Eq HNRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=E7c/GN7mhw3MT1JAjHM7fWI+FkBPUMdgWszPHDec8Y8=; b=QyIj4ewUkdkzRgvicZh4Y3WSu3ycvcaajR+mX19hpzIWLGMWvIj7k8yZvfwMrEf16H ukW/utGBEsuGnzSIjnVSCW0rl303r+IMajx30G5Pkq5vQDEVXGNTVbK1WcEEZYkCKwpn JR6ZsHhiULyYCzP3yvfWsY2hLooJ6MQur7ES+faIhvuwK0H/FUkl6jHc5yLbGYqUBmxc KvtYxftE4ejXz+NCsrsLDjboTaH8mWI3++W75eT/68hzAsvy9SAhpw7nS1Ocn6aSpZI6 itPPihtZwqAgcXfXt7j5H7PKlB5/ycfvOJuWlBNlcvsf0KShSqbeJ7WCDZLhUgJ8ewmj XQDQ== X-Gm-Message-State: AOAM533r8+6QAGnjWzYQb61mIwho/B0p6tKwxuvzN3dTPJGRU09usQly X2xRn7sWJUgITJXAoLcX6MyUQmoB1QSWQvsMWA8= X-Google-Smtp-Source: ABdhPJyMHWvhEX7pQ69L5pgFYZBbJ4mY9GCsNESBSfVrG3zSQyP26sLckjnP1Efe20VtcE5Nz5zyF8DcygawII9asKY= X-Received: by 2002:a67:b647:: with SMTP id e7mr821382vsm.63.1591211993117; Wed, 03 Jun 2020 12:19:53 -0700 (PDT) MIME-Version: 1.0 References: <20200602201334.95D9718C079@mercury.lcs.mit.edu> <0BF3AFA4-0B0E-45AA-A3AA-609704AF493F@cfcl.com> In-Reply-To: From: "John P. Linderman" Date: Wed, 3 Jun 2020 15:19:40 -0400 Message-ID: To: Paul Winalski Content-Type: multipart/alternative; boundary="0000000000009cb81505a732e91a" Subject: Re: [TUHS] non-blocking IO X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --0000000000009cb81505a732e91a Content-Type: text/plain; charset="UTF-8" On a distantly related note, when I worked part time for the MIT administration in the 60's, we'd do processing on the 7094 in the main comp center, then bring a tape of results back to our office to do the printing and card punching. For reasons that were never explained to me, the blocks of print and punch data were combined on a single tape, and were distinguished by being written with different parities. If you attempted to read a block with the correct parity setting, the tape could stream. If you guessed wrong, you had to stop, back up a block, change the parity, and try again. So I wrote a simple 360 assembly program to keep track how often blocks of each parity followed the observed parities of the previous 8 blocks. Essentially, 256 pairs of parity observations, indexed by the previous 8 parity observations. Blocks of print and punch data tended to fall into patterns that depended on what job was being run on the 7094, so detecting those patterns and correctly anticipating the upcoming parity made the tapes move much more smoothly. It was fun to watch the tape at the start of a run. It was mostly just a coin-toss, so the tape was jerking around fitfully. As the patterns started to emerge, the predictions got better, the jerking got less and less common, and the tapes were streaming most of the time. My introduction to learning algorithms. On Wed, Jun 3, 2020 at 12:33 PM Paul Winalski wrote: > On 6/2/20, Rich Morin wrote: > > > > IIRC, we had five tape drives; my challenge was to keep them all as busy > as > > possible, so as > > to dump the data set expeditiously. Because I had asynchronous I/O > (mostly > > in the form of > > BUFFER IN and BUFFER OUT commands), I was able to implement a simple but > > quite effective > > polling loop. The machine room was a bit of a madhouse, but the tapes > were > > written about > > as quickly as the hardware allowed. Asynchronous I/O FTW... > > With 9-track magnetic tape devices, reading and writing can't start > until the tape is up to speed. Once up to speed the drive can read > and write records while keeping the tape moving at speed. This is > called streaming. If there's a pause in the read/write requests from > the CPU, time is lost as the drive stops and starts moving the tape. > It was essential that applications doing large amounts of tape I/O > keep up the I/O requests at a rate that allows streaming. > Asynchronous I/O with multi-buffering is a straightforward way to > accomplish this. The IBM S/360 channel commands for tape devices > provided a mechanism for the tape control unit to send an interrupt to > the CPU when a read or write channel command completed. This notified > the sequential access method (the user program I/O interface) when I/O > to each buffer had completed and the buffer was available for reuse. > OS/360's Sequential Access Method could read or write an entire tape > using a single SIO (start I/O) instruction, as long as no read or > write errors were encountered. > > -Paul W. > --0000000000009cb81505a732e91a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On = a distantly related note, when I worked part time for the MIT administratio= n in the 60's, we'd do processing on the 7094 in the main comp cent= er, then bring a tape of results back to our office to do the printing and = card punching. For reasons that were never explained to me, the blocks of p= rint and punch data were combined on a single tape, and were distinguished = by being written with different parities. If you attempted to read a block = with the correct parity setting, the tape could stream. If you guessed wron= g, you had to stop, back up a block, change the parity, and try again. So I= wrote a simple 360 assembly program to keep track how often blocks of each= parity followed the observed parities of the previous 8 blocks. Essentiall= y, 256 pairs of parity observations, indexed by the previous 8 parity obser= vations. Blocks of print and punch data tended to fall into patterns that d= epended on what job was being run on the 7094, so detecting those patterns = and correctly anticipating the upcoming parity made the tapes move much mor= e smoothly. It was fun to watch the tape at the start of a run. It was most= ly just a coin-toss, so the tape was jerking around fitfully. As the patter= ns started to emerge, the predictions got better, the jerking got less and = less common, and the tapes were streaming most of the time. My introduction= to learning algorithms.

On Wed, Jun 3, 2020 at 12:33 PM Paul Winalski= <paul.winalski@gmail.com= > wrote:
On 6= /2/20, Rich Morin <rdm= @cfcl.com> wrote:
>
> IIRC, we had five tape drives; my challenge was to keep them all as bu= sy as
> possible, so as
> to dump the data set expeditiously.=C2=A0 Because I had asynchronous I= /O (mostly
> in the form of
> BUFFER IN and BUFFER OUT commands), I was able to implement a simple b= ut
> quite effective
> polling loop.=C2=A0 The machine room was a bit of a madhouse, but the = tapes were
> written about
> as quickly as the hardware allowed.=C2=A0 Asynchronous I/O FTW...

With 9-track magnetic tape devices, reading and writing can't start
until the tape is up to speed.=C2=A0 Once up to speed the drive can read and write records while keeping the tape moving at speed.=C2=A0 This is
called streaming.=C2=A0 If there's a pause in the read/write requests f= rom
the CPU, time is lost as the drive stops and starts moving the tape.
It was essential that applications doing large amounts of tape I/O
keep up the I/O requests at a rate that allows streaming.
Asynchronous I/O with multi-buffering is a straightforward way to
accomplish this.=C2=A0 The IBM S/360 channel commands for tape devices
provided a mechanism for the tape control unit to send an interrupt to
the CPU when a read or write channel command completed.=C2=A0 This notified=
the sequential access method (the user program I/O interface) when I/O
to each buffer had completed and the buffer was available for reuse.
OS/360's Sequential Access Method could read or write an entire tape using a single SIO (start I/O) instruction, as long as no read or
write errors were encountered.

-Paul W.
--0000000000009cb81505a732e91a--