From owner-freebsd-hackers  Fri Sep  6 08:17:43 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id IAA00351
          for hackers-outgoing; Fri, 6 Sep 1996 08:17:43 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA00346
          for <hackers@freebsd.org>; Fri, 6 Sep 1996 08:17:39 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id BAA06002; Sat, 7 Sep 1996 01:05:22 +1000
Date: Sat, 7 Sep 1996 01:05:22 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199609061505.BAA06002@godzilla.zeta.org.au>
To: hackers@freebsd.org, luigi@labinfo.iet.unipi.it
Subject: Re: Faster kern.clockrate ?
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>for my dummynet stuff, I would like to have a finer clock granularity
>than the default 10ms: 1ms would probably be ok.  There shouldn't

options "HZ=1000" should work if you don't use xntpd.

>be so much overhead (after all, I started using FreeBSD on a 386/25,
>and now I have a Pentium100!).

Pentiums handle clock interrupts relatively inefficiently in FreeBSD,
because a large component of the overhead is for i/o's to the interrupt
controller, and the interrupt controller is slow on Pentiums too
(perhaps twice as fast, but the CPU may be 50 times as fast).

>I have been thinking of changing the value of hz (assumed I can
>find there it is initialized), but there are so many lines of code
>with
>
>	hz == 100
>	100 / hz
>	hz / 100

This shouldn't be much of a problem.  Dividing hz by something works
better if hz is large, and dividing by hz is rare.  timeouts of 1
tick are more of a problem.

>which makes me think that this is a bit dangerous. Otherwise, I thought
>I could initialize the timer (timer0, I guess) so as to interrupt
>faster, and then manage to call hardclock() every 10ms.

Interrupts at a faster rate are already supported.  See acquire_timer0().
This is only useful inside the kernel.  Increasing HZ gives better time
granularity in select().

>Still, has anyone already done something similar ? And, what are the
>implications of this approach with other timers ?

acquire_timer0() requires lots of code to avoid breaking microtime()
when timer0 is reprogrammed.  The RTC timer is almost independent,
but should interrupt at a faster rate than the main timer if you
want reasonably accurate kernel profiling.

Bruce