HP has announced that it plans to port its fault-tolerant NonStop server technology to the x86 architecture, in a move that should both reduce price tags in the NonStop product line and help HP further distance itself from Intel's all-but-stagnant Itanium platform. HP is by far the world's leading Itanium vendor, accounting for …
I have spent significant time with virtually every major Unix (and many many minor ones) in and out of shop except for HP-UX. Not being available for x86 these days has to be a mind share killer. Killing Itanium sooner than later and moving to x86 is probably five years overdue.
HP - Non stop
In there with chocolate fire-guards, leprechauns & Dell uptime stats.
Give me IBM kit any day
An outbreak of sense at HP
the world is getting weirder by the day. First I agree with Bill Gates and now this. Good move for HP. Maybe it is worth moving HPUX to X86-64 again. Does company have time before it does a Blackberry or Nokia ? They had a bootable kernel but it got killed in the new HP tradition a CEO or two ago. Hard to say as the linux juggernaut makes propriety unices less attractive, especially as Linux has containers now. Still think AIX on Power has the edge though. For the indigent, Solaris X86/FreeBSD with ZFS is a cheap option, although BTFS seems to be catching up in geek desirability stakes. As for their success in fondle slabs, not much hope. Already a near saturated market with low margins, unless one is Apple. Or HP stun everyone and release a phablet with memristor RAM of a TB or so.
HP Non-Stop Itanium will surely come to stop in the near future at HP. At least HP can tout 95% of the market. I would rather have 1% of something than 100% of nothing.
It's all about legacy software
NonStop supports a large number of legacy applications that have been evolving since the Tandem days, mostly in very conservative industries. It is extremely expensive to migrate this software, since NonStop supports a set of fine-grained checkpointing that is not available on Unix. The architecture of those applications depends on these features, so they cannot be "ported," but instead must be re-implemented starting from the architecture level. The users are therefor locked in, and HP can therefore make good money if they can provide NonStop on modern hardware. Sadly, this means Xeon.
This happened to both Unisys architectures, (Burroughs and UNiVAC,) both of which are sufficiently different from UNIX to make porting infeasible. It's not clear if this is also true of HPUX or VMS.
The NonStop architecture depends on fault identification features at the hardware level, some of which have only recently been added to the Xeons. This may be the reason that HP did not do this earlier.
[edit: this was meant to be a reply to another_vulture but my error detection mechanism didn't spot that I pressed the wrong button]
" if they can provide NonStop on modern hardware. Sadly, this means Xeon."
"The NonStop architecture depends on fault identification features at the hardware level, some of which have only recently been added to the Xeons. "
Details welcome. Tandem kit hasn't needed custom CPU chips for a long time (since before the MIPS CPU days?).
As I understood it, the heavyweight synchronisation and comparison stuff in recent years was done in off-CPU logic called the Logical Synchronisation Unit. It's hard (maybe even silly) to even think about instruction level synchronisation when modern high performance chips are all cache based, and are consequently subject to soft (recoverable) cache errors and other trivia which would rapidly destroy any hope of instruction level (or memory access level) synchronisation.
Synchronisation when the OS does an IO operation (or something conceptually similar) remains entirely practical (but not exactly simple).
"sufficiently different from UNIX to make porting infeasible. It's not clear if this is also true of ... VMS."
Those familiar with the VMS sources and the relevant history (and who are not hampered by the alleged ongoing non-disclosure agreements) suggest there is no overwhelming technical reason why a port of VMS to AMD64/x86-64 would not be sensible. Commercial/political factors are a different question. There have even been suggestions that a skunkworks/proof of concept AMD64 port existed briefly inside DEC (covered by ongoing NDA).
Equally, since HP earlier this year finally admitted that IA64 was dead, there has been talk of reviving an x86-64 port of VMS, but outside HP (since there are some customers who are more interested in VMS than HP are willing to acknowledge). Will it fly? Who knows. If it doesn't, it won't be because technical reasons blocked it.
"This may be the reason that HP did not do this earlier."
Someone important in HP/Intel bet something big on the success of IA64, whereas what they should have bet on was the continuing importance to customers of their investment in *software* -be it HP-UX, NSK, or VMS. That HP/Intel person lost that bet, that was plainly apparent years ago, and customers have been paying the price ever since. Finally HP are being forced to admit their stupidity.
Are there ANY benefits to Itanium/IA64 over the Xeons availible at this time? I'm asking about hardware here, not software support or porting issues. I have heard about Intel bringing Itanium features to Xeon, and I'm just wondering what is left? Is the only problem with Itanium the low clocks? high cost? Is the only thing keeping IA64 alive the software lock-in?
Re: Serious question
"Are there ANY benefits to Itanium/IA64 over the Xeons availible at this time?"
I'd love to hear the answers to that too. Let's see what turns up.
"Is the only problem with Itanium the low clocks? high cost?"
Afaict the actual VLIW disadvantages in real world applications outweigh the alleged benefits (which iirc were most beneficial in areas like HPC where program flow was in theory relatively predictable at compile time).
"Is the only thing keeping IA64 alive the software lock-in?"
Probably the software investment protection, the fact that both Nonstop and VMS arguably have some uniqueness in programming approach which cannot be replicated satisfactorily on other OSes (hardware is largely irrelevant), and most importantly, some senior idiot(s) at HP/Intel not wanting to admit they made a wrong decision ten or more years ago.
HP might almost have got away with it, except (1) IA64 isn't interesting of its own right, it's the software that can [only] run on IA64 that's interesting (2) the departure of Mark Hurd from HP and his arrival at Oracle and the subsequent court case exposed HP's (non-)commitment to IA64 in a rather inconveniet manner (and inconvenient time).
Until recently, IA64 would have had an advantage on paper at the really really really silly high end in terms of ultramassive memory single system image SMP systems - IA64 could in theory do more CPUs and more memory than you could get in a high end Proliant. Maybe three digits worth of CPUs on IA64 and a handful of TB of RAM. But that gap was decreasing with every generation of AMD64 that came out (and every generation of IA64 that didn't).
Whether this capability gap, or the lack of it, was ever relevant to any real customers (rather than just being brochureware) was never clear to me.
Re: Serious question
"it's the software that can [only] run on IA64 that's interesting"
For the avoidance of doubt, this should have read "it's the software that HP have dictated will only run on IA64 that's interesting". It's been clear for a long time, and this announcement makes it clearer still, that there are no insurmountable engineering reasons to prevent NonStop and VMS running on IA64.
Re: Serious question
Correction to the correction
"there are no insurmountable engineering reasons to prevent NonStop and VMS running on IA64. Or on x86. Only political reasons".
Matt's very quiet on this topic these days.
That is all.