Even after comiling latest clockspeed (0.62-r3) with pooh ~ # CFLAGS="-march=i386 -pipe" CXXFLAGS=$CFLAGS emerge clockspeed sntpclock then spits a number of annoying warning before doing its job: pooh ~ # sntpclock 192.92.129.13 | clockview sntpclock: warning: unable to read clock: bad response format sntpclock: warning: unable to read clock: bad response format sntpclock: warning: unable to read clock: bad response format sntpclock: warning: unable to read clock: bad response format sntpclock: warning: unable to read clock: bad response format sntpclock: warning: unable to read clock: bad response format sntpclock: warning: unable to read clock: bad response format sntpclock: warning: unable to read clock: bad response format before: 2005-11-16 18:30:46.621091000000000000 after: 2005-11-16 18:31:03.551627499852441251 Sometimes completely fails with this last report: sntpclock: fatal: time uncertainty too large I could reproduce this on two 2005.1 machines: an P4 and a P3 one. Reproducible: Always Steps to Reproduce: 1.emerge clockspeed 2.# sntpclock ntp.ser.ver.ip | clockview Actual Results: repeated warnings of this kind: "sntpclock: warning: unable to read clock: bad response format" sometimes completely failing with: "sntpclock: fatal: time uncertainty too large" Expected Results: directly doing its job to dump the time difference via clockview: pooh ~ # sntpclock 192.92.129.13 | clockview before: 2005-11-16 18:30:46.621091000000000000 after: 2005-11-16 18:31:03.551627499852441251 Portage 2.0.51.22-r3 (default-linux/x86/2005.1, gcc-3.4.4, glibc-2.3.5-r3, 2.6.14-gentoo-r2 i686) ================================================================= System uname: 2.6.14-gentoo-r2 i686 Pentium III (Coppermine) Gentoo Base System version 1.6.13 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.3.5, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium3 -pipe -Os -fforce-addr -fomit-frame-pointer -ftracer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium3 -pipe -Os -fforce-addr -fomit-frame-pointer -ftracer -fvisibility-inlines-hidden" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms" GENTOO_MIRRORS="http://gentoo.itdnet.net/gentoo ftp://gentoo.itdnet.net/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local" SYNC="rsync://gentoo.itdnet.net/gentoo-portage" USE="x86 alsa apm arts avi berkdb bitmap-fonts bzip2 crypt cups eds emboss encode expat foomaticdb fortran gdbm gif gstreamer imlib ipv6 jpeg libg++ libwww mad mikmod motif mp3 mpeg mysql ncurses nls nptl ogg oggvorbis opengl oss pam pcre pdflib perl png python quicktime readline sdl spell ssl tcpd truetype truetype-fonts type1-fonts udev vorbis xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
good people from the clockspeed list pointed me to the source of those warnings: Toby Betts: "The messages you're seeing: sntpclock: warning: unable to read clock: bad response format sntpclock: fatal: time uncertainty too large have more to do with your network and your choice of NTP server than with the sntpclock software itself. The Network Time Protocol uses UDP, a connectionless data transfer method with no built-in system of congestion control. What this means is that sometimes UDP packets get to their intended destination and sometimes they don't. Under very heavy traffic, sntpclock won't he able to communicate with the NTP server in a timely manner and thus won't have enough information to adjust the system clock correctly. It will warn you and if things don't improve, eventually die. Every time I've seen these messages, it's been because of high traffic or a dodgy NTP server." Stupid me. So, closing this as invalid :-\
