From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id cd278069 for ; Fri, 10 Jan 2020 14:36:04 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 5FAFE9B881; Sat, 11 Jan 2020 00:36:03 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 77F2893D85; Sat, 11 Jan 2020 00:35:42 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id ADC2D93D85; Sat, 11 Jan 2020 00:35:40 +1000 (AEST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by minnie.tuhs.org (Postfix) with ESMTPS id 453FB93D07 for ; Sat, 11 Jan 2020 00:35:40 +1000 (AEST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 94B6218C09C; Fri, 10 Jan 2020 09:35:39 -0500 (EST) To: tuhs@minnie.tuhs.org Message-Id: <20200110143539.94B6218C09C@mercury.lcs.mit.edu> Date: Fri, 10 Jan 2020 09:35:39 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Subject: Re: [TUHS] screen editors / machine load 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: jnc@mercury.lcs.mit.edu Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" > From: Otto Moerbeek > I believe it was not only vi itself that was causing the load, it was > also running many terminals in raw mode that killed performance. I'm not familiar with the tty driver in late versions of Unix like 4.1 (sic), but I'm very familiar with the one in V6, and it's not the raw mode _itself_ that caused the load (the code paths in the kernel for cooked and raw aren't that different), but rather the need to wake up and run a process on every character that was the real load. When Bernie Greenberg did EMACS for Multics, he had a similar issue. I recall reading a document with an extensive discussion of how they dealt with this, especially when using the system over the ARPANET. IIRC, normal printing characters were echoed without waking up the process; remotely, when using the network. If anyone's really interested in this, and can't find it themselves, I can try looking for it. Noel