16 Jun 2025

Digital AlphaStation 250 4/266 — Part 4

Previous:

• Digital AlphaStation 250 4/266 — Part 1
• Digital AlphaStation 250 4/266 — Part 2
• Digital AlphaStation 250 4/266 — Part 3

Video

I think the video card is powerful enough for a graphical user interface, but I’m not going to use one (anyway X11 is broken on OpenBSD/alpha). But the resolution is 640×480, and even in text mode it’s a bit limited, but there’s something I can do about it.

The original video card has 4 switches, visible from the back of the workstation. Changing their position changes the video card resolution, so it changes the amount of lines of texts visible at any given time on the screen.

I have tried the different settings, with two different screens, they didn’t always report the same values, but here is what I found:

I’m using a screen supporting 1280×1024, so I changed the switches accordingly.

The main issue I have is that the video card uses a PCI port, and there are only two of them available. I’m pretty sure I had an ISA video card that could have been put in the ISA port and free up a PCI port, but I can’t find it. A quick search online reveals that the second-hand market is dominated by assholes reselling old cards for indecent prices (around 150 €).

Console

An alternative is to use a text terminal plugged on the RS-232 serial port. The most well-known one is the VT220, also from Digital. But I don’t have such terminals, but there are cables to convert the serial signal to USB to plug on another computer.

Be careful to use a null-modem cable, which invert the data lines. In my case I used a serial to USB cable and a null-modem adapter. The console port on the AlphaStation is the top serial port.

Watch the logs while plugging the USB/Serial cable in the main computer:

sudo tail -f /var/log/kern.log
usb 1-1.1: pl2303 converter now attached to ttyUSB0

So the cable is device /dev/ttyUSB0. On the AlphaStation, in SRM, the console can be redirected to the serial port. One important parameter is the baud rate. By default, the baud rate in SRM is 9600.

The serial line can be opened in Linux using the screen utility:

screen /dev/ttyUSB0 9600

At this point there should be nothing displayed in the terminal, as SRM is still using the graphic card. To kill the current screen, type ctrl+a then k.

In SRM, to switch to the serial port:

>>> set console serial
>>> init

To switch back to the graphical mode, same but type graphic instead of serial. If you are in serial mode but without a terminal/functioning serial cable, removing the RTC battery should switch the configuration to the default settings again. The motherboard does not seem to have a jumper to reset the configuration. I also had the case where turning off OpenBSD (halt command), which was in graphic mode, landed me back in a graphical SRM. If the video card is removed, it looks like OpenBSD automatically switches in console mode.

The manual says that the AlphaStation supports baud rate up to 115200… but no way to configure it in SRM. In some other versions of SRM (on other Alpha machines) it looks like you can change the baud rate with commands like set com1_baud 115200.

In OpenBSD, the serial console configuration is in file /etc/ttys. The serial port should be tty00, so configure the line starting with it:

tty00   "/usr/libexec/getty std.9600"   vt220    on secure

Here, 9600 should be changed to 115200, then reboot. Now the whole boot is at 9600 bauds, and switches at 115200 bauds when arriving at the login prompt.

Why using a faster baud rate? The serial console is synchronous. So if you have a process spitting out a lot of text, the process waits for the text to be displayed before continuing. The faster the text is displayed, the less time the process has to wait doing nothing.

Fans

As I said in a previous post, the AlphaStation has 2 fans: one blowing air on the CPU and PCI/ISA cards and one pushing air out of the power supply.

And I find them a bit noisy. The AlphaStation seems to make a bit more than 45 dB, and that noise is entirely made by the fans (and the moving air) since I replaced the HDD with an SSD.

Let’s replace them with a pair of Noctua NF-A8 FLX. Changing the CPU fan is quite straightforward. Which is not the case of the power supply one.

The power supply has to be unplugged then removed. Then it needs to be opened, and I’m not a huge fan (haha) of working in a power supply with big dangerous capacitors.

Then realize that the original fan’s connector is a 2-pin JST connector, obviously different from the Noctua’s connector. I do have some spare JST connectors, so time to cut the Noctua’s connector and plug a JST one on it.

With my lame technique of using my phone to measure the sound level, I now get around ~43 dB. That’s a bit better, but not much. I think I’m just not used to desktop PCs noise anymore.

So that was a probably unnecessary improvement. The main noise reduction gain was to replace the HDD with an SD card/SSD.

CPU cooling

The CPU heat sink is bolted down. Between the CPU and the heat sink, there was no thermal paste but a thin thermal pad (probably made of graphite).

I did replace the thermal pad by thermal paste in 2002. With the CPU under full load (compiling), my infrared thermometer reports a maximum of 61.5 °C. Not as hot as I would have expected. But anyway, it’s time to change the paste.

But first, let’s try the thermal pad again. Neither the CPU nor the motherboard have any embedded thermal sensors. So I’m relying on an infrared thermometer, so the values are just to give an idea. Anyway, started compiling again, and now measuring a maximum of 55.3 °C. The thermal pad seems to be working pretty well.

Again, I’m pretty sure I still had some thermal paste from a CPU I changed a year or two ago, but I can’t find it anymore. So I bought some Noctua NT-H2. Compiling again, now the max is around 54.2 °C. Given the unreliable way of measuring, I would say it’s in the same ballpark as the original thermal pad, maybe slightly better. Again, another improvement that was probably not necessary.

Memory

The AlphaStation I have has 128 MB of memory and can support up to 256 MB of memory. It has 2 banks of 4 slots. So 4 memory modules need to be installed simultaneously in a bank for it to work.

Mine has 4 modules of 32 MB, 4 mores are required to upgrade to the maximum 256 MB. Given that I see the swap partition is quite often in use, maybe adding memory will help.

On each side of the memory module there are 8 Mitsubishi chips and 1 Texas Instruments chip:

• Mitsubishi M5M417400BJ-7
  Fast Page DRAM, 4MX4, 70 ns, CMOS, PDSO24
  (4MX4 = 4 millions of 4-bit words = 2 MB)
• Texas Instruments TMS44100DJ
  Fast Page DRAM, 4MX1, 70 ns

The Mitsubishi chips are the actual memory (8 chips × 2 sides × 2 MB = 32 MB). My guess is that the Texas Instruments chips are for parity.

Looking at the AlphaStation documentation (I should have started with that):

• “The system requires 72-pin parity SIMMs that have an access time of 70 ns (nanoseconds) or 60 ns.”
• “The data is longword parity protected (each set of 32-bits has a parity bit).”

I had a look online, and found seemingly compatible memory modules. 19 $ a module is kind of OK, but I require 4 of them, and there’s 40 $ of delivery from the US. And 8 € of customs.

When booting, the machine was swapping, which is not the case anymore. So as a bonus, boot time is now 5 minutes 30 seconds, 1 minute better than before.

Ethernet

According to the operating system, the ethernet card is a 10baseT. Let’s compare the theoretical maximum speed of various components:

• Ethernet (10baseT): 1.25 MB/s.
• SCSI bus: 10 MB/s.
• PCI bus (1.0, 33 MHz): ~133 MB/s.
• RAM (access time of 70 ns and a 64 bit bus width): ~114 MB/s (no idea if this calculation (bit/access time) is the right one to calculate bandwidth).

So, the ethernet is one order of magnitude slower than the SCSI, which is one order of magnitude slower than the PCI bus and memory. The ethernet card is clearly the biggest bottleneck.

Two solutions:

• Add a Fast Ethernet PCI card (~12.5 MB/s).
• Add a Gigabit Ethernet PCI card (~125 MB/s).

I have plenty of ethernet PCI cards in my stash… and they are all Fast Ethernet (100 Mb/s). None of them is a Gigabit Ethernet one 🙁. So solution 1 it is.

And as I said, that was theoretical speeds. As seen in the previous post, originally, the performances of the ethernet card was probably on par with the actual speed of the SCSI drive. But now that I moved to an SSD on a PCI card, the drive performances are better than Fast Ethernet, but not much more. So, not having a Gigabit Ethernet card available is in fact not a real issue.

The main issue here is that I don’t have any PCI port available anymore for the ethernet card as it’s now used by the SATA card. As seen above, I can use the console only and remove the video card and use that PCI slot.

So now I have both ethernet cards plugged in, the 10baseT one visible in OpenBSD as de0 and the fast ethernet one as rl0. They are configured in /etc/hostname.XXX where XXX is the device name, so de0 and rl0.

Benchmark using speedtest-cli, best results of 3 runs for each ethernet card:

The difference between the two is surprisingly low.

So more tests requires, I downloaded a big file (~1 GB) over HTTPS from my local network with curl and redirecting the output to /dev/null so the hard drive would not be the bottleneck. Looking at the CPU usage, I think it was the bottleneck in HTTPS, so I also tried over plain HTTP.

The encryption is kind of killing the CPU, without it, the 10baseT interface runs close to its max speed. The fast ethernet card, on the other hand, doesn’t reach its full potential, but can reach speeds way higher than the 10aseT one.

Cost

Let’s recap the cost of this renovation:

I could have saved 50 € by not changing the fans and CPU thermal interface material.