From owner-freebsd-bugs@FreeBSD.ORG Wed Jun 4 03:30:16 2003 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 259CE37B401 for ; Wed, 4 Jun 2003 03:30:16 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9D9543FB1 for ; Wed, 4 Jun 2003 03:30:15 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h54AUFUp068276 for ; Wed, 4 Jun 2003 03:30:15 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h54AUFeh068275; Wed, 4 Jun 2003 03:30:15 -0700 (PDT) Date: Wed, 4 Jun 2003 03:30:15 -0700 (PDT) Message-Id: <200306041030.h54AUFeh068275@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Bruce Evans Subject: Re: misc/34596: slow gettimeofday in FreeBSD 4.5 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Bruce Evans List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2003 10:30:16 -0000 The following reply was made to PR misc/34596; it has been noted by GNATS. From: Bruce Evans To: Andreas Gustafsson Cc: freebsd-gnats-submit@freebsd.org Subject: Re: misc/34596: slow gettimeofday in FreeBSD 4.5 Date: Wed, 4 Jun 2003 20:26:10 +1000 (EST) > gettimeofday() is still really slow in FreeBSD 4.8-STABLE. Some > numbers from the test program submitted with misc/34596: > > FreeBSD 4.8, single Intel Xeon 2.8 GHz delta: 5s 59701us > NetBSD 1.6L, dual AMD Athlon MP 1800+ delta: 2s 801360us > NetBSD 1.6T, single Transmeta Crusoe 600 MHz delta: 2s 582755us > Linux 2.4.9-31smp, dual AMD Athlon MP 1900+ delta: 0s 247116us > > That's more than 5 microseconds on a 2.8 GHz processor, or more than > 14000 clock cycles per call. > > Other info: > > $ grep -i time /var/run/dmesg.boot > Timecounter "i8254" frequency 1193182 Hz > $ sysctl kern.timecounter > kern.timecounter.method: 0 > kern.timecounter.hardware: i8254 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ It cannot possibly be much faster if such a slow timecounter is configured. The i8254 timecounter uses 3 ISA bus accesses. ISA bus accesses usually take even longer on n GHz machines now than they did on n MHz machines in 1992, since they are usually behind an ISA bridge or two and BIOSes have usually lost support for tweaking the number of ISA wait states to the mininum permitted by the spec and below. Some timings for reading the i8254 registers in a loop: 0x40 (i8254 mode) 0x43(i8254 counter 0) 1996: (ASUS P55TP4XE) 703 1180 nsec 1997: (FIC PA2007) 1105 1233 2003: (ASUS A7V266/E) 1317 1317 FreeBSD-4.8 should be configured to use the TSC timecounter in the non-SMP case. Configuration of apm may pessimize the default configuration. The TSC is not supported for the !SMP case. Then the only alternative to the i8254 timecounter is the PIIX timecounter which AFAIK is only available on some old Intel chipsets (BX). The PIIX timecounter hardware is a bit slower than the TSC. FreeBSD-5 can use the ACPI timecounter, which is essentially the same as the PIIX timecounter including its bugs. FreeBSD-5 should be configured to use the TSC timecounter in the non-SMP case if it works. It doesn't work mainly if the CPU is ever throttled by power management. Some timings by another benchmark on an AthlonXP-1600 overclocked by 146/133: %%% 2002/01/15 4.5RC min 343, max 19573, mean 345.082019, std 109.709710 1th: 344 (1354559 observations) 2th: 343 (292357 observations) 3th: 346 (275037 observations) 4th: 345 (77690 observations) 5th: 350 (33 observations) 2002/01/15 5.0-2000/09/09 min 343, max 40335, mean 346.613161, std 126.348898 1th: 344 (1099112 observations) 2th: 349 (635890 observations) 3th: 343 (236910 observations) 4th: 350 (27833 observations) 5th: 352 (12 observations) 2002/02/17 5.0-2002/02/17 min 508, max 212269, mean 512.057268, std 96.120401 1th: 509 (941667 observations) 2th: 510 (608011 observations) 3th: 517 (243539 observations) 4th: 518 (123703 observations) 5th: 508 (62574 observations) 2002/02/17 min 378, max 212621, mean 381.234928, std 115.229532 1th: 380 (1139521 observations) 2th: 381 (535937 observations) 3th: 379 (263698 observations) 4th: 378 (47663 observations) 5th: 382 (12839 observations) 2002/03/04 min 378, max 237729, mean 379.740075, std 120.720743 1th: 378 (1197389 observations) 2th: 379 (802202 observations) 3th: 380 (95 observations) 4th: 476 (21 observations) 5th: 397 (16 observations) 2002/03/30 (ACPI-fast timecounter) min 837, max 210920, mean 892.293601, std 226.259588 1th: 838 (1419633 observations) 2th: 1117 (198530 observations) 3th: 839 (183607 observations) 4th: 1118 (169521 observations) 5th: 837 (28327 observations) 2002/03/30 (i8254 timecounter) min 4190, max 252275, mean 4301.709102, std 835.697703 1th: 4191 (1113886 observations) 2th: 4190 (683892 observations) 3th: 5029 (148800 observations) 4th: 5028 (51440 observations) 5th: 28496 (662 observations) 2002/03/30 min 376, max 209046, mean 378.621313, std 116.589942 1th: 378 (870256 observations) 2th: 377 (470356 observations) 3th: 376 (386644 observations) 4th: 379 (263005 observations) 5th: 380 (8563 observations) 2003/06/04 min 400, max 295020, mean 402.220277, std 101.969771 1th: 401 (1078607 observations) 2th: 400 (534769 observations) 3th: 402 (329776 observations) 4th: 403 (54325 observations) 5th: 662 (317 observations) %%% Times are for the TSC timecounter except as noted. All times are in nsec. The benchmark uses clock_gettime() instead of the archaic, nonstandard, imprecise gettimeofday(). Old versions used getttimeofday() and broke a few years ago when average delta-time became less than 1 usec. Bruce