From nobody@FreeBSD.org  Sun Feb  3 14:57:31 2002
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id 115A837B41C
	for <freebsd-gnats-submit@FreeBSD.org>; Sun,  3 Feb 2002 14:57:31 -0800 (PST)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.6/8.11.6) id g13MvVa66671;
	Sun, 3 Feb 2002 14:57:31 -0800 (PST)
	(envelope-from nobody)
Message-Id: <200202032257.g13MvVa66671@freefall.freebsd.org>
Date: Sun, 3 Feb 2002 14:57:31 -0800 (PST)
From: Jason Carroll <jason@carrollgroup.org>
To: freebsd-gnats-submit@FreeBSD.org
Subject: slow gettimeofday in FreeBSD 4.5
X-Send-Pr-Version: www-1.0

>Number:         34596
>Category:       misc
>Synopsis:       slow gettimeofday in FreeBSD 4.5
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Feb 03 15:00:01 PST 2002
>Closed-Date:    Wed Aug 21 16:05:39 PDT 2002
>Last-Modified:  Wed Jun  4 18:10:14 PDT 2003
>Originator:     Jason Carroll
>Release:        FreeBSD 4.5
>Organization:
>Environment:
FreeBSD galois 4.5-RELEASE FreeBSD 4.5-RELEASE #0: Sat Feb  2 16:28:26 EST 2002     jason@galois:/usr/obj/usr/src/sys/LOCAL  i386

(I also tried this with the GENERIC kernel that came with the 4.5 release)
>Description:
gettimeofday() seems to be slower (by about 5 times) than it was under FreeBSD 4.2.  I ran the program below on an Intel 1.9ghz machine with 4.5 FreeBSD installed (with the GENERIC kernel), and it took approximately 5 seconds, or 5ms per call to gettimeofday.  I then boot the same machine with a 4.2 kernel and the same program ran in under 1 second.  See the next window for the program source.

Any ideas?  This doesn't seem like a critical problem, but I thought it should be mentioned.

Thanks
>How-To-Repeat:
#include <sys/time.h>
#include <stdio.h>

int main(int argc, char *argv[])
{
    timeval tv, st, en;

    gettimeofday(&st, NULL);

    for (int i = 0; i < 1000000; i++) {
        gettimeofday(&tv, NULL);
    }

    gettimeofday(&en, NULL);

    printf("delta: %ds %dus\n", en.tv_sec- st.tv_sec, en.tv_usec - st.tv_usec);
}
>Fix:
      
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->analyzed 
State-Changed-By: asmodai 
State-Changed-When: Mon Apr 8 11:24:45 PDT 2002 
State-Changed-Why:  
Raised the issue on standards@freebsd.org. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=34596 
State-Changed-From-To: analyzed->feedback 
State-Changed-By: asmodai 
State-Changed-When: Mon Apr 8 22:44:49 PDT 2002 
State-Changed-Why:  
Can you do a grep -i time /var/run/dmesg and sysctl kern.timecounter and 
provide the output as a follow-up to this PR? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=34596 
State-Changed-From-To: feedback->closed 
State-Changed-By: keramida 
State-Changed-When: Wed Aug 21 16:05:22 PDT 2002 
State-Changed-Why:  
Feedback timeout. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=34596 

From: gson@nominum.com (Andreas Gustafsson)
To: freebsd-gnats-submit@FreeBSD.org, jason@carrollgroup.org
Cc:  
Subject: Re: misc/34596: slow gettimeofday in FreeBSD 4.5
Date: Tue, 3 Jun 2003 14:01:36 -0700 (PDT)

 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
 
 -- 
 Andreas Gustafsson, gson@nominum.com

From: Bruce Evans <bde@zeta.org.au>
To: Andreas Gustafsson <gson@nominum.com>
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

From: gson@nominum.com (Andreas Gustafsson)
To: Bruce Evans <bde@zeta.org.au>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: misc/34596: slow gettimeofday in FreeBSD 4.5
Date: Wed, 4 Jun 2003 12:13:03 -0700 (PDT)

 Bruce Evans writes:
 > FreeBSD-4.8 should be configured to use the TSC timecounter in the non-SMP
 > case.
 
 Do you mean "should be automatically configured", or "should be
 configured by the user"?  If the latter, where is this documented?
 
 > Configuration of apm may pessimize the default configuration.  The
 > TSC is not supported for the !SMP case.
 
 When you say "!SMP", do you mean "non-SMP" (which would seem to
 contradict the above) or "SMP"?
 -- 
 Andreas Gustafsson, gson@nominum.com
 

From: Bruce Evans <bde@zeta.org.au>
To: Andreas Gustafsson <gson@nominum.com>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: misc/34596: slow gettimeofday in FreeBSD 4.5
Date: Thu, 5 Jun 2003 06:43:01 +1000 (EST)

 On Wed, 4 Jun 2003, Andreas Gustafsson wrote:
 
 > Bruce Evans writes:
 > > FreeBSD-4.8 should be configured to use the TSC timecounter in the non-SMP
 > > case.
 >
 > Do you mean "should be automatically configured", or "should be
 > configured by the user"?  If the latter, where is this documented?
 
 Both :-).  It seems to be undocumented (except in the source code).
 
 > > Configuration of apm may pessimize the default configuration.  The
 > > TSC is not supported for the !SMP case.
 >
 > When you say "!SMP", do you mean "non-SMP" (which would seem to
 > contradict the above) or "SMP"?
 
 I mean "non-SMP".  The automatic configuration does a reasonable job
 in the non-SMP case unless apm is configured.  Unfortunately, GENERIC
 in RELENG_4 sets a bad example by configuring apm.  It is configured
 as disabled so it is usually not used, but this doesn't help because
 the automatic configuration uses a compile-time test for apm.  Better
 yet, the automatic configuration refuses to register the TSC as a
 timecounter if apm is statically configured, so you can't select the
 TSC timecounter at runtime using "sysctl kern.timecounter=TSC" unless
 you remove apm from the configuration.  These bugs are fixed in -current.
 
 In the SMP case, the TSC timecounter is similarly statically not
 configured, but this is correct since it doesn't work in the SMP
 case.  The automatic configuration uses the best available timecounter,
 but this is too often the i8254 timecounter since there aren't many
 working timecounters to choose from.  In -current, there is also the
 acpi timecounter which works right in more cases (broken cases include
 ones where acpi is broken and some old machines where the acpi timer
 runs at double speed).
 
 Bruce

From: gson@nominum.com (Andreas Gustafsson)
To: Bruce Evans <bde@zeta.org.au>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: misc/34596: slow gettimeofday in FreeBSD 4.5
Date: Wed, 4 Jun 2003 18:06:23 -0700 (PDT)

 Bruce Evans writes:
 > I mean "non-SMP".  The automatic configuration does a reasonable job
 > in the non-SMP case unless apm is configured.  Unfortunately, GENERIC
 > in RELENG_4 sets a bad example by configuring apm.
 
 Thanks for the explanation.  We commented out the apm0 line, and the
 gettimeofday() execution time went down to 0.6 microseconds (from 5.1).
 -- 
 Andreas Gustafsson, gson@nominum.com
>Unformatted:
