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=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 23782 invoked from network); 3 Jun 2020 16:32:38 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 3 Jun 2020 16:32:38 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id AD7B59CB09; Thu, 4 Jun 2020 02:32:30 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id E1C0C9C96B; Thu, 4 Jun 2020 02:32:02 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="ZUcerywf"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id A082B9C96B; Thu, 4 Jun 2020 02:31:59 +1000 (AEST) Received: from mail-vs1-f41.google.com (mail-vs1-f41.google.com [209.85.217.41]) by minnie.tuhs.org (Postfix) with ESMTPS id 06D659C1C8 for ; Thu, 4 Jun 2020 02:31:59 +1000 (AEST) Received: by mail-vs1-f41.google.com with SMTP id r11so1762872vsj.5 for ; Wed, 03 Jun 2020 09:31:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KxZtcihsaF6rS2AFfdLIucx3OAWdOY55r9iNRqMFyss=; b=ZUcerywfH1hJemPm/wfi3Btj/tnOn3Vy6rjEDZ94/6I0ODKAdOkIFOuOnSXEswOFHn j6WQmM9bxncwMi84LwedQg2B45mWY3ZAG43kKuh/MuTTS/fJcau2frN9HD1k593zjQrc eUVejoeJXgzHgB6JVQ3OQoEy6RjogiJf5FTxiYdo2wRlNdSebLc061TFJ3BoxPpgsWdw M2cA2kbO+a7ck4sipF+SfPd98eXTNRAOkvh0c+lLDIeYVhyN5rapd+sNUayNZKZDyD5q B99oztPJvws7+PbG1QDdwyyb7iAUwnI1j7AozK4xfHVt3VfyMdMeGh7Xeo4VkHgWIWhh ThQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KxZtcihsaF6rS2AFfdLIucx3OAWdOY55r9iNRqMFyss=; b=fyJkqJJHTKWqvD0JEtF6teiulUKnMfsIlJ14brj4D+QbFe6DJqDux9IF/AZoBUIduT nwr4jW8XfVbZkyPHcHiI1JVjNMF3IUF0pBUYUiblyQ+CJibCj4T7sm7XLPbM0y05/9MO H+xYbAy+3KE74nd9haaf+tok1CALdmnWFW9Y4iJHGdUgz4ackFDL3g2jNRMRhNHz1G3Q DthiXVymYMVmCCtg7yhdDWKSp8ak8AGHkZt96IoL1wyV7IB6S9MeoXDdsSFmoSd1rPyl r559pZynzaI2rNIZWgoEkdj2Qdd6LtU3m/GbZl33t5DcRjAqubLRNEN5d2MyIqNCiPi4 yIKw== X-Gm-Message-State: AOAM532ZQ85rmPISTUakLrraKyA7mSOCgkKAmIounaDTd28pKAn9tt/f 51rNzJUl3mBTCxpXNk6UqezC61tZaW9ueGYHDbM= X-Google-Smtp-Source: ABdhPJzsZrGn/2PyFChwesmKzSMqoo41qrOb+jc4uOgS1QDbPYlaymGajjZtDF0pR4lfvw3AHy4GVehG9sorj7NolUU= X-Received: by 2002:a67:2504:: with SMTP id l4mr198113vsl.228.1591201918011; Wed, 03 Jun 2020 09:31:58 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:2b92:0:0:0:0:0 with HTTP; Wed, 3 Jun 2020 09:31:57 -0700 (PDT) In-Reply-To: <0BF3AFA4-0B0E-45AA-A3AA-609704AF493F@cfcl.com> References: <20200602201334.95D9718C079@mercury.lcs.mit.edu> <0BF3AFA4-0B0E-45AA-A3AA-609704AF493F@cfcl.com> From: Paul Winalski Date: Wed, 3 Jun 2020 12:31:57 -0400 Message-ID: To: Rich Morin Content-Type: text/plain; charset="UTF-8" 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" 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.