Date: Tue, 27 Aug 2002 11:27:28 -0600 From: "Jeff W. Boote" <boote@internet2.edu> To: FreeBSD-gnats-submit@FreeBSD.org Subject: kern/42089: ntp_gettime returns time in wrong scale Message-ID: <3D6BB680.65E122C@internet2.edu>
next in thread | raw e-mail | index | archive | help
>Number: 42089 >Category: kern >Synopsis: ntp_gettime returns time in wrong scale >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Aug 27 10:30:03 PDT 2002 >Closed-Date: >Last-Modified: >Originator: Jeff W. Boote >Release: FreeBSD 4.5-RELEASE i386 >Organization: Internet2 - http://www.internet2.edu/ >Environment: System: FreeBSD cronus.boote.net 4.5-RELEASE FreeBSD 4.5-RELEASE #0: Mon Jan 28 14:31:56 GMT 2002 murray@builder.freebsdmall.com:/usr/src/sys/compile/GENERIC i386 >Description: The fractional component of the ntptimeval.time structure is always currently returned in nanoseconds from the ntp_gettime system call. It should be returned in microseconds if the STA_NANO flag is not set. (See the ntp_adjtime() system call.) I have verified that this is the case in a recent exchange with David Mills. (the ntp author) http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=3D651789.CE68D7D%40internet2.edu&rnum=1&prev=/groups%3Fq%3Dfreebsd%2Bntp%2BSTA_NANO%26ie%3DISO-8859-1%26hl%3Den >How-To-Repeat: The bug can be demonstrated using the /usr/sbin/ntptime command line utility. First call ntptime to put the clock in "microsecond" mode: % /usr/sbin/ntptime -M # as root (Ignore the timestamps reported this time around because they are reported before the actual call to ntp_adjtime().) Now, call ntptime again: % /usr/sbin/ntptime The output should look similar to: >Fix: The simplest fix would be to hardcode the value of STA_NANO so that it is always returned from ntp_adjtime()'s timex.status field. However, as Mills points out, NTPv3 would no longer work then. However - NTPv3 will not currently work either since NTPv3 only understands microseconds, and FreeBSD is not currently doing microseconds... The next "simplest" fix would be to scale the return to microseconds unless STA_NANO is set. Basically, you would just need to re-include the code from the original nanokernel distribution from Mills. >Release-Note: >Audit-Trail: >Unformatted: >cronus# ntptime >ntp_gettime() returns code 0 (OK) > time c11532aa.adff5000 Mon, Aug 26 2002 17:05:14.679, (.141188861), > maximum error 675321 us, estimated error 6559 us, TAI offset 0 >ntp_adjtime() returns code 0 (OK) > modes 0x0 (), > offset 3975.000 us, frequency 83.724 ppm, interval 1 s, > maximum error 675321 us, estimated error 6559 us, > status 0x1 (PLL), > time constant 8, precision 0.000 us, tolerance 496 ppm, You will notice that in the date stamp the time is listed as: 17:05:14.679 - so the fractional portion is reported as .679 from the "prettydate" function. However, the fractional part being reported directly from ntp_gettime in the ()'s is .141188861 It is overflowing in prettydate because "prettydate" expects usecs, and ntp_gettime is reporting nanoseconds. This is easy to see if you look at /usr/src/sys/kern/kern_ntptime.c - it calls nanotime() to return this value. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D6BB680.65E122C>