From owner-freebsd-performance@FreeBSD.ORG Mon Jun 2 06:06:24 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4D3F1065677 for ; Mon, 2 Jun 2008 06:06:24 +0000 (UTC) (envelope-from gary@velocity-servers.net) Received: from longhorn.velocity-servers.net (longhorn.velocity-servers.net [65.99.246.30]) by mx1.freebsd.org (Postfix) with ESMTP id 93F5F8FC4A for ; Mon, 2 Jun 2008 06:06:24 +0000 (UTC) (envelope-from gary@velocity-servers.net) Received: from [70.106.53.131] (helo=dragoon.velocity-servers.net) by longhorn.velocity-servers.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K32lk-000J0h-4X; Mon, 02 Jun 2008 00:39:44 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 02 Jun 2008 01:39:41 -0400 To: Sean Chittenden ,freebsd-performance@freebsd.org From: Gary Stanley In-Reply-To: <2B465A44-2578-4675-AA17-EBE17A072017@chittenden.org> References: <2B465A44-2578-4675-AA17-EBE17A072017@chittenden.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - longhorn.velocity-servers.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [26 6] / [26 6] X-AntiAbuse: Sender Address Domain - velocity-servers.net Message-Id: <20080602060624.93F5F8FC4A@mx1.freebsd.org> X-Mailman-Approved-At: Mon, 02 Jun 2008 09:35:00 +0000 Cc: Subject: Re: Micro-benchmark for various time syscalls... X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2008 06:06:24 -0000 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?