Discussion:
New Itanium I6 Article with Previous I4/I2 Specs Comparison
(too old to reply)
Kerry Main
2017-05-27 13:12:47 UTC
Permalink
Raw Message
Nice read .. includes history and current Intel Itanium I6 vs previous
I4/I2 comparisons.

The Last Itanium, At Long Last (May 23, 2017)
<https://www.nextplatform.com/2017/05/23/last-itanium-long-last/>

Based on the referenced I2/I4/I6 specs in this article, if you already
have I4 servers, then if looking for more compute power is the driver,
upgrading to I6 is likely not worth it.

If you have I2 or earlier Itanium servers, then upgrading to I6 would
likely provide a justifiable performance increase.

A few key extracts:

"During the course of the Itanium trial, we learned all kinds of things.
HP started a port of HP-UX to X86 chips and was even working on a big,
fat NUMA machine based on AMD Opteron processors, and then spiked it."

"Perhaps more interestingly, HPE is working on porting HP-UX to run atop
Linux containers on regular ProLiant Xeon servers. The company has some
experience in running emulated environments. Its "Aries" emulation
environment from many years ago allowed HP-UX binaries compiled for its
PA-RISC processors to run atop Itanium chips.

In the end, HP-UX will end up being just another Linux application, even
if it is a fat one wrapped around a database and application servers. In
fact, we would not be surprised if many HP-UX shops forego the Itanium
9700 upgrade and wait for these containers running on Xeon Skylake or
kicker systems."

Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Neil Rieck
2017-05-28 11:12:08 UTC
Permalink
Raw Message
On Saturday, May 27, 2017 at 9:15:05 AM UTC-4, Kerry Main wrote:
> Nice read .. includes history and current Intel Itanium I6 vs previous
> I4/I2 comparisons.
>
> The Last Itanium, At Long Last (May 23, 2017)
> <https://www.nextplatform.com/2017/05/23/last-itanium-long-last/>
>
> Based on the referenced I2/I4/I6 specs in this article, if you already
> have I4 servers, then if looking for more compute power is the driver,
> upgrading to I6 is likely not worth it.
>
> If you have I2 or earlier Itanium servers, then upgrading to I6 would
> likely provide a justifiable performance increase.
>
> A few key extracts:
>
> "During the course of the Itanium trial, we learned all kinds of things.
> HP started a port of HP-UX to X86 chips and was even working on a big,
> fat NUMA machine based on AMD Opteron processors, and then spiked it."
>
> "Perhaps more interestingly, HPE is working on porting HP-UX to run atop
> Linux containers on regular ProLiant Xeon servers. The company has some
> experience in running emulated environments. Its "Aries" emulation
> environment from many years ago allowed HP-UX binaries compiled for its
> PA-RISC processors to run atop Itanium chips.
>
> In the end, HP-UX will end up being just another Linux application, even
> if it is a fat one wrapped around a database and application servers. In
> fact, we would not be surprised if many HP-UX shops forego the Itanium
> 9700 upgrade and wait for these containers running on Xeon Skylake or
> kicker systems."
>
> Regards,
>
> Kerry Main
> Kerry dot main at starkgaming dot com

Thanks for this. I was waiting to see a real-world review of this product.

Neil Rieck
Waterloo, Ontario, Canada.
http://www3.sympatico.ca/n.rieck/
Snowshoe
2017-06-03 02:32:45 UTC
Permalink
Raw Message
On 5/27/2017 9:12 AM, Kerry Main wrote:
> Based on the referenced I2/I4/I6 specs in this article, if you already
> have I4 servers, then if looking for more compute power is the driver,
> upgrading to I6 is likely not worth it.
>
> If you have I2 or earlier Itanium servers, then upgrading to I6 would
> likely provide a justifiable performance increase.

What is the advantages of I6 over I4? It looks like the same clock
speeds, same number of cores, same cache. If, at some time in the
future, if you had to choose between, say, an rx2800 I4 or an rx2800 I6,
identical except for the CPU, why would one be better than the other?

> In the end, HP-UX will end up being just another Linux application, even
> if it is a fat one wrapped around a database and application servers. In
> fact, we would not be surprised if many HP-UX shops forego the Itanium
> 9700 upgrade and wait for these containers running on Xeon Skylake or
> kicker systems."

What does HP-UX have that the various Linuxes don't? What advantages
does it have over Red Hat or whatever? Other than the (dubious)
advantage of running on an Itanic.
Kerry Main
2017-06-03 13:07:21 UTC
Permalink
Raw Message
> -----Original Message-----
> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
> Snowshoe via Info-vax
> Sent: June 2, 2017 10:33 PM
> To: info-***@rbnsn.com
> Cc: Snowshoe <***@spam.please>
> Subject: Re: [Info-vax] New Itanium I6 Article with Previous I4/I2 Specs
> Comparison
>
> On 5/27/2017 9:12 AM, Kerry Main wrote:
> > Based on the referenced I2/I4/I6 specs in this article, if you already
> > have I4 servers, then if looking for more compute power is the driver,
> > upgrading to I6 is likely not worth it.
> >
> > If you have I2 or earlier Itanium servers, then upgrading to I6 would
> > likely provide a justifiable performance increase.
>
> What is the advantages of I6 over I4? It looks like the same clock
> speeds, same number of cores, same cache. If, at some time in the
> future, if you had to choose between, say, an rx2800 I4 or an rx2800 I6,
> identical except for the CPU, why would one be better than the other?
>

The only real differentiator between I4-I6 may (tbd) be small bit of pricing.

The bigger jump was from I2 to I4 series and that is where one could argue there is a justifiable performance increase worth investing in.

> > In the end, HP-UX will end up being just another Linux application,
> even
> > if it is a fat one wrapped around a database and application servers. In
> > fact, we would not be surprised if many HP-UX shops forego the
> Itanium
> > 9700 upgrade and wait for these containers running on Xeon Skylake or
> > kicker systems."
>
> What does HP-UX have that the various Linuxes don't? What advantages
> does it have over Red Hat or whatever? Other than the (dubious)
> advantage of running on an Itanic.
>

Being fair, one could argue that HP-UX does scale up better on a single server than Linux for those certain workloads that requires lpars, npars, dynamically transitioning cpu's among different HP-UX instances on the same server (aka Galaxy light) and large numbers of cores.

HP-UX has a very large installed base (many with highly customized HP-UX code) and HPE needed to fulfill an earlier promise to these Cust's to come out with an upgraded IA64 chip. For those HP-UX Cust's that are looking for short term performance increases and still on I2 systems (likely the majority btw), then moving to I6 is likely a good move for them.

Having stated this, HPE is aggressively pushing these HP-UX Cust's to move to RH Linux on X86-64 (HPE ProLiant server HW of course) and is offering different types of services to assist.

Fwiw, I do not believe HPE sees OS platforms as being a strategic offering for them in the future. They are headed back to their roots as a server/storage/network(?) / infrastructure company with enterprise level consulting services. In the near future, I expect HPE will also transition its NonStop Engineering support to a partner using the VSI OpenVMS model.

Btw, this is a good thing for both VSI/OpenVMS and NonStop customers.

😊


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
John Reagan
2017-06-04 11:26:11 UTC
Permalink
Raw Message
Also, HPUX (and NonStop) is a big endian platform. X86-64 Linux is little endian. That can sometimes be a porting problem if you have lots of existing binary data.
j***@yahoo.co.uk
2017-06-04 14:12:45 UTC
Permalink
Raw Message
On Sunday, 4 June 2017 12:26:14 UTC+1, John Reagan wrote:
> Also, HPUX (and NonStop) is a big endian platform. X86-64 Linux is little endian. That can sometimes be a porting problem if you have lots of existing binary data.

But but but...

NonStop now runs on x86 on fairly standard x86-64 hardware.
How does that work?

If anyone would like to know a bit more about how it works,
here's a very quick (4page) intro:
http://www.availabilitydigest.com/public_articles/1005/nonstop_x.pdf

One thing which helps is that the language+runtime environment
on NonStop is relatively limited, and when that is combined
with applications with explicit typing and no pointers ("pointers
considered harmful"?) then *in principle* the endianness problem
becomes more manageable.

Mind you, any applications that had a proper data-representation
layer (as per OSI model), vs IP-world sockets plus whatever
user library is popular for this week, was already half way
to solving the enddianness challenge decades ago. Also a long
way towards handling all those weird characters that 'foreign'
folks seem to want, and a few other related things too (EBCDIC?).

Have a lot of fun.
John Reagan
2017-06-04 20:38:03 UTC
Permalink
Raw Message
NonStop on X86-64 byte swaps all user data. It is in big endian in memory and little endian when moved to and from registers. Linker-generated addresses are BE, extra directives in assembler for both LE and BE data, etc

I was in charge of the backend before I left HP.

While COBOL might not have pointers, there are plenty in C, C++, and pTAL.

My comment was to why people might stick with HPUX on Itanium instead of jumping to Linux. Endian and HPUX specific applications.
j***@yahoo.co.uk
2017-06-04 21:19:05 UTC
Permalink
Raw Message
On Sunday, 4 June 2017 21:38:06 UTC+1, John Reagan wrote:
> NonStop on X86-64 byte swaps all user data. It is in big endian in memory and little endian when moved to and from registers. Linker-generated addresses are BE, extra directives in assembler for both LE and BE data, etc
>
> I was in charge of the backend before I left HP.
>
> While COBOL might not have pointers, there are plenty in C, C++, and pTAL.
>
> My comment was to why people might stick with HPUX on Itanium instead of jumping to Linux. Endian and HPUX specific applications.

Maybe I should have referred to "anonymous pointer" or
something like that, meaning a pointer to an item
whose datatype isn't clear to the compiler, and which
therefore can't necessarily reliably be byteswapped.
Strict typing would be helpful to avoid such cases.

It used to be great fun doing this kind of thing on
an RSX or VMS host when developing software and tools
for use with M68K targets, in languages without strict
typing. Or maybe it wasn't, it was a very long time ago.

Never mind, thanks for the additional info :)
Ian Miller
2017-06-13 13:07:47 UTC
Permalink
Raw Message
The important attribute of the i6 servers is not their potential performance, but the fact that they push the EOSL date for HPE Integrity servers further ahead by some years thus providing a period in which OpenVMS x86 can be proven and business critical applications migrated. The process of proving a platform and migrating to it takes years. HPE Integrity i6 servers provide something to run on during those years.
David Froble
2017-06-13 16:48:53 UTC
Permalink
Raw Message
Ian Miller wrote:
> The important attribute of the i6 servers is not their potential performance,
> but the fact that they push the EOSL date for HPE Integrity servers further
> ahead by some years thus providing a period in which OpenVMS x86 can be
> proven and business critical applications migrated. The process of proving a
> platform and migrating to it takes years. HPE Integrity i6 servers provide
> something to run on during those years.

That sounds reasonable, at first.

How long is it going to take to "prove" the i6 servers?

For me, I cannot wait to sink the itanic and get onto x86. Not because I like
x86, because I dislike the itanic, and, the itanic has no future.

Much better to support VSI as soon as possible.
Bob Gezelter
2017-06-13 16:57:39 UTC
Permalink
Raw Message
On Tuesday, June 13, 2017 at 9:07:49 AM UTC-4, Ian Miller wrote:
> The important attribute of the i6 servers is not their potential performance, but the fact that they push the EOSL date for HPE Integrity servers further ahead by some years thus providing a period in which OpenVMS x86 can be proven and business critical applications migrated. The process of proving a platform and migrating to it takes years. HPE Integrity i6 servers provide something to run on during those years.

Ian,

The EOSL issue is worth noting with respect to hardware. Based upon experience of the last two ports (VAX->Alpha; Alpha->Itanium), I would expect the OpenVMS-x64 to go even more smoothly than its predecessors.

In fact, the biggest delay may be accounting and qualification. Some organizations will have to wait for depreciation, others have extensive qualification procedures (which, as a preamble) which require a production-quality OS base.

- Bob Gezelter, http://www.rlgsc.com
abrsvc
2017-06-14 10:52:43 UTC
Permalink
Raw Message
On Tuesday, June 13, 2017 at 12:57:40 PM UTC-4, Bob Gezelter wrote:

> The EOSL issue is worth noting with respect to hardware. Based upon experience of the last two ports (VAX->Alpha; Alpha->Itanium), I would expect the OpenVMS-x64 to go even more smoothly than its predecessors.
>
> In fact, the biggest delay may be accounting and qualification. Some organizations will have to wait for depreciation, others have extensive qualification procedures (which, as a preamble) which require a production-quality OS base.
>
> - Bob Gezelter, http://www.rlgsc.com

Add to that the validation and certification suites required for most medical applications. This too can add significant cost and time. Note: I know of two clients that are continuing to use Alpha hardware delaying the "port" until the X86 becomes reality. The port to Itanium has been completed and tested but not certified (a much more intensive testing suite). Since the certification process is expensive, they are choosing to wait and do it once with the x86 platform.

Dan
Jan-Erik Soderholm
2017-06-14 12:09:43 UTC
Permalink
Raw Message
Den 2017-06-14 kl. 12:52, skrev abrsvc:
> On Tuesday, June 13, 2017 at 12:57:40 PM UTC-4, Bob Gezelter wrote:
>
>> The EOSL issue is worth noting with respect to hardware. Based upon
>> experience of the last two ports (VAX->Alpha; Alpha->Itanium), I would
>> expect the OpenVMS-x64 to go even more smoothly than its
>> predecessors.
>>
>> In fact, the biggest delay may be accounting and qualification. Some
>> organizations will have to wait for depreciation, others have
>> extensive qualification procedures (which, as a preamble) which
>> require a production-quality OS base.
>>
>> - Bob Gezelter, http://www.rlgsc.com
>
> Add to that the validation and certification suites required for most
> medical applications. This too can add significant cost and time.
> Note: I know of two clients that are continuing to use Alpha hardware
> delaying the "port" until the X86 becomes reality.

Same here at my client. *If* we would port from Alpha at all, it will
most likely not be to Itanium. I do not expect a lot of VMS users
going for i6 *today*, if you aren't at the very top of the
performance of your i2 or i4 systems.

> The port to Itanium
> has been completed and tested but not certified (a much more intensive
> testing suite). Since the certification process is expensive, they are
> choosing to wait and do it once with the x86 platform.
>
> Dan
>
Michael Moroney
2017-06-14 15:42:42 UTC
Permalink
Raw Message
What was the advantage to HPE for coming out with I6? It was a shrink,
but a shrink using a shrink of a couple cycles ago, plus they didn't
increase the clock speed or cache or anything. Just so they could say
"The Itanic is still above water!" or "New! Improved!!" (when it isn't) ?
Neil Rieck
2017-06-14 18:05:50 UTC
Permalink
Raw Message
On Wednesday, June 14, 2017 at 11:42:43 AM UTC-4, Michael Moroney wrote:
> What was the advantage to HPE for coming out with I6? It was a shrink,
> but a shrink using a shrink of a couple cycles ago, plus they didn't
> increase the clock speed or cache or anything. Just so they could say
> "The Itanic is still above water!" or "New! Improved!!" (when it isn't) ?

The original chart does seem a bit confusing.
https://www.nextplatform.com/2017/05/23/last-itanium-long-last/

Comparing the bottom two Poulson chips with Kittson shows no improvement at all except for the fact that Turbo Boost is enabled in Kittson. Then the text after the chart reads:

Quote: As you can see, the Poulsons are really a deep bin sort of the Poulsons, with the Turbo Boost overclocking enabled. This is not really a tick or a tock, in the Intel parlance. But if HPE is not making a fuss about what HP and its customers were promised so many years ago, it doesn’t much matter.

Question: did he mean to say "the Kittsons are really a deep bin sort of the Poulsons, with the Turbo Boost overclocking enabled"?

###

On a related note, my rx2800 appears to be running a single Tukwila 9340 with 20 MB of cache and 4 cores. Not sure if I need to compare this with the Poulson 9520 or 9550 but you can see the "raw clock" number jump from my 6.4 GHz to 6.8 and 9.6 respectively.

Then when you compare those Poulson chips to their Kittson counterparts, the "raw clock" numbers are 6.8 (no change) and 10 (barely a change). So it does appear that Kittson was released in this form just to save face.

Neil Rieck
Waterloo, Ontario, Canada.
http://www3.sympatico.ca/n.rieck/

p.s. We cut-over our rx2800 on 2016-02-14 and it has behaved spectacularly.

OpenVMS V8.4 on node KAWC90 14-JUN-2017 14:04:43.53 Uptime 486 03:40:15
Pid Process Name State Pri I/O CPU Page flts Pages
00000101 SWAPPER HIB 16 0 0 03:33:54.15 0 4
000C2203 APACHE$SWS0015 LEF 3 5118 0 00:00:01.85 1124 1396
David Froble
2017-06-14 19:08:40 UTC
Permalink
Raw Message
Neil Rieck wrote:
> On Wednesday, June 14, 2017 at 11:42:43 AM UTC-4, Michael Moroney wrote:
>> What was the advantage to HPE for coming out with I6? It was a shrink,
>> but a shrink using a shrink of a couple cycles ago, plus they didn't
>> increase the clock speed or cache or anything. Just so they could say
>> "The Itanic is still above water!" or "New! Improved!!" (when it isn't) ?
>
> The original chart does seem a bit confusing.
> https://www.nextplatform.com/2017/05/23/last-itanium-long-last/
>
> Comparing the bottom two Poulson chips with Kittson shows no improvement at all except for the fact that Turbo Boost is enabled in Kittson. Then the text after the chart reads:
>
> Quote: As you can see, the Poulsons are really a deep bin sort of the Poulsons, with the Turbo Boost overclocking enabled. This is not really a tick or a tock, in the Intel parlance. But if HPE is not making a fuss about what HP and its customers were promised so many years ago, it doesn’t much matter.
>
> Question: did he mean to say "the Kittsons are really a deep bin sort of the Poulsons, with the Turbo Boost overclocking enabled"?
>
> ###
>
> On a related note, my rx2800 appears to be running a single Tukwila 9340 with 20 MB of cache and 4 cores. Not sure if I need to compare this with the Poulson 9520 or 9550 but you can see the "raw clock" number jump from my 6.4 GHz to 6.8 and 9.6 respectively.
>
> Then when you compare those Poulson chips to their Kittson counterparts, the "raw clock" numbers are 6.8 (no change) and 10 (barely a change). So it does appear that Kittson was released in this form just to save face.
>
> Neil Rieck
> Waterloo, Ontario, Canada.
> http://www3.sympatico.ca/n.rieck/
>
> p.s. We cut-over our rx2800 on 2016-02-14 and it has behaved spectacularly.
>
> OpenVMS V8.4 on node KAWC90 14-JUN-2017 14:04:43.53 Uptime 486 03:40:15
> Pid Process Name State Pri I/O CPU Page flts Pages
> 00000101 SWAPPER HIB 16 0 0 03:33:54.15 0 4
> 000C2203 APACHE$SWS0015 LEF 3 5118 0 00:00:01.85 1124 1396
>

Well, that's what process shrinks, faster clock, and gobs of memory can do for you.

Alpha is now over 25 years old. It was planned to be usable for those 25 years.
Got to consider it successful, from that perspective.

The question I have is, which semiconductor company will be designing the next
"new" processor? When there was competition, such was happening. It's sort of
depressing to think of x86 as being an eternal design ....
Arne Vajhøj
2017-06-14 19:20:01 UTC
Permalink
Raw Message
On 6/14/2017 3:08 PM, David Froble wrote:
> The question I have is, which semiconductor company will be designing
> the next "new" processor? When there was competition, such was
> happening. It's sort of depressing to think of x86 as being an eternal
> design ....

The only current design that may have a chance is ARM.

And it is a market with huge barriers to entry.

Arne
Paul Sture
2017-06-14 20:46:36 UTC
Permalink
Raw Message
On 2017-06-14, David Froble <***@tsoft-inc.com> wrote:
>
> Alpha is now over 25 years old. It was planned to be usable for those
> 25 years. Got to consider it successful, from that perspective.
>
> The question I have is, which semiconductor company will be designing
> the next "new" processor? When there was competition, such was
> happening. It's sort of depressing to think of x86 as being an
> eternal design ....

ARM seems to be the competition for the future. Please note that ARM
isn't a manufacturer, it licenses designs to the large semiconductor
manufacturers, who then crank out the product.

<https://en.wikipedia.org/wiki/ARM_architecture>

"British company ARM Holdings develops the architecture and licenses it
to other companies, who design their own products that implement one of
those architectures‍—‌including systems-on-chips (SoC) and
systems-on-modules (SoM) that incorporate memory, interfaces, radios,
etc. It also designs cores that implement this instruction set and
licenses these designs to a number of companies that incorporate those
core designs into their own products."

From reading elsewhere, I gather that these designs are produced in a
machine-readable format which is useable by the semiconductor
manufacturers' production lines.

and

"With over 100 billion ARM processors produced as of 2017, ARM is the
most widely used instruction set architecture in terms of quantity
produced."

ARM obviously has Intel worried:

<https://www.theregister.co.uk/2017/06/09/intel_sends_arm_a_shot_across_bow/>

"[Intel] ... said it would not hesitate to sic its lawyers on any
competitor whose emulation tools got too close to copying the patented
portions of its x86 instruction set architecture (ISA)."

--
Everybody has a testing environment. Some people are lucky enough to
have a totally separate environment to run production in.
Stephen Hoffman
2017-06-14 21:34:26 UTC
Permalink
Raw Message
On 2017-06-14 20:46:36 +0000, Paul Sture said:

> From reading elsewhere, I gather that these designs are produced in a
> machine-readable format which is useable by the semiconductor
> manufacturers' production lines.

https://alastairreid.github.io/alastairreid.github.io/ARM-v8a-xml-release/



--
Pure Personal Opinion | HoffmanLabs LLC
David Froble
2017-06-14 22:05:46 UTC
Permalink
Raw Message
Paul Sture wrote:
> On 2017-06-14, David Froble <***@tsoft-inc.com> wrote:
>> Alpha is now over 25 years old. It was planned to be usable for those
>> 25 years. Got to consider it successful, from that perspective.
>>
>> The question I have is, which semiconductor company will be designing
>> the next "new" processor? When there was competition, such was
>> happening. It's sort of depressing to think of x86 as being an
>> eternal design ....
>
> ARM seems to be the competition for the future. Please note that ARM
> isn't a manufacturer, it licenses designs to the large semiconductor
> manufacturers, who then crank out the product.
>
> <https://en.wikipedia.org/wiki/ARM_architecture>
>
> "British company ARM Holdings develops the architecture and licenses it
> to other companies, who design their own products that implement one of
> those architectures‍—‌including systems-on-chips (SoC) and
> systems-on-modules (SoM) that incorporate memory, interfaces, radios,
> etc. It also designs cores that implement this instruction set and
> licenses these designs to a number of companies that incorporate those
> core designs into their own products."
>
> From reading elsewhere, I gather that these designs are produced in a
> machine-readable format which is useable by the semiconductor
> manufacturers' production lines.
>
> and
>
> "With over 100 billion ARM processors produced as of 2017, ARM is the
> most widely used instruction set architecture in terms of quantity
> produced."
>
> ARM obviously has Intel worried:
>
> <https://www.theregister.co.uk/2017/06/09/intel_sends_arm_a_shot_across_bow/>
>
> "[Intel] ... said it would not hesitate to sic its lawyers on any
> competitor whose emulation tools got too close to copying the patented
> portions of its x86 instruction set architecture (ISA)."
>

Now, I'm just a dumb polock, come down out of the hills, but it's my impression
that ARM targets the low end commodity market. Could be wrong.

What I was referring to is the same targets Alpha was aimed at, ie; super
performance, the CPU of "the future".
Arne Vajhøj
2017-06-15 00:55:44 UTC
Permalink
Raw Message
On 6/14/2017 6:05 PM, David Froble wrote:
> Paul Sture wrote:
>> On 2017-06-14, David Froble <***@tsoft-inc.com> wrote:
>>> Alpha is now over 25 years old. It was planned to be usable for those
>>> 25 years. Got to consider it successful, from that perspective.
>>>
>>> The question I have is, which semiconductor company will be designing
>>> the next "new" processor? When there was competition, such was
>>> happening. It's sort of depressing to think of x86 as being an
>>> eternal design ....
>>
>> ARM seems to be the competition for the future.

>> "With over 100 billion ARM processors produced as of 2017, ARM is the
>> most widely used instruction set architecture in terms of quantity
>> produced."

> Now, I'm just a dumb polock, come down out of the hills, but it's my
> impression that ARM targets the low end commodity market. Could be wrong.
>
> What I was referring to is the same targets Alpha was aimed at, ie;
> super performance, the CPU of "the future".

You are absolutely right ARM is targeting phones and other low end
commodity markets.

But let us go back 20-25 years. What was status back then?

SPARC, Power, Alpha etc. was targeting the super performance
market.

x86 (later evolving into x86-64) was targeting low end
commodity markets (PC's).

Did SPARC/Power/Alpha kill x86 or did x86 kill SPARC/Power/Alpha?

(well SPARC and Power is not dead yet but close to gettting
into intensive care)

ARM is right where they should be to be serious competitor!

Arne
David Froble
2017-06-15 04:40:16 UTC
Permalink
Raw Message
Arne Vajhøj wrote:
> On 6/14/2017 6:05 PM, David Froble wrote:
>> Paul Sture wrote:
>>> On 2017-06-14, David Froble <***@tsoft-inc.com> wrote:
>>>> Alpha is now over 25 years old. It was planned to be usable for those
>>>> 25 years. Got to consider it successful, from that perspective.
>>>>
>>>> The question I have is, which semiconductor company will be designing
>>>> the next "new" processor? When there was competition, such was
>>>> happening. It's sort of depressing to think of x86 as being an
>>>> eternal design ....
>>>
>>> ARM seems to be the competition for the future.
>
>>> "With over 100 billion ARM processors produced as of 2017, ARM is the
>>> most widely used instruction set architecture in terms of quantity
>>> produced."
>
>> Now, I'm just a dumb polock, come down out of the hills, but it's my
>> impression that ARM targets the low end commodity market. Could be
>> wrong.
>>
>> What I was referring to is the same targets Alpha was aimed at, ie;
>> super performance, the CPU of "the future".
>
> You are absolutely right ARM is targeting phones and other low end
> commodity markets.
>
> But let us go back 20-25 years. What was status back then?
>
> SPARC, Power, Alpha etc. was targeting the super performance
> market.
>
> x86 (later evolving into x86-64) was targeting low end
> commodity markets (PC's).

At the time the volume was in desktop PCs. Could they do everything? No, but,
they sure could be cheap.

DEC thought they had to get Alpha into PCs, or something like that. Did they
really? Not so sure. But, their choices, and the changing computing
environment, and lack of vision, and other things, did DEC in.

> Did SPARC/Power/Alpha kill x86 or did x86 kill SPARC/Power/Alpha?

IBM took a different course, and Power is still with us, and is top of the line.
It will never have the volume x86 had at one time. I don't think x86 on the
desktop still has the market it once had. Not too many XEONs and Opterons in
desktops.

I don't feel that it's the CPU designs, nearly as much as the companies making
them. Look at Intel. Look at their dedication to the itanic. Then look at
IBM, knowing they need a better CPU to differentiate themselves, and they have
the dedication to stay the course. If you want to talk about "killing", talk
about management, not design.

> (well SPARC and Power is not dead yet but close to gettting
> into intensive care)

Some people have been saying that for a long time. Don't know about Sparc, but
I'm thinking Power will be around for some time yet.

> ARM is right where they should be to be serious competitor!

In what market?
Simon Clubley
2017-06-15 12:31:47 UTC
Permalink
Raw Message
On 2017-06-15, David Froble <***@tsoft-inc.com> wrote:
> Arne Vajhøj wrote:
>> ARM is right where they should be to be serious competitor!
>
> In what market?

Right now, anything from a small 8 pin DIP device (Cortex-M0) running
at several 10s of MHz and with a few kilobytes of flash and SRAM right
up to GHz class server capable MCUs.

ARM literally have an option for everything within those two boundaries.

I'm much more familiar with the embedded class ARM MCUs, but this is an
article I just found dated about a year ago that gives you an idea of
where things are moving at the top end of the ARM ecosystem:

https://www.theregister.co.uk/2016/01/14/amd_arm_seattle_launch/

Basically, sometimes your servers do not need to be the latest
supercomputers.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Arne Vajhøj
2017-06-15 12:54:48 UTC
Permalink
Raw Message
On 6/15/2017 12:40 AM, David Froble wrote:
> Arne Vajhøj wrote:
>> On 6/14/2017 6:05 PM, David Froble wrote:
>>> Now, I'm just a dumb polock, come down out of the hills, but it's my
>>> impression that ARM targets the low end commodity market. Could be
>>> wrong.
>>>
>>> What I was referring to is the same targets Alpha was aimed at, ie;
>>> super performance, the CPU of "the future".
>>
>> You are absolutely right ARM is targeting phones and other low end
>> commodity markets.
>>
>> But let us go back 20-25 years. What was status back then?
>>
>> SPARC, Power, Alpha etc. was targeting the super performance
>> market.
>>
>> x86 (later evolving into x86-64) was targeting low end
>> commodity markets (PC's).
>
> At the time the volume was in desktop PCs. Could they do everything?
> No, but, they sure could be cheap.
>
> DEC thought they had to get Alpha into PCs, or something like that. Did
> they really? Not so sure. But, their choices, and the changing
> computing environment, and lack of vision, and other things, did DEC in.
>
>> Did SPARC/Power/Alpha kill x86 or did x86 kill SPARC/Power/Alpha?
>
> IBM took a different course, and Power is still with us, and is top of
> the line.

Top of the line performance/socket.

Low performance/dollar and shrinking market share.

> It will never have the volume x86 had at one time. I don't
> think x86 on the desktop still has the market it once had. Not too many
> XEONs and Opterons in desktops.

Doesn't matter. Intel and AMD can reuse designs and fabs between desktop
and server CPU's.

> I don't feel that it's the CPU designs, nearly as much as the companies
> making them. Look at Intel. Look at their dedication to the itanic.
> Then look at IBM, knowing they need a better CPU to differentiate
> themselves, and they have the dedication to stay the course. If you
> want to talk about "killing", talk about management, not design.

It is not design.

Management may have some importance.

But by far the most important driver is economics.

CPU production has huge fixed cost and low variable cost.

That favors high volume production.

>> (well SPARC and Power is not dead yet but close to gettting
>> into intensive care)
>
> Some people have been saying that for a long time. Don't know about
> Sparc, but I'm thinking Power will be around for some time yet.

Around yes.

Thriving no.

Itanic 10-20 years delayed.

>> ARM is right where they should be to be serious competitor!
>
> In what market?

The volume market that can fund crazy expensive investments.

They sell billions of CPU's every year for phones and
other stuff.

That could very likely fund going after the server market.

Just like the home PC's funded Intel and AMD taking over the
server market 20 years ago.

Arne
John Wallace
2017-06-15 15:58:01 UTC
Permalink
Raw Message
On 15/06/2017 05:40, David Froble wrote:
> Arne Vajhøj wrote:
>> On 6/14/2017 6:05 PM, David Froble wrote:
>>> Paul Sture wrote:
>>>> On 2017-06-14, David Froble <***@tsoft-inc.com> wrote:
>>>>> Alpha is now over 25 years old. It was planned to be usable for those
>>>>> 25 years. Got to consider it successful, from that perspective.
>>>>>
>>>>> The question I have is, which semiconductor company will be designing
>>>>> the next "new" processor? When there was competition, such was
>>>>> happening. It's sort of depressing to think of x86 as being an
>>>>> eternal design ....
>>>>
>>>> ARM seems to be the competition for the future.
>>
>>>> "With over 100 billion ARM processors produced as of 2017, ARM is the
>>>> most widely used instruction set architecture in terms of quantity
>>>> produced."
>>
>>> Now, I'm just a dumb polock, come down out of the hills, but it's my
>>> impression that ARM targets the low end commodity market. Could be
>>> wrong.
>>>
>>> What I was referring to is the same targets Alpha was aimed at, ie;
>>> super performance, the CPU of "the future".
>>
>> You are absolutely right ARM is targeting phones and other low end
>> commodity markets.
>>
>> But let us go back 20-25 years. What was status back then?
>>
>> SPARC, Power, Alpha etc. was targeting the super performance
>> market.
>>
>> x86 (later evolving into x86-64) was targeting low end
>> commodity markets (PC's).
>
> At the time the volume was in desktop PCs. Could they do everything?
> No, but, they sure could be cheap.

Commodity PCs could appear cheap to buy. Business-class PCs with a
lifecycle of more than a couple of months cost a bit more.

>
> DEC thought they had to get Alpha into PCs, or something like that. Did
> they really? Not so sure. But, their choices, and the changing
> computing environment, and lack of vision, and other things, did DEC in.


Did you try doing a price comparison between volume orders for
business-class desktop PCs and a comparable desktop Alpha system,
e.g. in the late 1990s? I did.

E.g. in the Personal Workstation range, based on industry standard
NLX-format boards, with the processor on a daughtercard, you could
have either an x86 system or an Alpha EV5 system, with
surprisingly small price difference (because everything except the
processor card was the same), and (for certain applications)
there was a very worthwhile performance benefit on the Alpha.

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

One such application was converting PostScript to bitmap for
professional printshops (then known as Raster Image Processing).
Performance and reliability were key, and NT/Alpha was a good fit
especially with the PWS range (which, for those willing to pay
the price premium for the same basic hardware, would also run VMS
or Tru64).

Then MS and Intel effectively pulled the plug on NT/Alpha and
suddenly there wasn't much future for NT/Alpha anywhere. And that
and a few other Intel/MS-related management issues meant that
there wasn't much of a future for Alpha anywhere.

>
>> Did SPARC/Power/Alpha kill x86 or did x86 kill SPARC/Power/Alpha?
>
> IBM took a different course, and Power is still with us, and is top of
> the line. It will never have the volume x86 had at one time. I don't
> think x86 on the desktop still has the market it once had. Not too many
> XEONs and Opterons in desktops.
>
> I don't feel that it's the CPU designs, nearly as much as the companies
> making them. Look at Intel. Look at their dedication to the itanic.

Intel were only dedicated to the Itanic till AMD64 came along and
showed that, contrary to Intel's public claims, x86-64 wasn't
impossible. Once AMD64 made x86-64 go public, and AMD64 scalability
showed that it was ready for what most people called "enterprise
class" systems, the limited future of IA64 was clear.

> Then look at IBM, knowing they need a better CPU to differentiate
> themselves, and they have the dedication to stay the course. If you
> want to talk about "killing", talk about management, not design.
>
>> (well SPARC and Power is not dead yet but close to gettting
>> into intensive care)
>
> Some people have been saying that for a long time. Don't know about
> Sparc, but I'm thinking Power will be around for some time yet.
>
>> ARM is right where they should be to be serious competitor!
>
> In what market?

ARM has been in (and often dominated) most volume markets where
Windows/x86 isn't a requirement. For most of those markets,
customers (who are not end users) can get almost everything the
system needs, all on one chip (processor, memory, IO, etc) -
this is what the industry calls 'system on chip', aka SoC.


ARM works everywhere, from the electronics on your disk drive, to
your smart TV, to your SoHo network gear. Oh, and mobile phones
and tablets and almost every other piece of kit with a computer
inside, so long as it doesn't need to run Wintel software native.

Legacy x86 designs are reliant on revenue from volume desktop
and notebook chip designs (which largely don't sell anywhere
else) to make lower-volume high end x86 chips affordable. As
the relevance of desktop and notebook designs decreases, and
the non-recurring costs of high end x86 designs increase,
the end user cost per high end x86 CPU will necessarily
increase - just as it did for Alpha.

Intel still haven't succeeded in doing SoC in volume, not
least because Intel can't do cheap x86. If they do cheap
x86 with reasonable performance they're just undercutting
their higher-end prices anwyay. For a while they tried to
hide the pricing impact of this by subsidising their SoC
products, but once it became obvious, they had to re-organise
the company accounts to keep it hidden. Look for 'contra
revenue' articles, e.g.
https://www.cnet.com/uk/news/behind-in-tablets-intel-pays-firms-to-use-its-chips/

In addition to those pricing issues, it's recently emerged
that some of Intel's SoC designs (specifically, Intel Atom
C2000 products based on new-to-Intel Finfet fabrication
technology) in routers, NAS boxes, etc, have had life-limiting
reliability issues after a few months, and it's been hushed
up:
https://www.theregister.co.uk/2017/02/07/intel_atom_failures_go_back_18_months/


Intel are not done yet though, especially given last year's
unforeseen purchase of ARM by Japan's Softbank, and earlier
this year there was talk of Softbank selling a quarter of
ARM to Middle Eastern investors...
David Froble
2017-06-15 20:42:42 UTC
Permalink
Raw Message
Got off topic more than a bit, with history and such.

My question was about the future. Will there be a new, better, processor
design, ever again? Some of the companies that might have done this aren't
around anymore.

Or, in 300 years, will x86 still be in use?
Stephen Hoffman
2017-06-15 22:15:23 UTC
Permalink
Raw Message
On 2017-06-15 20:42:42 +0000, David Froble said:

> Got off topic more than a bit, with history and such.
>
> My question was about the future. Will there be a new, better,
> processor design, ever again? Some of the companies that might have
> done this aren't around anymore.
>
> Or, in 300 years, will x86 still be in use?

New processor designs are certainly feasible. There've been rather
more designs available than there've been successes, too. As for
alternatives beyond SPARC or POWER, there's been more than a little
investment in Loongson (龙芯) (MIPS64), for instance. RISC-V is a new
design that looks interesting to various folks, too. Where any of
that gets to? Getting to market with the necessary support and with
enough volume takes deep pockets and a decade or more. VSI is in a
similar situation, though with a larger installed base than most
startups launch with. Much like supplementing (maybe eventually
replacing?) gasoline stations with electric vehicle charging stations,
or replacing automobiles in the US with some other form of conveyance,
or some other fundamental shift, this stuff gets adopted or built or
purchased very slowly for many years, and then — maybe, if there's then
some particularly compelling reason to shift — much more quickly as
it's more widely adopted. As for the future and given we're ~ten
years past iPhone, things in computing can change slowly for a while
and get into a particular state and markets can then shift very
quickly. What happens with processor designs and new vendors over the
next decades or the next centuries? No sé. Nadie sabe. Nobody knows.

https://www.youtube.com/watch?v=Ctin21yrfcA


--
Pure Personal Opinion | HoffmanLabs LLC
Stephen Hoffman
2017-06-15 15:27:58 UTC
Permalink
Raw Message
On 2017-06-14 22:05:46 +0000, David Froble said:

> ...but it's my impression that ARM targets the low end commodity
> market. Could be wrong.
>
> What I was referring to is the same targets Alpha was aimed at, ie;
> super performance, the CPU of "the future".

The performance[1] of ARM AArch64 systems is pretty good in comparison
to that of mobile x86-64 processors.

But then OpenVMS hasn't been at the high-end of performance in most of
twenty years. Arguably, probably not anywhere near the top of the heap
since the VAX era. OpenVMS never saw native boot support on the
top-end Integrity SuperDome 2 servers, for that matter.

That written, there are folks[2][3] that think ARM processors do have
sufficient performance capabilities for their servers.

There are and have been processors faster than x86-64. POWER8, for
instance. Probably have been faster options, as x86 seemingly never
reached the top of the performance heap. But then low prices and
good-enough are a pretty powerful combination in the computing market.
Lower prices and good-enough products that have managed to get into
volume have crept up underneath more than a few entrenched vendors,
too. Any of these hardware transitions can take a decade or more to
really get rolling, then things start to get interesting for the
competitors. Alpha and Itanium never got to sufficient production
volume to get the prices down and the volume further up. Alpha and
Itanium were more than good enough to compete, but were also competing
from the high-end and with higher prices.

There are hosting providers offering ARM servers, as well. Scaleway is
one that's been offering and marketing ARMv7 and ARMv8 (AArch64)
hosting for a while, and there are others.

VSI is doing the right thing with the x86-64 port. Any discussions of
porting over to ARM — VSI has mentioned ARM in some of their early
presentations — are arguably premature, too. At least until ARM
servers are more common and established and SBSA[4] and SBBR[5][6]
becomes more ubiquitous and entrenched among the available servers.
Those ARM AArch64 servers — or some longer-shot processor and platform
such as RISC V — won't matter to VSI for some years; not once VSI have
an established and stable x86-64-based OpenVMS product. Not unless
some customer writes a porting request in the notes section of a bank
transfer with a whole lot of zeros, that is.


[1] http://barefeats.com/ipadpro2017.html
[2]
http://www.datacenterknowledge.com/archives/2017/03/13/arm-servers-can-soon-power-half-of-microsoft-data-center-muscle/

[3]
https://www.nextplatform.com/2016/06/23/inside-japans-future-exaflops-arm-supercomputer/

[4] https://github.com/ARM-software/sbsa-acs
[5]
http://infocenter.arm.com/help/topic/com.arm.doc.den0044b/DEN0044B_Server_Base_Boot_Requirements.pdf

[6]
http://www.uefi.org/sites/default/files/resources/S4_BldgARMServers_UEFILinuxCon_FINAL_Aug.%2021.pdf



--
Pure Personal Opinion | HoffmanLabs LLC
Bob Koehler
2017-06-15 20:49:07 UTC
Permalink
Raw Message
In article <ohur98$8k4$***@dont-email.me>, David Froble <***@tsoft-inc.com> writes:
> Got off topic more than a bit, with history and such.
>
> My question was about the future. Will there be a new, better, processor
> design, ever again? Some of the companies that might have done this aren't
> around anymore.
>
> Or, in 300 years, will x86 still be in use?

In 300 years, if the governemnts of the free workd keep using
MicroSoft, we'll all be dead.
Jan-Erik Soderholm
2017-06-15 21:15:55 UTC
Permalink
Raw Message
Den 2017-06-15 kl. 22:49, skrev Bob Koehler:
> In article <ohur98$8k4$***@dont-email.me>, David Froble <***@tsoft-inc.com> writes:
>> Got off topic more than a bit, with history and such.
>>
>> My question was about the future. Will there be a new, better, processor
>> design, ever again? Some of the companies that might have done this aren't
>> around anymore.
>>
>> Or, in 300 years, will x86 still be in use?
>
> In 300 years, if the governemnts of the free workd keep using
> MicroSoft, we'll all be dead.
>

If current governments keep on as today, we are lost.
It is not an issue about Microsoft or not, of course.
Just silly...
Arne Vajhøj
2017-06-14 19:07:07 UTC
Permalink
Raw Message
On 6/14/2017 11:42 AM, Michael Moroney wrote:
> What was the advantage to HPE for coming out with I6? It was a shrink,
> but a shrink using a shrink of a couple cycles ago, plus they didn't
> increase the clock speed or cache or anything. Just so they could say
> "The Itanic is still above water!" or "New! Improved!!" (when it isn't) ?

Probably. It sends a signal about effort still being put in.

And no matter how subtle a change it is "new".

Most car manufactures put out so called facelifted models
frequently.

Arne
Craig A. Berry
2017-06-16 03:42:51 UTC
Permalink
Raw Message
On 6/14/17 7:09 AM, Jan-Erik Soderholm wrote:

> *If* we would port from Alpha at all, it will
> most likely not be to Itanium. I do not expect a lot of VMS users
> going for i6 *today*, if you aren't at the very top of the
> performance of your i2 or i4 systems.

You're forgetting or ignoring the fact that most people with the
technical wherewithal to do a port did so a decade or more ago and now
have aging Itanium hardware that needs replacement. Where I work, we
moved to Itanium eight years ago and it seemed to me at the time that we
were towards the end of the curve.

Of course servers can operate for longer than a decade, but generally
require increasingly frequent downtime for even relatively minor things
like the odd DIMM that went bad or RAID cache battery that needs
replacement. On the one hand, it might make sense to nurse the old beast
along for a couple more years and move to OpenVMS X64 without buying any
more Itaniums, but on the other hand, OpenVMS X64 was two years in the
future three years ago and is still two years in the future now. I
believe Hoff said something once about jumping from a burning ship onto
one that hadn't been built yet.

Then there is the fact that regardless of what chip is in it, a new line
of Integrity servers just might have a console to which one can connect
without downgrading or disabling secure connection methods. Such is not
the case for many existing Integrity servers that are no longer getting
firmware upgrades.

Also not mentioned in this i6 thread so far is that process shrinks
generally reduce power consumption, which is important to a lot of
people. I have not seen (nor looked for) power consumption figures, but
if there's a noticeable difference, that would certainly be a consideration.

In short, there might be a lot of reasons people need new Itanium
hardware in the next year or two. They might in many cases be better
served by looking for a good deal on i4 hardware than paying for i6, but
at least there is something new that can be had for those who need it.
Stephen Hoffman
2017-06-16 21:59:27 UTC
Permalink
Raw Message
On 2017-06-16 03:42:51 +0000, Craig A. Berry said:

> ...most people with the technical wherewithal to do a port did so a
> decade or more ago and now have aging Itanium hardware that needs
> replacement. Where I work, we moved to Itanium eight years ago and it
> seemed to me at the time that we were towards the end of the curve.

We don't build'm like we used to. And in many ways, that's a good thing.

> I believe Hoff said something once about jumping from a burning ship
> onto one that hadn't been built yet.

That sinking ship quote likely wasn't one of mine:
https://groups.google.com/d/msg/comp.os.vms/fGwg0mZlMqA/7f8Dj0eeagwJ

> Then there is the fact that regardless of what chip is in it, a new
> line of Integrity servers just might have a console to which one can
> connect without downgrading or disabling secure connection methods.
> Such is not the case for many existing Integrity servers that are no
> longer getting firmware upgrades.

As compared with anything i2 / Tukwila or particularly prior, yes.
Certainly preferable to the Alpha management hardware, though many
folks have add-on hardware to mostly-remote-manage many old Alpha boxes
via the serial console. But in terms of what's available now, Kittson
i6 looks to be the same as Poulson i4, with the exception of the ~5%
clock increase available with two top-end SKUs that became available
with Itanium 9700 series Kittson processors and the Integrity i6 boxes.
So not a lot of reason for i4 to upgrade.

> Also not mentioned in this i6 thread so far is that process shrinks
> generally reduce power consumption, which is important to a lot of
> people. I have not seen (nor looked for) power consumption figures, but
> if there's a noticeable difference, that would certainly be a
> consideration.

AFAICT... Kittson is not a shrink. Both Kittson and Poulson are built
on 32nm. Power consumption figures are also very similar, as well.
Other than that ~5% clock bump on two of the Kittson SKUs, not much
seems to have changed in the implementations.


--
Pure Personal Opinion | HoffmanLabs LLC
Jan-Erik Soderholm
2017-06-16 22:08:22 UTC
Permalink
Raw Message
Den 2017-06-16 kl. 23:59, skrev Stephen Hoffman:
> On 2017-06-16 03:42:51 +0000, Craig A. Berry said:
>
>> ...most people with the technical wherewithal to do a port did so a
>> decade or more ago and now have aging Itanium hardware that needs
>> replacement. Where I work, we moved to Itanium eight years ago and it
>> seemed to me at the time that we were towards the end of the curve.
>
> We don't build'm like we used to. And in many ways, that's a good thing.
>
>> I believe Hoff said something once about jumping from a burning ship onto
>> one that hadn't been built yet.
>
> That sinking ship quote likely wasn't one of mine:
> https://groups.google.com/d/msg/comp.os.vms/fGwg0mZlMqA/7f8Dj0eeagwJ
>
>> Then there is the fact that regardless of what chip is in it, a new line
>> of Integrity servers just might have a console to which one can connect
>> without downgrading or disabling secure connection methods. Such is not
>> the case for many existing Integrity servers that are no longer getting
>> firmware upgrades.
>
> As compared with anything i2 / Tukwila or particularly prior, yes.
> Certainly preferable to the Alpha management hardware, though many folks
> have add-on hardware to mostly-remote-manage many old Alpha boxes via the
> serial console.

What is it that you cannot do via the console? Besides of
pushing the power switch, but for anything else, it is all
done over the serial console, AFAIK. And the "add on hardware"
is one (can be old) terminal server and a serial cable.


> But in terms of what's available now, Kittson i6 looks to
> be the same as Poulson i4, with the exception of the ~5% clock increase
> available with two top-end SKUs that became available with Itanium 9700
> series Kittson processors and the Integrity i6 boxes. So not a lot of
> reason for i4 to upgrade.
>
>> Also not mentioned in this i6 thread so far is that process shrinks
>> generally reduce power consumption, which is important to a lot of
>> people. I have not seen (nor looked for) power consumption figures, but
>> if there's a noticeable difference, that would certainly be a consideration.
>
> AFAICT... Kittson is not a shrink. Both Kittson and Poulson are built on
> 32nm. Power consumption figures are also very similar, as well. Other than
> that ~5% clock bump on two of the Kittson SKUs, not much seems to have
> changed in the implementations.
>
>
Simon Clubley
2017-06-18 09:19:54 UTC
Permalink
Raw Message
On 2017-06-16, Jan-Erik Soderholm <jan-***@telia.com> wrote:
>
> What is it that you cannot do via the console? Besides of
> pushing the power switch, but for anything else, it is all
> done over the serial console, AFAIK. And the "add on hardware"
> is one (can be old) terminal server and a serial cable.
>

What networking protocols are being used to talk to the terminal
server ?

If they are not encrypted protocols, then I sincerely hope the
network connection to that terminal server is physically isolated
from the rest of the network so that traffic to/from the terminal
server cannot be sniffed.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Jan-Erik Soderholm
2017-06-18 10:57:31 UTC
Permalink
Raw Message
Den 2017-06-18 kl. 11:19, skrev Simon Clubley:
> On 2017-06-16, Jan-Erik Soderholm <jan-***@telia.com> wrote:
>>
>> What is it that you cannot do via the console? Besides of
>> pushing the power switch, but for anything else, it is all
>> done over the serial console, AFAIK. And the "add on hardware"
>> is one (can be old) terminal server and a serial cable.
>>
>
> What networking protocols are being used to talk to the terminal
> server ?
>
> If they are not encrypted protocols, then I sincerely hope the
> network connection to that terminal server is physically isolated
> from the rest of the network so that traffic to/from the terminal
> server cannot be sniffed.
>
> Simon.
>

I see no reason you could not use an terminal server that uses SSH.
Stephen Hoffman
2017-06-19 21:27:52 UTC
Permalink
Raw Message
On 2017-06-18 09:19:54 +0000, Simon Clubley said:

> On 2017-06-16, Jan-Erik Soderholm <jan-***@telia.com> wrote:
>>
>> What is it that you cannot do via the console? Besides of pushing the
>> power switch,

The Alpha RMC allows system power control on AlphaServer DS20-class
servers, FWIW. Various late-stage Alpha systems had RMC or RCM
support. You're probably already aware of those capabilities, though.

>> but for anything else, it is all done over the serial console, AFAIK.
>> And the "add on hardware" is one (can be old) terminal server and a
>> serial cable.

See the comment on the various folks having cobbled together ways to
remotely manage servers in the reply. Integrated management consoles
such as HPE iLO or Dell DRAC and analogs integrate that, and provide
additional status and monitoring and control capabilities, and
variously remote installation capabilities via vKVM or related. And
the integrated consoles are fewer parts to configure and manage and
deploy.

> What networking protocols are being used to talk to the terminal server ?
>
> If they are not encrypted protocols, then I sincerely hope the network
> connection to that terminal server is physically isolated from the rest
> of the network so that traffic to/from the terminal server cannot be
> sniffed.

Ayup. Whether ssh or https or otherwise. Those isolated networks
are increasingly difficult to keep isolated over the years, too.
Just bumped into a nice reverse shell for down-revision HP OfficeJet
printers, injected via SNMP.

We're also in an era where servers have shorter support cycles and are
increasingly replaceable, and not the sorts of boxes that were once
kept around for nearly as long as was common with VAX and Alpha.
Microprocessors and glue chips too are seeing attempts to differentiate
and to encourage upgrades based on instruction sets such as features
for specific software operations and features aimed for better security
or easier manageability — Intel AME is iLO on the hub, for instance —
rather than the more traditional work to encourage customer upgrades
based on faster cores or more cores. VSI has already encountered
issues around these feature sets, and these changes are only likely to
become more common.


--
Pure Personal Opinion | HoffmanLabs LLC
Kerry Main
2017-06-20 01:05:10 UTC
Permalink
Raw Message
> -----Original Message-----
> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: June 19, 2017 5:28 PM
> To: info-***@rbnsn.com
> Cc: Stephen Hoffman <***@hoffmanlabs.invalid>
> Subject: Re: [Info-vax] New Itanium I6 Article with Previous I4/I2 Specs
> Comparison
>
> On 2017-06-18 09:19:54 +0000, Simon Clubley said:
>
> > On 2017-06-16, Jan-Erik Soderholm <jan-***@telia.com>
> wrote:
> >>
> >> What is it that you cannot do via the console? Besides of pushing the
> >> power switch,
>
> The Alpha RMC allows system power control on AlphaServer DS20-class
> servers, FWIW. Various late-stage Alpha systems had RMC or RCM
> support. You're probably already aware of those capabilities, though.
>
> >> but for anything else, it is all done over the serial console, AFAIK.
> >> And the "add on hardware" is one (can be old) terminal server and a
> >> serial cable.
>
> See the comment on the various folks having cobbled together ways to
> remotely manage servers in the reply. Integrated management
> consoles
> such as HPE iLO or Dell DRAC and analogs integrate that, and provide
> additional status and monitoring and control capabilities, and
> variously remote installation capabilities via vKVM or related. And
> the integrated consoles are fewer parts to configure and manage and
> deploy.
>
[snip..]

Good news is that HPE is now building loads more security into its next gen ProLiant servers silicon.

Reference: June 05, 2017
<https://news.hpe.com/hpe-unveils-the-worlds-most-secure-industry-standard-servers>


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Simon Clubley
2017-06-20 07:25:52 UTC
Permalink
Raw Message
On 2017-06-19, Kerry Main <***@gmail.com> wrote:
>
> Good news is that HPE is now building loads more security into its next gen ProLiant servers silicon.
>

The bad news is that (based on the state of the computing ecosystem
to date) they probably will still have some vulnerabilities in them
at some level.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Kerry Main
2017-06-21 00:59:43 UTC
Permalink
Raw Message
> -----Original Message-----
> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
> Simon Clubley via Info-vax
> Sent: June 20, 2017 3:26 AM
> To: info-***@rbnsn.com
> Cc: Simon Clubley <***@remove_me.eisner.decus.org-Earth.UFP>
> Subject: Re: [Info-vax] New Itanium I6 Article with Previous I4/I2
Specs
> Comparison
>
> On 2017-06-19, Kerry Main <***@gmail.com> wrote:
> >
> > Good news is that HPE is now building loads more security into its
next
> gen ProLiant servers silicon.
> >
>
> The bad news is that (based on the state of the computing ecosystem
> to date) they probably will still have some vulnerabilities in them
> at some level.
>
> Simon.
>

There is no such thing as perfect security .. except for perhaps a
powered off server that just spent 4 hours in an incinerator.

Having stated this, until such time as a vulnerability is identified,
then one has to assume their server firmware security is very high.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Stephen Hoffman
2017-06-21 02:57:20 UTC
Permalink
Raw Message
On 2017-06-20 07:25:52 +0000, Simon Clubley said:

> The bad news is that (based on the state of the computing ecosystem to
> date) they probably will still have some vulnerabilities in them at
> some level.

I'm chasing down some old and down-revision iLOs (again).

As for the Intel processor and hub hardware, or more specifically the
"hardware"...

https://www.tenable.com/blog/rediscovering-the-intel-amt-vulnerability
https://www.troopers.de/downloads/troopers17/TR17_ME11_Static.pdf
https://software.intel.com/en-us/blogs/2012/06/08/local-access-to-the-intel-amt-web-ui

https://recon.cx/2014/slides/Recon%202014%20Skochinsky.pdf (older, but
a nice intro)

There are other folks rummaging Minix and the AMT code looking for
vulnerabilities, of course.

But as I've commented elsewhere, there's also little reason to use a
sophisticated attack on the AMT when various target OpenVMS systems are
using insecure network transports or down-revision network services.

VSI is working to address a number of these issues, of course.


--
Pure Personal Opinion | HoffmanLabs LLC
Kerry Main
2017-06-17 13:25:09 UTC
Permalink
Raw Message
> -----Original Message-----
> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of Craig
> A. Berry via Info-vax
> Sent: June 15, 2017 11:43 PM
> To: info-***@rbnsn.com
> Cc: Craig A. Berry <***@nospam.mac.com>
> Subject: Re: [Info-vax] New Itanium I6 Article with Previous I4/I2
Specs
> Comparison
>
> On 6/14/17 7:09 AM, Jan-Erik Soderholm wrote:
>
> > *If* we would port from Alpha at all, it will
> > most likely not be to Itanium. I do not expect a lot of VMS users
> > going for i6 *today*, if you aren't at the very top of the
> > performance of your i2 or i4 systems.
>
> You're forgetting or ignoring the fact that most people with the
> technical wherewithal to do a port did so a decade or more ago and now
> have aging Itanium hardware that needs replacement. Where I work, we
> moved to Itanium eight years ago and it seemed to me at the time that
> we
> were towards the end of the curve.
>
> Of course servers can operate for longer than a decade, but generally
> require increasingly frequent downtime for even relatively minor
things
> like the odd DIMM that went bad or RAID cache battery that needs
> replacement. On the one hand, it might make sense to nurse the old
> beast
> along for a couple more years and move to OpenVMS X64 without
> buying any
> more Itaniums, but on the other hand, OpenVMS X64 was two years in
> the
> future three years ago and is still two years in the future now. I
> believe Hoff said something once about jumping from a burning ship
> onto
> one that hadn't been built yet.
>
> Then there is the fact that regardless of what chip is in it, a new
line
> of Integrity servers just might have a console to which one can
connect
> without downgrading or disabling secure connection methods. Such is
> not
> the case for many existing Integrity servers that are no longer
getting
> firmware upgrades.
>
> Also not mentioned in this i6 thread so far is that process shrinks
> generally reduce power consumption, which is important to a lot of
> people. I have not seen (nor looked for) power consumption figures,
but
> if there's a noticeable difference, that would certainly be a
consideration.
>

Based on the table in the article in the original post for this thread,
I looks like the i6/I4 have identical cpu chip power consumption (170W)
, which are both better than the I2 (185W) by approx. 9%.
<https://www.nextplatform.com/2017/05/23/last-itanium-long-last/>

Power consumption is not likely going to be a major factor in any new
upgrade.

> In short, there might be a lot of reasons people need new Itanium
> hardware in the next year or two. They might in many cases be better
> served by looking for a good deal on i4 hardware than paying for i6,
but
> at least there is something new that can be had for those who need it.
>

For those OpenVMS Cust's with I4's, there is no reason to look at I6.

For those OpenVMS Cust's with I2's that need extra performance in the
short term, then it could be justifiable to move to I4 or I6 . Which one
I suspect, would depend on price. The price differential might favor I4
if HPE/partners have a lot of I4's in stock today. If not, then the
price differential will likely not be much and jumping to I6 would be
the way to go.

Lets not forget that the sole reason for the I6 was for the HP-UX base
which have no current roadmap other than following HPE's recommendations
to move to Linux or looking at a container type future running on some
hypervisor.

Imho, as is the case in the last 50 years, the compute HW platforms will
continue to evolve in the next 50 years and market share will go up and
down for each of them. Some will drop out (Itanium, SPARC, others?), but
the trend will continue. Trying to pick a winner in compute platforms
would be like trying to predict which car manufacturer will win out and
capture the majority of all the future vehicle market share.

Rather than pick a winner and make an all-in bet, OpenVMS has shown it
can adapt (now on its 4th platform) and with each new HW platform
supported, the effort required to adapt to the new platform becomes
easier. As an example, because of past porting design strategies, I
would expect an OpenVMS post X86-64 port to ARM or PowerX (my hope) will
be much easier than the current port to X86-64.

VSI has already stated that X86-64 is not the last platform they are
looking at in the long term, so imho, that is the best way to position
OpenVMS for the long term i.e. a solid platform that is adaptable to
changing technologies.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Bob Koehler
2017-06-15 13:16:20 UTC
Permalink
Raw Message
In article <453c8f15-2dc1-43d3-8a76-***@googlegroups.com>, abrsvc <***@yahoo.com> writes:
>
> Add to that the validation and certification suites required for most medic=
> al applications. This too can add significant cost and time. Note: I kno=
> w of two clients that are continuing to use Alpha hardware delaying the "po=
> rt" until the X86 becomes reality. The port to Itanium has been completed =
> and tested but not certified (a much more intensive testing suite). Since =
> the certification process is expensive, they are choosing to wait and do it=
> once with the x86 platform.

While me and my old customers just keep our VAXen running.
Loading...