Subject: Re: Timecounter on sun4c
To: Fanch <fanch@kekpar.net>
From: Frank Kardel <kardel@netbsd.org>
List: current-users
Date: 08/24/2006 00:01:09
This is a multi-part message in MIME format.
--------------060104010609060304070401
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Fanch wrote:

> Hi,
>
> I have to downgrade kern.timecounter.hardware (cool feature) to
> clockinterrupt to get a correct clock, timer-counter seems to drift
> over 800000 ppm (no typo !) with or without ntpd.

As I could only test on sun4m and sun4u there is a distinct possibility
that other variants may still have problems. Thus thanks for you 
observation.
Maybe I find an SS2 in the cellar.

But could you please try the attached patch ?
I think I saw/found the same inconsistency (passing the wrong timer 
registers
 -stat instead of clock counter- to the setup code) as in other parts of the
sparc-cpu specific code.

>
> Maybe a too slow computer (SS1+, 25 MHz, no hardware multiply,
> timer-counter freq = 1 MHz) ?

CPU speed shouldn't matter at all.

>
> Tested with sources from 22 july and yesterday. Kernel includes
> only sun4c devices/options, and is compiled with
> DEFCOPTS+=-O2 -mcpu=v7
>
ok.

> No problem on a sun4m (SS10), same tree, kernel with only sun4m
> devices/options and DEFCOPTS+=-O2 -mcpu=supersparc
>
That's what got tested.

> The two are cross-compiled from a i386-current host (no problem
> on it either).
>
> Relevant informations :
>
> caillou# sysctl kern.timecounter
> kern.timecounter.choice = clockinterrupt(q=0, f=100 Hz) 
> timer-counter(q=100, f=1000000 Hz) dummy(q=-1000000, f=1000000 Hz)
> kern.timecounter.hardware = clockinterrupt
> kern.timecounter.timestepwarnings = 0
>
As this gives correct time there the interrupt limit is still 
initialized correctly.
Try the patch.

[...]

>
> Note : the "precision" reported by ntpd has changed a lot since the
> use of timecounters.
>
Yes, every time you switch the counter you basically get a new clock and
ntpd should be re-start so it's estimates match the reality.

> Before :
> Apr  2 16:40:11 caillou ntpd[528]: precision = 45.000 usec
> Aug  3 17:38:14 caillou ntpd[536]: precision = 46.000 usec
>
This was a hand optimized microtime implementation.

> After, timer-counter :
> Aug 20 09:11:31 caillou ntpd[541]: precision = 137.000 usec
> Aug 22 18:01:19 caillou ntpd[657]: precision = 115.002 usec

This is the timecounter implementation. It is a bit slower as time
calculation uses a multiplication for scaling and 64 bit values.

>
> After, clockinterrupt :
> Aug 23 07:31:42 caillou ntpd[570]: precision = 10000.000 usec
>
Also clear - 10 ms steps.

> Regards,
>
> Fanch
>
Frank

--------------060104010609060304070401
Content-Type: text/plain;
 name="tmrpatch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="tmrpatch"

Index: timer_sun4.c
===================================================================
RCS file: /cvsroot/src/sys/arch/sparc/sparc/timer_sun4.c,v
retrieving revision 1.14
diff -u -r1.14 timer_sun4.c
--- timer_sun4.c	7 Jun 2006 22:38:50 -0000	1.14
+++ timer_sun4.c	23 Aug 2006 21:45:36 -0000
@@ -169,7 +169,7 @@
 		return;
 	}
 
-	timerattach(&timerreg4->t_c14.t_counter, &timerreg4->t_c14.t_limit);
+	timerattach(&timerreg4->t_c10.t_counter, &timerreg4->t_c10.t_limit);
 }
 #endif /* SUN4 */
 
@@ -194,6 +194,6 @@
 		return;
 	}
 
-	timerattach(&timerreg4->t_c14.t_counter, &timerreg4->t_c14.t_limit);
+	timerattach(&timerreg4->t_c10.t_counter, &timerreg4->t_c10.t_limit);
 }
 #endif /* SUN4C */

--------------060104010609060304070401--