From owner-freebsd-net@FreeBSD.ORG Sun Apr 25 19:39:57 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47C0D16A4CF for ; Sun, 25 Apr 2004 19:39:57 -0700 (PDT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8646043D46 for ; Sun, 25 Apr 2004 19:39:56 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])i3Q2dp5v009055; Mon, 26 Apr 2004 12:39:51 +1000 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i3Q2dmI2003761; Mon, 26 Apr 2004 12:39:49 +1000 Date: Mon, 26 Apr 2004 12:39:46 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: David Burns In-Reply-To: <408BBBD3.4090200@dugeem.net> Message-ID: <20040426115156.X3272@gamplex.bde.org> References: <408A160F.4090703@dugeem.net> <20040424140143.S5713@odysseus.silby.com> <408BBBD3.4090200@dugeem.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: net@freebsd.org Subject: Re: fast ethernet driver MII phy serial clock rates X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2004 02:39:57 -0000 On Sun, 25 Apr 2004, David Burns wrote: > Mike Silbersack wrote: > > > > On Sat, 24 Apr 2004, David Burns wrote: > >>NB this assumes that a DELAY(1) is really a delay of 1?s! Which I don't > >>think it is ... :-( > > > > Correct, DELAY takes far longer than it should. Actually, it takes at least as long as it should (normally a few microseconds longer than the specified delay, but hundreds or thousands of microseconds longer if it is interrupted). The bus ISA accesses in it can also be delayed by (PCI) bus activity (I've measured 170 usec for the 3 accesses in getit() which normally take 3-4 usec). > > If you're really interested in fixing the problem and not inadvertantly > > breaking older cards, what you should do is implement a nanodelay function > > that actually delays for the time it's supposed to and then delay the > > rated amount. Removing all delays will probably break something > > somewhere. > > We could probably build a driver specific nanodelay function based on > dummy PCI operations. Some will say this sucks but then I'd argue it's > better than the current DELAY implementation. No, it would be considerably worse. DELAY() has a poor resolution because non-dummy ISA operations that it uses to read the time are slow. Dummy PCI operations aren't much faster, depending on which address they are at. They would be at least 3 times faster in practice since the current implementation of DELAY() needs 3 ISA operations. DELAY() could probably use only the low byte of an unlatched counter if its efficiency were important. I think it is unimportant, since only broken code uses busy-wait. Anyway, you won't get near nansoseconds reasolution or PCI clock resolution (30 nsec) using PCI i/o instructions. rdtsc on i386's and delay loops on all machines can easily do better provided the CPU doesn't get throttled. > Of course just sending one bit of data on the MDIO will take us about > 600 nanoseconds - resulting in a 1.6MHz clock. Except some machines add lots of wait states. I have a PCI card which can usually be accessed in 467 nsec (write) and 150 nsec (read) on one machine, but on a newer machine which is otherwise 6 times faster but appears to have a slow PCI bugs (ASUS A7N8X-E), the access times increase to 943 nsec (write) and 290 nsec (read). Bruce