[Simh] Simh and OpenVMS Integrity V8.4 Network Support issues

Mark Pizzolato - Info Comm Mark at infocomm.com
Wed Apr 4 14:34:50 EDT 2012


On Sunday, April 01, 2012 at 9:39 AM, Stephen Hoffman wrote:
> On Sat, 31 Mar 2012 18:31:33 +0200, Maurizio De Tommaso posited:
> 
> > I see you are able to reproduce the behavior of slowness of new SIMH
> > code that I observed on my rx1620 Integrity server.
> 
> Itanium alignment faults can trigger platform-specific performance issues.
> 
> Put another way, consider enabling the detection of and monitor for
> excessive numbers of alignment faults.
> 
> OpenVMS I64 on Itanium requires the rough equivalent of ten to fifteen
> thousand instructions to fix a single alignment fault.
> 
> A few alignment faults or more numerous faults in a non-performance-
> critical code-path aren't going to produce an application performance issue.
> 
> Too many alignment faults or faults arising in a critical code-path, however,
> and application performance can degrade drastically.
> 
> An introduction to the topic, with links to more detailed articles:
> <http://labs.hoffmanlabs.com/node/160>

Thanks for the pointer.

I explored this using the info in your article:
         For this fault-monitoring task, consider use of the MONITOR ALIGN command 
         (OpenVMS V8.3 and later), the the ANALYZE/SYSTEM (SDA) extension FLT (See 
         the HP OpenVMS System Analysis Tools Manual in the OpenVMS documentation 
         set) and its commands including FLT START TRACE /CALLER, and the 
         SET BREAK/UNALIGNED command within the OpenVMS debugger.

This didn't actually yield anything to get excited about, and hence no resolution to the problem.  :-(

As it turns out the issue was due to me not linking my multi-threaded application with /THREADS_ENABLE.  Without that Linker switch, the application created Process threads which had to share the single process with each other.  One thread, executing simulator instructions never gives up the CPU and must be eventually preempted.  It was the timeouts waiting for this preemption which caused the very slow behavior.

- Mark




More information about the Simh mailing list