On Fri, Dec 30, 2011 at 09:28, Harlan Stenn <st...@ntp.org> wrote: > Paul wrote: >> I installed NTP v4.2.7p244 on my Sun SPARC + Solaris 9 system a couple >> of days ago, >> and now I have a message in the NTP log file that I've never seen >> before: >> >> 30 Dec 05:48:51 xntpd[23840]: ts_min 1325220531.588564214 ts_prev >> 1325220531.588563380 ts 1325220531.588711963 >> 30 Dec 05:48:51 xntpd[23840]: sys_fuzz 834 nsec, this fuzz 0.000000136 >> 30 Dec 05:48:51 xntpd[23840]: get_systime prev result >> 0xd2a7c133.96b79e2c is 0.000027187 later than 0xd2a7c133.96b5d60b >> >> Can anybody tell me what the message means? > > That's a warning message from get_systime(). Dave Hart can say more, > and I think it means that a *very* slightly later call to get_systime() > managed to come up with a *very* slightly earlier time, based on the > random nature of the "fuzz" that we add below the precision floor.
That's basically correct, except I'd leave out the "very"s and the explanation starting with "based on". ts_* are all struct timespec (nanosecond resolution). ts_prev is the ts value from the previous invocation, likely the same value the OS getclock() or similar provided at that earlier point. ts_min is ts_prev + sys_fuzz (minimum measured time to read clock). ts is the current clock reading, possibly bumped to ts_min if this clock reading managed to happen faster than the measurement reads (which did not happen in this case). ts is 148583 nsec later than ts_prev, or 149 usec. This is more than 2 orders of magnitude larger than sys_fuzz. After the timespec to convert to fixed-point NTP 32:32 timestamp is determined in ts, it is converted to fixed point, a random fuzz is generated between 0 and sys_fuzz, also converted to fixed point, and added to the converted timestamp in result. At this point, given that sequential timespec values are increasing by at least sys_fuzz, and converted fixed-point timestamps have a fuzz less than sys_fuzz, one might reasonably hope sequential fixed-point values are also strictly increasing. The warning you see is because they were not, apparently, and in particular here the later clock reading after fixed-point conversion and fuzzing is 27 usec earlier than the earlier clock reading. This seems like nonsense to me, and may be exposing a compiler or other lower-level bug, or more likely exposing that this logic isn't doing quite what is intended. Do you see this message at startup, or later? Every time, mostly, sometimes? I know this paranoid check has at least one bug, but I thought it was good until the next NTP fixed-point 32:32 rollover in 2036, when it would complain a very low valued fixed-point timestamp does not precede a very high-valued one from before the rollover. Thanks for testing ntp-dev, Dave Hart _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
