13

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.

  1. Why was only downstream affected and not upstream?

  2. Are these real collisions? Since cable has separate transmit and receive pairs.

Improve this question
1
  • Are 70/80 based on a single test or the average of multiple tests? Considering the varying window size a single test would be too vague.
    – user2964971
    Commented Apr 19, 2014 at 10:32

2 Answers 2

Reset to default
14

This is entirely normal behaviour with a duplex mismatch.

Why was only downstream affected and not upstream?

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.

Are these real collisions? Since cable has separate transmit and receive pairs.

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.

Improve this answer
4
  • 2
    it took me a while to see your point on the speed difference question, but this is a good answer... you may want to improve it to explicitly point out that the switch's Tx is rate-limited more than the PC, because it must wait longer due to CSMA/CD collision detection than the PC will wait for runt frames from the collisions. Conversely, if even a few of the PC's TCP ACKs collide on the PC's download, the download is double-penalized by both TCP and ethernet's CSMA/CD. Dropped TCP ACKs slow both transfers down, but CSMA/CD's backoff kills the download.
    – Mike Pennington
    Commented Feb 1, 2014 at 17:15
  • It also depends on which end is Full and which end is Half The Full one sends/receives without problems while the other one will see a collision for every packet This means that data transfer from the Full end will cause less collision on the Half end (as the half end will try to squeeze the ACK between large packet) while the other way around, the full end will cause lots of collision because it has more chance to "hit" a large packet with a smaller acknowledge. It might not be the right explanation but it fits what I've seen.
    – Remi Letourneau
    Commented Feb 4, 2014 at 14:09
  • @RemiLetourneau, clearly if the direction of the mismatch were to be reversed, the effect would be reversed as well. In such a case you could swap the computer/switch terms in my answer (which was frame to answer the OP's question). Not sure I follow all the rest of your comment though.
    – YLearn
    Commented Feb 10, 2014 at 19:51
  • @YLearn What I meant to say is that duplex mismatch symptoms includes traffic going at a relatively normal speed one way and slowing to a crawl the other way around. Something to do on which end is sending big frames and witch end is sending acknowledge. As you say, if you reverse the mismatch config, you reverse the traffic slowness.
    – Remi Letourneau
    Commented Feb 10, 2014 at 20:56
3

If the TCP was tested, there are a lot of things you can't control or even to imagine. The difference in downstream/upstream could be easily caused by NIC internal priority settings, buffers for RX/TX and essentially low-level settings that dictate how to handle RX and TX traffic.

'sh controllers' should report any simultaneous RX and TX condition as collision if working in half-duplex mode.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.