Return to solaris.xtra.4023118 CVS log | Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / ntp / html / hints |
1.1 ! misho 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: