In my mind, this stuff is impossibly reliable and should simply not work, but here we are.
2,500 continuous runtime hours on a 4.77Mhz DOS web server
71–80 of 92 posts
Re: 2,500 continuous runtime hours on a 4.77Mhz DOS web server
#72The complexity of operation of 2500 hours at 4.77Mhz, single core, is equivalent to about an hour on a garden variety modern server. In my mind, this stuff is impossibly reliable and should simply not work, but here we are.
Re: 2,500 continuous runtime hours on a 4.77Mhz DOS web server
#73Earlier quoted context omitted.
Wow expectations sure have come down! When that computer was new, people had uptimes measured in years, 100 days was pedestrian.
And we were all on HN 40 years ago huh?
Re: 2,500 continuous runtime hours on a 4.77Mhz DOS web server
#74The complexity of operation of 2500 hours at 4.77Mhz, single core, is equivalent to about an hour on a garden variety modern server. In my mind, this stuff is impossibly reliable and should simply not work, but here we are.
Are you referring to the CPU used for the site? If so, how did you arrive at one hour? I'd put it closer to a second.
Back of the napkin-
assuming 2020 tech, 20 cores, 2.4ghz and ignoring all of the non-cpu complexity growth, it would be around 0.2 seconds lol.
If you were to wrap in the actual system complexity *operating frequency we’d probably be around 10ms equivalent complexity.
The reliability of modern computing systems is ridiculous.
Re: 2,500 continuous runtime hours on a 4.77Mhz DOS web server
#75That keyboard there was a work of art. I can still remember typing on one as a kid. So responsive, so satisfying, it just compelled you to want to write more. I own a few mechanical keyboards now and none of them compare to the original IBM Model M (I have heard that there are companies making 'new ones' though so maybe I'll have to try one.)
Re: 2,500 continuous runtime hours on a 4.77Mhz DOS web server
#76Earlier quoted context omitted.
I had a 486 go through a tornado where the entire building was torn apart. Completely soaked. Brought it home, let it dry for a few weeks. Worked fine for a few years after as a mp3 player.
That must have been a beefy 486, as I remember I had trouble getting a Pentium 100 Mhz Toshiba laptop to play mp3's on Linux kernel ver 2.4, and it could only do so from the bash shell without XWindows running. It could manage it on Windows 98, though, but only with the windows media player, if I remember correctly. Winamp 2 was a bit of a CPU hog for some reason, even though I never used visualizations.
Brings back memories of the mp3car (PC parts) and mp3ar (MAS3507d) projects. Going back to 2000 on archive.org https://web.archive.org/web/20000408180856/http://www.mp3ar....
Re: 2,500 continuous runtime hours on a 4.77Mhz DOS web server
#77Re: 2,500 continuous runtime hours on a 4.77Mhz DOS web server
#78Could this claim the title of “oldest host on the public internet serving traffic”? At first I thought “~100 days, so what?” - but that was before I knew this was an 8088 managing to hold up to even just the background noise of the modern net (portscans, etc). It’s surviving being slashdotted by HN. Very impressive.
I'm just happy it's been surviving the hug of death for 12+ hours now. Given the age and software that might be the true accomplishment.
Re: 2,500 continuous runtime hours on a 4.77Mhz DOS web server
#79Somehow this is even more interesting after reading that OP is a Site Reliability Engineer for Google. http://www.brutman.com/Michael_Brutman_resume.pdf
On the plus side, when I finally do get around to building a cluster of these and a load balancer I'll know what to do. ;)
Re: 2,500 continuous runtime hours on a 4.77Mhz DOS web server
#80So how do you apply the latest DOS security patches without rebooting?
On a more serious note, the web server is the problem here. I've tried to run long periods of time before but eventually it would crash. I finally found a 10+ year old parsing bug that wasn't handling quoting correctly, and it was some sort of crypto coin mining JSON request that tripped the bug. So even what I thought was bullet proof years ago turned out to be broken by changes in the user traffic.