AMD outsells Intel in the datacenter space

Oh my, allow me to reminisce.

When the Intel 80386-33 came out we thought it was the pinnacle of CPUs, running our Novell servers! We now had a justification to switch from arcnet to token ring. Our servers could push things way faster!

Then, in the middle 1991, the AMD 80386-40 CPU came out. Mind completely blown! We ordered some (I think) Twinhead motherboards. They were so fast we could only use Hercules mono cards in them; all other video cards were fried. 16Mb token ring was out, so some of my clients moved to it with the fantastic CPU.

I have seen some closet-servers running Novell NetWare 3.14 (?) with that AMD CPU in the late '90s. There was a QUIC tape & tape drive in the machine that was never changed for maybe a decade? The machine never went down (or properly backed up).

Some AMD 80386DX-40 drama:

> While the AM386 CPU was essentially ready to be released prior to 1991, Intel kept it tied up in court.[2] Intel learned of the Am386 when both companies hired employees with the same name who coincidentally stayed at the same hotel, which accidentally forwarded a package for AMD to Intel's employee.[3]

I remember that 386-40. That was a great time.

Token ring networks! So glad we moved on from that.

Far out LOL

That's amazing!

Quick! Everyone! Someone dropped the token. Get up and look behind your desks.

Wonder if the hotel had a liability problem from that?

After all, it sounds like they directly caused a "billion dollar" type of problem for AMD through their mistake.

NW 3.12 was the final version I think. I recall patching a couple for W2K. NetWare would crash a lot (abend) until you'd fixed all the issues and then it would run forever, unless it didn't.

I once had a bloke writing a patch for eDirectory in real time in his basement whilst running our data on his home lab gear, on a weekend. I'm in the UK and he was in Utah. He'd upload an effort and I'd ftp it down, put it in place, reboot the cluster and test. Two iterations and job done. That was quite impressive support for a customer with roughly 5,000 users.

For me the CPU wasn't that important, per se. NWFS ate RAM: when the volumes were mounted, the system generated all sorts of funky caches which meant that you could apply and use trustee assignments (ACLs) really fast. The RAID controller and the discs were the important thing for file serving and ideally you had wires, switches and NICs to dole the data out at a reasonable rate.

In 1996 we set up a rack (department store surplus) of Cyrix 586 (running on 486 socket C motherboards) running at 75mhz with 16mb of RAM and could serve 100 concurrent users with CGI scripts and image maps doing web serving and VOIP with over 1 million requests a month on a single T1 line.

Good luck doing that on a load balanced rack of 96 core AMD servers today.

> So glad we moved on from that.

Don't look too closely at the collision avoidance mechanism in 10base-T1S, standardized in 2020. Sure looks like a virtual token ring passing mechanism if you squint...

Peak requests per second (and whether a SIP invite or CGI script being run) would be very useful to know.

SIP hasn't gotten much heavier, nor CGI scripts, and tiny distros like OpenWRT can do a lot with little iron.

Heard lots of rough ADSL era VoIP stories, hopefully you weren't struggling with that back then.

Are you seriously arguing that a rack of modern servers can’t handle 100 concurrent users?

It would be harder than it needs to be with modern software 'engineering' practices.

...a RACK full of 96-core servers could give a whole core to each user and still have hundreds to spare.