39-Year-Old 4.77 MHz DOS Web Server Hits 2,500 Hours of Uptime

Brutman Labs web server
(Image credit: Brutman Labs)

Behind the simple but not-unappealing website of Brutman Labs, there are some surprising features and statistics. In a recent update posted to the site, it was revealed that the server behind the web destination has run for an impressive "2,500 hours of continuous runtime." However, probably far more eyebrow-raising is the fact that the web server is a 39-year-old IBM PCjr that's packing a 4.77 MHz CPU.

The Brutman Labs web page is subtitled "retrocomputing performance art," and we think that may be due to the incongruence between the ancient hardware and the capable and steady web serving achieved. At the time of writing, the server status page reveals that the beige IBM computing fossil has continuously been doing its duty for 2,541 hours+. That is over 105 days straight, with no restarts.

The achievement outlined above deserves closer inspection, so what are the specs behind the BrutmanLabs.Org server? You can see the hardware and software listed in the image below:

(Image credit: Brutman Labs)

The 39-year-old IBM PCjr acting as a web server here has had some significant modernizations. Probably the biggest upgrade has been delivered to the storage subsystem, with an IDE adapter and a 240GB SATA SSD installed. Also, the RAM is maxed out to 736 KB, which may have been unusual on this machine 39 years ago. Nevertheless, the beating heart of this system remains the NEC V20 CPU, a chip that is code and pin compatible with the fabled Intel 8088, running at 4.77 MHz.

If you visit BrutmanLabs.Org today, the machine serving the web pages you read is served by this old very IBM PCjr. The site is also worth visiting for lots of information on related and side projects.

Brutman Labs Server Uptime in Context

It may be impressive that the retro-server mentioned above has been continuously running for 2,541+ hours, or 105+ days, but it is just a minnow in the uptime league tables.

Last month we reported an AMD Epyc Rome bug, which the red team admitted could cause "a core to hang after about 1,044 days." That's about 2.93 years. The issue that affected second-gen Epyc processors meant a workaround of restarting your system more regularly than every 1,044 days was suggested. Alternatively, users could disable the CC6 sleep state.

Sadly for Epyc Rome users, AMD's bug meant systems based around the CPU wouldn't have a chance to rank highly in the uptime league. 2.93 years might sound like a long time between restarts, but the computer in the Voyager spacecraft has been running for over 48 years (and counting) without a reboot, for example. If we look at only terrestrial computers, the record seems to be over 16 years for a server decommissioned in 2018.

If you have a computer system uptime you are proud of; it may be worth comparing notes with the throng on the uptimeporn subreddit. These listings aren't just for computers, but for all kinds of devices. We noticed a fascinating post about a Cisco router, which was claimed to have run continuously for over 19 years.

Mark Tyson
Freelance News Writer

Mark Tyson is a Freelance News Writer at Tom's Hardware US. He enjoys covering the full breadth of PC tech; from business and semiconductor design to products approaching the edge of reason.

  • Sceptical87
    Michael Brutman's mTCP suite makes it really easy to use Internet technologies on DOS. With mTCP I can easily connect my 3/486 PCs to my home network and use FTP to pull across games and programs without needing to burn them to CD or copy to floppy disk. Makes retro computing that little bit easier.

    I note mTCP had a recent update too, which is great to see.

    Not to mention the wealth of information he's compiled on his website.

    Thanks Michael for your efforts - keep up the great work.
    Reply
  • bit_user
    I feel like it's a little bit cheating that it's running off a SATA SSD.

    Somehow, it just doesn't feel that impressive to hit 100ish days of uptime. I know DOS had no memory protection, but still...
    Reply
  • InvalidError
    My PCs routinely routinely hit 2-3 months of uptime between OS and driver updates when I'm not screwing around with hardware changes or install games that install outdated stuff Windows Updates overwrites and requires a restart right after.

    Running a mostly static web server on an old XT-like PC doesn't sound quite that impressive when you consider that many IP-connected micro-controllers and DSPs with somewhat comparable specs packed into a single chip are doing something similar for their configuration UI.
    Reply
  • Gavin Greenwalt
    InvalidError said:
    Running a mostly static web server on an old XT-like PC doesn't sound quite that impressive when you consider that many IP-connected micro-controllers and DSPs with somewhat comparable specs packed into a single chip are doing something similar for their configuration UI.
    Yeah I ran a very similar PC for my router in Highschool on my 10Base-T home network when I finally got "broadband" aka a 600kbps wireless uplink to a rural WISP.

    I think I was running Coyote Linux off of a floppy
    Reply
  • mbbrutman
    Keep in mind that this just isn't about being running for 100 days; I also wrote the TCP/IP library and web server. It's also entirely exposed on port 80 to the entire world. And it has also survived the Hacker News "hug of death."

    All of the upgrades could be removed and replaced with period correct hardware. The SSD is there because I don't want to burn up an old MFM hard drive.

    Remember this is an 16-bit machine from the 1980s. It is way out of its duty cycle.
    Reply
  • InvalidError
    mbbrutman said:
    Remember this is an 16-bit machine from the 1980s. It is way out of its duty cycle.
    Being "16bits" doesn't mean much when even 8bits micro-controllers can run IP stacks. The killer blow for any sensible application isn't so much the hardware being old as it is that modern chips eliminate the hardware, software and power overheads of adapter-on-adapter(-on-adapter) kludges. You can get the same job done in 1/50th the footprint and 1/100th the power with modern stuff.

    10Base-T(X) ISA cards were a thing in the late 80s, that would streamline things quite a bit.
    Reply
  • Vanderlindemedia
    In most old computers, the spindle based HDD is usually the first one to go.
    Reply
  • mbbrutman
    InvalidError said:
    Being "16bits" doesn't mean much when even 8bits micro-controllers can run IP stacks. The killer blow for any sensible application isn't so much the hardware being old as it is that modern chips eliminate the hardware, software and power overheads of adapter-on-adapter(-on-adapter) kludges. You can get the same job done in 1/50th the footprint and 1/100th the power with modern stuff.

    10Base-T(X) ISA cards were a thing in the late 80s, that would streamline things quite a bit.
    Which is why it's "Retrocomputing Performance Art" and kind of fun to build and watch. If it were a commercially available micro controller running modern software nobody would care and it wouldn't be showing up in a news feed.

    (And yes, ISA cards are available, but not on this machine which has no ISA slots. I haven't finished replicating a bus adapter that I have so it has to use the Xircom adapter for now.)
    Reply
  • InvalidError
    Vanderlindemedia said:
    In most old computers, the spindle based HDD is usually the first one to go.
    SSDs are easily replaceable consumable wear items too and they fail almost as often as HDDs do albeit for different reasons so you still need to have a regular backup strategy for any important files.
    Reply
  • mbbrutman
    bit_user said:
    I feel like it's a little bit cheating that it's running off a SATA SSD.

    Somehow, it just doesn't feel that impressive to hit 100ish days of uptime. I know DOS had no memory protection, but still...

    It would run fine on period correct hardware. I'm just not really interested in sacrificing an MFM hard drive for a silly project. The memory, floppy drive, IDE controller, SATA device, etc. are there for convenience. The SSD is not needed for performance; the machine can only read at about 300KB/sec at best. It's there for the log file, which is optional.

    DOS has no memory protection. No threads. No networking support. No virtual memory. I could keep going ... Basically, except for the code that I wrote and the lower level packet driver to send and receive raw bytes on the Ethernet device, there is not much else running. DOS here is basically the program loader and the library that lets me write to the filesystem.
    Reply