From owner-freebsd-stable@FreeBSD.ORG Mon Nov 7 19:16:49 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D9EB16A41F for ; Mon, 7 Nov 2005 19:16:49 +0000 (GMT) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61F2E43D5E for ; Mon, 7 Nov 2005 19:16:45 +0000 (GMT) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EZCQw-00054u-HO for freebsd-stable@freebsd.org; Mon, 07 Nov 2005 20:13:34 +0100 Received: from r5k101.chello.upc.cz ([86.49.10.101]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 07 Nov 2005 20:13:34 +0100 Received: from martinkov by r5k101.chello.upc.cz with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 07 Nov 2005 20:13:34 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: martinko Date: Mon, 07 Nov 2005 20:09:14 +0100 Lines: 68 Message-ID: References: <1dbad3150511070339k15a99854r@mail.gmail.com> <200511071610.jA7GAKSB047437@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: r5k101.chello.upc.cz User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20050925 X-Accept-Language: sk, cs, en-gb, en-us, en In-Reply-To: <200511071610.jA7GAKSB047437@lurza.secnetix.de> Sender: news Subject: Re: timecounter and Hz quality in kern RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 19:16:49 -0000 Oliver Fromme wrote: > Michael Schuh wrote: > > i be very surprised about the performance of RELENG_6. > > Congratulations to the entire Team for this very good work. > > > > Now i have 2 Machines installed with 6.0-RC1, and i have seen that on > > both machines the Hz is differntly with GENERIC-Kernel. > > "sysctl kern.clockrate" tells you the HZ value. > In FreeBSD 6 the dafult is 1000, unless you change > it via "options HZ=x" in your kernel configuration. > > The values from systat(1) or vmstat(8) are not reliable, > because the counters are only 32bit and can overflow. > For example, one machine here with HZ=1000 reports only > 428 in "vmstat -i": > > $ sysctl kern.boottime ; date +%s ; vmstat -i | grep clk > kern.boottime: { sec = 1123867316, usec = 744735 } Fri Aug 12 19:21:56 2005 > 1131378875 > clk irq0 3216967596 428 > > Dividing the counter value by the uptime (in seconds) > seems to confirm the bogus rate of 428: > > $ runtime='( 1131378875 - 1123867316 )' > $ echo '3216967596 / $runtime' | bc > 428 > > But the 32bit counter has already overflowed once, so > we have to add 2^32. This gives the correct value: > > $ echo '( 3216967596 + 2 ^ 32 ) / $runtime' | bc > 1000 > > > After digging in the source i have found that timec.c have an routine for > > computing the so called "Hz quality". > > During boot, the kernel probes several time counters and > assigns "quality" values. Typically you have three of > them (i8254, ACPI, TPC). The time counter with the > highest quality value will be used for timing by default, > but you can change it via sysctl if you know what you are > doing. Type "sysctl kern.timecounter" and see the result. are those quality values preset (i.e. TSC = 800) or are they computed (during boot) somehow? and if the latter, how pls?? > > > Can anyone explain me the "mystics" behind Hz quality, > > and why or how this quality is computed and what are the > > efforts? > > The reason for that is to have a time counter that is as > precise and reliable as possible. For example, TPC has > issues on SMP and power-managed machines, therefore it is > not as reliable as ACPI, so usually the ACPI timecounter > has higher quality (although it takes more clock cycles > to query it). > > Oh, there's also a timecounter called "dummy", which does > not count time at all. :-) It exists for debugging > purposes only, AFAIK, and has a negative quality value, > so it is never selected automatically. > > Best regards > Oliver >