From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 9 12:28:56 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 4056237B41E for ; Wed, 9 Apr 2003 12:28:55 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D72543F75 for ; Wed, 9 Apr 2003 12:28:54 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h39JSnE29133; Wed, 9 Apr 2003 21:28:49 +0200 (MEST) Date: Wed, 9 Apr 2003 21:28:48 +0200 (CEST) From: Harti Brandt To: John Polstra In-Reply-To: <200304091900.h39J0igT063938@strings.polstra.com> Message-ID: <20030409211302.S1322@beagle.fokus.fraunhofer.de> References: <20030409114957.GN83126@cicely9.cicely.de> <200304091900.h39J0igT063938@strings.polstra.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hackers@freebsd.org Subject: Re: realtime problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: harti@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2003 19:28:57 -0000 On Wed, 9 Apr 2003, John Polstra wrote: JP>In article <20030409144042.B901@beagle.fokus.fraunhofer.de>, JP>Harti Brandt wrote: JP>> You must change HZ by putting JP>> JP>> options HZ=2000 JP>> JP>> or whatever you want in your config file. JP>> JP>> You should also ensure, that you have no miibus ethernet cards in your JP>> system, or comment out the relevant sections in dev/mii that periodically JP>> call the status update stuff. JP> JP>Huh? I'm not aware of any hz-related botches in the mii code. JP>Could you give me a specific example? I'd like to fix it if I can JP>find it. 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. I first discovered this with the xl driver. Mike Silbersack commited a number of patches that have improved the situation somewhat coming down from some 8ms to a little bit more than 1ms. There have been again some emails about this a couple of days ago (don't remember which list). 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 Actually I think the latter is much easier to do and is also better because it gets unneccesary processing out of the clock processing. You will find some of the mails in cvs-all around september 16th last year with the subject Re: src/sys/kern kern_timeout.c What I have done im my setup is to return from ukphy_status after the first 30 calls :-) harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org