NTP driftness oddity

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

NTP driftness oddity

FRLinux-2
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.000086 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

Reply | Threaded
Open this post in threaded view
|

Re: NTP driftness oddity

David Walker-16
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-misc&m=121638309016429&w=2

Best wishes.

Reply | Threaded
Open this post in threaded view
|

Re: NTP driftness oddity

Corey-43
In reply to this post by FRLinux-2
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.000086 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

Reply | Threaded
Open this post in threaded view
|

Re: NTP driftness oddity

Otto Moerbeek
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.000086 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

Reply | Threaded
Open this post in threaded view
|

Re: NTP driftness oddity

FRLinux-2
Thanks for all the replies guys, it makes sense now :)

Steph

Reply | Threaded
Open this post in threaded view
|

Re: NTP driftness oddity

Henning Brauer
In reply to this post by Otto Moerbeek
* Otto Moerbeek <[hidden email]> [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, [hidden email], [hidden email]
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting