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,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4458 invoked from network); 9 Mar 2023 19:56:37 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 9 Mar 2023 19:56:37 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 9674741315; Fri, 10 Mar 2023 05:56:34 +1000 (AEST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) by minnie.tuhs.org (Postfix) with ESMTPS id AA3F041309 for ; Fri, 10 Mar 2023 05:56:23 +1000 (AEST) Received: by mail-lj1-x22a.google.com with SMTP id z42so3019251ljq.13 for ; Thu, 09 Mar 2023 11:56:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678391781; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=5qqnSWjV7BTNoMWVvEtvBMnPMgOdJ2mHS4eb+wA+8Ls=; b=dgRfiF3Ib5UEODO/3ce4HZYc6Gj1uYDq42qMbe1hwHs+lTRYSykC0tq+YAlcT1FujB EdNtC6AwxIvaLL+ZU9Q6kXKfjr5UDhgMDSD6DO0dciw9mFe0Un4D+sziQSZX8rszll0r W1Grjc/MyTE65dO9kcg8MzmY1au4U1aRtK9Y7Wc7Hm6F/QFk0SzKwZWUOSYoF1s8iBQX 4nTk0D97pzKn6hfpYUDaP8aXclkjNR6gkhY5vTidVfdDCqzDXtHTT/x1CZKRRoqaFlJr e5AIqvfFXN2wi8R/t11j9yJFuYfPmlv6TtLnCNzSA9CJevTYKFcR4O+o7vtEDWvktmkO /rjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678391781; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5qqnSWjV7BTNoMWVvEtvBMnPMgOdJ2mHS4eb+wA+8Ls=; b=h/AC+bHf38zfNhydspqI3wKKx6VKqEcQ2vKlhAyXO+tTk4u/LmVxvCjbhA5mLOpd7Z RdtUk4/Rcom+Eccc4cYEnBokTz4oQmw+TB626ur6jfinCBcp24HNEhIcvLWRpxs/j8XK jIACwmzgPIrxon1GO9qDbqJJmUpe9mzQ1YHemRqvTj/80phW8DM3vvF6YmzvnTTFKwIr u0gIqi2T2FDsDYzJYIk2uQS6PTsPIpmcjr3yekkkw6JhOimHzhEu81cyR8x8vHgGN/Ct SR30G8SQyh0D8zZEiiJ1zelISoETqXoTlEqwJe7jrHWSdxS78oVh0t/MJlLDVR2O2TYj QBxw== X-Gm-Message-State: AO0yUKV0w3YOTQj+HvyOHGwUxVRPT7A3Od8ynw1JBhFtyCINoFKG+usB 4jp21mDm8phpYSR1VAe2zr5Wxap1t5gd0wW63NIxufW+2QA= X-Google-Smtp-Source: AK7set/MdEHXuhpp93QnGoBbjr02im6DAlJP/9CbkKol9F/m3pAFmPy82dn7nZt3p3CO7Lq5ok83WMlY4VmN3ctcxSI= X-Received: by 2002:a05:651c:10a3:b0:293:4ffa:a68c with SMTP id k3-20020a05651c10a300b002934ffaa68cmr7207740ljn.8.1678391781248; Thu, 09 Mar 2023 11:56:21 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dan Cross Date: Thu, 9 Mar 2023 14:55:44 -0500 Message-ID: To: John Cowan Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: Z3BRB4WI53XZ2WWSWXBDLRIZW6BCV5I4 X-Message-ID-Hash: Z3BRB4WI53XZ2WWSWXBDLRIZW6BCV5I4 X-MailFrom: crossd@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: ron minnich , COFF X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [COFF] Re: [TUHS] Re: the wheel of reincarnation goes sideways List-Id: Computer Old Farts Forum Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Wed, Mar 8, 2023 at 8:22=E2=80=AFPM John Cowan wrote: > On Wed, Mar 8, 2023 at 2:53=E2=80=AFPM Dan Cross wrote= : >> But the >> 3090 was really more like a distributed system than the Athlon box >> was, with all sorts of offload capabilities. For that matter, a >> thousand users probably _could_ telnet into the Athlon system. With >> telnet in line mode, it'd probably even be decently responsive. > > I find that difficult to believe. It seems too high by an order of magni= tude. I'm not going to claim it would be zippy, but I do think it would work acceptably. Suppose that 1000 users telnet'ed into the x86 machine, but remained essentially idle; what resources would that consume? We'd have 1000 open TCP connections, a thousand shell processes, a thousand telnetd's, etc. All of that would consume some amount of RAM (though there'd be a lot of sharing of text and read-only data and so on), some VM space requiring RAM for paging structures and so on, some accounting data in the kernel, 1000 pseudo-ttys allocated, entries in the process table, etc. But, most of those shells would spend most of their time blocked waiting on input, so wouldn't consume CPU continuously, and similarly with the TCP connections mostly idle, the kernel is not generally wasting a lot of processor time on the login sessions. There'd be some bookkeeping data on disk, but that would be small. System overhead would amount to maybe a few megabytes, I'd imagine. If all of those users ran telnet in line mode, then the system isn't getting pounded with interrupts all the time, even if they're executing commands (the per-character overhead would be absorbed by the client). I don't think I have a machine of quite the Athlon vintage, but I _do_ have a machine with a Ryzen processor that's a couple of years old down in my basement. As an experiment, I wrote a little "expect" script to login to that machine a thousand times, doing so recursively: that is, the script starts off ssh'ing into the machine, and then in that session, logs in again, and so on, a thousand times, before finally going interactive. I used encryption, public-key authentication, and compression, and bounced through a "jump host" for each session, ensuring that I'm using the network for each login. The effect here is that typing into the final shell sort of simulates 1000 users typing simultaneously, complete with all the glorious interrupt and scheduler overhead that implies. Response time in that connection is not bad; certainly on par with the 3090 I used for a while in the early 90s. If I login in another window, it doesn't even register that there are a thousand "users" logged in, even if I'm running something chatty in the "thousand users" window. By contrast, the mainframe required a tremendous amount of offload support to shield the CPU from all of that bursty user activity. They made user actions look like block transfers, thus amortizing (much) of the overhead of interactivity. With the same load, the mainframe is storing some state data in memory regarding which users are logged in or connected or dialed or whatever, but the situation isn't that much different than mostly-idle telnet connections in line-mode: save that it's even more favorable to the mainframe in that much of the interaction is per-screen of data, as opposed to per-line. The difference in interactivity and offload is why I think the comparison is poor. If the mainframe handled user sessions the same way the x86 machine handled telnet logins, I imagine it would be swamped way worse than the AMD machine (or whatever it was that person was writing about 10 or 15 years ago). Perhaps a better comparison would be to a web server that was accepting HTTP requests from 1000 different clients. I'm quite sure that x86 machines of the Athlon era could cope with that load. > Another thing that doesn't get mentioned much is that classic mainframes = had SRAM, so their memory bandwidth was enormous. I suspect this has less of a difference than one would hope when comparing against a modern machine. The specific comparison in this case was against an IBM 3090-600J. It appears to use SRAM for cache ("high speed buffer" in IBM-speak), but seems to use DRAM for central and expanded storage. In this reference I found on bitsavers, they make a big deal about their "one million bit memory chip", but that's DRAM (http://www.bitsavers.org/pdf/ibm/3090/G580-1005-0_The_IBM_3090_Processor_F= amily_Jul87.pdf; see "IBM Advances the Technology" on page 10). Moreover, that machine supported up to 6 CPUs running at a clock rate of 69 MHz. That same reference says they could bring cycle times down to 17.2ns using ECL chips; DDR2 can match that. My Mac Studio blows it out of the water. For systems older than the 3090, I'm not sure that the SRAM difference matters much at all: those machines had tiny memories compared to even modern cell phones, and their CPUs and buses were pitifully slow. Even if they had more RAM bandwidth than machines now (which I do not think is really true), they couldn't use it. Indeed, I suspect their total memory sizes were smaller than L3 cache (which is SRAM) on modern machines. - Dan C.