1258945Sroberto Bug Id: 4023118 2258945Sroberto Category: kernel 3258945Sroberto Subcategory: other 4258945Sroberto State: integrated 5258945Sroberto Synopsis: sun4u doesn't keep accurate time 6258945Sroberto Description: 7258945Sroberto 8258945Sroberto[ bmc, 12/20/96 ] 9258945Sroberto 10258945SrobertoThe clock on a sun4u drifts unacceptably. On a typical 143 mHz Ultra, 11258945Srobertothe clock took 1.0001350 seconds to count 1 second. While this may seem 12258945Srobertotrivial, it adds up quickly. In this case, the TOD chip will have to 13258945Srobertopull the clock forward by 2 seconds every 4 hours and 7 minutes. 14258945SrobertoThis drift rate is so high, that the clock is close to being too broken 15258945Srobertofor NTP to guarantee correctness (in order for NTP's mechanism to work, 16258945Srobertoit must be assured that the local clock drifts no more than 20 ms in 64 17258945Srobertoseconds; this particular 143 mHz Ultra will drift by nearly 9 ms in that 18258945Srobertoperiod). This problem has been reproduced on virtually all sun4u 19258945Srobertoclasses. 20258945Sroberto 21258945SrobertoThe fundamental problem lies in the kernel's perception of ticks per 22258945Srobertosecond. The PROM is responsible for determining this figure exactly, 23258945Srobertoand the kernel extracts it into the variable cpu_tick_freq. On sun4u's, 24258945Srobertothis number is disconcertingly round: 143000000, 167000000, 248000000, 25258945Srobertoetc. Indeed, a simple experiment revealed that these numbers were 26258945Srobertoquite far from the actual ticks per second. Typical was the 143 mHz 27258945SrobertoUltra which was discovered to tick around 142,980,806 (+/- 10) times 28258945Srobertoper second. 29258945Sroberto 30258945Sroberto Work around: 31258945Sroberto 32258945Sroberto Integrated in releases: s297_27 33258945Sroberto Duplicate of: 34258945Sroberto Patch id: 35258945Sroberto See also: 36258945Sroberto Summary: 37