Subject: Re: Timekeeping in NetBSD -or- getting ready to split the microsecond
To: Frank Kardel <kardel@acm.org>
From: Simon Burge <simonb@wasabisystems.com>
List: tech-kern
Date: 10/25/2005 12:24:51
On Tue, Oct 25, 2005 at 02:16:37AM +0200, Frank Kardel wrote:

> Why ?
> 
> Until the day I got my hands on a SOEKRIS 4801 I was pretty content
> with NetBSD's time implementation. It was sufficient to support all my
> tests I need to do when doing NTP development work.

Heh, I've been playing a little with timecounters too in my spare time.
My laptop is running a timecounter kernel now.  However, using an alpha
as my main time server means this hasn't been as much a priority for me
as it appears to be for you :-)

> So much for the examples - the patches for -current as of 
> 20051024-094940(UTC) can be found
> along with some before and after graphics on:
> 
>    http://www.kardel.name

I'll have a better look when I get a chance.  A couple of differences
are immediately noticable from your README_TIMECOUNTERS to how I've done
things so far:

 - I didn't worry about changing the signatures of
   {,get}{micro,nano,bin}{,up}time() and adapted our calling functions
   to suit the new interface.

 - I haven't added support for the __HAVE_TIMERCOUNTER option - I think
   I was planning on converting all arch's on a branch then merging, but
   hadn't really thought too far ahead on that one.  On one hand, MD
   support for timecounters isn't really that hard.  On the other, not
   having to wait for all ports to be converted has its merits.

 - I've adapted userland to work (savecore/vmstat).  build.sh completes
   (only for i386).

 - I've moved a lot of time-related prototypes and variable declarations
   to the new <sys/timevar.h> kernel-only header file.

I still have far too many XXX comments to deal with though in my working
tree.  I also haven't throught about SMP yet - in particular our
cc_microtime/cc_microset has had work to be SMP friendly, and we need
to investigate those changes versus what timekeepers provide.

Another thought is the

	Timecounter "i8254" frequency 1193182 Hz quality 0

style messages spread throughout the boot messages doesn't exactly fit
in with our boot message style.

A positive note is that the size between my old "normal" kernel and new
timekeeper kernel is negligible:

   text    data     bss     dec     hex filename
3171771   76220  113360 3361351  334a47 /netbsd
3171258   77020  113488 3361766  334be6 /nettc

> Future work (roughly sorted):
> 
>    - BRANCH: [ ... ]

I was planning on creating a branch probably next weekend.  I might see
if I can do that sooner.

> Please feel free to look at the patch (consider it "newer as current" 
> 8-) and give me
> feedback about the time counter port.

Good to have another reference, and one that certainly looks further
along in some (probably many) areas.

Cheers,
Simon.
--
Simon Burge                                   <simonb@wasabisystems.com>
NetBSD Development, Support and Service:   http://www.wasabisystems.com/