From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 10 08:56:57 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 653D637B401; Thu, 10 Apr 2003 08:56:57 -0700 (PDT) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 480D643FCB; Thu, 10 Apr 2003 08:56:56 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [206.213.73.20]) by wall.polstra.com (8.12.3p2/8.12.3) with ESMTP id h3AFutdt089804 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 10 Apr 2003 08:56:55 -0700 (PDT) (envelope-from jdp@strings.polstra.com) Received: (from jdp@localhost) by strings.polstra.com (8.12.6/8.12.6/Submit) id h3AFuto3066162; Thu, 10 Apr 2003 08:56:55 -0700 (PDT) (envelope-from jdp) Date: Thu, 10 Apr 2003 08:56:55 -0700 (PDT) Message-Id: <200304101556.h3AFuto3066162@strings.polstra.com> To: hackers@freebsd.org From: John Polstra In-Reply-To: <20030409211302.S1322@beagle.fokus.fraunhofer.de> References: <20030409114957.GN83126@cicely9.cicely.de> <200304091900.h39J0igT063938@strings.polstra.com> <20030409211302.S1322@beagle.fokus.fraunhofer.de> Organization: Polstra & Co., Seattle, WA cc: harti@freebsd.org Subject: Re: realtime problem 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: Thu, 10 Apr 2003 15:56:57 -0000 In article <20030409211302.S1322@beagle.fokus.fraunhofer.de>, Harti Brandt wrote: > > The problem is, that the access to the MII registers is very slow. It > needs to shift out and in data and addresses into a serial line with > defined timings. The timings are in the sub-usec range and therefor > DELAY(1) are used. Because a DELAY(1) actually delays several microseconds > this may sum up to several milliseconds. This mii status code is called > from a callout and that means it botches your timing if HZ is 1ms or less. [...] > There are basically two solutions to the problem: > > 1. a nanodelay() function in the kernel > 2. do all the status polling via a kernel thread And a possible third solution for some NICs: Don't poll the PHY at all. Several modern Ethernet chips, including the em and bge gigabit chips, monitor the PHY themselves and can interrupt on link state changes. With these chips there should be no need at all for periodic polling of the PHY. Our bge driver polls it anyway, but that could be fixed. The em driver also seems to poll the PHY, but I don't see why it's necessary. With that change, the large delays would happen only when the link state actually changed. That would be a big improvement. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa