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 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). > There’s a 600G model that was used in large quantities by the US Government (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 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 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 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 >>>> 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: >>>>> >>>>>  >>>>> >>>>> [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=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. >>>>> >>>>>