[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ntp-bugs
Subject:    [ntp:bugs] [Bug 1074] New: ntpd 4.2.4 on linux 2.6.18 time_freq bug
From:       simon d hughes via the NTP Bugzilla <bugzilla () ntp ! org>
Date:       2008-10-08 15:45:56
Message-ID: 20081008154556.5189039912 () mail2 ! ntp ! org
[Download RAW message or body]

http://bugs.ntp.org/1074

           Summary: ntpd 4.2.4 on linux 2.6.18 time_freq bug for small mu~60
           Product: ntp
           Version: 4.2.4
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: ntpd
        AssignedTo: stenn@ntp.org
        ReportedBy: simon.hughes@ipaccess.com
                CC: bugs@ntp.org


>From the data I’ve collected I can see there is a problem with ntpd 4.2.4 
running on the linux 2.6.18, which is the kernel I’m using. My questions 
concern the best way to fix it. Let me state the problem as I understand it:

 

In <kernel_src_root>/kernel/time.time.c from 2.6.18:

 

 

                if (time_status & STA_FREQHOLD || time_reftime == 0)

                    time_reftime = xtime.tv_sec;

                mtemp = xtime.tv_sec - time_reftime;

                time_reftime = xtime.tv_sec;

                if (time_status & STA_FLL) {

                    if (mtemp >= MINSEC) {

                      ltemp = (time_offset / mtemp) << (SHIFT_USEC -

                                                SHIFT_UPDATE);

                      time_freq += shift_right(ltemp, SHIFT_KH);

                  } else /* calibration interval too short (p. 12) */

                        result = TIME_ERROR;

                } else {      /* PLL mode */

                    if (mtemp < MAXSEC) {

                      ltemp *= mtemp;

                      time_freq += shift_right(ltemp,(time_constant +

                                           time_constant +

                                           SHIFT_KF - SHIFT_USEC));

                  } else /* calibration interval too long (p. 12) */

                        result = TIME_ERROR;

                }

                time_freq = min(time_freq, time_tolerance);

                time_freq = max(time_freq, -time_tolerance);

            } /* STA_PLL */

          } /* txc->modes & ADJ_OFFSET */

 

 

Under the following conditions:

-          Using ntpd 4.2.4 on linux 2.6.18.

-          When sys_poll > 10 so that STA_FLL is set (ntp_loopfilter.c)

-          From test data, I observe ntp_loopfilter.c::local_clock() is 
occasionally called with small values of mu (mu~45) when the polling exponent 
is, for example sys_poll~13. Lets assume that such a call has already taken 
place, so that time_reftime in the kernel has been just reset (this comment is 
referred to as *A* below).

-          A second call to ntp_loopfilter.c::local_clock() ntp_adjtime() is 
received with mu~2^sys_poll. 

 

Then:

-          In the kernel, time.c::mtemp is computed to be very small as the 
kernel remembers the last time it was called (in time_reftime) to be very 
recent (due to *A*)

-          ltemp =(time_offset/mtemp) << (shift_usec-shift_update) is very large

-          time_freq += shift_right(ltemp, shift_kh) produces a ~1000ppb change 
in time_freq.

 

 

I am aware of public postings regarding the problems with ntpd on the linux 
kernel. However, I find the discussions confusing and inconclusive in relation 
to this problem. 

 

There appears to be a number of alternatives to fixing this problem, but I’m 
not sure which is most appropriate or advantageous. 

-          make MINSEC larger to be ~2^sys_poll

-          bailing out of ntp_loopfilter.c::local_clock() if mu << 2^sys_poll 
in FLL mode. Such updates must be spurious.

 

 

I don’t really understand (yet) how mu can be correct (is large) for so many 
calls to local_clock() and then a small value is computed:

mu = peer->epoch - sys_clocktime;

 

How can this happen?

 

Any guidance as to the preferred way to fix this problem would be gratefully 
appreciated? 

 

 

Thanks

Simon

-- 
simon d hughes <simon.hughes@ipaccess.com>



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


_______________________________________________
bugs mailing list
bugs@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/bugs

[prev in list] [next in list] [prev in thread] [next in thread]