From owner-freebsd-performance@FreeBSD.ORG Tue Jun 3 09:20:00 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 60E631065670 for ; Tue, 3 Jun 2008 09:20:00 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id E964B8FC2F for ; Tue, 3 Jun 2008 09:19:59 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c220-239-252-11.carlnfd3.nsw.optusnet.com.au (c220-239-252-11.carlnfd3.nsw.optusnet.com.au [220.239.252.11]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m539Juip026310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jun 2008 19:19:57 +1000 Date: Tue, 3 Jun 2008 19:19:56 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Gary Stanley In-Reply-To: <200806021955.m52Jtqg2019409@mail14.syd.optusnet.com.au> Message-ID: <20080603185459.T6038@delplex.bde.org> References: <2B465A44-2578-4675-AA17-EBE17A072017@chittenden.org> <20080602182214.I2764@delplex.bde.org> <200806021955.m52Jtqg2019409@mail14.syd.optusnet.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-performance@FreeBSD.org, Bruce Evans 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: Tue, 03 Jun 2008 09:20:00 -0000 On Mon, 2 Jun 2008, Gary Stanley wrote: > 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: According to the amd64 arch manual (volume 3 3.14 Sep 2007): If CPUID 8000_0007.edx[8] = 1, then [details about hardware states...] then the TSC is suitable for use as a source of time. Google shows support for this feature in at least Linux and Xen. Phenom also has a rdtscp instruction which is serializing. > 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 difference seems to be only about -0x6000, with an overflow bug in the test giving a value near -2^32. > 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. Interesting. Please check the manual. I don't have current Intel arch manuals handy Bruce