Date: Mon, 26 Apr 2004 14:25:57 +1000 From: David Burns <david.burns@dugeem.net> To: Bruce Evans <bde@zeta.org.au> Cc: net@freebsd.org Subject: Re: fast ethernet driver MII phy serial clock rates Message-ID: <408C8F55.1080001@dugeem.net> In-Reply-To: <20040426115156.X3272@gamplex.bde.org> References: <408A160F.4090703@dugeem.net> <20040424140143.S5713@odysseus.silby.com> <408BBBD3.4090200@dugeem.net> <20040426115156.X3272@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote: > 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). > No argument that a DELAY(x) delays for a minimum of x microseconds - this is what we're seeing. The fact that we're using a DELAY() which can be interrupted inside locked code seems problematic - although I guess it just slows driver operation down. > >>>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. Sorry I should have made myself clearer. Given the evidence that a DELAY(1) delays for far more than 1 microsecond we just need some other kind of known delay which will allow us to wait a few hundred nanoseconds (the MDIO clock period of most 100Mb/s PHYs) instead of a DELAY which is an order of magnitude higher (and is subject to interrupts). A dummy PCI operation would achieve this. > > 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. > Yes the term nanosecond delay is inappropriate - when it is only a submicrosecond delay we need. > >>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). > A PCI implementation built from ISA components perhaps ... :-) It still comes back to slowing down PHY accesses without using DELAY(). The fact that ste DELAY() removal provided a small but non-trivial improvement in network performance (including other network cards on the same PCI bus) underlines how horrible the use of DELAY() is. I'm only after a simple fix - experiment with removal of MII code DELAY() on the affected drivers and commit the change only where testing results are good. David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?408C8F55.1080001>