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@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@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@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. 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@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@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.