Hi, I’ve got a package of OpenNTPD with the adjtimex patch applied, but have both problems too:
• negative delays ⇒ clearly a Xen problem, only happens with machines in the LAN though (kind of defeats having a local bunch of NTP servers…) • _positive_ adjustments work, but _negative_ (i.e. if the clock is ahead of time at the time ntpd is started) don’t (if I use (MirBSD) rdate(8) to set it, it’s kept mostly in line – your theory about a maximum adjustment has merit?) Note that xen.independent_wallclock=1 and the clocksource is jiffies for the Xen domU, tsc (mostly), hpet or acpi_pm in other systems, but that doesn’t seem to matter EXCEPT when changing the clocksource at run-time after ntpd has run, the clock goes mad (so _some_ kind of adjfreq seems to have been done). http://www.freewrt.org/~tg/debs/dists/lenny/wtf/pkgs/openntpd/openntpd_3.9p1-7wtf8.dsc Did you get any more information? bye, //mirabilos -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.” -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
