A Fast Ethernet duplex mismatch can happen in one of the following ways (not meant to be an exhaustive list of causes):

1. One card is hard-coded to use full-duplex (often the switch side but it might be the host side, if you or your system administrator set it that way) and the other is set to auto-configure: the full-duplex side will not participate in negotiation and the auto-negotiating side will assume half-duplex mode to be conservative;
2. Both cards are set to auto-configure, but one or both of them is old or cheap and handles auto-configuration poorly (the odds also happened to work against you during this boot cycle); note that in this case, the problem will occur in roughly 50% of cases and rebooting (or resetting the interface by bringing it down and up again on) either end will clear the problem with about 50% probability;
3. The two cards are hard-coded to use different duplex modes;
4. One card is hard-coded to use full-duplex mode and the other side only supports half-duplex mode;
5. Both cards are relatively new and use brand-name chipsets from different manufacturers that do not inter-operate particularly well and you are unlucky this boot cycle.

The symptoms seen by the hosts will be the same regardless of the cause.

When duplex mismatch happens, a peculiar breakdown in communication occurs; an attempt to analyze it will be made here (the analysis is tentative). Denote the NIC that thinks that the connection is in full-duplex mode F and the NIC that thinks that the connection is in half-duplex mode H. F sends data whenever it has any and can receive data at any time; H does not receive bits while sending. Thus, frames going from H to F will sometimes be lost if there are frames going in the opposite direction. Frames going from H to F should not suffer. Assume that TCP data flow is essentially unidirectional. Denote the NIC on whose side the sender is located S, and the NIC on which the receiver is located R. A stream of MTU-sized frames will go from S to R and a stream (with typically half as many frames per second) of small frames containing packets that are TCP ACKs will go from R to S. ACKs are cumulative: if an ACK is lost and subsequent ACK is delivered, the same information is conveyed (and the effect of missed increment of TCP congestion window is mild). Consider two cases:

1. S=F, R=H: Data frames go from F to H, and can be lost whenever H is transmitting a frame containing an ACK packet. About 39 bytes are transmitted from H to F for every 1514 bytes in the opposite direction and the probability of missed bits in any given packet sent from F to H could be as much as 2-3%. This will have ruinous effect on TCP throughput: with RTT=70ms, no more than roughly 100kb/s can be transmitted. With low WAN jitter, significant correlation between times of arrival of frames going in the opposite directions can be present; it can make throughput larger or smaller. However, it will usually not exceed 1Mb/s for transcontinental links.
2. S=H, R=F: Data frames go from H to F and are normally not lost. A large percentage of frames from F to H containing ACKs will, however, be lost. If a link is fully used from H to F, almost all ACKs would be lost, and congestion window would stop increasing. Occasional losses in the data stream would make one reduce congestion window. Moreover, with many ACKs lost, fast retransmit is unlikely to happen, so the connection is likely to go into a timeout and then slow start. When link is only moderately used, significant percentage of ACKs get through, so TCP is sufficiently aggressive to sustain the rate. Overall, while TCP performance suffers badly, the effect is not nearly as catastrophic and pronounced than in the first case. (In this case, a window-size-limited TCP connection would do best if window is chosen to so that throughput is limited by, e.g., 30Mb/s. It is, of course, easier and better to fix the duplex mismatch.)