From owner-freebsd-performance@FreeBSD.ORG Mon Jun 2 19:55:52 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 BC39C1065671 for ; Mon, 2 Jun 2008 19:55:52 +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 ADC778FC1F for ; Mon, 2 Jun 2008 19:55:52 +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 1K3G8H-000Lk0-OD; Mon, 02 Jun 2008 14:55:53 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 02 Jun 2008 15:55:48 -0400 To: Bruce Evans From: Gary Stanley In-Reply-To: <20080602182214.I2764@delplex.bde.org> References: <2B465A44-2578-4675-AA17-EBE17A072017@chittenden.org> <20080602182214.I2764@delplex.bde.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: <20080602195552.ADC778FC1F@mx1.freebsd.org> X-Mailman-Approved-At: Mon, 02 Jun 2008 20:24:46 +0000 Cc: freebsd-performance@FreeBSD.org 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 19:55:52 -0000 At 06:19 AM 6/2/2008, Bruce Evans wrote: >These are very slow. Are they on a 486? :-) I get about 262 ns for >CLOCK_REALTIME using the TSC timecounter on all ~2GHz UP systems. >The syscall overhead is about 200 nsec (170 nsec for a simpler syscall >and maybe 30 nsec extra for copyin/out for clock_gettime()) and reading >the TSC timecounter adds another 60 nsec, including a whole 6 nsec for >the hardware part of the read (perhaps more like 30 nsec than 60 for the >whoe read). The TSC doesn't work on all machines (never for SMP), but >this will hopefully change. (Phenom is supposed to have TSCs that are >coherent across CPUs, and rdtsc has slowed down from 12 cycles to 40+ >to implement this :-(. Core2 already has a 40+ cycles rdtsc, but AFAIK >it doesn't have coherent TSCs.) Other timecounters are much slower than >the TSC, but I haven't seen one take 8000 nsec since 486 days. Phenom's don't have TSCs that are coherent, as least on a few machines here: 4 CPUs, running 4 parallel test-tasks. checking for time-warps via: - read time stamp counter (RDTSC) instruction (cycle resolution) - gettimeofday (TOD) syscall (usec resolution) - clock_gettime(CLOCK_MONOTONIC) syscall (nsec resolution) new TSC-warp maximum: -4294919263 cycles, 00000000ffffe11b -> 0000000000009cbc new TSC-warp maximum: -4294919300 cycles, 00000000ffff74e4 -> 0000000000003060 | TSC: 2.24us, fail:3 | TOD: 2.24us, fail:0 | CLK: 2.24us, fail:0 | The code to test the TSC to check for warping: http://leaf.dragonflybsd.org/~gary/tests/time-warp-test.c However, it seems that Core2's don't have any warping of the TSC. I tested that code on a core2quad for 8 hours with no TSC failures.