Re: clock skew on B/W G3

[George Anzinger <george@mvista.com>]

Rune Torgersen wrote:
>  
> 
> 
>>-----Original Message-----
>>From: Paul Mackerras [mailto:paulus@samba.org] 
>>Sent: Tuesday, October 04, 2005 07:49
>>Subject: RE: clock skew on B/W G3
>>
>>I do not believe CLOCK_TICK_RATE affects timekeeping at all on ppc or
>>ppc64 machines, but I could be wrong.  Can you show us where and how
>>CLOCK_TICK_RATE affects things?
> 
> 
> I looked very closely at htis thing earlier this summer because of an
> embedded board that drifted quite severly (15sec a day) with a very
> accureate BITS clock as clock source.
> 
> Here goes:
> In arch/ppc/kernel/time.c
> timer_interrupt() gets called every decrementer timeout (about every
> 1/CONFIG_HZ seconds, accuracy depends on how easily your decrementer
> cliock can be divided by CONFIG_HZ)
> this calls do_timer() to do the timer increment.
> 
> do_timer is in kernel/timer.c and calls update_times().
> update_times() calls update_wall_time() which in turns calls
> update_wall_time_one_tick()
> 
> update_wall_time_one_tick()uses tick_nsec to increment xtime.
> 
> tick_nsec is defined as: (kernel/timer.c:561)
> unsigned long tick_nsec = TICK_NSEC;
> 
> TICK_NSEC is defined as: (include/linux/jiffies.h:64)
> #define TICK_NSEC (SH_DIV (1000000UL * 1000, ACTHZ, 8))
> 
> ACTHZ is defined as: (include/linux/jiffies.h:61)
> #define ACTHZ (SH_DIV (CLOCK_TICK_RATE, LATCH, 8))
> 
> LATCH is defined as: (include/linux/jiffies.h:46)
> #define LATCH  ((CLOCK_TICK_RATE + HZ/2) / HZ)
> 
> which means that tick_nsec depends on CLOCK_TICK_RATE to get its value.
> 
> defined as:
> #define CLOCK_TICK_RATE	1193180 /* Underlying HZ */

But this is defined in include/asm/???.h  so you should be able to set something more to your liking 
(or rather to your archs liking).  It is true that it SHOULD be defined as it is used to define 
TICK_NSEC which is used to define the jiffies<-->timeval/timespec conversions which would be VERY 
slow it it were a variable.

George
-- 

> 
> this clock is completely wrong for most/all ppc. 
> It happens to generate a tick_nsec of 999848 which is close enough to
> 1000000 that most people does not notice.
> (tick_nsec is number of nsec per timer tick)
> 
> When HZ is 250, TICK_NSEC becomes 4000250.
> While this might not completely explain a 20% change in clock sped, it
> it clearly not acurate either.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-- 
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/