[ntp:questions] Re: where should we update sys_rootdispersion?

Dongling Duan duan at cisco.com
Sat Sep 6 22:55:14 UTC 2003

"David L. Mills" wrote:
> -dongling,
> Over the ten years since rfc-1305 some implementation details have
> evolved, so don't treat the procedure functional description as
> concrete. However, and as I restated in a recent message on this list,
> the dispersion increases at constant rate, but is reset when a clock
> update is received. Details are in the architecture briefing on the NTP
> project page linked from www.ntp.org.

Yeah. In the ntpv4 implementation, I saw sys_rootdispersion increases at
constant rate CLOCK_PHI in adj_host_clock() and is reset in

> The usual cause of elevated dispersion is either dropped packets or no
> updates received for a very long time.

  What I observed is that in ntpv4 implementation for each arrive ntp
packet from server, we call clock_filter, clock_select which call
clock_update() -> local_clock(). But for some packets, I saw
clock_update get called but we did not call local_clock so that
sysroot_dispersion did not reset (I think the reason is that either
sys_peer->pollsw is FALSE or sys_peer->burst > 0). Even it get reset, It
seems that it was reset to a big value. I think the main reason is that
sys_jitter (sys_error in old implementation of v4) is very big somehow,
which cause sysroot_dispersion is hundreds or thousands. 

   I saw peer has a field called pollsw, what's the purpose of this
filed? I think version 3 implementation do not have this field.

   I have a isolated topology as following:

               |                  |
               |                  |
               |                  |
               V                  V

On boxA:  configure boxA is a master with stratum as 7
On boxb:  configure boxA as server and boxC as a peer
On boxc:  configure boxA as server and boxB as a peer

   I do two test: 1. make sure all three boxs are synced; 2. on all box,
make sure all peer associations are reachable via checking peer->reach
field is not zero.

   I noticed that sometime on boxB there is no reachability to active
peer boxC. peer->reach is always zero and peer->refid is always
After further debugging I notice all the packets from boxC to boxB are
dropped because header validation test8 failed. Once I even wait for an
hour, not even one packet from boxC is accepted by boxB. While boxC is
synched to boxA without any issue. It is intermittent. I did not see
this happens every time. 

   I would like to know:  first, is the second test (reachability) a
valid test? Second, how much time we need wait to check the reachability
(sometime even an hour is not enough)? Third, it seems that after
sometime (do not know how long and it seems that it is different each
time) all peer associations become reachable. Is this normal? I do not
understand how come the other side send packets with that big
rootdispersion. Is something wrong in some ntpv4 code or system just
need more time to become stable?

   this is the whole story that why I try to see how sys_rootdispersion
get updated.

thanks very much for any help!


> Dave
> donglingd at hotmail.com wrote:
> >
> > Hi,
> >
> >    could somebody let me know in which procedure we should update
> > sys_rootdispersion? I saw some old code update sys_rootdispersion in
> > clock_update procedure after calling clock_select() while ntpv4 code update
> > this system veriable in local_clock(). Which one is correct?
> >
> >     I saw some how sys_rootdispersion is very big which cause all the
> > packets send from this boxs are dropped by remote peer since header test8
> > failed. I try to figure out how come sys_rootdispersion become that big.
> > could anybode let me know how sys_rootdispersion is supposely caculated and
> > update? what could be the cause?
> >
> > Thanks so much!
> > -dongling
> >
> > _________________________________________________________________
> > Express yourself with MSN Messenger 6.0 -- download now!
> > http://www.msnmessenger-download.com/tracking/reach_general

More information about the questions mailing list