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=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,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 16fe9273 for ; Sat, 11 Jan 2020 00:31:21 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 55BC09B880; Sat, 11 Jan 2020 10:31:20 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 53E8293D85; Sat, 11 Jan 2020 10:30:49 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="nnWZNqAA"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id BB40293D85; Sat, 11 Jan 2020 10:30:45 +1000 (AEST) Received: from mail-vs1-f51.google.com (mail-vs1-f51.google.com [209.85.217.51]) by minnie.tuhs.org (Postfix) with ESMTPS id 2BF6D93D07 for ; Sat, 11 Jan 2020 10:30:45 +1000 (AEST) Received: by mail-vs1-f51.google.com with SMTP id x123so2429600vsc.2 for ; Fri, 10 Jan 2020 16:30:45 -0800 (PST) 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=cLr3X9hADJAb0pJaZoUApeAZGWCOvesz1NbjqH8Y2NM=; b=nnWZNqAAJSnxDpMF0PAqNt+Jg5h93FtXFHw5U24Z+o5kBbZSLdb4nMMrRdbEiurivR Ot/ZPPmTnSZ15EmRipGa647mjRaINGnRM11Cpx6hKSEJHFAv1R9fSorGxloi2SN8b2Tw n6M78S0ltN+kIap0qZKtTNGNnKb4eDY2qbdnYX37/J30d3bkBYqd364JUVjDZkqpwi1g UhGyMXf71r77WmIQ1G54Tx3j/NxWMlGGHogcSUlceKY+HwGC5bwMsi08b5o/lfOlQFFH DlfqxLkfcGFwFg+b7NdAM3HGDTvF0QSCjq+U/586p58MzDE0x4s7plWxk2g1oab2Wt4+ GMxw== 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=cLr3X9hADJAb0pJaZoUApeAZGWCOvesz1NbjqH8Y2NM=; b=ftybZAP0Y7yoq88nNiTcl/A+HAPTiTsqQdxPqcb9bjuRlSSM0W/scyzKjIhVThvKcm +VVlzEAgvq6LaWp1PyNyNbQl1OdfQUwl6zmCzi4VFwCgavyfgRYrvf7i9RCxXBIFznVI wTXvxmO7dsUn223enRCOdKLX1PGT3ORhHqQUKMhNNoVuHTIuuznSqSPuqDoHRAHJujFN 9SrWE7TN3Us+lphjHkeHuqpvzUG4oMY24QHp/OhS7YIgDGLYR5u74tYa8mMXDFL/F6eX whLYJy3N3cdQnUZd1LGalHiZluUxJYCENeysUazys3WEQD5nH43ayl3CiiBNCJpbOPuY /ylA== X-Gm-Message-State: APjAAAUrNQPJC/5SAoYdcYKSzpiwt6tLGl6Sw7K7/3hQCukNjSXze4O/ VHdmdF5Zd3TNLQM4Ei2/WxxoUi1WAGcI65t7fOg= X-Google-Smtp-Source: APXvYqy2yqOcFdMoUU5r5jlc90FJIEEW4gQpr+OpYvxTtEnBQdkzNyqHrThMYLcqrq0FAlRp5oGj+UCw5qTEifzBjEQ= X-Received: by 2002:a67:ee4e:: with SMTP id g14mr3307688vsp.223.1578702644238; Fri, 10 Jan 2020 16:30:44 -0800 (PST) MIME-Version: 1.0 References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <81cf0f73-2141-10c9-7352-51c0aac76959@mhorton.net> In-Reply-To: From: Christopher Browne Date: Fri, 10 Jan 2020 19:30:30 -0500 Message-ID: To: Adam Thornton Content-Type: multipart/alternative; boundary="00000000000050df65059bd25a1b" 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: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --00000000000050df65059bd25a1b Content-Type: text/plain; charset="UTF-8" On Fri, 10 Jan 2020 at 17:19, Adam Thornton wrote: > A) The original WD UART chip had very limited buffering. The timing was > such that as high rates it could not empty accept a second character > without the first being overwritten. This was a long-standing issue for > many UARTs long in the 1990s. The original chip NS built and IBM used on > the PC (the NS8250) was notorious for the same problem. By the time of > Motorola's 6881, it had 8 characters of buffering IIRC. > > Great, now I'm having flashbacks to upgrading my 4-port serial card with > 16450s and then 16550s in the early 90s. > Yep, same sorts of memories here. I recall the 16450 upgrade being a big deal for Internet connectivity in that a PC lacking the extra bytes of buffering in the UART would find that the 80386 was having clock cycles eaten nearly completely by PPP connections. It was amazing to realize how a few bytes of memory lurking in a crucial system interface could affect performance in such dramatic ways. Tagged command queueing on SCSI controllers had a slightly less dramatic effect on I/O performance, but again, a few hundred bytes of memory in the right spot could nevertheless have dramatic effects. --00000000000050df65059bd25a1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, 10 Jan 2020 at = 17:19, Adam Thornton <athornton@gmail.com> wrote:
A) The original WD UART chip = had very limited buffering.=C2=A0 =C2=A0The timing=20 was such that as high rates it could not empty accept a second character without the first being overwritten.=C2=A0 This was a long-standing issue= =20 for many UARTs long in the 1990s.=C2=A0 The original chip NS built and IBM= =20 used on the PC (the NS8250) was notorious for the same problem.=C2=A0 By th= e=20 time of Motorola's 6881, it had 8 characters of buffering IIRC.

Great, now I'm having flashbacks to upgrading my 4-po= rt serial card with 16450s and then 16550s in the early 90s.

Yep, same sorts of memories here.=C2=A0 I rec= all the 16450 upgrade being a big deal for Internet connectivity in that a = PC lacking the extra bytes of buffering in the UART would find that the 803= 86 was having clock cycles eaten nearly completely by PPP connections.=C2= =A0=C2=A0
It was amazing to realize how a few bytes = of memory lurking in a crucial system interface could affect performance in= such dramatic ways.=C2=A0=C2=A0
Tagged command queu= eing on SCSI controllers had a slightly less dramatic effect on I/O perform= ance, but again, a few hundred bytes of memory in the right spot could neve= rtheless have dramatic effects.
--00000000000050df65059bd25a1b--