Hacker News Reader

Comment by bryanlarsen | Hacker News Reader

up to 8,000 Linux VMs (not sure with what load)

Traditionally mainframes were superior for loads that were IO bound rather than CPU bound. I suspect that this is still the case.

View on HN

The mainframe hardware isn't anything special (I've said this before, I still have access to a z114). You can probably host that many lxc containers on a decent x86 server too. Not that you probably want to.

The z114 CPU doesn't keep up with anything > midrange x86, and its IO capabilities are limited by the inifiniband links it uses to communicate with the IO drawers. A pretty basic dual socket E5 v3 has more PCIe bandwidth available than you can get out of the z114. It appears that is the case for larger machines as well (aka there are E7 configurations with significantly more bandwidth than the z13). And yes, I've heard all about SC's and all that. But what most people fail to realize is that most storage adapters have some form of ARM/etc cpu onboard that does most of what the SC does on a mainframe, and people have been fighting the CPU vs offload engine battle for years for network adapters.

So, a lot of the mainframe advantage is in zOS/zTPF and not the hardware. Running linux with its inefficient block layer, misses the point.

Heck, your probably better off running linux on POWER8.

A company I worked for about 10 years ago had an IBM s/390 mainframe for about a month. Our manager at that time had previously worked for IBM and was trying to move the company over to hardware managed by IBM.

The biggest selling point was redundancy in the hardware being able to handle CPU/RAM/Disk/PSU failures without taking down the Linux VMs running on it.

Our workload was network bound, not much CPU or Disk IO load.

We ended up using generic Intel PCs (some custom built, some Dell and some IBM Netfinities). We had more down time with the IBM managed Netfinities, then with the custom built rack mount servers.

Back then we also had some Sun UltraSparc E3500 & E6500s, but we found that the Java VM (from Sun!) was much slower on the UltraSparc CPUs then on Intel CPUs.

I find it interesting that we had much better results from generic no brand rack mount servers then most of the expensive "enterprise" class servers.

Note: This was over 10 years ago.

Anyone have more recent experience with servers in a self-managed DC or co-location? It seems most companies/developers now use cloud/vps/hosted servers.

It's really not possible to make a blanket judgement. The lot of high end systems boil down to brand name, software compatibility, "one throat to choke", and vertical integration. While the first two are mostly meaningless, the last two can have profound network effects. IBM has been able to realize nice vertical integration across most of their current systems, and they have some world class people doing CPUs, compilers, OSes, application stacks. If you have a problem with the mainframe you have one company to deal with.. that could be very good or very bad (somewhere brand name aka reputation does matter). In consumer terms, it's kind of like Mac vs PC.

It's also not so easy to judge x86 as low end. Stratus and HP make some really high end fault tolerant/instruction retry x86 servers that could be considered mainframes IMHO.

Low end x86 servers are "good enough" for a large portion of what people use servers for, and a massive amount of work has gone into making distributed systems that can scale and handle faults semi-predictably. That said, I'd much prefer my bank account to reside on an IBM mainframe SysPlex for the time being.

Sun kind of struggled in the CPU market as well as indecision around x86 for a long time, it's one of the primary reasons they are now part of Oracle. Those E3500/6500 systems are very high quality and would probably still be running fine today if performance isn't the only measure of worth.

I've long been a fan of IBM's POWER system p or whatever they want to call it depending on the day of the week. It's positioned somewhat in the middle of x86 and mainframe, but you generally get more powerful systems than x86 with mainframe inspired reliability. Still, these fill a much narrower niche than cheap x86 boxes.

I agree with what you said. I was just relating the experience I had.

We also had two large (U8) Compaq ProLiant servers that we used to run Oracle DB. We didn't have any problems with them, and only replaced them with newer faster Dell servers later. The redundant PSUs and hot-swap drives were the main reason we ran our database on them (one master, the other a standby slave). Those server were later used for our beta site (used for staging/development).

We later ported the backend Java service to C++, which most likely would have run fine on the UltraSparcs, but I think we had already sold them or returned them back to the vendor. I really wished Sun's UltraSparc T1 & T2 CPUs had taken off. I think they could have really good CPUs, but it was hard to compete with x86 because of all the software that was already compiled/optimized for the x86 architecture.

For us it was important to be able to fix problems quickly. Having to call in a service tech. to fix a hardware problem just increased downtime. Also we just had really bad luck with the IBM Netfinities, all 4 servers had a bad motherboard which failed in each server at different times. After that we didn't have any problems with them.

Personally I prefer to deal with generic hardware that I can service myself when a problem happens. But for some companies, it is better to have managed hardware with service contracts.

A few years ago our management had a healthy portion of kool aid and demanded that we land a few systems to Linux zOS containers.

It was awful and we discovered why a few days in -- running our workload on a few VMs on my crappy corporate laptop in VMWare smoked the mainframe.

I guess it's better now, but it seems more like an Oracle license laundering scheme that something anyone would choose to run.

Total agreement. Linux on the mainframe is really silly beyond utility purposes, whoever the business people are that convinced senior IBM management otherwise really pulled a fast one.

POWER8 is designed for UNIX, and adjusting for certain parameters goes beyond what x86 servers can do in the same footprint and reliability. Price is approachable to people who need the reliability these kinds of systems can provide. IBM systems have grown a lot in common over the years, with AS/400 or System i and RS/6000 or System p melding together, POWER8 kit has a lot of mainframe inspired RAS features.

Can you do an AMA, or umm, tell us more?

+1 Insightful

Even with high CPU loads, due to license costs for expensive proprietary software, the advantage can shift towards mainframes when dedicated Application Assist Processors (zAAP) are employed, because usually only the generic CPUs have to be licensed. By offloading work to the 'license-free' zAAPs, overall throughput can be greatly increased with equal license costs.

Of course, this scenario isn't what LinuxONE boxes are made for; they are more focused towards open source deployments in the enterprise, with low license costs (usually only support contract costs).

I used to work at a place that did this. The only issue we ran into was memory was HELLA expensive on the z series boxes. It was to the point that it was cheaper to buy an hp server with 1TiB ram than get 16g of ram from the zaaps.

That and getting software to run on it was almost impossible. In the end we ended up moving everything to HP servers for a fraction of the cost.

When deployments like this happen, where does the z series box then go? Back to IBM (because it was on lease?) Is the z series modular enough that it's easy for ibm to reconfigure to lease to someone else?

If it was a lease through something like IBM Global Services they will take it back and possibly redeploy it. Otherwise, they can kind of get lost in the noise, either ending up at auction or straight to an edisposal service. They are usually parted out at that point to sell spare parts, because the licensing makes it nearly impossible to use one of these w/o involving and paying IBM, usually monthly. Otherwise they are crushed for precious metal recovery. Kind of sad ends for such works of art.

The Linux dichotomy IBM created is pretty stupid. I don't know why you'd want to run a tire fire on such expensive HW, sure maybe utility VMs, but not as the raison d'etat. Instead they should be a lot more willing to provide cheap z/VM, z/OS, z/TPF licenses for smaller shops to build up an ISV, admin, and porting community. But they charge thousands of dollars for an emulator when Hercules is freely available and ADCD is quite restricted.

I recently bought an older one for the cost of a soda https://twitter.com/kevinbowling1/status/685240077161598976. I would warn against doing this for a number of reasons, namely FICON storage and licensing, but if you are determined it is a lot of fun.

Thats cool, your lucky with the z800, most of the other mainframes have "exotic" (aka 3 phase 277/480) power requirements. We had to pull power in our existing computer lab to run our MF. So, while its possible to order most mainframe equipment for single phase 208, it doesn't appear to be the default choice for the kinds of places that buy mainframes.

I settled for hercules at home, hell of a lot easier to manage, and is pretty fast given that its a fairly naive emulator (aka no JIT/tracing/etc). I think if the turbo hercules guys (or someone else) added a decent JIT, and solved the licensing problem IBM would be in a world of hurt. Although, maybe not, the few remaining customers aren't the kind to run their bank/airline/etc on a 10k piece of hardware and an open source emulator. Of course, I've been wondering for a few years what percentage of machines are being sold to development shops to support the limited number of real customers. That is why we purchased ours, to support real customers, not to run any actual work on it. Of course I've also heard that most of the business class machines are sold with tiny capacities, because they are simply hot fail-over targets. The assumption is that if something goes wrong at the primary site, someone calls up IBM and gets them to boost the capacity on the idle machine as the workload is shifting over.

Yeah IBM really created a false dichotomy. Production users want the mainframe architecture and reliability. Developers are fine with emulation and create demand.

I've got to imagine they are barely breaking even on a minimal config baby class system. The yield on an MCM has to be minimal. You can find videos of how labor intensive the build of a frame is, let alone the engineering. I wouldn't even be surprised if they were loss leaders.

And that begs the question, why not grow the user base with aggressive placement, training, and development. Another $1 billion investment in Linux has no appreciable affect to most mainframe users, and no way there is an ROI. Imagine that injection on this small, loyal platform of users.

Yep, either IBM says ok thanks we'll move this hardware to somewhere else. Or the other odd thing about mainframes, they ship them out fully loaded, and make it so they can turn on the hardware you want if you need it.

Yeah, it is a weird environment. The i/o on them is nice though, but everything else is so wackadoo I never want to touch it.

Good for you haha. How much power do one of those things use, btw?

The z13 uses 12.9 kW with 3 CPC drawers (~96 CPUs) up to 24.7 kW in a 4 CPC (141 CPUs) fully loaded, maximum power configuration.

See: https://books.google.nl/books?id=Do1WCAAAQBAJ&pg=PA78&lpg=PA...

Appreciate it.

This is the baby class z800, it's 3kw max which isn't too bad for a full cab.

Yeah, that's like 6 gaming rigs when I built them. Not bad at all.

I don't know how they decommission a zSystem.

But from what the mainframe guys at work told me, hardware between 2 z boxes are pretty much the same and it's kind of licensed by load usage or components usage.

So if you want to downgrade or upgrade memory/CPUs/etc. (to a certain degree), it's just a matter of having an IBM tech to enter the right license in the console.

Interesting.

Never worked on mainframes myself, but have on Unix (and Linux) a lot. Had read some years ago that mainframes had some powerful features that were often not available on Unixes. One such feature that was available, could be HP's PRM (Process Resource Manager), which, IIRC (from my time at a HP joint venture), could ensure allocation of a guaranteed minimum percentage of system resources (such as RAM and CPU time) to a specific process (say a payroll job running at the end of the month). I remember being impressed by the concept at the time.

There was also HP MC/Service Guard, but didn't have a good idea what it did, just remember the name.

P.S. Had also tried out rtprio and prioc(n)tl on some Unix boxes, maybe one was an HP one, the other a SVR4. They allowed assigning (quite) higher priorities to specified processes, IIRC.

P.P.S. Both those product names could have been changed by now, or been merged into bigger products, as sometimes happens.

Edited to say that HP's PRM _was_ an example of a mainframe-like feature.

Another one I like very much is how OS/400 works.

Written originally in PL/I and Assembly, it contains a kernel level JIT.

All user space applications target a general purpose abstract Assembly and they are AOT to native either at installation time or on-demand.

Other mainframes had similar approaches to code portability.

Sounds familiar?

Another cool thing are the catalog based filesystem and OO Assembly.

The JIT scheme worked well for future-proofing for decades. That means it's an approach others should consider emulating if they're not yet. Only thing I couldn't figure out, due to IBM terminology, is if the compiled output is actual microcode or just CPU instructions. Or if they both create a optimized, microcode implementation and a JIT to move things to it.

Integrating DB-like functionality into the system was ahead of time. The original, System/38, had capability security in the hardware enforcing an object-based view of memory with permissible operations on different types of objects: processes, I/O, arrays, stacks, and so on. The security implications of that means I'd recommend one to a business in a heartbeat if they hadn't ditched that for POWER.

https://homes.cs.washington.edu/~levy/capabook/Chapter8.pdf

All in all, System/38 was a very, forward-thinking and practical design that continues to prove itself year after year. If it doesn't exist, I'd like to see a Lesson's Learned report on that project and how the team decided what would be in it.

OS/400 doesn't run on s390/zenterprise. It runs on pSeries (POWER8), which also run AIX and Linux.

OS/400/IBM i (or whatever its called this week) is actually probably one of the cooler OS's still around. It should be mandatory study in any comp sci/comp eng OS classes, but sadly its not and because of that, a lot of wheels are being reinvented.

> Sounds familiar?

Java JIT doesn't write machine code to disk. OS/400 does, and then it re-uses the machine code until it no longer exists (you move to new hardware) or the bytecode is newer (you change the program and recompile), at which point it compiles the bytecode to machine code and stores it to disk again.

Actually it does.

You just need to look to the correct JVM. Apparently people keep forgetting Java is like C and C++. There are plenty options to choose from and OpenJDK only plays the role of reference implementation.

If I am not mistaken IBM J9 is one of those JVMs.

Kernel level JIT? Didn't know, sounds cool.

>Sounds familiar?

I suppose you mean like Java and Python bytecode running on their VMs (of the language, not OS kind).

I've sometimes thought, as well as heard others say, that some of the tech advancements of earlier decades haven't been "re-invented" :) yet ...

Actually I was thinking more about some Oberon versions that used a JIT, the way .NET is integrated into Windows, specially on the mobile since version 7.

Also the way Java gets used on Android and other embedded platforms.

Or the new deployment model for iDevices.

Ah, Oberon. Don't know much about it. But do somewhat remember an interesting feature of it from a BYTE or other computer mag article: You could write a subroutine once and then have it available in the whole operating system - something like that. My description might not be right but I remember thinking the feature was powerful at the time.

Yes, that is correct.

But the original idea was from Mesa/Cedar at Xerox PARC.

Didn't know, thanks. Also saw that you just posted a link to an article about Mesa on HN. Viewed it briefly. It says the Alto file system was written in "BPCL". Should that BCPL, a precursor of C? Had read a book it, by Martin Richards, IIRC, long ago. Good read. I think it had only one type - machine words. Fun to implement higher level stuff on such a base, though tedious by today's HLL standards.

Just checked out Martin Richards' web site:

http://www.cl.cam.ac.uk/~mr10/

(Richards invented BCPL.)

He has an interpreter for BCPL. The page says:

BCPL, an interpretive implementation of the BCPL language and system, including many demonstration programs. Click on BCPL.html to obtain a copy of the current version. This version can be installed easily on most machines running Linux, Windows and MAC OSX. In particular, it is easy to install this version on the Raspberry Pi machine. See the Young Person's Guide to BCPL Programming on the Raspberry Pi (bcpl4raspi.pdf) for details.

His Wikipedia page:

https://en.wikipedia.org/wiki/Martin_Richards_(computer_scie...

says:

He was awarded the IEEE Computer Society's Computer Pioneer Award in 2003 for "pioneering system software portability through the programming language BCPL".[9]

https://en.wikipedia.org/wiki/BCPL

C followed B which followed BCPL.

I think he's refering to things like Apple's "bitcode".

http://lowlevelbits.org/bitcode-demystified/

Bitcode isn't JIT (yet); it simply allows Apple to compile binaries targeted at new devices or with newer compilers, without the developer having to do anything.

This has not been my experience running Linux on mainframes.

The 8000 VM tests I've seen picked apart are typically "a webserver" type load, not meaningful work.

Reply on news.ycombinator.com