Re: clock skew on B/W G3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Rune Torgersen wrote:

-----Original Message-----
From: Paul Mackerras [mailto:[email protected]] 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


--
George Anzinger   [email protected]
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux