Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 9 Apr 2003 21:28:48 +0200 (CEST)
From:      Harti Brandt <brandt@fokus.fraunhofer.de>
To:        John Polstra <jdp@polstra.com>
Cc:        hackers@freebsd.org
Subject:   Re: realtime problem
Message-ID:  <20030409211302.S1322@beagle.fokus.fraunhofer.de>
In-Reply-To: <200304091900.h39J0igT063938@strings.polstra.com>
References:  <20030409114957.GN83126@cicely9.cicely.de> <200304091900.h39J0igT063938@strings.polstra.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 9 Apr 2003, John Polstra wrote:

JP>In article <20030409144042.B901@beagle.fokus.fraunhofer.de>,
JP>Harti Brandt  <brandt@fokus.fraunhofer.de> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030409211302.S1322>