RE: clock skew on B/W G3

RE: clock skew on B/W G3

[Rune Torgersen]

 

> -----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 */

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.

Re: clock skew on B/W G3

[George Anzinger]

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/

RE: clock skew on B/W G3

[Rune Torgersen]

 

> From: George Anzinger [mailto:george@mvista.com] 
> 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.

Just make them variables, and compute them ONCE during boot.
ppc calls calibrate_decr() before enabling the timer interrupt anyways.

time_nsec is easy. 
in a platfrom specific file do (very simplified):

extern unsigned long time_nsec;

void platform_specific_calibrate_decr()
{
	time_nsec = REAL_TIME_NSEC;
}

This (of course) will do nothing about LATCH and ACTHZ that might be
used other places.

RE: clock skew on B/W G3

[Rune Torgersen]

> -----Original Message-----
> From:  Marc
> Sent: Sunday, October 02, 2005 11:46
> 
> Some additions to the previous mail: I was able to isolate 
> the problem to the 
> introduction of a user specificable value of HZ (in 
> include/asm-ppc/parm.h). 
> I used a value of 250 while the former default was 1000. 
> Setting it back to 
> 1000 makes the clock tick right again.
> 
> Is the CONFIG_HZ known to be broken on PPC ?
> 

CONFIG_HZ is not broken, but the whole clock configuration is.
(I poseded something about it for 8260 earlier this summer)

Basic problem is that CLOCK_TICK_RATE which is used for setting up the
variables used for advancing the clock, is hardcoded to a value that
only makes sence for an i386. (it is default set at 1193180Hz which
happens to be the timer clock for timer1 on an i386 machine)

Another problem here is that that value apparently hve to be #define'd
which means you cannot insert the decrementer frequency from the
boot-loader either.

Re: clock skew on B/W G3

[Marc]

Hi,

given that this option causes problems on non i386 systems, may I propose to 
mark CONFIG_HZ as broken on these architectures and/or use a default value of 
1000 ? I guess this issue can't be fixed in a sane way until 2.6.14 is out.

Marc

Le Montag 03 Oktober 2005 16:18, Rune Torgersen a écrit :
> > -----Original Message-----
> > From:  Marc
> > Sent: Sunday, October 02, 2005 11:46
> >
> > Some additions to the previous mail: I was able to isolate
> > the problem to the
> > introduction of a user specificable value of HZ (in
> > include/asm-ppc/parm.h).
> > I used a value of 250 while the former default was 1000.
> > Setting it back to
> > 1000 makes the clock tick right again.
> >
> > Is the CONFIG_HZ known to be broken on PPC ?
>
> CONFIG_HZ is not broken, but the whole clock configuration is.
> (I poseded something about it for 8260 earlier this summer)
>
> Basic problem is that CLOCK_TICK_RATE which is used for setting up the
> variables used for advancing the clock, is hardcoded to a value that
> only makes sence for an i386. (it is default set at 1193180Hz which
> happens to be the timer clock for timer1 on an i386 machine)
>
> Another problem here is that that value apparently hve to be #define'd
> which means you cannot insert the decrementer frequency from the
> boot-loader either.

Re: clock skew on B/W G3

[Benjamin Herrenschmidt]

On Tue, 2005-10-04 at 08:14 +0200, Marc wrote:
> Hi,
> 
> given that this option causes problems on non i386 systems, may I propose to 
> mark CONFIG_HZ as broken on these architectures and/or use a default value of 
> 1000 ? I guess this issue can't be fixed in a sane way until 2.6.14 is out.

No, it should work fine, there is something else broken on this G3

Ben.

Re: clock skew on B/W G3

[Benjamin Herrenschmidt]

On Tue, 2005-10-04 at 08:14 +0200, Marc wrote:
> Hi,
> 
> given that this option causes problems on non i386 systems, may I propose to 
> mark CONFIG_HZ as broken on these architectures and/or use a default value of 
> 1000 ? I guess this issue can't be fixed in a sane way until 2.6.14 is out.

The problem is indeed in via_calibrate_decr(). This routine works on
HZ/100 so it will not do any good with HZ not beeing a multiple of 100.

Can you test this patch ?

Index: linux-work/arch/ppc/platforms/pmac_time.c
===================================================================
--- linux-work.orig/arch/ppc/platforms/pmac_time.c	2005-09-22 14:06:18.000000000 +1000
+++ linux-work/arch/ppc/platforms/pmac_time.c	2005-10-05 08:14:17.000000000 +1000
@@ -195,7 +195,7 @@
 		;
 	dend = get_dec();
 
-	tb_ticks_per_jiffy = (dstart - dend) / (6 * (HZ/100));
+	tb_ticks_per_jiffy = (dstart - dend) / ((6 * HZ)/100);
 	tb_to_us = mulhwu_scale_factor(dstart - dend, 60000);
 
 	printk(KERN_INFO "via_calibrate_decr: ticks per jiffy = %u (%u ticks)\n",

Re: clock skew on B/W G3

[Marc]

Hi Ben, 

Le Mittwoch 05 Oktober 2005 00:14, Benjamin Herrenschmidt a écrit :
> The problem is indeed in via_calibrate_decr(). This routine works on
> HZ/100 so it will not do any good with HZ not beeing a multiple of 100.
>
> Can you test this patch ?

I can confirm that this patch solves the timer skew on my mac.

Thanks!

>
> Index: linux-work/arch/ppc/platforms/pmac_time.c
> ===================================================================
> --- linux-work.orig/arch/ppc/platforms/pmac_time.c	2005-09-22
> 14:06:18.000000000 +1000 +++
> linux-work/arch/ppc/platforms/pmac_time.c	2005-10-05 08:14:17.000000000
> +1000 @@ -195,7 +195,7 @@
>  		;
>  	dend = get_dec();
>
> -	tb_ticks_per_jiffy = (dstart - dend) / (6 * (HZ/100));
> +	tb_ticks_per_jiffy = (dstart - dend) / ((6 * HZ)/100);
>  	tb_to_us = mulhwu_scale_factor(dstart - dend, 60000);
>
>  	printk(KERN_INFO "via_calibrate_decr: ticks per jiffy = %u (%u ticks)\n",
>
>
> -
> 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/

RE: clock skew on B/W G3

[Paul Mackerras]

Rune Torgersen writes:

> CONFIG_HZ is not broken, but the whole clock configuration is.
> (I poseded something about it for 8260 earlier this summer)
> 
> Basic problem is that CLOCK_TICK_RATE which is used for setting up the
> variables used for advancing the clock, is hardcoded to a value that
> only makes sence for an i386. (it is default set at 1193180Hz which
> happens to be the timer clock for timer1 on an i386 machine)

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?

Paul.

Re: clock skew on B/W G3

[Marc]

Some additions to the previous mail: I was able to isolate the problem to the 
introduction of a user specificable value of HZ (in include/asm-ppc/parm.h). 
I used a value of 250 while the former default was 1000. Setting it back to 
1000 makes the clock tick right again.

Is the CONFIG_HZ known to be broken on PPC ?

Thanks

Marc

Le Samstag 01 Oktober 2005 14:29, marvin24@gmx.de a écrit :
> Hi,
>
> something between 2.6.13-git4 and 2.6.14-git5 makes my clock running ~20%
                                        ^^ should be 13 of course 

> slower. This problem still exists in current kernel versions. Sorry for
> reporting so late, but I hope it would go away while time passes...
>
> As the subject says I have blue/white Apple G3/400. My config I attached.