Return to solaris.xtra.4023118 CVS log

Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / ntp / html / hints

ntp 4.2.6p5

    1:  Bug Id: 4023118
    2:  Category: kernel
    3:  Subcategory: other
    4:  State: integrated
    5:  Synopsis: sun4u doesn't keep accurate time
    6:  Description:
    7: 
    8: [ bmc, 12/20/96 ]
    9: 
   10: The clock on a sun4u drifts unacceptably.  On a typical 143 mHz Ultra,
   11: the clock took 1.0001350 seconds to count 1 second.  While this may seem
   12: trivial, it adds up quickly.  In this case, the TOD chip will have to
   13: pull the clock forward by 2 seconds every 4 hours and 7 minutes.
   14: This drift rate is so high, that the clock is close to being too broken
   15: for NTP to guarantee correctness (in order for NTP's mechanism to work,
   16: it must be assured that the local clock drifts no more than 20 ms in 64
   17: seconds;  this particular 143 mHz Ultra will drift by nearly 9 ms in that
   18: period).  This problem has been reproduced on virtually all sun4u
   19: classes.
   20: 
   21: The fundamental problem lies in the kernel's perception of ticks per
   22: second.  The PROM is responsible for determining this figure exactly,
   23: and the kernel extracts it into the variable cpu_tick_freq.  On sun4u's,
   24: this number is disconcertingly round:  143000000, 167000000, 248000000,
   25: etc.  Indeed, a simple experiment revealed that these numbers were
   26: quite far from the actual ticks per second.  Typical was the 143 mHz
   27: Ultra which was discovered to tick around 142,980,806 (+/- 10) times
   28: per second.
   29: 
   30:  Work around:
   31: 
   32:         Integrated in releases: s297_27
   33:  Duplicate of:
   34:  Patch id:
   35:  See also:
   36:  Summary: