On 2/21/2000 2:53 AM Bob Edwards Robert.Edwards@anu.edu.au wrote:
>Thanks to all who replied to my enquiry about the suspect speed of
>the ntulip driver. Paul Mackerras of Linuxcare's OZLabs (and the guy who
>ported Linux to the PPC) sat down with me earlier in the day and helped
>me figure out what was wrong (he has contributed to the de4x5 driver).
Glad you had some success, Bob! Many thanks to Paul for his efforts!
>Basically, there were three main problems:
> - udelay was broken.
Well, yes, udelay was/is broken (as the comments in the source code
indicated, it is for very gross delays only), but, udelay was only used
in two sections. First, it was used in the EEPROM reading code. This
happened well before the frames were transmitted, and thus, by the time
the Etherboot code printed the card's MAC address on the screen (a
fraction of a second into booting) this code was long over.
The other use of udelay was at the end of ntulip_transmit, which I
immediately (and emphatically) suggested removing in my patch, as it was
clearly not needed.
> - ntulip_transmit doesn't need to stop and start the transmitter for
> each frame
True, it probably doesn't; But the delay introduced by this code amounts
to a couple of bus cycles (outl calls), which is negligable. In the
environment we're in (pre-boot, supporting a variety of cards), turning
off and on the transmitter, though over-kill (for your card) may be more
robust for some cards. Probably a NOOP in most cases. Remember, we're
supporting a number of cards here, and defensive programming, though
marginally slower, may be more robust.
> - ntulip_transmit doesn't need to wait 300us (actually ~3800us) before
> returning, it can simply wait until the frame has gone.
From your message (and my analysis), this seemed to be the real
time-stealer, and my patch removed this call to udelay, which probably
got back 3800/3900 or over 97.4% of the delay you were seeing. I guess
you did not receive my email that described this fix in a timely fashion.
(Maybe your network connection is infrequent? I did reply to your first
message with a patch within 8 hours of your message appearing at my mail
server on Sunday morning.)
>With these changes to ntulip.c, we have now got the 5.4MB download time
>down from 42+ seconds to 10.5 seconds. Still not as good as the eepro100
>driver (at 3.6 seconds), but a lot better (over 30 seconds less per boot).
>I will forward the patches onto Ken as soon as I have them formatted
>correctly.
There are a few other things that I noticed that may be contributing to
the performance difference you are seeing with you 21143s. As soon as I
see your patches, I'd like to suggest a couple of other optimizations for
your particular card that might give you even better performance. I
suspect part of the initialization code being run for your card is not
optimal.
What is the brand and model of your Ethernet cards? If I can find one
locally, I'd be happy to try to optimize the driver to lower latency and
increase performance for you.
Remember that ntulip.c supports a number of Tulip clone cards, and some
of the code which might appear not applicable to the 21143 may be
necessary for other cards to be reliable, thus we may need to
conditionalize your optimizations. The Linux driver, for example says it
support over 100 tulip models and clones, and is heavily conditionalized.
The general execution path is sometimes not optimal for any one card, but
can be optimized by conditionalization where the performance/reliability
improvement warrants.
In any case, I'm glad you're seeing better performance, and hope that my
efforts contributed to the improvement.
Regards,
Marty
---
Name: Martin D. Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827; Cambridge, MA 02139; USA
Voice: (617) 491-6935, Fax: (617) 491-7046
Email: mdc@thinguin.org
Web: http://www.thinguin.org/
===========================================================================
This Mail was sent to netboot mailing list by:
Marty Connor <mdc@thinguin.org>
To get help about this list, send a mail with 'help' as the only string in
it's body to majordomo@baghira.han.de. If you have problems with this list,
send a mail to netboot-owner@baghira.han.de.
For requests or suggestions regarding this mailing list archive please write to netboot@gkminix.han.de.