Date: Sat, 7 Sep 1996 01:05:22 +1000 From: Bruce Evans <bde@zeta.org.au> To: hackers@freebsd.org, luigi@labinfo.iet.unipi.it Subject: Re: Faster kern.clockrate ? Message-ID: <199609061505.BAA06002@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609061505.BAA06002>