[Info-vax] Baremetal emulators, was: Re: Alpha emulator for OSX

[johnwallace4 at yahoo.co.uk]

On Monday, 8 February 2016 23:39:26 UTC, Stephen Hoffman  wrote:
> On 2016-02-08 20:40:14 +0000, Johnny Billquist said:
> 
> > On 2016-02-08 17:13, Stephen Hoffman wrote:
> >> On 2016-02-08 14:21:55 +0000, lists at openmailbox.org said:
> >> 
> >>> Very well said as usual. But is this an issue for OpenVMS users? Is 
> >>> OpenVMS used for real-time applications?
> >> 
> >> There are many applications with latent dependencies on timing; that 
> >> will fail when calls operate too quickly or too slowly.  These 
> >> applications are arguably poorly written, but they can and do exist.
> > 
> > All very true, but this is a different can of worms, Stephen.
> > 
> > Linux is not realtime. In fact, you have no idea how long time might 
> > pass between the execution of one instruction and the next in your 
> > application. Normally, it will be fast, but there is no bounded limit 
> > on it. If you depending on a reaction within a bounded time, you are 
> > playing russian roulette using a host OS like Linux.
> > And this of course also affect how long "interrupt" latencies your 
> > machine will appear to have. It might be super fast, and it might take 
> > a long long time to react to that interrupt. And it varies from time to 
> > time.
> > Because with "next instruction", we're now talking about the next 
> > instruction in the emulated machine. The actual host will be running 
> > and executing instructions normally, just that it might be in the 
> > bowels of Linux for a while...
> > 
> > 	Johnny
> 
> I was referring to vanilla, simple, ordinary timing dependencies 
> involving incorrectly or unsynchronized operations.  Stuff that goes 
> wrong when the underlying timing changes.   About timing-related things 
> that should be simple to get right, but -- as several folks around here 
> are fond of demonstrating with some of the code that gets posted -- 
> correctly and consistently managing asynch activities isn't always 
> something that always gets implemented.  Not even instruction 
> dependencies.   (VAX instruction processing was its own special joy to 
> deal with, but I digress.)
> 
> As for Linux Realtime, there are options:  https://www.rtai.org or 
> http://xenomai.org or 
> https://www.osadl.org/Realtime-Linux.projects-realtime-linux.0.html or 
> https://github.com/rtmux depending on specific requirements.
> 
> I'm sure there are others.
> 
> Related reading: http://elinux.org/images/0/00/Elc2013_Roman.pdf  -- VMS 
> has some of the same requirements and discussions, as -- for instance -- 
> a cluster transition can hose the timing sof certain sorts of 
> processing.
> 
> But discussions of what is or is not "realtime" -- without application 
> timing requirements, or at least a set of definitions that can be 
> referenced -- are rather more like "cloud" or "security" or "bare iron". 
>   Either there's a framework for the discussions, or the conversation 
> turns into "no true Scotsman".   As this one will continue.
> 
> With the prices of hardware, doing dedicated processing in a loop -- 
> either a specific core in a box, or with a dedicated box -- or other 
> such shenanigans becomes feasible.   Competent computing boards and 
> boxes don't cost nearly as much as a PDP-11 or a VAX anymore, after all.
> 
> 
> 
> -- 
> Pure Personal Opinion | HoffmanLabs LLC

Whether your steel mill fails or not isn't really related to
the price and availability of fast hardware. The timing 
constraint is application specific, e.g. that sensors read
the thickness and report to the control system, which looks
up what's desired right now, and commands actuators to adjust
the roll separation on the mills. For example. Other examples
exist;  one I'm personally familiar with (but not on VMS) is a 
serial data logger intended to capture multiple channels of
non flow controlled near continuous async data at 1Mbit or
so (using nothing but COTS hardware), timestamp it, and log
it to file (fortunately there was no need to produce a
timely output, just a need to not lose incoming data).

Whether that kind of thing works or not isn't just related
to box performance, it depends on whether you can trust the
hardware and the OS and all the rest to behave predictably,
in particular to respond in a timely manner, and to just
KEEP THE UNDERLYING LAYERS/EMULATORS/OS OUT OF THE DAMN WAY
when the application has important and time critical things to do.


A dedicated RTOS should be able to do most of that, either on a
real computer or hiding inside a programmable logic controller etc,
so long as there's nothing too unRTOSlike or unPLClike.

Some Linux systems might be able to do that when configured
correctly and with careful attention to detail.

RSX and IAS did and could do most of that in the right circumstances.

VMS on VAX and Alpha did and could do that in the right circumstances.

VMS on IA64? Not sure, there seemed to be lots of unpredictable 
timing stuff causing far more overhead than might previously have
be expected, a visible example of which would be alignment faults
(others may well be less visible).

A clustered VMS setup might not be a good choice in that kind of
circumstance, due to activity blocking during state transitions etc. 

No IT-compatible Window box will ever do that reliably (can't
process that roller separation adjustment or that incoming serial
data right now, got a daily virus scan to think about).

Those Xenomai people might want to talk to DEC E+RT HQ folk about
how succesful DEC was in moving people from VAXELN to VxWorks
using API emulation. Sensible people may look at the concept and
wonder what all those layers are going to do and decide to either
keep what they've got or recode to suit where they're going.