Date: Tue, 15 May 2001 20:46:35 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: dleimbac@earthlink.net, freebsd-questions@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: Gettimeofday Again... Message-ID: <Pine.BSF.4.21.0105151951240.872-100000@besplex.bde.org> In-Reply-To: <30515.989915996@critter>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 15 May 2001, Poul-Henning Kamp wrote:
> In message <200105150337.UAA19677@gull.mail.pas.earthlink.net>, dave writes:
> >
> >Why does gettimeofday perform so poorly on FreeBSD vs the same hardware on
> >Linux 2.4.2?
> >
> >---SNIP-----
> >#include <sys/time.h>
> >#include <unistd.h>
> >
> >int main() {
> > struct timeval tv1, tv2, tv3;
> >
> > gettimeofday(&tv1, 0);
> > gettimeofday(&tv2, 0);
> > gettimeofday(&tv3, 0);
> >
> > printf("Time 1 %d:%d\n", tv1.tv_sec, tv1.tv_usec);
> > printf("Time 2 %d:%d\n", tv3.tv_sec, tv3.tv_usec);
> >
> >}
> >----SNIP-----
> >
> >I get anywhere from 14usec to 17usec just for the call to gettimeofday.
I get 2 or 3 usec per call (on a Celeron 5.5 * 96MHz).
> >On the 2.4.2 linux kernel its something like 3usec.
> >
> >I just want to know why we are so much slower.
Probably primarily because FreeBSD is misconfigured to used the i8254
timecounter and Linux is configured to use the TSC. I can get closer to
your results by suitably misconfiguring FreeBSD:
# sysctl -w kern.timecounter.hardware=i8254
The test then takes 5, 6 or 7 usec per call.
# sysctl -w kern.timecounter.hardware=TSC # put it back before I forget :)
Secondarily, because Linux syscalls are faster than FreeBSD's in general.
Most of the 2-3 usec times above is for generic syscall overhead (i.e.,
the overhead for an almost minimal syscall() like getppid() that has no
args and returns one value in a register). Some measurements of this
overhead on the above system by lmbench2:
Linux-2.2.9: 0.7 usec
Linux-2.4.0.something: 0.6 usec
FreeBSD-4.something: 0.8 usec (maybe my version of it)
FreeBSD-current: 1.4 usec (KTRACE but no INVARIANT* or WITNESS*, etc.)
FreeBSD-current: 1.6 usec (my version of it)
FreeBSD-current-SMP: 2.2 usec
gettimeofday() has slightly more overhead (for copying in 2 args and
copying out one timeval), but not much more. The above times are for
getppid() in a loop, and the corresponding time for gettimeofday() in
a loop is only 2.045 usec. So my version of -current is taking only
0.445 usec to do the actual work for gettimeofday(). My version of
microtime() even does more work than the standard one (it updates
time_second, timecounter->tc_microtime and timecounter->tc_nanotime
so that the `get' functions are monotonic).
> Because we havn't particularly optimised it. If we want to, we
Actually we (mainly you) have optimized most of it more than it is
possible (microtime-went backwards problems are a symptom of over-
optimization). OTOH, syscalls haven't been optimized; they have
mostly been pessimized, especially in SMPng.
> can get to the point where a machine with a usable TSC doesn't
> even have to enter the kernel.
That would be about as useful as optimizing getppid(). (The details
would be similar -- you would have to signal applications or something
to tell them when a relevant kernel state change occurs.) Optimizing
syscalls generally would be more useful, but is still only important
for unusual applications that make too many syscalls.
Some history of the performance of gettimeofday() under FreeBSD: output
from an old benchmark/test program written by wollman:
==> dx2-66 <==
1995/11/03:
min 13, max 171, mean 14.286634, std 1.836667
1th: 14 (1053245 observations)
2th: 15 (587593 observations)
3th: 13 (299847 observations)
4th: 16 (51817 observations)
5th: 33 (934 observations)
2000/11/15:
min 20, max 542, mean 21.843003, std 8.003137
1th: 21 (1237408 observations)
2th: 22 (610609 observations)
3th: 23 (68643 observations)
4th: 20 (64561 observations)
5th: 25 (2233 observations)
==> k6-233 <==
1998/02/21:
min 2, max 124, mean 2.240976, std 0.617886
1th: 2 (1535123 observations)
2th: 3 (463782 observations)
3th: 18 (302 observations)
4th: 17 (234 observations)
5th: 19 (107 observations)
==> p5-133 <==
1996/07/12:
min 3, max 472, mean 3.320346, std 0.694846
1th: 3 (1376420 observations)
2th: 4 (621949 observations)
3th: 12 (594 observations)
4th: 13 (281 observations)
5th: 11 (233 observations)
1998/02/21 pre-phk:
min 3, max 595, mean 3.443382, std 0.767383
1th: 3 (1134768 observations)
2th: 4 (863276 observations)
3th: 15 (719 observations)
4th: 5 (299 observations)
5th: 16 (263 observations)
1998/02/21 post-phk:
min 4, max 99, mean 4.614527, std 0.710407
1th: 5 (1195577 observations)
2th: 4 (801694 observations)
3th: 16 (707 observations)
4th: 6 (456 observations)
5th: 17 (420 observations)
1999/12/04:
min 4, max 120, mean 4.630231, std 0.777733
1th: 5 (1222295 observations)
2th: 4 (775244 observations)
3th: 18 (444 observations)
4th: 19 (441 observations)
5th: 21 (250 observations)
==> cel-450 <==
1999/05/02:
min 1, max 44, mean 1.683213, std 0.501948
1th: 2 (1359226 observations)
2th: 1 (639961 observations)
3th: 10 (286 observations)
4th: 11 (123 observations)
5th: 7 (116 observations)
==> cel-458 <==
1999/12/04:
min 1, max 29, mean 1.498473, std 0.523034
1th: 1 (1008000 observations)
2th: 2 (991299 observations)
3th: 9 (253 observations)
4th: 10 (144 observations)
5th: 6 (106 observations)
==> cel-522 <==
2000/10/27
min 1, max 125, mean 1.389330, std 0.628235
1th: 1 (1233282 observations)
2th: 2 (765817 observations)
3th: 15 (137 observations)
4th: 4 (119 observations)
5th: 5 (118 observations)
2001/05/15
min 2, max 1194, mean 2.045723, std 0.933668
1th: 2 (1922234 observations)
2th: 3 (76839 observations)
3th: 16 (360 observations)
4th: 15 (280 observations)
5th: 14 (108 observations)
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0105151951240.872-100000>