[Info-vax] Poulson info from Dave Cantor

[John Wallace]

On Nov 17, 11:44 pm, JF Mezei <jfmezei.spam... at vaxination.ca> wrote:
> John Wallace wrote:
> > By the time you get to a system of that size you need a better OS than
> > Windows, and quite possibly a better OS than Linux too, depending on
> > needs. A few customers *might* also need more IO slots than Proliant
> > can provide.
>
> Is there a reason why an X86 based server can't have as much memory or
> bus slots compared to an IA64 based one ?
>
> I suspect that if HP were to announce EOL of IA64 tonight, by tomorrow
> morning, their web site would feature some 8086 servers that scale all
> the way up to what IA64 offered.
>
> IA64 started off as a preplacement for PA-Risc and then 32 bit 8086.
> When it eventually came out circa 2001/2002, the 8086 had gone through
> puberty and no longer needed a replacement, so IA64 was pitched as a HPC
> chip with RAS features. It naver made it to commodity PCs and soon was
> alaso widthdrawn from non-commodity PCs (aka: workstations).
>
> Now, the 8086 has the same RAS features (namely, the memory
> interconnect) and can also have the same boot console (EFI).  And IA64
> is no longer a contender in the HPC market.
>
> There isn't really much left as reasons/markets to justify the huge
> development costs.
>
> I guess HP makes enough money with HP-UX/Tandem/VMS systems to justify
> the continued subsidy to Intel. But wouldn't the profits be greater if
> they gave IA64 it coup de gr ce and moved HP-UX and Tandem to industry
> standard archittecture ?

"But wouldn't the profits be greater if they gave IA64 it coup de gr
ce and moved HP-UX and Tandem to industry
standard archittecture ?"

That's exactly the logic used to justify terminating the Alpha program
in favour of "industry standard 64bit architecture" IA64 (which we now
know turned out to be not industry standard at all).

If the logic was valid there in Alpha vs IA64, it's valid here in IA64
vs AMD64, give or take a difference in volume.

Note I'm not saying that it was the real reason Alpha development was
terminated; what went on inside HQ is something most of us can only
speculate about.

Anyway, put the technology to one side - as Arne says, there's no big
reason in principle and little visible reason in practice why a high
end AMD64-based system couldn't tomorrow do what a high end  IA64
system does today (evidence to the contrary would be most welcome); at
the lower end of the IA64 range the overlap is already considerable.

Instead, look at the basic financial logic. Intel continue to have to
pay for parallel (overlapping, competing, duplicating) x86-64  and
IA64 development teams for the CPU core even though they now have
massive overlap in the market they address. Those costs are doubtless
passed on to the sole significant IA64 customer, HPQ, who also
continue to have to pay for parallel Proliant and Integrity server
development teams even though again there is substantial hardware
overlap between Integrity and mid/high-end Proliant.

Integrity does already have massive-SMP capability beyond Proliant's
current 64 CPUs, and massive IO capability beyond what Proliant can do
today. How many customers (and how much revenue/profit) depends on
those capabilities (rather than depending on what HP/UX, Tandem/
NonStop, or VMS does for them)?

Would it be more cost effective to wind down the parallel development
and use the existing high-end engineering knowledge to expand Proliant
upwards a little (it's all QuickPath now whether it's IA64 or x86-64,
remember) or to continue the ongoing costs of the duplicated
development teams? In answering that question in the bigger picture,
the various impacts of yet another OS migration would also have to be
considered. Still, software engineering costs are lower now than they
were ten years ago, though whether the background knowledge of porting
the OSes to different hardware is still available is obviously moot.

Come back in 5 years and the picture might be clearer.