From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 11:35:00 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A4C937B404 for ; Tue, 1 Apr 2003 11:35:00 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 2B99143FBF for ; Tue, 1 Apr 2003 11:34:59 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 36617 invoked from network); 1 Apr 2003 19:34:57 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 1 Apr 2003 19:34:57 -0000 X-pair-Authenticated: 209.68.2.70 Date: Tue, 1 Apr 2003 13:31:30 -0600 (CST) From: Mike Silbersack To: Poul-Henning Kamp In-Reply-To: <57215.1049219837@critter.freebsd.dk> Message-ID: <20030401132751.I564@odysseus.silby.com> References: <57215.1049219837@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Yar Tikhiy cc: hackers@freebsd.org Subject: Re: "Expensive timeout(9) function..." X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2003 19:35:00 -0000 On Tue, 1 Apr 2003, Poul-Henning Kamp wrote: > >Yeah, I suppose limiting it to one mii_tick routine per second would help > >somewhat... but it's still a bad situation. > > I wasn't advocating slowing it down that much, merely trying to run it > sequentially out of timeout()'s hair. Either way would be fine, I don't think there's any major need for a poll once per second. > There used to be a crumbled note with this somewhere in my stack > of TODO items, but by now I suspect that it is ironed perfectly > flat from the weight of all the stuff on top of it. > > But to add to my knowledge-base: What length of delays are you > looking for ? > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 I'd be happy with 100ns granularity (rounded up), with no major concern for jitter. For the purposes of the MII delays, all we really care is that we wait long enough; if we wait too long sometimes, that's no big deal. For reference, 3Com's documentation states that 40ns should be enough, but our current DELAY on i386 seems to take a few uS last time I checked. So, even if you can only get 300ns granularity, that'd still save a lot of time. This is why I suggested using something which just reads nanotime in a loop; nanotime should be accurate enough, right? BTW, does it appear to everyone else that half of these messages are getting dropped on their way to the lists, or is it just me? Mike "Silby" Silbersack