Date: Mon, 02 Jun 2008 01:39:41 -0400 From: Gary Stanley <gary@velocity-servers.net> To: Sean Chittenden <sean@chittenden.org>,freebsd-performance@freebsd.org Subject: Re: Micro-benchmark for various time syscalls... Message-ID: <20080602060624.93F5F8FC4A@mx1.freebsd.org> In-Reply-To: <2B465A44-2578-4675-AA17-EBE17A072017@chittenden.org> References: <2B465A44-2578-4675-AA17-EBE17A072017@chittenden.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At 12:54 AM 6/2/2008, Sean Chittenden wrote: >I wrote a small micro-benchmark utility[1] to test various time >syscalls and the results were a bit surprising to me. The results >were from a UP machine and I believe that the difference between >gettimeofday(2) and clock_gettime(CLOCK_REALTIME_FAST) would've been >bigger on an SMP system and performance would've degraded further with >each additional core. > >clock_gettime(CLOCK_REALTIME_FAST) is likely the ideal function for >most authors (CLOCK_REALTIME_FAST is supposed to be precise to +/- >10ms of CLOCK_REALTIME's value[2]). In fact, I'd assume that >CLOCK_REALTIME_FAST is just as accurate as Linux's gettimeofday(2) (a >statement I can't back up, but believe is likely to be correct) and >therefore there isn't much harm (if any) in seeing clock_gettime(2) + >CLOCK_REALTIME_FAST receive more widespread use vs. gettimeofday(2). >FYI. -sc > >PS Is there a reason that time(3) can't be implemented in terms of >clock_gettime(CLOCK_SECOND)? 10ms seems precise enough compared to >time_t's whole second resolution. Another interesting idea is to map gettimeofday() to userland, sort of like darwin (commpage) and linux (vsyscall) via read only page. Can you try changing microtime() in kern_time.c:gettimeofday() to getmicrotime() to see if your benchmarks change any? Also; what clock are you using for your benchmarks? ACPI? TSC?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080602060624.93F5F8FC4A>