Annotation of embedaddon/ntp/html/hints/solaris.xtra.4023118, revision 1.1
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:
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>