From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 01:29:05 2005 Return-Path: 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 07C8D16A4CF for ; Mon, 31 Jan 2005 01:29:05 +0000 (GMT) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.FreeBSD.org (Postfix) with SMTP id 4A81C43D3F for ; Mon, 31 Jan 2005 01:29:04 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 33005 invoked from network); 31 Jan 2005 01:29:02 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 31 Jan 2005 01:29:02 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sun, 30 Jan 2005 19:29:02 -0600 (CST) From: Mike Silbersack To: Robert Watson In-Reply-To: <20050130191410.R62670@odysseus.silby.com> Message-ID: <20050130192525.T62670@odysseus.silby.com> References: <20050130191410.R62670@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Mon, 31 Jan 2005 12:46:43 +0000 cc: Poul-Henning Kamp cc: current@freebsd.org cc: Colin Percival Subject: Re: tcp_isn_tick() / dummynet() callout madness ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 31 Jan 2005 01:29:05 -0000 On Sun, 30 Jan 2005, Mike Silbersack wrote: > This could be used with your auto-reschedule idea; perhaps the way > auto-reschedule would work is that each callout has a next callout time set. > So, suppose that we have a delayed ack timeout happening in 50ms, and a > potential retransmit timeout happening in 4 seconds. We'd set the per-socket > callout for 50ms, with a next time of 4 seconds. When the callout fires, > it'll be rescheduled for 3.95 seconds from now, and if that's wrong, we'll > just have to incur the cost of rescheduling it. Ok, thinking about it just a little more, the "next" field would have to be stored in the callout structure, and it would have to be unsychronized. We'd have to assume that it would ONLY be updated by a callout handler, which is why sychronization would be safe. Example: tcp_isn_tick_callout fires + tcp_isn_tick_callout rescheduled to fire at "next" time tcp_isn_tick routine is executed + tcp_isn_tick_callout.next is set for whatever time it should fire after the next firing Does that make sense? It allows for routines to schedule themselves on a fixed schedule or on a mildly variable schedule. If they guessed wrong on what "next" should be, then they'd just use callout_reset to change the scheduling, and incur the cost they do right now for every reschedule. Mike "Silby" Silbersack