By design, the clock servo tries to get the 0 crossing to occur at the time of the subsequent poll. In my attempts to learn ntp servo operation over the years from Dave Mills, I have yet to find a single area which he did not consider. I may disagree at times with how he addressed the problem but I have found his 40+ years of network synch to be pretty comprehensive :-)
-----Original Message----- From: questions-bounces+greg.dowd=microsemi....@lists.ntp.org [mailto:questions-bounces+greg.dowd=microsemi....@lists.ntp.org] On Behalf Of Charles Elliott Sent: Wednesday, April 09, 2014 4:31 PM To: questions@lists.ntp.org Subject: [ntp:questions] Has anyone thought about this? In ntp_proto.c the delay and offset are computed as follows: t34 = t3 - t4; t21 - t2 - t1; p_del = t21 - t34; offset = (t21 - t3)/2.; where t1 = client send time t2 = server receive time t3 = server send time t4 = client receive time. However, t1 and t4 are not really in seconds if the client clock is slewing. That is, the difference t4 - t1 will be shorter than seconds if the clock is being slowed down and larger if the clock is being sped up. Hence the clock slew may be a source of variation that is not presently being accounted for. One some systems the frequency of the Performance Counter (PC) is constant because it is driven by the High Performance Event Timer (HPET). And according to one article on the Internet, the PC can be made to be driven by the HPET on Win 8 by this edit: " run cmd as admin and paste 'bcdedit /set {current} useplatformclock Yes'". Would NTPD have less variation in offset and delay if, say, t4 were measured by the difference in PC readings between the time t1 is measured and the time T4 is presently measured? Charles Elliott _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions