[Info-vax] Microsoft: Alpha architecture responsible for poor Windows file compression

[johnwallace4 at yahoo.co.uk]

On Thursday, 3 November 2016 01:41:16 UTC, terry-... at glaver.org  wrote:
> On Wednesday, November 2, 2016 at 6:28:51 PM UTC-4, johnwa... at yahoo.co.uk wrote:
> > They ended up with one or two crashes a week per control
> > room due to memory parity errors. That was unacceptable
> > to this VMS customer so they were replaced with similarly
> > configured AlphaServer 1000s which had ECC rather than
> > parity. The single bit memory errors which crashed a box
> > with parity memory were still occurring, but they were
> > invisible to the software on a box with ECC memory, the
> > system just kept on running.
> 
> This sure sounds like a design error, incompatible add-on
> memory, or an out-of-spec operating environment. I had quite
> a few AS200 4/233 systems maxed out w/ 768MB, where I would
> expect to see problems if something was marginal, and they
> worked just fine.
> 
> A common issue at that time was using SIMMs with the wrong
> connector material. There were two types, gold and tin (sol-
> der). Sockets for tin SIMMS had sharp points on the pins to
> make an air-tight seal (similar to how wire-wrap works). If
> you put a gold SIMM in a socket designed for tin SIMMs, the
> pins in the socket would "stub their toes" on the harder
> material and become deformed, so even replacing the SIMM
> with the correct tin one would no longer be reliable. You
> may be saying "gold is harder than tin?", but the gold was
> plated directly onto the copper of the PCB and that's where
> the problem came from.
> 
> However, all bets were off with "PC" type hardware. There
> was a proliferation of processor support chipset brands and
> some of them had problems. I had a coversation (via an in-
> terpreter) with the lead designer of one brand (unnamed, but
> sounds like "sympathy" 8-) where he flat-out told me he did
> not care about cache consistency errors because "Windows 
> wouldn't stay up that long anyway". Unfortunately, I was 
> using BSD/OS and one system from that era eventually showed
> the uptime as "***" as it had overflowed the 999 days the
> utility would display. Somewhat later, the market was treat-
> ed to the "COASt fiasco" which also introduced gratuitous
> cache errors.

I remember the tin-vs-gold thing but I'm not sure it's
relevant to DEC-produced Alpha systems. ICBW.

Unfortunately I can't quickly find the relevant QuickSpecs
or other directly helpful AlphaStation 200/400 documentation.

My recollection (correction welcome) is that the
AlphaStation 200 was designed to use ECC memory (needing
genuine 36bit SIMMs) whereas the 400 used basically the
same 21064 processor and memory chipset, but configured in
lower-budget mode, to use a narrower memory bus potentially
using 33-bit (longword parity) SIMMs.

AlphaStation 200 was a classicish DEC-style single board
design in a  product-specific lowish-profile desktop case.
No obvious constraints on budget ($$$ or space), thus a 
full memory-bus chipset (21072) allowing 128bit-wide
main memory with ECC. Maybe even enough budget for enough
flash memory for two sets of console firmware (NT and SRM).

AlphaStation 400 was a cost reduced design with an Alpha
processor and specific support chips (including SIMMs) on
a quite compact daughtercard. Everything else, including
main board, minitower enclosure, PSU, etc was derived
from a design from DEC's PC Business Unit. The limited
budget (space and $$$) didn't allow for the full memory
support chipset, it had a 21071 (vs 21072) which provided
a 64bit-wide main memory system without ECC. 

Or something like that. It's been a while.

The 21071 and 21072 spec sheets are on archive.org:
https://archive.org/details/dec-21071_72_data_sheet

Correction welcome.

Meanwhile here we are two decades later and people are
happily buying multi-GB-memory PCs with no error protection 
of any kind. Server purchasers still seem a little bit
fussier with their hardware, and a server without ECC 
memory might look a little low-budget.