From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 09:42:02 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 924A516A41F for ; Fri, 14 Oct 2005 09:42:02 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFC1E43D4C for ; Fri, 14 Oct 2005 09:42:01 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j9E9frv8009558; Fri, 14 Oct 2005 19:41:53 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j9E9fkDT020104; Fri, 14 Oct 2005 19:41:52 +1000 Date: Fri, 14 Oct 2005 19:41:48 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Poul-Henning Kamp In-Reply-To: <12349.1129279613@critter.freebsd.dk> Message-ID: <20051014192509.F80520@delplex.bde.org> References: <12349.1129279613@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Garrett Wollman , Andrew Gallatin , net@FreeBSD.org Subject: Re: Call for performance evaluation: net.isr.direct (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 09:42:02 -0000 On Fri, 14 Oct 2005, Poul-Henning Kamp wrote: > In message <17230.62415.991707.840932@grasshopper.cs.duke.edu>, Andrew Gallatin > writes: > >> Linux already takes care of syncing the TSC between SMP cpus, so we >> know it is possible. This seems like a much more doable optimization. >> And it is likely to have other benefits.. The timestamps in mi_switch() are taken on the same CPU and only their differences are used, so they don't even need to be synced. It they use the TSC, then the TSCs just need to have the same almost-constant frequency (or different almost-constant frequencies if timecounters werre per-CPU). > Validating that the TSC is reliable is a nontrivial task which requires > access to a lot of NDA information and an extensive positive/negative > list of chips and chipsets. It only requires comparsion with another time source over a sufficently long enough time and large enough set of operating environments. This is hard to automate. I compare with a local ntp server with a known good TSC. > Even in the most recent chips, there are still issues with TSC that > makes it unusable as a default timecounter. I think newer chipsets are more liketly to have unusable TSCs. Anything with power control is unleky to have an almost-constant frequency. Bruce