[Info-vax] FREWSLX Alpha 7.3-2

[wolkenr at gmail.com]

On Friday, 27 April 2012 15:08:02 UTC+10, Volker Halle  wrote:
> Richard,
> 
> the FREWSLX crash with MONITOR in V8.2, described in the 26-AUG-2006
> c.o.v. entry, appears to have been a known problem in SPISHR. So it
> does not directly explain what you have seen.
> 
> The fact, that your FREWSLX crash in V7.3-2 has been seen on a CHARON-
> AXP/4100 system, does not immediately make the emulator a 'suspect'.
> Please verify, if you might have seen this crash on this system
> before: $ TYPE CLUE$HISTORY - any other FREWSLX seen during the life
> of this system on the real hardware ?
> 
> Note that the CPU speed of an emulated AlphaServer 4100 is - depending
> on the performance of the underlying host system - at least 30% faster
> than the real 4100, so this may change some behaviour of the system
> regarding the overall timing of events. Although this is unlikely on
> OpenVMS Alpha V7.3-2, which can run on much faster systems.
> 
> Please save the current dumpfile (using SDA> COPY/COMPRESS filename)
> as evidence to be compared with possible future crashes.
> 
> ---
> Volker Halle, Invenate GmbH, OpenVMS Support
> 
> An OpenVMS crashdump analysis a day
> makes the Windows headaches go away.

Thanks Volker,
We haven't seen this crash in our fleet before. We are piloting Charon now with an eye to further deployments. This is a non-production system which is used to test batch processing for the application. A suite of jobs run there every day, and has done so for many years. I have seen over history that SYSMWCNT has lowered over time, but not at all in the last 5 years, so ~274 (or 4333) has been its value for that time. It is clustered with a DS10, which is the primary RDB DB server, and a VAX7720 for ACMS online users (also emulated as a charon VAX6620 also since about 3 weeks ago without problems) 

FWIW, shortly before the 4100 was virtualized we also converted the system disk to SAN for the 2 Alpha nodes. Application storage was on SAN already.
This made it possible to continue booting both physical & Charon nodes from the same disk.

We've noticed the speed improvement in the emulator, probably more than 30% in CPU time required to process the same job as an example, but not necessarily elapsed time.
We're talking ~0.80 seconds versus ~1.40 seconds CPU, but ~4.5 seconds elapsed versus ~3 seconds before. SCA is an interesting change now, because we have PEA0  over a second NIC in the virtual systems. 


TSG_RW_BA1090> ty clue$history
Date               Version   System/CPU           Node    Bugcheck      Process          PC        Module                   Offset
-----------------  --------  -------------------  ------  ------------  ---------------  --------  -----------------------  --------

21-APR-2011 15:57  V7.3-2    AlphaServer 4100 5/  BA1090  CLUEXIT       NULL             8034C724  SYS$CLUSTER              00002724
 4-AUG-2011 12:41  V7.3-2    COMPAQ AlphaServer   BA2283  CWLNMERR      A.HEMANTH2       00030B60  CSP                      00030B60
 8-MAR-2012 12:43  V7.3-2    AlphaServer 4100     BA1090  INVEXCEPTN    NULL             86C33AB4  TCPIP$INTERNET_SERVICES  00055AB4
 3-APR-2012 08:38  V7.3-2    AlphaServer 4100     BA1090  INVEXCEPTN    TCPIP$INETACP    00003088  <not available>          00000000
 3-APR-2012 08:54  V7.3-2    AlphaServer 4100     BA1090  INVEXCEPTN    TCPIP$INETACP    86C08010  TCPIP$INTERNET_SERVICES  0002A010
17-APR-2012 22:30  V7.3-2    AlphaServer 4100     BA1090  FREWSLX       BATCH_1184       8017807C  SYS$VM                   0000A07C

On Friday, 27 April 2012 15:08:02 UTC+10, Volker Halle  wrote:
> Richard,
> 
> the FREWSLX crash with MONITOR in V8.2, described in the 26-AUG-2006
> c.o.v. entry, appears to have been a known problem in SPISHR. So it
> does not directly explain what you have seen.
> 
> The fact, that your FREWSLX crash in V7.3-2 has been seen on a CHARON-
> AXP/4100 system, does not immediately make the emulator a 'suspect'.
> Please verify, if you might have seen this crash on this system
> before: $ TYPE CLUE$HISTORY - any other FREWSLX seen during the life
> of this system on the real hardware ?
> 
> Note that the CPU speed of an emulated AlphaServer 4100 is - depending
> on the performance of the underlying host system - at least 30% faster
> than the real 4100, so this may change some behaviour of the system
> regarding the overall timing of events. Although this is unlikely on
> OpenVMS Alpha V7.3-2, which can run on much faster systems.
> 
> Please save the current dumpfile (using SDA> COPY/COMPRESS filename)
> as evidence to be compared with possible future crashes.
> 
> ---
> Volker Halle, Invenate GmbH, OpenVMS Support
> 
> An OpenVMS crashdump analysis a day
> makes the Windows headaches go away.