From owner-freebsd-performance@FreeBSD.ORG Mon Apr 27 03:00:31 2009 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2DEB106566C; Mon, 27 Apr 2009 03:00:31 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mx1.freebsd.org (Postfix) with ESMTP id 73DE48FC1A; Mon, 27 Apr 2009 03:00:31 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by gxk18 with SMTP id 18so1848438gxk.19 for ; Sun, 26 Apr 2009 20:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pUsvqDt7M19zmTn73Ua5JkFaCAcDPz5upV4j6KHS6gU=; b=EqBhSoTUo8WleHQEQGXUYWp492f6G4Sz1J1zyEIYTpKJ/YO2x3NScnkxXTs0dgYR+B wC1+KIctsOikschyc8WRFj4rbR4cwqso7EnhGTsYXuwFkCwenx2lQRe3Nb7oLLc1e6F3 yS88oojYEv0k4azpzErgpA9o/OB9se1MrCfFk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rbtBMdtv6Z/FGX7UUBBjW1dyUnXlVLffL7WNEVR3qjvYOFnTkBtKEsKiXbIpZVJKyr n9MmiG22AoaUIfNJHbt7WQ3ZxG42hdBPaOufyBEMgvXjmqpXfG08VNDErnDA3NoTWGwQ iXPu/kxbCoKWBjayHhvlMKVMx0MM+UKsLuVi8= MIME-Version: 1.0 Received: by 10.151.137.5 with SMTP id p5mr7844582ybn.223.1240799262908; Sun, 26 Apr 2009 19:27:42 -0700 (PDT) In-Reply-To: <200904270150.31912.pieter@degoeje.nl> References: <200904270150.31912.pieter@degoeje.nl> Date: Sun, 26 Apr 2009 19:27:42 -0700 Message-ID: <7d6fde3d0904261927s1a67cf85jc982c1a68e30e081@mail.gmail.com> From: Garrett Cooper To: Pieter de Goeje Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 27 Apr 2009 03:14:33 +0000 Cc: acpi , freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org Subject: Re: ACPI-fast default timecounter, but HPET 83% faster X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 03:00:32 -0000 On Sun, Apr 26, 2009 at 4:50 PM, Pieter de Goeje wrote: > Dear hackers, > > While fiddling with the sysctl kern.timecounter.hardware, I found out tha= t on > my system HPET is significantly faster than ACPI-fast. Using the program > below I measured the number of clock_gettime() calls the system can execu= te > per second. I ran the program 10 times for each configuration and here ar= e > the results: > > x ACPI-fast > + HPET > +------------------------------------------------------------------------= -+ > |x =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +| > |x =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +| > |x =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0++| > |x =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0++| > |x =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0++| > |x =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0++| > |A =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|A| > +------------------------------------------------------------------------= -+ > =A0 =A0N =A0 =A0 =A0 =A0 =A0 Min =A0 =A0 =A0 =A0 =A0 Max =A0 =A0 =A0 =A0M= edian =A0 =A0 =A0 =A0 =A0 Avg =A0 =A0 =A0 =A0Stddev > x =A010 =A0 =A0 =A0 =A0822032 =A0 =A0 =A0 =A0823752 =A0 =A0 =A0 =A0823551= =A0 =A0 =A0823397.8 =A0 =A0 509.43254 > + =A010 =A0 =A0 =A0 1498348 =A0 =A0 =A0 1506862 =A0 =A0 =A0 1502830 =A0 = =A0 1503267.4 =A0 =A0 2842.9779 > Difference at 95.0% confidence > =A0 =A0 =A0 =A0679870 +/- 1918.94 > =A0 =A0 =A0 =A082.5688% +/- 0.233052% > =A0 =A0 =A0 =A0(Student's t, pooled s =3D 2042.31) > > System details: Intel(R) Core(TM)2 Duo CPU E6750 =A0@ 2.66GHz (3200.02-MH= z > 686-class CPU), Gigabyte P35-DS3R motherboard running i386 -CURRENT updat= ed > today. > > Unfortunately I only have one system with a HPET timecounter, so I cannot > verify these results on another system. If similar results are obtained o= n > other machines, I think the HPET timecounter quality needs to be increase= d > beyond that of ACPI-fast. > > Regards, > > Pieter de Goeje > > ----- 8< ----- clock_gettime.c ----- 8< ------ > #include > #include > #include > > #define COUNT 1000000 > > int main() { > =A0 =A0 =A0 =A0struct timespec ts_start, ts_stop, ts_read; > =A0 =A0 =A0 =A0double time; > =A0 =A0 =A0 =A0int i; > > =A0 =A0 =A0 =A0clock_gettime(CLOCK_MONOTONIC, &ts_start); > =A0 =A0 =A0 =A0for(i =3D 0; i < COUNT; i++) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0clock_gettime(CLOCK_MONOTONIC, &ts_read); > =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0clock_gettime(CLOCK_MONOTONIC, &ts_stop); > > =A0 =A0 =A0 =A0time =3D (ts_stop.tv_sec - ts_start.tv_sec) + (ts_stop.tv_= nsec - > ts_start.tv_nsec) * 1E-9; > =A0 =A0 =A0 =A0printf("%.0f\n", COUNT / time); > } I'm seeing similar results. [root@orangebox /usr/home/gcooper]# dmesg | grep 'Timecounter "' Timecounter "i8254" frequency 1193182 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Timecounter "HPET" frequency 14318180 Hz quality 900 [root@orangebox /usr/home/gcooper]# ./cgt 1369355 [root@orangebox /usr/home/gcooper]# sysctl kern.timecounter.hardware=3D"ACPI-fast" kern.timecounter.hardware: HPET -> ACPI-fast [root@orangebox /usr/home/gcooper]# ./cgt 772289 Why's the default ACPI-fast? For power-saving functionality or because of the `quality' factor? What is the criteria that determines the `quality' of a clock as what's being reported above (I know what determines the quality of a clock visually from a oscilloscope =3D])? Thanks, -Garrett