Don't Nurse Old Hardware - Emulate It

gManZboy writes "Bob Supnik, former team lead for DEC's VAX microprossesor, has an article up on Queue about his Computer History Simulation Project and how emulating old servers may be a better way to keep them running that servicing the physical machines. So how many PDP-11's can you run on a Pentium 4 anyhow?"

Comments

Can't believe no one's thought of this

[Jonny_eh]

Everyone has been so busy emulating the GBA and Xbox that no one has thought about emulating these old servers?

Re:Can't believe no one's thought of this

[PhilHibbs]

It's not like there is some pool of emulator writers, constantly considering what the world needs in terms of emulators. The people that write GBA emulators are people that want a GBA emulator. Asking them nicely to write a Pr1me emulator is likely to get you nowhere. You need to talk to the people that want a Pr1me emulator.

Re:Can't believe no one's thought of this

[MoneyT]

Actualy people have thought about it. The problem is, emulators are all well and good, until you actualy need to access a periphrial.

Re:Can't believe no one's thought of this

[confused one]

There have been PDP and VAX emulation boards available for some time. I believe some of the other big iron is also emulated already. This isn't something new, just new to /.

Re:Can't believe no one's thought of this

[pla]

The problem is, emulators are all well and good, until you actualy need to access a periphrial.

So you emulate those, as well... And usually, they take a lot less to emulate than the core system.

As a trivial example, consider the peripherals available even on previous-gen consoles... You have 3rd party joysticks, mice, keyboards, cameras, tape drives, printers(?), etc. All those eventually end up emulated, if enough people needed them.

The same goes for something like a PDP-11 or VAX 11/750 or the like. You have some odd storage devices (that store a tiny fraction of modern HDDs, thus you can emulate them with an image file). You have printers (emulatable with... printers!). Perhaps really ancient input devices such as a cardreader (scanner -> conversion tool -> file). No doubt other exotic peripherals exist, but you can somehow emulate them all.

The conceptual problem with dealing with peripherals I think lies in just how much we've advanced since the days of Big Iron... Even for emulating CPU-cycle-critical hardware interactions, you can deal with it in emulation, by pure brute-force. Consider the 11/780, which ran at a whopping 6MHz. On a modern P4, that means you have over 500 CPU cycles per emulated cycle (and while the P4 can push through more than two ops per clock, the VAX only managed one instruction per 6(?) clocks, meaning you realistically have over six thousand real instructions per emulated one, on average). With six thousand instructions to burn, you could emulate your VAX while still getting a good framerate playing Super Metroid on an emulated SuperNes in the foreground.

That I know of, only the humble old laserdisc has thus far resisted attempts at perfect emulation, due to using an analog encoding scheme (rather than storing bits, it actually encoded the raw NTSC or PAL signal handled by the TV. And depending on what sort of access to them you need, even that problem has a way around it, via an MPEG rip and a frame file (ala Daphne).

Re:Can't believe no one's thought of this

[pla]

What about real peripherals? Ones you can't emulate?

Fair enough point - But in that case, I would have to consider the computer secondary to the machine itself - I don't know your specific situation, but the computer most likely did data collection and analysis. The controller-proper I would consider part of the "peripheral", and search for the easiest-to-tap connection as the point to break away from reality and into emulation.

I'll admit, I hadn't considered that point. You can't emulate a fatigue testing machine. You can't emulate a GC/MS. You can't emulate a CNC. You can't emulate an MRI. But I see that as similar to saying you can't emulate a car... You could fake-out a car's computer, but it doesn't do much good without car itself. Apples and Oranges.

So no, emulation won't solve all obsolescence problems... But for those situations where you wouldn't consider the computer as secondary to the peripheral...


However - as I touched on above, you can almost certainly still replace the computer portion of the system. At some point, the computer just takes a digital input, and at that point, you make the split from reality. My car doesn't care if its own computer runs it, or a PC sitting in the passenger seat. That might not do much to reduce the maintenence costs of the primary machine involved, but it does mean you can have your data on something other than an ancient reel-to-reel... ;-)

Emulation is great ..

[z0ink]

.. but you forget the reason people dont upgrade is that it costs money to do so.

Re:Emulation is great ..

[Halo1]

The large cost of upgrading is not the hardware cost, it's the migration cost. If your new hardware can emulate exactly the same environment where you came from, this cost can be reduced immensely.

Good idea... but...

[AdeBaumann]

Before I even R'd TFA, I thought about one big problem:

How are you going to emulate a 5.25 inch drive to read old disks?

Re:Good idea... but...

[Anonymous Coward]

Either convert them yourself, or pay someone to do it.. The point is the efficiency of emulation rather than hardware compatability..

The Stability of New Products vs Old

[Anonymous Coward]

Although this is a very good idea I question the stability of a new emulator vs an old proven system.

By using the original the kinks have already been worked out, quirks are known and understood, and everything just works.

By creating an emulator you have bugs to smash, that's just the way software is. Also keep in mind this seems to apply to big businesses (financial, medical) and large organizations (NASA) with legacy hardware. Since the stability of these systems is absolutely crucial why would they want to switch to a new, unproven, buggy system that stick with the old?

Re:The Stability of New Products vs Old

[GeoGreg]

Well, for one thing, the old, (formerly) stable hardware may be failing. It might be easier to get hold of a PDP/11 emulator being used (and, hopefully, improved) by multiple organizations than to attempt to translate the in-house PDP/11 assembly code into something that will run on a PIV Linux box. Especially if the people who wrote the legacy app are retired/laid off/dead.

Re:The Stability of New Products vs Old

[quarkscat]

There is no equivalence. For instance, DEC VMS
was used as the design "core" for Microsoft's
Windows NT. I have known of DEC VAX hardware
that ran continuously for 5 years without a
warm reboot, let alone a system shutdown. The
Microsoft OS often needed to be rebooted daily.

The hardware that Microsoft runs on is not as
reliable as the old DEC VAXs, as a rule. The
short term emulation of a legacy system is not
the same as replacing it. For exammple, an IBM
z/390 running MVS might be able to run 1000
linux servers, but in terms of reliability
(the proverbial 5 Nines), that z/390 could not
be replaced with 1000 linux boxes, or even 2000.

The old adage "They just don't make things the
way they used to." applies here. New hardware
costs are way down, as are HW/SW maintenence
costs, but the reliability of the new gear is
underwhelming.

DEC VAX -- why not port?!

[bunburyist]

If the DEC VAX systems are so antiquated, wouldn't it make more sense for businesses using these systems to simply upgrade to newer/better technology? I mean even if they have incredibly stability and "wow" factor, wouldn't it be easier than both solutions just to upgrade the software to newer systems. Uptime on many linux/unix systems are just fine for most usage, and QNX has their real time fail proof operating system, but I doubt people using VAX would even need something that powerful.

Re:DEC VAX -- why not port?!

[CarrionBird]

just upgrade the software?

Methinks you underestimate how badly software projects of that sort often go.

Re:DEC VAX -- why not port?!

[PingPongBoy]

If something breaks or if the capacity is reached, what then? Are parts available? Can an upgrade be done economically?

An upgrade path could be way overdue

Re:DEC VAX -- why not port?!

[flabbergast]

There are a couple reasons, most mentioned previously.

1. Uptime on linux/unix is not good enough. Linux/Unix versus Microsoft, sure its got a better uptime, but against a mainframe that hasn't been turned off in 20-30 years? We're not talking commodity hardware here that'll break in a few years, or need constant replacing. Banks, hospitals, etc can't afford any down time.

2. The code is probably long gone, and the software was probably custom. So, how exactly are you going to "port" this software? Oh, I know, tell all those banks to use gnucash.

3. If it ain't broke, don't fix it. All their employees know how it works. All their sys admins know the quirks. If you move to a new system, you've got thousands of employees who have to learn the new system from sys admins who don't know the software.

When it comes to upgrading a mainframe, its not like upgrading your home computer or home file server. You don't simply copy your ~/ over to your new computer and start running firefox.

I wonder why...

[5m477m4n]

by Bob Supnik, Sun Microsystems

Gee, I wonder why he would be recommending buying new servers?

Re:I wonder why...

[SillyNickName4me]

> "Perfectly usable"... VAX... VMS... hahaha hhahaaahahhahaha. Good. Got that out of my system.

And while I hope it never happens to you, if you happen to get into hospital, there is quite some chance that your information will be registered on a.... VAX. that is right, an old, according to you obviously unusable VAX.

Next time you transfer some money, chances are quite good that your order will be processed by... again one of those unusable vaxen...

I suggest you delve a bit into the matter before laughing your ass off because this makes you look like someone who knows very little of what is being used.

More important question:

[Enahs]

How do you emulate an 8 inch drive?

efficient versus speed

[www.sorehands.com]

If you keep the old system, it is running at .8mhz, 5mhz, or some other slow speed. It still runs faster emulated, though the emulation is not efficient. It also takes care of problems of repair and replacement of parts.

Why not port? Why bother?

[Mr. Roadkill]

If the DEC VAX systems are so antiquated, wouldn't it make more sense for businesses using these systems to simply upgrade to newer/better technology? I mean even if they have incredibly stability and "wow" factor, wouldn't it be easier than both solutions just to upgrade the software to newer systems.

Say you've got an existing system performing a particular task - maybe your inventory or payroll system, and it's coping with the load and has sufficient flexibility to allow you to make changes in response to foreseeable business and legislative changes. You are faced with a bill of a couple of thousand dollars every time something breaks, and that's happening more frequently. You know you want to get newer software in the future, but you're not entirely sure what you want and want time to look but are concerned the old system will not last until then.

In this situation, you could spend a couple of thousand dollars on a new machine and run your old software on it using a free emulator. Hell, the machine you just ordered for your secretary would probably out-perform the old server. The new machine will be one twentieth the size of the old, use one twentieth of the electricity and won't have twenty years of accumulated wear and tear.

If you've got a custom application written in a dead language, emulation may be the best way to continue fulfilling your requirements too. Sure, a new app in the shiny new language du jour might be nice, but if you've got proven 30 year old code and performance on the old hardware is adequate then it makes sense to keep things ticking on a virtual vax or pdp. And think of the kind of server room consolidation you could perform!

Other posters have commented on the proven behaviour of hardware v. emulators - how the latter could have bugs that aren't apparant, and may thus be unsuitable for users like NASA etc. Surely it's easier to produce a bug-for-bug compatible emulator than it is to re-write possibly millions of lines of legacy code in a bug-free manner. Sure, it's nice in the long run to re-write software with greater portability in mind, but while that's happening wouldn't it be worth making sure you can continue to run your existing programs without having to worry what will happen if some obscure I.C. elects a new Pope?

Re:I agree!

[NoMoreNicksLeft]

Then it's an even worse idea. How so? They think running a critical app on hard-to-repair hardware is tough? Then they need to wait until the emulator bugs out on something subtle.

They end up with still failing "virtual" hardware, and the only consolation is that if they persist long enough, they may eventually fix it completely. Oh, at least until they need to port the emulator to Windows 2009 Gold Pro edition on the Pentium 9, then it bugs out again.

Start porting the damn apps, or rewrite them. And even as you're doing this, plan for the next changeover in 10-15 years.

Why: Coolness and Bootstrap Education

[seawall]

There are several reasons to have emulators.

A big one (not the one that funds them) is they are cool.

Useful sometimes. E.g. PDP-11 on a PCI board with a PDP-11 hardware interface is buyable. It's used, among other places, in the postal system to run hardware that needs a PDP-11. Interestingly, it used to use the PDP-11 on a chip but last I checked used an Intel CPU. XEROX had allegedly bought all the remaining PDP-11 on a chip machines for their use in copiers.

The article was pushing the "where we came from" aspects. I KNOW how hard it is to keep PDP-10 hardware running. It's rather handy in defeating patents to come up with prior art...from, say, 1964. The thing here is it's use it or lose it time. You write an emulator and you understand the machine.

Bootstrap Education. A young person can understand a CP/M machine on a level that just isn't going to happen, say, my iBook G4 and use that understanding to bootstrap up to the next level of complexity.