[Info-vax] 1 year.

already5chosen at yahoo.com already5chosen at yahoo.com
Sun Aug 9 09:57:37 EDT 2015


On Sunday, August 9, 2015 at 4:05:05 PM UTC+3, Kerry Main wrote:
> > -----Original Message-----
> > From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf Of
> > already5chosen at yahoo.com
> > Sent: 09-Aug-15 5:28 AM
> > To: info-vax at info-vax.com
> > Subject: Re: [New Info-vax] 1 year.
> > 
> > On Sunday, August 9, 2015 at 6:30:06 AM UTC+3, Kerry Main wrote:
> > > > -----Original Message-----
> > > > From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf
> > Of
> > > > Stephen Hoffman
> > > > Sent: 08-Aug-15 6:39 PM
> > > > To: info-vax at info-vax.com
> > > > Subject: Re: [New Info-vax] 1 year.
> > > >
> > > > On 2015-08-08 19:54:35 +0000, already5chosen at yahoo.com said:
> > > >
> > > > > Yes, more or less. Except that AEST appears to be a static translator,
> > > >
> > > > Incremental translation and instruction emulation are necessarily
> > > > performed.  Details are in the previously-linked documentation.
> > > >
> > > > Using application translation for the environment that IanD has
> > > > described is likely more expensive, with no improvements in their
> > > > current results and quite possibly with a reductions in stability or
> > > > availability or maintainability.   It's unclear why emulation would be
> > > > acceptable to responsible managers here, either.  Particularly given it
> > > > hasn't already been deemed acceptable some time over the past
> > decade
> > > > or
> > > > so.
> > > >
> > > > This particular translation case also involves moving to a platform
> > > > where Kittson as the last Itanium processor being discussed for
> > > > OpenVMS
> > > > itself, and where VSI has already picked the follow-on architecture
> > > > with OpenVMS porting to x86-64.
> > > >
> > > > Management wants to migrate and has a replacement environment
> > and
> > > > wants
> > > > this particular environment gone, so -- in the absence of a viable
> > > > financial justification to the contrary, and quite possibly even with
> > > > such a justification -- that's the target here.   Build a financial case
> > > > to stay with OpenVMS.  Or get going on the migration.
> > > >
> > >
> > > Would building an Alpha HW emulator on OpenVMS/X86-64 not be a
> > > more preferred option?
> > 
> > I see no advantages over existing Stromasys products and numerous
> > disadvantages.
> > The biggest one - OpenVMS/X86-64 does not exist.
> > The second biggest - when it finally exists, drivers availability will always
> > remain far behind Windows Server. Running host VMS OS in para-
> > virtualization mode under VMWare or under its Winduws or Linux
> > counterparts can partially alleviate the issue, but only partially and at cost
> > of making already slow solution even slower.
> > 
> 
> Stromasys exists today, but they are not cheap - typically 4+ digits.
> 
> > On the other hand, application-level binary translation demonstrated
> > very good performance. IA32EL claimed, on average, 50-60% of native
> > (i.e. the same sources recompiled for Itanium) performance for apps
> > that spend almost no time in syscalls. Applications that spend more time
> > in syscalls and native libraries calls will fare even better.
> > 
> 
> I am all for this if it can be done in a timely, and cost effective timeframe,
> but from what I understand, application level binary translation is
> also many numerous of magnitude more complex to build/support.
>

I never did either, but from common knowledge it seems the opposite is true. Emulating just a CPU sounds far easier than emulating the whole machine, with all quirks of peripheral devices. And in this particular case you don't even have to emulate the full Alpha ISA, all system-only stuff can be omitted.
The only aspect that is harder is a much higher performance bar that you are aiming at.

> I also recall binary translation was/is primarily targeted on user mode 
> applications, so it would reduce the number of potential use cases.
>

Not by much. There are far fewer shops with their own kernel drivers than those that has their own applications. Among those that have kernel drivers significant part (majority?) is for hardware that is connected through buses that no longer exist in modern servers, so they are screwed regardless. Of those that are not relaying on obsolete buses, I hope that majority didn't lose a source code and with source code available porting drivers from Alpha to Itanium does not have to be difficult - after all drivers tend to be much smaller and simpler than applications and are written by more conservative developers.

> > >
> > > Future VAX HW emulators???
> > >
> > > From a Customer perspective, standardize on one X86-64 platform and
> > > move older environments to new platform with zero (or low) impact?
> > >
> > > Latest OpenVMS running on V9.x/X86-64 and older env's running on
> > > same server running OpenVMS Alpha .. similar to VMware.
> > >
> > > Course, the mix would depend on performance requirements.
> > >
> > > Big benefit would be to get all those Alpha/VAX systems on new HW
> > > (HP ProLiants?) and under monthly service support contracts to VSI.
> > >
> > > Would certainly help monthly revenue stream.
> > >
> > > There is also quite a bit of experience with building HW emulators via
> > > other vendors, so perhaps, one could be contracted separately to do
> > > this?
> > 
> > Yes, Stromasys emulators work, but they are far from speed demons.
> > 
> 
> True, but from what I have seen, most existing VAX/Alpha environments 
> are running less than 30% in peak times anyway. As long as the perf was
> "as good", then it would be "good enough".
> 
> Yes, there are big Alpha and likely some bigger VAX env's but these are 
> the exception - not the norm.
>

I don't believe that there are still Vaxen in production that meet two criteria below at the same time:
a) does not run real-time jobs (for real-time no sort of emulation will work) b) are so big that they present performance challenge for Charon-Vax on modern Intel hardware.

Alpha is very different story.

> 
> The draw for Custs moving to Alpha/VAX HW emulators on OpenVMS/
> X86-64 would be a move to current HW with minimal/no changes to their 
> App environment e.g. OpenVMS V8.4. Same draw as what VMware has
> when they support older versions of Windows/Linux on their most 
> current versions of VMware.
>

I'd guess, that sort of mentality (do no changes anything, including not applying fixes to known OS bugs and vulnerabilities) is the reason behind negative reaction of Mr. Hoffman.

And you still didn't present a single reason for a move to (non-existing) HW emulator hosted on VMS vs existing, proven and working emulators hosted on Windows.

> The draw for VSI would be to get additional monthly support revenue.
> 
> Yes, some VAX/Alpha systems have HW and/or timing dependencies 
> that may make them ineligible for this use case.
> 
> Kerry




More information about the Info-vax mailing list