Subject: Re: i386 uses slow clock routine with options NTP and options HZ=100
To: Charles M. Hannum <mycroft@NetBSD.ORG>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: netbsd-bugs
Date: 03/14/1996 16:55:37
>From: "Charles M. Hannum" <mycroft@NetBSD.ORG>
>Message-Id: <199603150034.TAA10386@pain.lcs.mit.edu>
>To: jonathan@Bowl.DSG.Stanford.EDU
>Subject: Re: i386 uses slow clock routine with options NTP and options HZ=100
>Cc: netbsd-bugs@NetBSD.ORG
>
>
>I'm more inclined to *not* define HZ, and figure out log2(hz) at run
>time.  Given the small actual number of shifts, I firmly disagree that
>this would be a noticable performance penalty.

Your're welcome to your opinion.  It's true that it might not
be much of a penalty on a x86.

... However, if you support arbitrary rates for HZ then the "shift"
stops being a simple shift and becomes a divide.  This is expensive
on many systems: e.g., another subroutine call, with a
not-nessarily-constant-at-compile time divisor.  that is _not_ cheap.

People at least as smart as you have looked at the cost of adding
HZ of these every second, into hardclock, where interrupts are
disabled, and concluded that it *IS* a noticeable performance penatly.

In summary, Charles, I disagree with your assessment, David Mills
disagrees with your assessment, wrong, people working at vendor
research labs with whom Dave Mills corresponds disagree with your
assessment; and if that's not enough, when I went over these issues on
the developers mailing list and interested individuals at the time I
imported the code into the NetBSD tree, and the consensus there was
also in disagreement with your assessment -- at least, enough to get
the NTP code incorporated in the first place.

If you have something positive to contribute, it would've been
nice to air it at the time.    If you  wish to examine the NTP
code and rewrite it such that it supports arbitrary values of
HZ correctly, and with good peformance, feel free to do that.  I,
personally, don't pretend to understand control theory and
phase-locked loops well enough to do better than David Mills has
already.

If you want to bite off the cost of a divide in the MI hardclock
code, please make sure that core and _ALL_ portmasters think that's
an appropriate decision before doing so.  If you can get that,
please feel free to make the change

thanks
--Jonathan