realtime problem

[Harti Brandt]

On Wed, 9 Apr 2003, John Polstra wrote:

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