OpenBSD Journal

adjtime(2), adjfreq(2), and ntpd Improvements

Contributed by mbalmer on from the timekeeping dept.

Otto Moerbeek, otto@, added code which gives us more accurate time and a generally smoother running system clock. Here is his story about the new adjfreq(2) call:

I recently imported frequency correction code from dragonfly, whith some changes: only do frequency compensation if the clock is synced, and a slightly diffent way of computing the linear regression. But let me explain a little more how things are done...

While mostly a userland hacker, recently I have been working on time code in the kernel: I helped mickey@ make time behave better on i386 SMP systems. I also have code to fix time going backwards on amd64 SMP systems, but this code is not ready for prime time yet. All this time stuff got me interested in ntpd(8) again.

ntpd(8) calls adjtime(2) to set the clock. adjtime(2) causes a temporary slowdown or speedup of the clock, until the requested adjustment is reached.

ntpd used to overcompensate, especially on systems with a large clock skew, caused by using old offset data from before a call to adjtime(2). I wrote code to correct that, which needed to be able to get the current amount of adjustment still underway. Sadly, the adjtime(2) did not have a way to get the current adjustment without setting one, so I added that.

While working on this I found out that DragonFlyBSD already had this overcompensating correction code and after evaluating it, I decided to use that version.

Then one big problem area remained: most computers have a clock that drifts: without being able to adjust the clock frequency, ntpd will be adjusting the time continuously, and between update intervals, time is not accurate.

I first looked at the ntp.org method of doing things, which i very complex and looks overengineered. Some people might need this, but in general I felt there should be a simpler method. Looking again at the DragonFlyBSD code, I found the basis of kernel changes to introduce a permanent skew in the clock. This code I could not use directly, since OpenBSD has a slightly different way of keeping time compared to DragonFlyBSD. But the idea was sound, and I found a way to implement it without using 64 bit divides, which would not have been acceptable in the hardlock() code, so adjfreq(2) was introduced: a system call that allows slight adjustments in the clock frequency.

The corresponding ntpd(8) changes are also based on the DragonFlyBSD code. The code computes a linear regression on the adjustments being done by ntpd(8) to compute a frequency correction. I took that code and made some changes: frequency corrections are only done if the clock is synced, and I changed a few things in the linear regression code to make it more clear. Various developers helped with testing, especially ckuethe@, who did very extensive tests and collected nice statistics.

All this now has the consequence that time will be much more accurate. From one of my test machines:

$ rdate -npv ntp1.nl.net                                                                                                  
Sat Jun 17 21:03:56 CEST 2006                                                                                             
rdate: adjust local clock by -0.000840 seconds                                                                            
$    

The reported offset will vary, but in general stays below 1ms. ntpd(8) is now even able to make the clock in my Mac mini behave:

Jun 17 21:17:46 fonzo ntpd[1912]: adjusting clock frequency by -0.190821 to 2877.689515ppm                                

This large correction is needed since the time base reported by Open Firmware is incorrect. Quite a few Macs suffer from this.

To try this, you will need a recent kernel, a recent libc and a recent ntpd. Snapshots made after Jun 17 should contain the full new functionality. It takes some time for ntpd to collect data to do the frequency correction, so be patient. The last step was to add code to remember the frequency adjustments between reboots.

(Comments are closed)


Comments
  1. By Anonymous Coward (24.72.118.207) on

    Wow. I'm beginning to wonder just how much more 'awesome' can be packed into a can of OpenBSD!

    OpenBSD might not have all the bells and whistles of some other ntp implementations, but it already exceeds my needs, and I imagine it exceeds the needs of most people.

    Super work. Gotta love the *BSD magic!

  2. By Anonymous Coward (198.208.251.24) on

    Now the trolls who whined about replacing unmaintainable cruft with a simple implementation because it is not as accurate can go sit in the corner.

    Comments
    1. By Anonymous Coward (66.11.66.41) on

      > Now the trolls who whined about replacing unmaintainable cruft with a simple implementation because it is not as accurate can go sit in the corner.

      What are you babbling about? Nothing was replaced. The only troll involved is you.

      Comments
      1. By CODOR (67.158.70.246) on

        > What are you babbling about? Nothing was replaced.

        It's replaced having to get ntpd from packages or ports...

        Comments
        1. By Anonymous Coward (70.27.15.123) on

          > > What are you babbling about? Nothing was replaced.
          >
          > It's replaced having to get ntpd from packages or ports...

          That's not replacing anything. Its still in ports. Maybe you should look up the definition of "replace". And nobody did complain, because it wasn't replacing. They always could and still can install ntp from ports if they want, so there's nothing to complain about.

          Comments
          1. By CODOR (67.158.70.246) on

            > That's not replacing anything. Its still in ports.

            You misunderstand. It's the steps required in getting a good NTP implementation running on OpenBSD that have been replaced, not the software itself...

  3. By Han (213.84.147.9) han@mijncomputer.nl on

    I'd really like it if ntpd check less. If you look at the logs you'll it checks about 6 servers every two minutes. I mean even if the clockspeed isn't corrected the maximum deviation is 0.2 second a day. I can live with that. In other words checking once a day would suffice for most people. That makes checking 6 servers every two minutes a bit hyperactive in my book.

    Comments
    1. By Sean (68.147.165.91) on

      >In other words checking once a day would suffice for most people. That makes checking 6 servers every two minutes a bit hyperactive in my book.
      >
      Well you could change the servers directive to point to only one or two time servers instead. What I don't understand is why ntpd feels the need to log every time it ajusts the clock. I haven't seen another ntp deamon do that since, well, who cares. All it does end up filling up logs really quickly so finding something important becomes a pain.

      I'd really like to be able to shut it up.

      Comments
      1. By Otto Moerbeek (213.84.84.111) otto@drijf.net on Otto Moerbeek

        > I'd really like to be able to shut it up.

        Again, making ntpd less chatty is work already done, but not yet committed.

        Comments
        1. By Amir S Mesry (66.23.227.241) on

          > > I'd really like to be able to shut it up.
          >
          > Again, making ntpd less chatty is work already done, but not yet committed.
          >

          I hope it's and option and not forced!

          Comments
          1. By Otto Moerbeek (82.197.192.49) otto@drijf.net on http://www.drijf.net

            > > > I'd really like to be able to shut it up.
            > >
            > > Again, making ntpd less chatty is work already done, but not yet committed.
            > >
            >
            > I hope it's and option and not forced!

            The goal is to make ntpd log very little, unless something interesting happens. Why would you need an option?

            Comments
            1. By Amir S Mesry (66.23.227.241) on

              > > > > I'd really like to be able to shut it up.
              > > >
              > > > Again, making ntpd less chatty is work already done, but not yet committed.
              > > >
              > >
              > > I hope it's and option and not forced!
              >
              > The goal is to make ntpd log very little, unless something interesting happens. Why would you need an option?

              The time adjustments for tracking purposes and when a peer becomes invalid and stays invalid would be helpful so in case the peer goes down and stays down(that is if I am interpreting the invalid statement that appears in the log file correctly).

            2. By Darrin Chandler (216.9.200.69) dwchandler@stilyagin.com on http://www.stilyagin.com/

              > > > > I'd really like to be able to shut it up.
              > > >
              > > > Again, making ntpd less chatty is work already done, but not yet committed.
              > > >
              > >
              > > I hope it's and option and not forced!
              >
              > The goal is to make ntpd log very little, unless something interesting happens. Why would you need an option?

              Adjusting the time is interesting, especially with the changes you've implemented. By watching the "chatty" ntpd logs I know which of my machines keep good time on their own, as in adjfreq would hardly be needed. I sync that machine with outside sources and use it as a local master for my other boxen.

              I hope the new, quieter logging still gives enough info to be useful for such purposes...

    2. By Otto Moerbeek (213.84.84.111) otto@drijf.net on Otto Moerbeek

      > I'd really like it if ntpd check less.

      I have diff already in my tree for that. You know, patience is a virtue ;-)

      Comments
      1. By Han (213.84.147.9) han@mijncomputer.nl on

        > > I'd really like it if ntpd check less.
        >
        > I have diff already in my tree for that.

        You rock Otto. May I test-drive it? :-)

        > You know, patience is a virtue ;-)

        This is the first time I heard about it... And I haven't heard anyone complain about hyperactiveness either. Though I did read a story about a ntp-server which got completely overloaded because some windows application choose that one for no real reason.

  4. By Anonymous Coward (156.34.230.212) on

    It is kind of neat that we are getting some stealable code from DragonFly. Can't have too many sources of code and ideas, or too many BSDs apparently!

  5. By Anonymous Coward (203.58.120.11) on

    what happened to timecounters? there was a flurry of activity around the time of c2k4 and then silence - did they turn out to be broken or ...?

  6. By phessler (209.204.157.100) on

    Earlier today I upgraded my ntp server to -current, with the new ntpd code (including the adjtime/adjfreq changes). What a difference!

    Beforehand, 0.1 sec off. A few hours ago it was 0.01, currently its 0.001. A little under 11 hours. *Very* nice.

    I'm a member of pool.ntp.org, and they keep some very nice graphs of the previous week's behaivour. Mine is listed at http://www.pool.ntp.org/scores/209.204.157.98 You'll notice that my offset has jittered quite a bit, until the thin blue line just above 'Sun'. That was when I activated the new ntpd. I'll be very interested to see what the offset graph looks like in a few days when that 600ms peak falls off.

    This is on
    kern.version=OpenBSD 3.9-current (GENERIC) #971: Thu Jun 22 21:38:10 MDT 2006
        deraadt@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC
    which is an Apple iBook connected to a DSL line, sitting on the upper shelf in my hall closet.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]