[Info-vax] Kittson question

[ljinnc at gmail.com]

On Monday, January 5, 2015 12:57:41 AM UTC-5, Chris Scheers wrote:
> johnwallace4 at yahoo.co.uk wrote:
> > On Sunday, 4 January 2015 21:09:49 UTC, lji... at gmail.com  wrote:
> >> On Sunday, January 4, 2015 11:00:29 AM UTC-5, johnwa... at yahoo.co.uk wrote:
> >>> On Sunday, 4 January 2015 15:22:30 UTC, Jan-Erik Soderholm  wrote:
> >>> Exactly. VAXeln has the capability to be fit and forget, as much as
> >>> or maybe even more than VMS does/did. Any VAXeln systems that are still
> >>> around stand an excellent chance of being almost invisible. 
> >>>
> >>> Unless a VAXeln application deliberately contains unusually
> >>> hardware-specific code, the only real hardware dependence in a VAXeln
> >>> system are the OS kernel's hardware-dependent pieces (the ones which
> >>> in a VMS system might iirc live in SYSLOAxxx?). In a VAXeln system,
> >>> the developer picks the relevant hardware=specific bits when the system
> >>> image is configured. Unlike VMS, there's no boot-time mechanism for
> >>> choosing the relevant hardware-specific bits for the OS. 
> >>>
> >>> If the hardware is emulated rather than real, the VAXeln system just
> >>> needs the emulator to look sufficiently like the originally chosen
> >>> target. On the surface it doesn't sound as though it needs any
> >>> particular magick.
> >>>
> >>> Of course if it's a genuine real-time VAXELN system running in an
> >>> emulator on top of Windows, and Windows decides to take a break from
> >>> running the emulator for a few hundred milliseconds (as it does),
> >>> *that* might sometimes be exciting. Or sometimes it might have no
> >>> visible effect.
> >> Exact timing is why The Logical Company (which you mentioned before) uses vtVAX for its NuVAX > >> product line - both the QBUS and Unibus models. Logical guarantees that cycle times to custom  > >> devices will be the same on the replacement system as on the original VAX. Very important to 
> >> military users like Patriot, HAWK, Minuteman, Milstar, USN, USAF.
> > 
> > Well that's interesting wording.
> > 
> > "Logical guarantees that cycle times to custom devices will be the
> > same on the replacement system "
> > 
> > So we're not saying the instruction timing is the same (that would be
> > tricky with a soft emulator)? We are saying the timing of operations
> > to/from IOspace is the same?

Yes, that's correct. The Logical PCI controller boards ensure proper operation and precise timing of attached peripherals. 

> > 
> > Ya gotta be keen to need that kind of thing. And some people (probably
> > not many, but possibly with big taxpayer-funded budgets) DO want/need
> > that kind of thing.

Radar and missile systems (CONUS and OCONUS) depend on it.

> 
> There's not many users that need this, but there are some and they 
> aren't all big or taxpayer funded.
> 
> If you run an emulation on a PC and talk to custom hardware through some 
> sort of hardware interface, you may discover that PCI (or PCIe) timing 
> can get, well, interesting.
> 
> PCI read and write times are not symmetric.
> 
> PCI timing can vary from motherboard to motherboard.
> 
> PCI timing is tied to a clock which may not match the granularity you 
> need for your hardware.
> 
> It can be a challenge to juggle all this and get the customer's I/O 
> working correctly.
> 
> Then throw in things like discovering that Windows would occasionally 
> hang the system for 15 microseconds when a task that ran every 10 
> seconds made a Windows call, which, when the stars were aligned wrong, 
> could corrupt the emulated I/O.  (Sometimes, the user's hardware was 
> generating a data sample every 10 microseconds, with no buffering.)

vtVAX ensures that doesn't happen.

> 
> Getting all this working correctly can be a bit of a nightmare.
> 
> After handling a few of these types of systems, you get a very good 
> appreciation of why these systems have never been upgraded or converted 
> to newer hardware.

PCI timing, OS calls, chip/disk/network speed increases are all factors. It would take hundreds of millions of dollars to replace these global defense systems with modern hardware and software. Many of them have life cycles to 2040 and 2050 for that reason.