[Info-vax] Clock running very slow on an Alpha

[Richard B. Gilbert]

Peter Weaver wrote:
> I have a customer with a four node cluster of Alphas running V7.2-1.
> Three of the Alphas are identical "AlphaServer 4100 5/533" machines.
> All four machines have been running Multinet  V4.2 XNTP for years. The
> XNTP configuration is identical on all four nodes, the SHOW LOG *TIME*
> command on all four nodes yields identical results. I downloaded and
> ran the TBO utility on the cluster, all three of the 4100's report;
> 
> $ tbo/info
> %TBO-I-IDENT, OpenVMS Time Booster Rev 2.0
> %TBO-I-INFO,  Systemtime: 25-AUG-2010 13:00:48.89
>        Timeadjust: 0
>        Ticklength: 8333
> 
> ANA/SYS returns the same values for these three locations on all three
> 4100's;
> EXE$GL_TIMEADJUST:  00000000.00000000   "........"
> EXE$GL_TICKLENGTH:  00000000.0000208D   ". ......"
> EXE$GL_SYSTICK:  00000000.0000208D   ". ......"
> 
> 
> One of the three 4100 machines servers recently started losing 15
> minutes per day. I have restarted XNTP on this node several times,

The maximum error that a standard NTP can correct is 43 seconds per day!

I hope you have a hardware support contract.  It looks very much as if 
your clock has gone belly up!

> each time the XNTPD.LOG reports that it acquired the peers (usually I
> have only one peer but during my troubleshooting I added in the other
> 3 Alphas as peers) but nothing else. The drift file on this node shows
> "0.000 0" I trield adjusting the time with TBO/DIRECTION=FORWARD/
> RANGE=7200/DELTA=4500 (move the clock ahead 75 minutes over the next 2
> hours) but even with that command the time on this Alpha was stil
> drifting away from the other Alphas just not as quickly.
> 
> If I stop XNTP and run the ntpdate command then the clock jumps to the
> correct time.
> 
> Can anyone think of anything from a VMS perspective that I missed that
> could be causing this? If it boils down to hardware then what part
> should I tell the hardware people I need replacing?

Tell the hardware people that the clock is consistently losing fifteen 
minutes per day.  Which part(s) need to be replaced is their problem!
If the H-P service guy doesn't know, he has the resources to find out!

That error is somewhere between fifteen and thirty times the maximum 
error that  NTPD can correct.  If H-P can get, and keep, the error below 
43 seconds per day, NTPD can handle it with no problem.  The "normal 
range" of error for the undisciplined clock should be more like +/- ten 
seconds per day or less!  And note that that is an error that the owner 
of a cheap wrist watch probably would not tolerate!!