🚀 go-pugleaf

On 2018-08-14 12:46, terry-...@glaver.org wrote:
> On Tuesday, August 14, 2018 at 5:43:37 AM UTC-4, Johnny Billquist wrote:
>> Yes. Although, the 8600 didn't miss the performance goals, as far as I
>> can remember, but it was *way* late. But as far as I can remember, the
>> goal was 4x 11/780, and that is what they achieved.
> 
> It shipped with some internal optimizations disabled, some of which were fixed by the regular shipment of microcode updates. I think the serial sense bus (that gathered data from each pin of each macrocell array) and wrote it to a state dump file on the console RL02 was more a statement about how nervous they were about the machine's reliability than the declared reason of letting them know exactly which board to bring when a system failed.

The dumps are pretty impressive. I guess they were also good for 
troubleshooting and analyzing if things went wrong. But I must say that 
the 86x0 machines were (are) impressively reliable. Lots of redundancy 
meaning they will normally keep running even when some stuff is broken.

> The only difference between an up-to-rev-level 8600 and an 8650 are the clock and mbox cache control boards. Every other board in the system is the same, if up to an acceptable rev level. I think that shows pretty clearly that the 8600 didn't meet its internal design goal. The marketing material may have said "4 times a 780" but that came along at a later date. The planned (and dropped) 8670 would have been a more major board swap (think 11/780 to 11/785 upgrade). But by then the writing on the wall was quite clear that "complete" VAX systems (w/ PDP11 mode, full instruction set support in microcode, etc,) were on the way out.

Yeah. It was the dawn of the VLSI VAXen. Suddenly production exploded 
and new VAX models were being introduced every few weeks. Reworking the 
86x0 at that point was probably very obviously not attractive anymore.

> An undocumented CE mode let you change the fundamental clock in the 86x0, presumably for margin tests when running diagnostics. But some customers found they could run jobs 20% faster.

Not undocumented. If you typed HELP on the console, you'd find all about 
how to play with it.
I can post the HELP information, if anyone is curious.

>> 8670 don't ring any bells in my head right now, so I can't comment. The
>> 9000 was done by the same group though, yes. And while it was fast, and
>> I don't know if it was late or not, it was certainly way too expensive,
> 
> It used to be fun to read the listing fiche (or the equivalent STARLET library) to find out the names of un-announced products. Unfortunately Charlie Matco exposing these caused DEC to change them to filler codes.

:-)

> The 9000 family was DEC acquiring every company they could find that had something remotely useful, in the theory that DEC could pull off a major architectural triumph (pun semi-intended) the way IBM did with their new packaging on 3090-class CPUs. DEC never did seem to understand that they weren't IBM.

True. And this was at the time when DEC really tried to become IBM.

>> and the NVAX came out not long after with the same performance on a
>> chip, making the 9000 immediately obsolete.
> 
> And making Ken's head explode, once he finally understood.

Yes. :-)

>> My brain keeps saying "LCG", for Large systems computer group, as the
>> ones being responsible for those machines, along with PDP-10s. Not sure
>> if I'm misremembering something, though.
> 
> LSG (Large Systems Group), I think.

Possible. Maybe someone around here was involved and can tell for sure.

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: b...@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol