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_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 26036 invoked from network); 1 Dec 2022 06:11:51 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 1 Dec 2022 06:11:51 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id D358D41C53; Thu, 1 Dec 2022 16:11:43 +1000 (AEST) Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) by minnie.tuhs.org (Postfix) with ESMTPS id 5AD1441C1B for ; Thu, 1 Dec 2022 16:11:28 +1000 (AEST) Received: by mail-pl1-f172.google.com with SMTP id y17so693727plp.3 for ; Wed, 30 Nov 2022 22:11:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kev009.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=qbmh6Eo/DtU7PvShvgZV6dATBWWrtVkMuEjNETwp/T0=; b=qXIzfHU6WgAcOg5CFQogtKFmVQ2eiKxdQmu8VvLiubsbp/FfRl6BdRM+1Xu1TJribx n5/y1jBs0r8PSIFsGKedqy/dVHTmlQdJm6QP/QQqIirJNZQON8t/GbJEwl7nbHcPRclZ 3PZAOka0buLrj+EwhSgoes2Gzv+EGqX4Bh0Vg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=qbmh6Eo/DtU7PvShvgZV6dATBWWrtVkMuEjNETwp/T0=; b=ZrwcszfjsP8tQL5x45FuWM/YbtIR+LcpcnmvuFC/EaKGg2VARRYfuKG54polt23KaA ZEFl6w92woeguchCoJTdkyrb6BCEIALl7UVKMUCh81S/+0Laz6/Mx690s6cFGWXIze5T wL9/MWRICdZeio0eLIDzkflR/Rv4HVt/NNXs9HwAWZwfJIl3PymrM/AKo1AoTV52b0fF VayJevS8tRMKUFpkgfTaAteoya/QdmmkvV5ejYHepGZNOuAoFqbvBkVxVuGhPne07ORR KFCqeY8JUHWx/KJF0cdr4wIj3Czb4vsYFSeHuxpkAJoKxqDSNSaAE82sTpHoSN/8ZxUj VsRQ== X-Gm-Message-State: ANoB5pksaPuICak0Xwqa8EfB025hmin/97yYrjm53mRZUkQDLP9ajol1 W0LBN6ZHpyhgO164XdfszZ69P/AHItg3fmyn7ZzZz/42U5LcTA== X-Google-Smtp-Source: AA0mqf5MDhQJYrAgVCtbvSIVXSFYXwSIjmeoqKIiDSAodX4BpoqhLGRoys1WGLLE5mW8BORs4sx25Xb5Vwu0EMix894= X-Received: by 2002:a17:90a:d38a:b0:218:a7e6:60df with SMTP id q10-20020a17090ad38a00b00218a7e660dfmr55158472pju.38.1669875026892; Wed, 30 Nov 2022 22:10:26 -0800 (PST) MIME-Version: 1.0 References: <8f278bf8-de57-4e77-a3b8-d007d7c3a446@app.fastmail.com> <20221126191827.GV18011@mcvoy.com> <764dda08-f358-4c74-8056-ef8fc80bcaac@app.fastmail.com> <20221126232323.GX18011@mcvoy.com> <20221127001714.GY18011@mcvoy.com> <202211270443.2AR4hofO067295@ultimate.com> <0EB50C1F-D226-40BF-8F42-43CB988B036E@jctaylor.com> In-Reply-To: From: Kevin Bowling Date: Wed, 30 Nov 2022 23:10:15 -0700 Message-ID: To: Alan Glasser Content-Type: multipart/alternative; boundary="000000000000cc2e0005eebe136a" Message-ID-Hash: RJNUZKNYR24NGSCPQFK3K3FL2CZJ4N7M X-Message-ID-Hash: RJNUZKNYR24NGSCPQFK3K3FL2CZJ4N7M X-MailFrom: kevin.bowling@kev009.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Marc Donner , The Eunuchs Hysterical Society X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Reaction to the 3B2 at Bell Labs List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000cc2e0005eebe136a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 28, 2022 at 6:51 PM Alan Glasser wrote: > A few 3B2 stories... > > In the late 1970's there were no 3B2's (yet), but there was the MAC 8 > processor. The name "MAC 8" was problematic to me and my coworkers: it > stood for Microprocessor Advisory Committee. It was a processor designed > by a committee! It was slow and more problematically, it was not hardwar= e > compatible with Intel 8080 support chips. I don't remember all of the > details but it was an edge versus level set of problems. It was fun to > program. There was an evaluation box (called a MacTutor) that you > connected to an RS-232 line to connect it with a PDP-11 UNIX system for > cross-assembly/cross-compiling (the assembler language was as close to C = as > an assembler language could get). The MacTutor was a fun toy. The MAC 8 > in production hardware (at least in Holmdel) was a disaster. See > https://archive.org/details/bitsavers_westernEleC8TUTORJul79_3968770/mode= /2up > > In the early 1980's, I was a Bell Labs technical supervisor in a number o= f > different development (in contrast to research) organizations. There was > considerable pressure on my management (and me) to utilize 3B2's instead = of > DEC hardware; a little later (about 1986) there was pressure to use 6300'= s > and later 6386's (which ran UNIX). > > My first experience with an original 3B2 (one without a model number) was > identical to that of John P Linderman's. Compiling a modest C program to= ok > forever. A little later they gave that one a model number of 300 and cam= e > out with a 400, which was almost reasonable and a 310 which, I believe, h= ad > the same processor and clock as a 400 with less expansion slots. Later ca= me > the 600 and 700, which were pretty reasonable and we used them for a numb= er > of products (DEFINITY Manager 3 for administering a large PBX was one I > brought to market with my team). > There=E2=80=99s a 600G model that was used in large quantities by the US Go= vernment (DoD). The later models (600 to 1000) support multiple processors. I find these later machines fairly interesting but can see how the market would have been set for Sun and DEC. And then there were a couple 11xx models with MIPS CPUs.. > In October, 1996 I was promoted to development department head of Global > Messaging Services (GMS) which was better known as AT&T Mail. It was a > hectic time to be joining the organization as the job I took had been bei= ng > filled temporarily by another person (who was a friend of mine and, like > me, was new to the organization) and they were in the final throes of > development of a significant new release, about to go into system test (i= n > another department). One of the first things I learned is that the servi= ce > ran on many 3b2/600's mostly in two locations in the US, but had many sma= ll > worldwide locations (Hong Kong, Tokyo, Sydney, Tel Aviv, London, Moscow, > and some others I don't remember) all connected by DataKit. The US syste= ms > had been running for many years and could not be powered off, because the > disk drives would seize and not spin up due to an absence of lubricant (a= s > I was told). This presented some challenges, as I liked to power cycle > systems I worked on and could not do this here. The release was deployed > on Valentine's Day, 1997. It was the worst deployment in the service's > history. Most everything broke. System test hadn't found these very man= y > latent bugs that were deployed. It was all hands on deck, working all > hours 7x24 with two conference calls a day with the Operations organizati= on > (running the servers) and the Customer Care organization (fielding custom= er > complaints) until things quieted down towards the end of March. > > It was then that I was able to pay more attention to future plans, which > were to replace the 3B2's with Stratus hardware running their fault > tolerant unix (FTX). We had a number of their dual processor systems in > lab test and had just taken delivery of a four processor system, which is > what my predecessor had specified for purchase to replace all of the US > based 3B2's. A group of 3 engineers (one of whom I had hired in 1980) > worked on running benchmarks of GMS workloads on the Stratus systems and > working with Stratus engineers to get fixes to problems in their code whe= n > they arose. They presented the first set of quad processor benchmarks to > me and they were all slower than the "twin" (or 2 processor) benchmarks. = I > requested daily updates on the status of this as it was bizarre and indee= d > a disaster for our plans. This culminated in my requesting that Stratus > send a small group of their FTX engineers to my location for (what I > called) a formal architecture review of the Quad and FTX. The review was > scheduled for a week. After the first morning, I told them that they > should go back to Stratus and that we'd be in touch. I wrote the followi= ng > in an email to my boss, my product manager peer and a handful of others: > > > Yesterday, 4/15/97, Stratus engineers from their hardware development, FT= X > (UNIX) development and performance and design groups met with members of > GMS R&D and AT&T Labs to share information about the Stratus and GMS > architectures. > > > Executive summary: the Quad will never work for GMS. > > > The Stratus 1225 (aka "Twin"), is a true SMP (symmetric multi-processor). > The two CPUs each have a one megabyte instruction cache and a one megabyt= e > data cache, and they both share a memory system of 512 megabytes. Cache > coherency is maintained by a pair of custom chips (ASICs). When data is i= n > a processor's cache, there is no contention possible. When data is in > the memory system, there is an additional penalty of between 250-390 > nanoseconds. Input and output take place on a slower bus. > > > The Stratus 1245 (aka "Quad") consists of two twin boards that communicat= e > via the I/O (i.e., slow) bus. This is not symmetric, hence not SMP. Each > board contains 512MB of memory. All of the Unix kernel data resides on > one board (the boot board). When a processor on the non-boot board needs > to access memory on the boot board, the cost is 1700 nanoseconds (a penal= ty > of 4.4 to 6.8 times worse). > > > Since all Unix kernel data resides on the boot board, any software that > makes significant use of Unix system calls (e.g., GMS) will pay a high > penalty when running on the non-boot board. Further, if a program (e.g., > the GMS User Agent) is simultaneously running on both boards, its > instructions will reside in the memory of only one of the boards, thus > incurring significant overhead to access instructions for some processes. > > > It appears that the hardware designers never consulted with the Unix > designers. They are located in different locations (Massachusetts and > California), which can't help. They claim they've seen between 1.4 and > 1.6 times improvement in going from Twin to Quad for other customers. The= y > do note, however, that an optimal application for the Quad is > > one which needs to execute application user-mode instructions and make > very few system calls (e.g., a graphics rendering application). GMS, in > its current architecture, assumes free and easy access to system calls. = GMS > can never run well on a Quad. > > > We should immediately abandon any efforts aimed at deploying Quads and > focus all of our attention on extracting compensatory Twins from Stratus. > > > Needless to say, we were able to get an appropriate number of Twins and > retired all of our 3B2s. > > Alan > > > > > > On Mon, Nov 28, 2022 at 5:45 PM Marc Donner wrote= : > >> IBM built a major semiconductor fab up in Fishkill, NY. About two hours >> drive north of NYC. At one point (mid-1980s) it was the biggest fab in = the >> world according to some metric. >> >> On Mon, Nov 28, 2022, 17:35 ron minnich wrote: >> >>> I was visiting Holmdel in 1981, and there was a tradeshow for the >>> BellMAC CPUs there, filling ground floor of the central atrium. There w= as >>> some swag, which I had for a few years, including refrigerator magnets.= The >>> one I remember: >>> "Don't be alone, call MACphone!" >>> >>> I remember reading an article in the early 80s pointing out that, due t= o >>> the scale of the Bell System, the center of the universe of semiconduct= or >>> fabrication at that time was ... Allentown, PA. Western Electric had an= ad, >>> along the lines of, "who will create the 256 Kb memory part? WE will" -= - WE >>> as in Western Electric.Those parts would have been fabbed in Allentown >>> IIRC. >>> >>> It is a bit hard to recall, much less believe. but PA, land of dead >>> still mills, the Molly Maguires, and underground coal mine fires that w= ill >>> burn for centuries, also had silicon. >>> >>> >>> >>> >>> On Mon, Nov 28, 2022 at 1:01 PM Kenneth Goodwin < >>> kennethgoodwin56@gmail.com> wrote: >>> >>>> That must be the 300 B superhive model CPU >>>> >>>> On Mon, Nov 28, 2022, 1:54 PM William Corcoran >>>> wrote: >>>> >>>>> I have a 3b2/300. Anytime you run a command that is compute bound, >>>>> like factoring a large prime number, the CPU buzzes! >>>>> >>>>> >>>>> >>>>> Bill Corcoran >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Nov 27, 2022, at 9:52 AM, John P. Linderman >>>>> wrote: >>>>> >>>>> =EF=BB=BF >>>>> >>>>> [EXTERNAL] >>>>> >>>>> >>>>> We were "gifted" a 3B2, as in "take this and use it!". I ran a "ps" >>>>> command in single user mode, and it took 20 seconds to run. >>>>> Our machine names were themed around bird names, so we christened the >>>>> 3B2 "junco". Our director said we had to get along, >>>>> so we renamed it "jay". But everyone knew what the J stood for. The >>>>> 3B2 served as a doorstop. >>>>> >>>>> On Sat, Nov 26, 2022 at 11:44 PM Phil Budne wrote= : >>>>> >>>>>> Larry McVoy wrote: >>>>>> > I read the Wikipedia page on the 9000. It's sad that the 9000 >>>>>> > wasn't cancelled when they had better alternatives. >>>>>> >>>>>> In an oral history Bob Supnik described Ken Olsen couldn't get his >>>>>> head around the fact that the NVAX chip could equal the 9000: >>>>>> >>>>>> @2:59:45 in https://www.youtube.com/watch?v=3DT3tcCBHRIfU >>>>>> >>>>>> In part 2, Bob described how then DEC VP Gordon Bell having earlier >>>>>> predicted when the microprocessor performance curve would cross over >>>>>> minis and mainframes: >>>>>> >>>>>> @1:51:45 in https://www.youtube.com/watch?v=3DT3tcCBHRIfU >>>>>> >>>>>> He also talks about how the company couldn't command the bsame gross >>>>>> margins as it did in the VAX era. >>>>>> >>>>> >>>>> >>>>> THIS IS AN EXTERNAL EMAIL -- This email was sent from someone OUTSIDE >>>>> of the NSM Insurance Group email system. PLEASE USE CAUTION WHEN REVI= EWING >>>>> THIS EMAIL. >>>>> >>>>> --000000000000cc2e0005eebe136a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Nov 28, 2022 at 6:51 PM Alan Glasser <alanglasser@gmail.com> wrote:
A few 3B2 stories...

In the late 1970's =C2=A0there were no 3B2's (yet), but there was = the MAC 8 processor.=C2=A0 The name "MAC 8" was problematic to me= and my coworkers: it stood for Microprocessor Advisory Committee.=C2=A0 It= was a processor designed by a committee!=C2=A0 It was=C2=A0slow and more p= roblematically, it was not hardware compatible with Intel 8080 support chip= s.=C2=A0 I don't remember all of the details but it was an edge versus = level set of problems.=C2=A0 It was fun to program.=C2=A0 There was an eval= uation box (called a MacTutor) that you connected to an RS-232 line to conn= ect it with a PDP-11 UNIX system for cross-assembly/cross-compiling (the as= sembler language was as close to C as an assembler language could get).=C2= =A0 The MacTutor was a fun toy.=C2=A0 The MAC 8 in production hardware (at = least in Holmdel) was a disaster.=C2=A0 See=C2=A0https://archive.org/details/bitsavers_westernEleC8TUTORJul79_3968770= /mode/2up

In the early 1980's, I was a= Bell Labs technical supervisor in a number of different development (in co= ntrast to research) organizations. There was considerable pressure on my ma= nagement (and me) to utilize 3B2's instead of DEC hardware; a little la= ter (about 1986) there was pressure to use 6300's and later 6386's = (which ran UNIX).

My first experience with an orig= inal 3B2 (one without a model number) was identical to that of John P Linde= rman's.=C2=A0 Compiling a modest C program took forever.=C2=A0 A little= later they gave that one a model number of 300 and came out with a 400, wh= ich was almost reasonable and a 310 which, I believe, had the same processo= r and clock as a 400 with less expansion slots. Later came the 600 and 700,= which were pretty reasonable and we used them for a number of products (DE= FINITY Manager 3 for administering a large PBX was one I brought=C2=A0to ma= rket with my team).

There=E2=80=99s a 600G model that was used in large quantiti= es by the US Government (DoD).

The later models (600 to 1000) support multiple processors.=C2=A0 I = find these later machines fairly interesting but can see how the market wou= ld have been set for Sun and DEC.

And then there were a couple 11xx models with MIPS CPUs..


In October, 1996 I was promoted to development= department head of Global Messaging Services (GMS) which was better known = as AT&T Mail.=C2=A0 It was a hectic time to be joining the organization= as the job I took had been being filled temporarily by another person (who= was a friend of mine and, like me, was new to the organization) and they w= ere in the final throes of development of a significant new release, about = to go into system test (in another department).=C2=A0 One of the first thin= gs I learned is that the service ran on many 3b2/600's mostly in two lo= cations in the US, but had many small worldwide locations (Hong Kong, Tokyo= , Sydney, Tel Aviv, London, Moscow, and some others I don't remember) a= ll connected by DataKit.=C2=A0 The US systems had been running for many yea= rs and could not be powered off, because the disk drives would seize=C2=A0a= nd not spin up due to an absence of lubricant (as I was told).=C2=A0 This p= resented some challenges, as I liked to power cycle systems I worked on and= could not do this here.=C2=A0 The release was deployed on Valentine's = Day, 1997.=C2=A0 It was the worst deployment in the service's history.= =C2=A0 Most everything broke.=C2=A0 System test hadn't found these very= many latent bugs that were deployed.=C2=A0 It was all hands on deck, worki= ng all hours 7x24 with two conference calls a day with the Operations organ= ization (running the servers) and the Customer Care organization (fielding = customer complaints) until things quieted down towards the end of March.

It was then that I was able to pay more attention to= future plans, which were to replace the 3B2's with Stratus hardware ru= nning their fault tolerant unix (FTX).=C2=A0 We had a number of their dual = processor systems in lab test and had just taken delivery of a four process= or system, which is what my predecessor had specified for purchase to repla= ce all of the US based 3B2's.=C2=A0 A group of 3 engineers (one of whom= I had hired in 1980) worked on running benchmarks of GMS workloads on the = Stratus systems and working with Stratus engineers to get fixes to problems= in their code when they arose.=C2=A0 They presented the first set of quad = processor benchmarks to me and they were all slower than the "twin&quo= t; (or 2 processor) benchmarks.=C2=A0 I requested daily updates on the stat= us of this as it was bizarre and indeed a disaster for our plans.=C2=A0 Thi= s culminated in my requesting that Stratus send a small group of their FTX = engineers to my location for (what I called) a formal architecture review o= f the Quad and FTX.=C2=A0 The review was scheduled for a week.=C2=A0 After = the first morning, I told them that they should go back to Stratus and that= we'd be in touch.=C2=A0 I wrote the following in an email to my boss, = my product manager peer and a handful of others:

Yesterday, 4/15/97, Stratus engineers= from their hardware development, FTX (UNIX) development and performance an= d design groups met with members of GMS R&D and AT&T Labs to share = information about the Stratus and GMS architectures.


Executive summary: the Quad will ne= ver work for GMS.


The Stratus 1225 (aka "Twin"), is a true SMP (symmetric mult= i-processor).=C2=A0 = The two CPUs each have a one megabyte instruction cache and a one me= gabyte data cache, and they both share a memory system of 512 megabytes.=C2=A0 Cache coh= erency is maintained by a pair of custom chips (ASICs). When data is in a p= rocessor's cache, there is no contention possible.=C2=A0 When data is in the memory = system, there is an additional penalty of between 250-390 nanoseconds. Inpu= t and output take place on a slower bus.


The Stratus 1245 (aka "Quad") consist= s of two twin boards that communicate via the I/O (i.e., slow) bus. This is= not symmetric, hence not SMP.=C2=A0 Each board contains 512MB of memory.=C2=A0 All of the Unix kerne= l data resides on one board (the boot board).=C2=A0 When a processor on the non-boot boa= rd needs to access memory on the boot board, the cost is 1700 nanoseconds (= a penalty of 4.4 to 6.8 times worse).


Since all Unix kernel data resides on the boot boa= rd, any software that makes significant use of Unix system calls (e.g., GMS= ) will pay a high penalty when running on the non-boot board. Further, if a= program (e.g., the GMS User Agent) is simultaneously running on both board= s, its instructions will reside in the memory of only one of the boards, th= us incurring significant overhead to access instructions for some processes= .


It appears = that the hardware designers never consulted with the Unix designers. They a= re located in different locations (Massachusetts and California), which can= 't help.=C2=A0 <= /span>They claim they've seen between 1.4 and 1.6 times improvement in = going from Twin to Quad for other customers. They do note, however, that an= optimal application for the Quad is=C2=A0

one which needs to execute application user-mode instructions = and make very few system calls (e.g., a graphics rendering application).=C2=A0 GMS, in i= ts current architecture, assumes free and easy access to system calls.=C2=A0 GMS can nev= er run well on a Quad.


We should immediately abandon any efforts aimed at deploying Quad= s and focus all of our attention on extracting compensatory Twins from Stra= tus.

=

Needless to say, we were able to get an appropriate number of Twins and ret= ired all of our 3B2s.

Alan<= /div>





=
On Mon, No= v 28, 2022 at 5:45 PM Marc Donner <marc.donner@gmail.com> wrote:
IBM built a major semiconductor fab up in Fishk= ill, NY.=C2=A0 About two hours drive north of NYC.=C2=A0 At one point (mid-= 1980s) it was the biggest fab in the world according to some metric.
<= br>
On Mon,= Nov 28, 2022, 17:35 ron minnich <rminnich@gmail.com> wrote:
I was visiting Holmdel in 1981, and there was a tradesh= ow for the BellMAC CPUs there, filling ground floor of the=C2=A0central atr= ium. There was some swag, which I had for a few years, including refrigerat= or magnets. The one I remember:
"Don't be alone, call MACphone= !"

I remember reading an article in the early= 80s pointing out that, due to the scale of the Bell System, the center of = the universe=C2=A0of semiconductor fabrication at that time was ... Allento= wn, PA. Western Electric had an ad, along the lines of, "who will crea= te the 256 Kb memory=C2=A0part? WE will" -- WE as in Western Electric.= Those parts would have been fabbed in Allentown IIRC.=C2=A0

<= /div>
=C2=A0It is a bit hard to recall, much less believe. but PA, land= of dead still mills, the Molly Maguires, and underground coal mine fires t= hat will burn for centuries, also had silicon.



On Mon, Nov 28, 2022 at 1:01 PM Kenneth Goodwin <<= a href=3D"mailto:kennethgoodwin56@gmail.com" rel=3D"noreferrer" target=3D"_= blank">kennethgoodwin56@gmail.com> wrote:
=
That must be the 300 B superhive model CPU

On Mon, Nov 28,= 2022, 1:54 PM William Corcoran <wlc@jctaylor.com> wrote:
=
I have a 3b2/300.=C2=A0 Anytime you run a command that is compute bound, li= ke factoring a large prime number, the CPU buzzes!



Bill Corcoran


=C2= =A0
=C2=A0
=C2=A0
On Nov 27, 20= 22, at 9:52 AM, John P. Linderman <jpl.jpl@gmail.com> w= rote:

=EF=BB=BF

= [EXTERNAL]<= /p>


We were "gifted= " a 3B2, as in "take this and use it!". I ran a "ps&quo= t; command in single user mode, and it took 20 seconds to run.
Our machine names we= re themed around bird names, so we christened the 3B2 "junco". Ou= r director said we had to get along,
so we renamed it &qu= ot;jay". But everyone knew what the J stood for. The 3B2 served as a d= oorstop.

On Sat, Nov 26, 2022 at 11:44 PM Phil= Budne <phil@ultimate.com> wrote:
Larry McVoy wrote:
> I read the Wikipedia page on the 9000.=C2=A0 It's sad that the 900= 0
> wasn't cancelled when they had better alternatives.

In an oral history Bob Supnik described Ken Olsen couldn't get his
head around the fact that the NVAX chip could equal the 9000:

@2:59:45 in https://www.youtube.com/watch?v=3DT3tcCBHRIfU

In part 2, Bob described how then DEC VP Gordon Bell having earlier
predicted when the microprocessor performance curve would cross over
minis and mainframes:

@1:51:45 in https://www.youtube.com/watch?v=3DT3tcCBHRIfU

He also talks about how the company couldn't command the bsame gross margins as it did in the VAX era.


THIS IS AN EXTERNAL EMAIL -- This email was sent from someone OUTSIDE of th= e NSM Insurance Group email system. PLEASE USE CAUTION WHEN REVIEWING THIS = EMAIL.
--000000000000cc2e0005eebe136a--