Hello Managers,
Well: It turned out to be some sort of local disturbance or something.
I have no explanation for it, as everything seems to be normal today:
xntpdc> peers
remote local st poll reach delay offset disp
=======================================================================
=finwds01.tu-gra 129.27.138.63 2 64 17 0.00293 0.053255 1.87582
I still get these "Previous time adjustment didn't complete" messages
but not so frequently. BTW: I get these messages on all of my other
systems (DEC 3000/600 - DU4.0B, Suns with Solaris 2.5.1, PCs with Linux)
as well so it's apparently just a property of the xntp software.
The Ultrix Box is running one of the latest xntpd implementations as
well so protocol differences should not occur either.
Well: As everthing is back to normal, I hope that it stays like this.
For the 274MHz message I got the following explanation from
"Dr. Tom Blinn, 603-881-0646" <tpb_at_zk3.dec.com> :
---------------------------------------------------------------------------
> P.S: Maybe its completely irrelevant but my processor should have 275MHz
> but startup messages in UERF say:
>
> Alpha 21064A Evaluation Board 274 MHz_system
>
> should I care about that?
On many platforms, the startup code simply retrieves a value that's put in
the hardware reset parameter block (HWRPB or RPB for short) by the console
firmware, truncates it to a MHz number (instead of rounding), and prints out
that number. So if the actual CPU clock rate would round to 275Mhz but
isn't over 275MHz, then you'll see 274MHz printed out. I haven't looked at
the code to be sure, but I'm pretty confident that's what's happening. So I
wouldn't worry about it. Interestingly enough, different systems come up
with different numbers, even though they're nominally all running at the
same speed. (I've seen this on several platforms.)
---------------------------------------------------------------------------
Thanks to the following people for their replies:
"Amy E. Skowronek" <amy_at_aloha.nascom.nasa.gov>
"Marcel Bernards" <bernards_at_ecn.nl>
"Jeffrey G. Micono 6533 (Ktech)" <jgmicon_at_sandia.gov>
"Dr. Tom Blinn, 603-881-0646" <tpb_at_zk3.dec.com>
Rainer Landes <rlandes_at_fphws01.physik.uni-karlsruhe.de>
"WHITTAKER, Bruce" <bjw_at_ansto.gov.au>
Tom
----------------------------------------------------------------------------
Here's my original posting:
--------
After installing 4.0B three days ago, I've noticed that my system time
is slowly drifting away and xntp refuses to sync to our time server.
This is on an Aspen Alpine EB64+ motherboard.
This morning, I found that time about 30 minutes late!! After I've
reset to the correct time with "ntpdate" and running the system
for about 8 hours, the time is already about 7 seconds away from the
time server's time again:
xntpdc> peers
remote local st poll reach delay offset disp
=======================================================================
=finwds01.tu-gra 129.27.138.63 16 1024 377 -0.0009 7.294414 3.35039
and xntpd refuses to synchronize with lots of
Previous time adjustment didn't complete
messages in the syslog.
Question: Has anyone already stumbled accross this? Any cure or
ideas what could cause that?
Thanks a lot -- Tom
P.S: Maybe its completely irrelevant but my processor should have 275MHz
but startup messages in UERF say:
Alpha 21064A Evaluation Board 274 MHz_system
should I care about that?
--------------------------------------------------------------------------
T o m L e i t n e r Dept. of Communications
Graz University of Technology,
e-mail : tom_at_finwds01.tu-graz.ac.at Inffeldgasse 12
Phone : +43-316-873-7455 A-8010 Graz / Austria / Europe
Fax : +43-316-463-697
Home page :
http://wiis.tu-graz.ac.at/people/tom.html
PGP public key on :
ftp://wiis.tu-graz.ac.at/pgp-keys/tom.asc or send
mail with subject "get Thomas Leitner" to pgp-public-keys_at_keys.pgp.net
--------------------------------------------------------------------------
Received on Fri Feb 14 1997 - 08:59:47 NZDT