Date: Thu, 10 Apr 2003 08:56:55 -0700 (PDT) From: John Polstra <jdp@polstra.com> To: hackers@freebsd.org Cc: harti@freebsd.org Subject: Re: realtime problem Message-ID: <200304101556.h3AFuto3066162@strings.polstra.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <20030409211302.S1322@beagle.fokus.fraunhofer.de>, Harti Brandt <harti@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200304101556.h3AFuto3066162>