Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 18 Feb 2002 15:41:40 +1100 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        Terry Lambert <tlambert2@mindspring.com>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Julian Elischer <julian@elischer.org>, Alfred Perlstein <bright@mu.org>, <arch@FreeBSD.ORG>, <jhb@FreeBSD.ORG>, <peter@wemm.org>, <jake@locore.ca>
Subject:   Re: gettimeofday() and crhold()/crfree() (was Re:  gettimeofday()andcopyout(). Is copyout() MPSAFE on non-i386 archs? )
Message-ID:  <20020218151249.E4728-100000@gamplex.bde.org>
In-Reply-To: <200202180409.g1I49vj10455@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 17 Feb 2002, Matthew Dillon wrote:

>     Just a note:  The gettimeofday() has an overhead of only 2-3 uS in
>     -current.  Squid would have to be doing an aweful lot of transactions

And that is only on slow machines and/or under SMP.  On my Athlon1600,
it has an overhead of 0.3-0.4 nsec.  I have been benchmarking it for
many years and recently had to change the benchmark program to use
clock_gettime(2) instead of gettimeofday() when getttimeofday()'s
resolution became too small.

>     for it to matter and even if it did, if that actually turned out to be the
>     bottleneck I'll eat my hat.  And if I wind up eating my hat the next
>     thing I'll do is spend the necessary 5 seconds writing a little code
>     to make squid only call gettimeofday every 5th time.

Or use an alarm to set it...

Summary of overheads for gettimeofday() (clock_gettime() for sub-usec ones)
in a loop::

-my-current on Athlon1600 @ 1532          0.381 usec (TSC)
-current on Athlon1600 @ 1532             0.512 usec (TSC)
4.5RC on Athlon1600 @ 1532                0.345 usec (TSC)

-my-current-2000 on Celeron366 @ 522      1.389 usec (TSC)
-my-current-1999 on Celeron400 @ 450      1.683 usec (TSC)

-my-current-1998 on K6-1/233              2.241 usec (TSC)

-my-current-2001 on Pentium1 @ 133        5.474 usec (TSC) (reduce SMPng pessim)
-my-current-2001 on Pentium1 @ 133        6.786 usec (TSC) (more SMPng pessim)
-my-current-2000 on Pentium1 @ 133        5.376 usec (TSC) (SMPng pessim)
-my-current-1999 on Pentium1 @ 133        4.630 usec (TSC)
-my-current-1998 on Pentium1 @ 133        4.615 usec (TSC) (timecounter pessim)
-my-current-1998 on Pentium1 @ 133        3.443 usec (TSC) (pre-timecounter)
-my-current-1996 on Pentium1 @ 133        3.320 usec (TSC)

-my-current-2000 on 486DX2/66            21.843 usec (i8254) (SMPng pessim)
-my-current-1995 on 486DX2/66            14.276 usec (i8254)

Except for the non-TSC timecounter, this mostly measure overheads for
syscalls generally.  The core part of gettimeofday(), i.e., microtime()
takes less than 100 nsec on the Athlon.

This stuff is fun to optimize, but I haven''t found a case where optimising
all syscalls (not just gettimeofday()) makes a difference in a normal
application.

Bruce


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020218151249.E4728-100000>