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