From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 23:20:35 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 7458416A41F for ; Fri, 14 Oct 2005 23:20:35 +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 CE55C43D4C for ; Fri, 14 Oct 2005 23:20:34 +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 j9ENKRNJ010475; Sat, 15 Oct 2005 09:20:27 +1000 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j9ENKOIE005570; Sat, 15 Oct 2005 09:20:25 +1000 Date: Sat, 15 Oct 2005 09:20:26 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Poul-Henning Kamp In-Reply-To: <13600.1129298731@critter.freebsd.dk> Message-ID: <20051015084425.C1403@epsplex.bde.org> References: <13600.1129298731@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 23:20:35 -0000 On Fri, 14 Oct 2005, Poul-Henning Kamp wrote: > In message <17231.43525.446450.161986@grasshopper.cs.duke.edu>, Andrew Gallatin > writes: >> What if somebody were to port the linux TSC syncing code, and use it >> to decide whether or not set kern.timecounter.smp_tsc=1? Would you >> object to that? > > Yes, I would object to that. > > Even to this day new CPU chips come out where TSC has flaws that > prevent it from being used as timecounter, and we do not have (NDA) > access to the data that would allow us to build a list of safe > hardware. Um, I have already pointed out that NDAs are not necessary. They (and staic lists) are also not sufficient. E.g., on my A7V-266E system (AXP on KT266A motherboard), the following breaks the TSC for timecounting: # Athlon idle hack for my KT266A. pciconf -w -b pci0:0:0 0x92 0xf9 # 79 -> f9 pciconf -w -b pci0:0:0 0x95 0x1a # 18 -> 1a Enough is freely disclosed, and the hardware is perfectly safe, but only if it configured without the (idle == really idle) setting which is set by the above hack but not by the BIOS. This setting reduces the temperature of a mostly-idle AXP system by about 10 degrees C. IIRC, the (idle == really idle) feature is entirely in the CPU and the hack just changes the state of the pins that control this feature. The breakage is much the same for 2 different generations of AXPs (a '1600 and a '2200) -- it causes jumps in the milliseconds per second range where without it there is only temperature-related drift in the nanoseconds per second range. I suspect all AXPs have this feature so they all have a potentially-broken TSC timecounter. Bruce