lkml.org 
[lkml]   [1998]   [Dec]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
SubjectRe: NTP accuracy?
Date
I wrote:
>
> As long as those 10 usecs are symmetric, there's no principal reason why it
> shouldn't.
>
> AFAIK, that is.
>
Further knowledge has been revelaed to me by the eclectic process, known to
only a select few, of reading actually-documented code and asking stupid
questions. ;-)

If you want 1 usec accuracy, you need something like a nanosecond clock in
the kernel. Linux 2.1.current doesn't have one yet, mainly because nobody
has been tracking the NTP-related kernel code available in
<ftp://ftp.udel.edu/pub/ntp/nanokernel.tar.Z>.

Linux also needs something like an ntp_gettime() system call which returns
current nanosecond time as well as the current clock accuracy. The current
ntp-4 code requires the call (but only for configuration) before it admits
that the kernel might have a correct kernel PLL, which doesn't make much
sense (Dave Mills disagrees -- it's a moot point, however, because we need
a new syscall to read a struct timespec from the kernel anyway; currently
there doesn't seem to be any system call which can do this).

The accuracy information which ntp_gettime() wants can be read via
__adjtimex() equally easily, so my question is whether there is any
standardized interface which works like gettimeofday() but returns
nanoseconds, or should we just bite the bullet, call the thing
ntp_gettime(), and be done with it?


I don't have time to port the NTP kernel stuff, unfortunately. Somebody
else please step forward.


In the meantime, here's an updated patch to make ntp-4.0.90a configure
correctly with linux 2.1.latest. You'll need to delete config.cache and
run autoconf and configure after applying it.

Index: base.6/ntpd/Makefile.am
--- base.6/ntpd/Makefile.am Sun, 22 Nov 1998 06:29:40 +0100 smurf (net_time_ntp/g/12_Makefile.a 1.1.1.3 664)
+++ noris.6(w)/ntpd/Makefile.am Sun, 22 Nov 1998 06:31:25 +0100 smurf (net_time_ntp/g/12_Makefile.a 1.1.1.4 664)
@@ -1,6 +1,6 @@
#AUTOMAKE_OPTIONS = ../util/ansi2knr no-dependencies
AUTOMAKE_OPTIONS = ../util/ansi2knr
-bin_PROGRAMS = ntpd
+sbin_PROGRAMS = ntpd
INCLUDES = -I$(top_srcdir)/include
# LDADD might need RESLIB and ADJLIB
LDADD = version.o @LIBPARSE@ ../libntp/libntp.a #-lm
Index: base.6/configure.in
--- base.6/configure.in Sun, 22 Nov 1998 06:29:40 +0100 smurf (net_time_ntp/j/32_configure. 1.6 664)
+++ noris.6(w)/configure.in Wed, 02 Dec 1998 20:56:17 +0100 smurf (net_time_ntp/j/32_configure. 1.7 664)
@@ -45,7 +45,7 @@
# CFLAGS="$CFLAGS -Wtraditional"
CFLAGS="$CFLAGS -Wshadow"
CFLAGS="$CFLAGS -Wwrite-strings"
- CFLAGS="$CFLAGS -Wconversion"
+ # CFLAGS="$CFLAGS -Wconversion"
CFLAGS="$CFLAGS -Wpointer-arith"
CFLAGS="$CFLAGS -Wcast-qual"
# CFLAGS="$CFLAGS -Wcast-align"
@@ -1060,17 +1060,17 @@

AC_CACHE_CHECK([availability of ntp_{adj,get}time()], ac_cv_var_ntp_syscalls,
[ac_cv_var_ntp_syscalls=no
- case "$ac_cv_func___adjtimex$ac_cv_func___ntp_gettime" in
- yesyes)
+ case "$ac_cv_func___adjtimex" in
+ yes)
ac_cv_var_ntp_syscalls=libc
;;
- *) case "$ac_cv_func_ntp_adjtime$ac_cv_func_ntp_gettime" in
- yesyes)
+ *) case "$ac_cv_func_ntp_adjtime" in
+ yes)
ac_cv_var_ntp_syscalls=libc
;;
*) AC_EGREP_CPP(yes,
[#include <sys/syscall.h>
-#if defined(SYS_ntp_gettime) && defined(SYS_ntp_adjtime)
+#if defined(SYS_ntp_adjtime)
yes
#endif
], ac_cv_var_ntp_syscalls=kernel)
@@ -2288,8 +2288,8 @@

AC_SUBST(MAKE_NTPTIME)
AC_CACHE_CHECK(if we want and can make the ntptime utility, ac_cv_make_ntptime,
-[case "$ac_cv_var_kernel_pll$ac_cv_hdr_def_sigsys" in
- yes*)
+[case "$ac_cv_func_ntp_gettime$ac_cv_func___ntp_gettime" in
+ *yes*)
ans=yes
;;
*)
--
Matthias Urlichs | noris network GmbH | smurf@noris.de | ICQ: 20193661
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.041 / U:1.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site