[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Delayed ACK behavior - Solved

From: David Empson
Subject: Re: [lwip-users] Delayed ACK behavior - Solved
Date: Tue, 25 Aug 2009 12:06:09 +1200

Glad to hear you have tracked down your problem with delayed acks. Just a comment on one point:
JM wrote:
> After a little research here and some general Internet searches, it appears that full duplex and hubs don't mix. 
Correct. Hubs require half duplex operation. Switches will function in either half or full duplex mode, but full duplex is more efficient because data can travel both ways simultaneously.
>I paid no attention to the duplex of the ethernet controller, but my guess is it's in full duplex right now, and if I switch
>modes to half duplex, a hub can be used.  I'm not sure how a computer does this; apparently it's automatic, seeing
>as how it doesn't seem to care if it's connected to a hub or switch. 
There is a negotiation protocol which is triggered when the cable is plugged in. The two Ethernet PHYs establish the best supported speed and duplex settings that both ends can handle, and in the last few years they also work out the wiring configuration (auto-MDX).
Some Ethernet controllers manage all of this automatically (or have a mode bit to enable automatic negotiation), while others may require you to interact with the PHY to trigger the negotation sequence, get its results (or set a fixed mode), and configure the MAC accordingly.
Looking at our driver, it appears we are waiting for the PHY to do auto-negotiation, then reading the result and setting the MAC to full or half duplex according to the result from the PHY. (We also have configuration which allows manual override of both the speed and duplex, in case the autonegotiation doesn't work for some customers.)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]