[Info-vax] FREWSLX Alpha 7.3-2

[abrsvc]

On Friday, April 27, 2012 3:29:25 AM UTC-4, wol... at gmail.com wrote:
> 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.

I was not trying to say that the emulator is the problem directly, but when that is the only change, I would check with that vendor first.  I also agree that timing can be an issue here.  Increased CPU performance can significantly effect timing and thus uncover latent bugs.

A close examination of the dump should be done.

Dan