[TUHS] Reaction to the 3B2 at Bell Labs

Tue Nov 29 11:49:23 AEST 2022

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 hardware
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 of
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 took
forever.  A little later they gave that one a model number of 300 and came
out with a 400, which was almost reasonable and a 310 which, I believe, had
the same processor 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 (DEFINITY Manager 3 for administering a large PBX was one I
brought to market with my team).

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 being
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 (in
another department).  One of the first things I learned is that the service
ran on many 3b2/600's mostly in two locations in the US, but had many small
worldwide locations (Hong Kong, Tokyo, Sydney, Tel Aviv, London, Moscow,
and some others I don't remember) all connected by DataKit.  The US systems
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 (as
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 many
latent bugs that were deployed.  It was all hands on deck, working all
hours 7x24 with two conference calls a day with the Operations organization
(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 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 when
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 indeed
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 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 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 megabyte 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 in
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 communicate
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 penalty 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. They 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 <marc.donner at gmail.com> 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 <rminnich at gmail.com> 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 was 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 to
>> the scale of the Bell System, the center of the universe of semiconductor
>> 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 will
>> burn for centuries, also had silicon.
>>
>>
>>
>>
>> On Mon, Nov 28, 2022 at 1:01 PM Kenneth Goodwin <
>> kennethgoodwin56 at gmail.com> wrote:
>>
>>> That must be the 300 B superhive model CPU
>>>
>>> On Mon, Nov 28, 2022, 1:54 PM William Corcoran <wlc at jctaylor.com> 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 <jpl.jpl at gmail.com>
>>>> wrote:
>>>>
>>>> 
>>>>
>>>> [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 <phil at ultimate.com> 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=T3tcCBHRIfU
>>>>>
>>>>> 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=T3tcCBHRIfU
>>>>>
>>>>> 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 REVIEWING
>>>> THIS EMAIL.
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221128/31be141f/attachment.htm>