Re: NTP driftness oddity
* Otto Moerbeek o...@drijf.net [2011-06-03 08:12]: ntpd does not jump. if invoked with -s it actually does, once, at startup: set local clock to Thu Jun 2 19:56:25 IST 2011 (offset 119.421739s) It adjusts by running the clock faster or slower. that is of course true, after startup. The offsets you are seeing are newly caclulated differences between what ntpd thinks is the time and the clocks time. yup -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: NTP driftness oddity
On Thu, Jun 02, 2011 at 11:21:41PM -0500, Corey wrote: On 06/02/2011 02:00 PM, FRLinux wrote: Hello, I am running OpenBSD 4.9 on a soekris which was in a closet for a few months. NTP is slowly drifting back the time to normal but I am wondering if anyone has seen this. It seems that every 5mn, the time gap decreases, this is not a behavior I have seen. Running from the command line with fix from startup worked: # ntpd -d -v -s ntp engine ready reply from 193.1.193.135: offset 119.421739 delay 0.003728, next query 9s set local clock to Thu Jun 2 19:56:25 IST 2011 (offset 119.421739s) reply from 193.1.193.135: offset -0.86 delay 0.003210, next query 5s Is that an expected behavior? Jun 2 08:31:03 ice ntpd[21279]: adjusting local clock by 322.878786s Jun 2 08:33:10 ice ntpd[21279]: adjusting local clock by 322.243729s Jun 2 08:34:12 ice ntpd[21279]: adjusting local clock by 321.938780s Jun 2 08:37:24 ice ntpd[21279]: adjusting local clock by 320.978779s [...] Jun 2 19:47:10 ice ntpd[24926]: adjusting local clock by 121.228150s Jun 2 19:48:42 ice ntpd[18164]: adjusting local clock by 121.128741s Jun 2 19:51:58 ice ntpd[18164]: adjusting local clock by 120.154673s Cheers, Steph Yes, on my Soekris net5501 that was out of commission for a month (but powered up) until I got the time to upgrade to a 4.9 snapshot. It did this for about 12 hours or so. Proper behavior I believe, to avoid confusing the system (or worse) with large clock jumps. ntpd does not jump. It adjusts by running the clock faster or slower. The offsets you are seeing are newly caclulated differences between what ntpd thinks is the time and the clocks time. -Otto
Re: NTP driftness oddity
Thanks for all the replies guys, it makes sense now :) Steph
NTP driftness oddity
Hello, I am running OpenBSD 4.9 on a soekris which was in a closet for a few months. NTP is slowly drifting back the time to normal but I am wondering if anyone has seen this. It seems that every 5mn, the time gap decreases, this is not a behavior I have seen. Running from the command line with fix from startup worked: # ntpd -d -v -s ntp engine ready reply from 193.1.193.135: offset 119.421739 delay 0.003728, next query 9s set local clock to Thu Jun 2 19:56:25 IST 2011 (offset 119.421739s) reply from 193.1.193.135: offset -0.86 delay 0.003210, next query 5s Is that an expected behavior? Jun 2 08:31:03 ice ntpd[21279]: adjusting local clock by 322.878786s Jun 2 08:33:10 ice ntpd[21279]: adjusting local clock by 322.243729s Jun 2 08:34:12 ice ntpd[21279]: adjusting local clock by 321.938780s Jun 2 08:37:24 ice ntpd[21279]: adjusting local clock by 320.978779s [...] Jun 2 19:47:10 ice ntpd[24926]: adjusting local clock by 121.228150s Jun 2 19:48:42 ice ntpd[18164]: adjusting local clock by 121.128741s Jun 2 19:51:58 ice ntpd[18164]: adjusting local clock by 120.154673s Cheers, Steph
Re: NTP driftness oddity
FRLinux frlinux () gmail ! com wrote: NTP is slowly drifting back the time to normal but I am wondering if anyone has seen this. From adjtime(2): The skew used to perform the correction is generally a fraction of one percent. Every adjustment brings the local clock closer to the desired time - the immediately subsequent delta (difference) becomes concommitantly smaller and the next adjustment (the fraction of one percent of the remaining difference) is ... therefore smaller. Surely this is not an oddity though but very much desired - the jumps should be as small as possible to keep time dependent functions happy, logs readable, etcetera. So the resultant smaller difference after the 321s adjustment is taken advantage of as soon as possible - at the very next jump - using a value of 320s ... That's how I read it and it fits with what would seem to be a reasonable goal. http://marc.info/?l=openbsd-miscm=121638309016429w=2 Best wishes.
Re: NTP driftness oddity
On 06/02/2011 02:00 PM, FRLinux wrote: Hello, I am running OpenBSD 4.9 on a soekris which was in a closet for a few months. NTP is slowly drifting back the time to normal but I am wondering if anyone has seen this. It seems that every 5mn, the time gap decreases, this is not a behavior I have seen. Running from the command line with fix from startup worked: # ntpd -d -v -s ntp engine ready reply from 193.1.193.135: offset 119.421739 delay 0.003728, next query 9s set local clock to Thu Jun 2 19:56:25 IST 2011 (offset 119.421739s) reply from 193.1.193.135: offset -0.86 delay 0.003210, next query 5s Is that an expected behavior? Jun 2 08:31:03 ice ntpd[21279]: adjusting local clock by 322.878786s Jun 2 08:33:10 ice ntpd[21279]: adjusting local clock by 322.243729s Jun 2 08:34:12 ice ntpd[21279]: adjusting local clock by 321.938780s Jun 2 08:37:24 ice ntpd[21279]: adjusting local clock by 320.978779s [...] Jun 2 19:47:10 ice ntpd[24926]: adjusting local clock by 121.228150s Jun 2 19:48:42 ice ntpd[18164]: adjusting local clock by 121.128741s Jun 2 19:51:58 ice ntpd[18164]: adjusting local clock by 120.154673s Cheers, Steph Yes, on my Soekris net5501 that was out of commission for a month (but powered up) until I got the time to upgrade to a 4.9 snapshot. It did this for about 12 hours or so. Proper behavior I believe, to avoid confusing the system (or worse) with large clock jumps. As a side note, the CMOS clocks on this thing is even worse than the crappy clocks I see on most desktops. On the plus side, and totally unrelated to this topic, it tcpbench'd at 60+ Mbps outbound and 90+ Mbps inbound on each port (one at a time) -- maybe a result of that MCLGETI dynamic-ring work? More than enough for my DSL line. It's gonna be interesting to put that snap (or maybe a newer one by now) on the Netgate Hamakua DTs I have sitting here :) C
