From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 17:21:33 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9515916A420 for ; Fri, 6 Jan 2006 17:21:33 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88FEB43D46 for ; Fri, 6 Jan 2006 17:21:22 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id A3A025DE9; Fri, 6 Jan 2006 12:21:21 -0500 (EST) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57657-06; Fri, 6 Jan 2006 12:21:19 -0500 (EST) Received: from [192.168.1.3] (pool-68-161-122-227.ny325.east.verizon.net [68.161.122.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 04B815DDA; Fri, 6 Jan 2006 12:21:18 -0500 (EST) Message-ID: <43BEA718.6090306@mac.com> Date: Fri, 06 Jan 2006 12:21:28 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Dillon References: <73774.1136109554@critter.freebsd.dk> <20060101035958.A86264@xorpc.icir.org> <43B7E1EC.5090301@mac.com> <200601060636.k066aNYn079015@apollo.backplane.com> In-Reply-To: <200601060636.k066aNYn079015@apollo.backplane.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Cc: Luigi Rizzo , Poul-Henning Kamp , current@freebsd.org Subject: Re: FreeBSD handles leapsecond correctly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 17:21:33 -0000 Matthew Dillon wrote: >: Luigi Rizzo wrote: [ ... ] >:> on a related topic, any comments on this one ? >:> Is this code that we could use ? >:> >:> http://www.dragonflybsd.org/docs/nanosleep/ >: >:I ported the tvtohz change from Dragonfly back to 4.10 and 5-STABLE here: >: >:http://www.pkix.net/~chuck/timer/ >: >:...so anyone who wants to experiment can try it out. :-) [ ... ] > > It isn't so much tvtohz that's the issue, but the fact that the > nanosleep() system call has really coarse hz-based resolution. That's > been fixed in DragonFly and I would recommend that it be fixed in > FreeBSD too. After all, there isn't much of a point having a system > call called 'nanosleep' whos time resolution is coarse-grained and > non-deterministic from computer to computer (based on how hz was > configured). Agreed. The changes I'd copied back basicly correct the issue of nanosleep() waiting an extra tick, so they cut the average latency seen by something trying to wakeup at an exact point from about 1.5 * HZ to about 0.5 * HZ, but they don't give it finer-grained timing. > Since you seem to be depending on fine-resolution timers more and > more in recent kernels, you should consider porting our SYSTIMER API > to virtualize one-shot and periodic-timers. Look at kern/kern_systimer.c > in the DragonFly source. The code is fairly well abstracted, operates > on a per-cpu basis, and even though you don't have generic IPI messaging > I think you could port it without too much trouble. > > If you port it and start using it you will quickly find that you can't > live without it. e.g. take a look at how we implement network POLLING for > an example of its use. The polling rate can be set to anything at > any time, regardless of 'hz'. Same goes for interrupt rate limiting, > various scheduler timers, and a number of other things. All the things > that should be divorced from 'hz' have been. Out of curiosity, what is DragonFly doing with the network timing counters (ie, TCPOPT_TIMESTAMP and the stuff in ), has that been seperated from HZ too? I'm pretty sure that setting: #define TCPTV_MSL ( 30*hz) /* max seg lifetime (hah!) */ ...with HZ=1000 or more is not entirely correct. :-) Not when it started with the TTL in hops being equated to one hop per second... -- -Chuck