Date: Tue, 15 May 2001 01:56:32 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Matt Dillon <dillon@earth.backplane.com> Cc: dave <dleimbac@earthlink.net>, freebsd-questions@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: Gettimeofday Again... Message-ID: <3B00EF40.A1232B75@mindspring.com> References: <200105150337.UAA19677@gull.mail.pas.earthlink.net> <200105150346.f4F3kLE45720@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matt Dillon wrote: > :Well I have been on the IRC in and out of mail list archives > :and cannot geta good answer to this question... > : > :Why does gettimeofday perform so poorly on FreeBSD vs the > :same hardware on Linux 2.4.2? > > Why should it matter? gettimeofday() is not something > that is typically called in a tight loop, it would be > silly to optimize it. 17uS is plenty fast enough. > > Systems rarely have performance problems due to syscall > overhead. I think that perhaps you aren't doing high performance server work, if you really think 17uS is "plenty fast enough". I have an application where gettimeofday() was a significant fraction of the overhead; it was being used to provide for marketing eye-candy... basically, squid-compatible proxy logging that could be processed using common eye-candy tools normally used against squid logs for transaction in, time sent to back end, time data came from back end, and time data sent to client. The gettimeofday() calls were _the_ major useless overhead, until I eliminated them by creating a zero system call version that someone (was it Bruce?) insisted was an impossibility (don't think that drift wasn't problematic to eliminate, in the case of a clock interrupt in the middle of the huge calculation). That's a savings of 68uS per transaction. IMO, the 12uS that Linux would have taken for the same 4 calls would also be too much overhead to be acceptable for the application in question. The timecounter code has a huge calculation overhead, by default, as well. I really dislike the amount of data that has to be pushed around, and I really dislike the amount of code that has to execute to do the calculation, whether it be in kernel or in user space. It doesn't help that the data structure it uses is a hidden copy that only has a reference when you are making the call via a structure pointer. Linux is generally faster, because it has a global "current time", and just copies it out from the global, while FreeBSD does this huge dance with many structure pointer dereferences each time, and ends up calling two functions deep to do the deed (or three, if you use time(2) instead of getimeofday(2)). Really ugly code, which appears designed to allow us to use alternate timecounters "because the i8254 is too slow", and then we just use it anyway, because the Pentium cycle counter is "not accurate enough". Foo. We were better off before all the timecounter crap, when we had much less data moving around, and a nice struct timeval global that could be cheaply copied; the new code doesn't do what it was supposed to do (let us use a less expensive method of getting a uS level time of day clock accuracy), and is vastly more expensive and complex. -- Terry 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?3B00EF40.A1232B75>