Subject: ntp group

From: Petri Helenius <[email-masked]>
Date: Sat, 16 Mar 1996 15:50:23 +0200

There seems to be different time sources feeding into the NTP group:
xntpdc> peer
     remote           local      st poll reach  delay   offset    disp
=======================================================================
*rackety.udel.ed 0.0.0.0          1   64  376 0.00000 -0.307535 0.02838
~merganser.cl.ca 0.0.0.0          1   64  376 0.00000  0.145574 0.05470
~thebrain.noc.in 0.0.0.0          2 1024    0 0.34538 -184.2431 16.0000

...which of two are off by three minutes from the real-world time
(the two above).

Pete

---

From: Piete Brooks <[email-masked]>
Date: Sat, 16 Mar 1996 16:30:46 +0000

>   There seems to be different time sources feeding into the NTP group:

That is the objective -- the more time sources the are, the better the time
NTP can deduce ...

>      remote           local      st poll reach  delay   offset    disp

As I read that, the two active clocks agree within half a second (not bad
if you know how the code works !).
The dead (reach = 0, disp = 16) high stratum (st = 2) unused (poll = 1024)
clock is just plain wrong.

Fear not -- NTP has no problem -- it has decided which to use !

[[ PS: which NTP code are you running ? "delay = 0" looks wrong to me ! ]]

---

From: Petri Helenius <[email-masked]>
Date: Sat, 16 Mar 1996 19:20:36 +0200

> clock is just plain wrong.
The problem above is that NTP is getting reset every five minutes or so
since two of the above (rackety and merganser) are feeding bullshit-
clocks that are three minutes off the real time. thebrain is trying to
compete. I find it discusting to feed incorrect stratum-1 information
into MBone. That's why I sent my mail.

 > [[ PS: which NTP code are you running ? "delay = 0" looks wrong to me ! ]]

The problem is the resets caused by two machines having their clocks wrong.
If you can, check the clock on merganser and rackety.

Pete

---

From: Piete Brooks <[email-masked]>
Date: Sat, 16 Mar 1996 17:55:07 +0000

> clocks that are three minutes off the real time.

I would be suprised if rackety were 3 mins out, knowing who runs it.
My driver for merganser compensates for a 4mS ramp in my S0 receiver,
and manages to get below 1mS.  I've done analysis of the scatter plot
against other S1s and found good V plots, so generally suspect I'm within 1mS.
I peer with 10 other S1s, and they register errors of the order of 10mS.

I would be exceedingly suprised if both rackety and merganser are both
"feeding clocks" which are out by 3 mins.
I would be suprised if the NTP packets were taking 3 mins to reach you !
In any case, your server should use the HACK "enter unicast mode at startup"
mode, which should get set the delay to the unicast delay at the time the
clock was first seen.

> thebrain is trying to compete.

It's an S2 -- I suspct I'd agree with NTP -- two S1s within half a second
are likley to be more reliable than one S2 ....

> I find it discusting to feed incorrect stratum-1 information into MBone.

I'd take care before flaming the managers of those clocks .....
You might hurt our feelings !! :-(

> That's why I sent my mail.

I suggest we take this off the MBone list, and correspond privately ....

> The problem is the resets caused by two machines having their clocks wrong.

That should not reset delay on the running clocks.
You didn't answer about which code you are running ...

> If you can, check the clock on merganser and rackety.

As above, merganser is within 10s of mS's of 10 other S1s.
rackety only has 4 S1 peers, but it does have 3 S0s and I trust its manager
and the diversity it has.

I've kicked woodcock in as well -- what does it show ?

[[ PS: what is your server address, so that I can look at it ? ]]

---

From: Ajit Thyagarajan <[email-masked]>
Date: Sat, 16 Mar 1996 18:02:16 +0000

Petri,

>      remote           local      st poll reach  delay   offset    disp

How did you arrive at the 3 minute figure?  That information does not
seem to be present in the above table!  Pete Brooks was right in his
analysis of "thebrain" being dead since the reachability & status
indicate that there is not even a pipsqueak from that machine.  It
looks like the offset of your host is only 307 milliseconds
w.r.t. rackety, and merganser and rackety could be upto 500 ms off
w.r.t to each other from the above table.  However if you compare
rackety and merganser directly, you get the following

ntpq> host merganser.cl.cam.ac.uk
current host set to merganser.cl.cam.ac.uk
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  disp
==============================================================================
 woodcock.cl.cam .PPS.            1 m    4   64   77     0.00    0.000 16000.0
*MSF_EES(1)      .MSF1.           0 l    4   16  377     0.00   -1.895 11.81
 ATOM_PPS(0)     .PPS.            0 -   8d   16    0     0.00   26.212 16000.0
 NTP.MCAST.NET   0.0.0.0         16 -    -   64    0     0.00    0.000 16000.0
 rackety.udel.ed .PPS.            1 -   8d  512    0   180.01  -13.704 16000.0
xrackety.udel.ed .PPS.            1 m  120   64  374   191.76   70.094 34.01
                                                                ^^^^^^
The offset between rackety and merganser is 70 milliseconds in this
case.  Note that nptq uses ms in the offset field and xntpdc uses seconds.

>into MBone. That's why I sent my mail.

It is possible that the behaviour you are seeing is a frequent
"stepping" of the clock on your local host.  This behaviour occurs
when the time obtained tends to wander a bit.  This has been observed
when you use only multicast to obtain time.

>If you can, check the clock on merganser and rackety.

The clocks on merganser and rackety are accurate to within a few
milliseconds if not better!  The table above for merganser shows that
it obtains its time from an MSF receiver with an offset as low as 1.8
ms.  Similarly, rackety indicates extremely good time with offsets
down in the microseconds regime.

Hope this helps,

Ajit

---

From: Petri Helenius <[email-masked]>
Date: Sat, 16 Mar 1996 21:07:47 +0200

> rackety and merganser directly, you get the following
I'm sorry for being too hasty on the conclusion, the picture was
upside down. My xntpd was resetting itself to thebrain which was
3 minutes off not because of rackety nor merganser. I was just
confused why it did that since thebrain is stratum 2 server.

Might be a bug in the xntpd itself?

 > down in the microseconds regime.
So what should happen if somebody starts leaking a wrong timesource
into NTP mcast group? I think xntpd should not believe it with worse
stratum and it being the only one telling a different story...

Pete

---

From: Piete Brooks <[email-masked]>
Date: Sat, 16 Mar 1996 20:04:29 +0000

> upside down. My xntpd was resetting itself to thebrain

That's not what I saw -- the info you sent showed it locked on to the
two S1s which agreed with each other, and ignoring the "false ticker" S2.

> which was 3 minutes off not because of rackety nor merganser.

Sounds reasonable.

> I was just confused why it did that since thebrain is stratum 2 server.

Why it did what ? Latched on to the two S1s ?

> Might be a bug in the xntpd itself?

There could be bugs in xntpd, but you've not supplied any evidence yet.

> into NTP mcast group?

It will be discarded as a false ticker.
That's why many sources are useful -- easier to spot false tickers.

> I think xntpd should not believe it

It won't !

> with worse stratum

Don't understand ...

By preference it won't use "worse" (higher) stratum clock.
But it doesn't use low stratum clocks regardless -- a number of S2s
can show an S1 to be a false ticker, and hence cause it to be ignored.

> and it being the only one telling a different story...

It will, and from what you sent, that was just what it did.
The one false ticker was duefully ignored.

[[ I think this should probably go offline ... ]]