A user had issues with download speed from the Internet. The connection to the Internet is 100 Mbit/s. The user got around 7 Mbit/s downstream and around 80 Mbit/s upstream.
I tested from my computer and it got around 70 Mbit/s downstream and 80 Mbit/s upstream. Obviously the users PC was to blame.
I checked the switch which is a Catalyst 3560 and there it was as I expected, the port was in half duplex. The user had hard coded his PC to 100/full and the port was using auto. The speed is detected by the Fast Link Pulses (FLP) but the duplex must be assumed to be half so the port was using 100/half. With show controller I could see collisions and late collisions as expected.
The bandwidth was tested via the swedish site www.bredbandskollen.se. It uses TCP to test the latency at first. Then it opens a socket via Flash and does several HTTP GET (TCP) and measures the downstream bandwith for about 10 seconds. After that it does four HTTP posts to the server and sends traffic for 10 seconds and calculates the upstream bandwidth.
I know that these kind of sites are not 100% accurate but usually they can at least give some kind of indication if you are close to receiving the kind of bandwidth that you should and it was an easy test to run to make sure it was the user and not the network at fault here.
-
Why was only downstream affected and not upstream?
-
Are these real collisions? Since cable has separate transmit and receive pairs.
Best Answer
This is entirely normal behaviour with a duplex mismatch.
Since the computer is operating in full duplex mode, it isn't utilizing CSMA-CD. This means it doesn't check if the medium is idle before it transmits, nor will it perceive any data it receives while transmitting as a collision. As such, the upload from the computer would remain largely unaffected.
Conversely, the switch is utilizing CSMA-CD and will wait for the medium to be idle before it transmits. In addition, when the switch detects a collision, it immediately stops transmitting the frame and follows the CSMA-CD collision detect procedure. This has a significant performance impact on the traffic sent to the computer.
When the traffic is TCP, the negative effect will be multiplied as any lost TCP ACK's going to the computer will cause a TCP retransmission.
Yes, they are real collisions; even in a full half duplex environment (i.e. hubs) there are separate transmit and receive pairs. The reason is that in a half duplex environment the hubs will repeat the signal received on one port out all other ports. If two stations were to try to transmit at the same time, the signal that gets repeated will not be usable.
Since the switch is operating in half duplex mode, it operates like it is in such an environment and can only transmit or receive at any given time. Any time the switch is sending a frame and detects other traffic on the medium (i.e. the computer, which isn't checking for an idle medium), this is treated as a collision and the switch will follow the collision detection procedure (which includes a wait or back off period of time).
As the computer is not operating this way (i.e. it starts transmitting automatically when there is data to send), you end up with many more collisions than you would get in a environment that was entirely made up of half duplex devices.
Edit: I did come across a reference to these this weekend while searching an unrelated matter where they were referred to as false collisions. I would disagree with this viewpoint since the switch clearly sees them as a collision and handles them as such. Rather, I would think of them as unnecessary collisions in that they should not exist in a switched network.
As an aside, this is the most often reported type of duplex mismatch (where the switch is set to auto and the computer to full duplex). Most people download much more than they upload, they tend to notice this condition more easily to report it.