From owner-freebsd-net@FreeBSD.ORG  Fri Oct 14 15:44:38 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 7450E16A41F
	for <net@FreeBSD.org>; Fri, 14 Oct 2005 15:44:38 +0000 (GMT)
	(envelope-from phk@critter.freebsd.dk)
Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 1305143D46
	for <net@FreeBSD.org>; Fri, 14 Oct 2005 15:44:37 +0000 (GMT)
	(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (unknown [192.168.48.2])
	by phk.freebsd.dk (Postfix) with ESMTP id 4ECC4BC84;
	Fri, 14 Oct 2005 15:44:34 +0000 (UTC)
To: Andrew Gallatin <gallatin@cs.duke.edu>
From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
In-Reply-To: Your message of "Fri, 14 Oct 2005 10:54:17 EDT."
	<17231.50841.442047.622878@grasshopper.cs.duke.edu> 
Date: Fri, 14 Oct 2005 17:44:33 +0200
Message-ID: <31823.1129304673@critter.freebsd.dk>
Sender: phk@critter.freebsd.dk
Cc: Garrett Wollman <wollman@csail.mit.edu>, 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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Oct 2005 15:44:38 -0000

In message <17231.50841.442047.622878@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.
>
>Bear in mind that I have no clue about timekeeping.  I got into this
>just because I noticed using a TSC timecounter reduces context switch
>latency by 40% or more on all the SMP platforms I have access to:
>
>1.0GHz dual PIII : 50% reduction vs i8254
>3.06GHz 1 HTT P4 : 55% vs ACPI-safe, 70% vs i8254)
>2.0GHz dual amd64: 43% vs ACPI-fast, 60% vs i8254)

The solution is not faster but less reliable timekeeping, the
solution is to move the scheduler(s) away from using time as an
approximation of cpu cycles.

>However, if the linux solution is not
>correct, then somebody with timekeeping knowledge needs to get 
>involved.  Is this you?

The linux "solution" is not correct, and timekeeping knowledge I
have, but the solution is in the scheduler where my clue is limited.

>BTW, is an algorithm like Solaris' the "best compromise" you mention
>above?  Or is it just keeping the TSC in sync?  They seem to maintain
>a high resolution timer based on tsc, and keep it in sync every
>second, and fixup drift on different cpus, and the TSC
>being reset after suspend/resume.
>http://cvs.opensolaris.org/source/xref/usr/src/uts/i86pc/os/timestamp.c

Solaris don't change the tsc frequency by a factor 8 without giving
the OS a chance to know about it.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.