Fragmentation threshold?

Discussion in 'Wireless Internet' started by Roderick Stewart, Feb 8, 2004.

  1. Can somebody please explain "Fragmentation Threshold" and "RTS
    Threshold" and how to choose the best settings? A new laptop with
    wireless already installed has 2346 and 2347 respectively for these
    values, but a US Robotics card that I installed in another laptop came
    up with 4096 as default. I think there was also a setting in the US
    Robotics router/AP (can't check this now because it's somewhere else)
    and this was 2346 just like my laptop. My Belkin access point doesn't
    seem to have a setting at all.

    It seemed logical to change the other laptop settings to be the same as
    the router (like MTU values), or at least the same as my laptop because
    it works, but I couldn't honestly say I noticed any difference. So what
    do they mean and what do they do?

    Roderick Stewart, Feb 8, 2004
    1. Advertisements

  2. Roderick Stewart

    gary Guest

    The MAC frame, or MPDU, is your data payload (an IP packet, for example)
    wrapped with MAC protocol header and trailer fields. The maximum length of
    the MPDU is 2346 bytes, and the amount of data in the payload field is a max
    of 2312 bytes. The packet you are sending could be much longer - each MAC
    transmit operation allows up to 4095 bytes. So, if 4095 bytes is submitted
    to the MAC for transmission, this has to be split into at least two payload
    fragments, to be sent in two separate MAC frames, and reassembled at the
    receiving station.

    The fragmentation threshold is a tuneable with a maximum value of 2346 that
    specifies the largest size of any MPDU. It must be an even number. The MAC
    will always fragment any payload that will not fit into a single 2346-byte
    MPDU, but by setting the threshold to a smaller number, you can force
    fragmentation to occur at smaller payload sizes - and therefore more
    frequently. This might be done on busy networks where several stations are
    routinely transferring large payloads, and have high contention and backoff
    overhead. Forcing smaller transmitted frame sizes is one way to reduce the
    likelihood of collisions.

    I don't know why the U.S. Robotics card had the value 4096, since it appears
    to be meaningless as an actual threshold. The MAC can receive up to 4095
    bytes for a single transmit transaction, but it has to break this up to meet
    maximum frame size requirements. Any number bigger than 2344 essentially has
    no effect, so maybe 4096 is just a big number that means "ignore this

    RTS threshold is the MPDU size at which the RTS protocol is used to reserve
    the entire network for each transmit. With RTS, every transmitted packet (in
    an infrastructure network) is guaranteed to have no collision. This adds
    huge overhead, and is only justified if it eliminates worse overhead due to
    contention and backoff. RTS threshold and fragmentation threshold are often
    set to the same value, for obvious reasons.

    Unless you have an extremely busy network, with multiple stations doing lots
    of file transfer or data streaming, I wouldn't change these settings. It
    sounds like all of your stations are set to values that disable RTS and
    transmit maximum size MPDUs, which is what you want on a normal network.
    gary, Feb 8, 2004
    1. Advertisements

  3. Hi Rod;

    Good questions. OK... Right.... Lets start with vendor philosophy.
    Vendors generally ship with defaults which defeat fragmentation and
    defeat RTS. Why? Vendors believe that most installs involve only one
    remote node (say a laptop). Therefore they opt for performance over
    sanity. Now we can talk about how things should be if you have more
    than one computer accessing your AP at the same time.

    RTS (Request To Send) is a value which is set that informs your STA
    (client device) when it should ask the AP for permission to send in an
    Infrastructure environment. If the packet your client device wishes
    to send is smaller than the RTS value it will send it without asking
    the AP for permission. If it is larger than the RTS value it will
    send a request to send before it actually sends the data. It will
    then wait for a CTS (clear to send) from the AP before it will
    actually send it's data. This is a good thing because when there are
    multiple STA (client devices) in a network they can't always hear each
    other but they can (theoretically) always hear the AP. Thus is one
    device hears the AP tell a different device that it may send data, the
    first device can "stand down" and thus avoid a collision. Such is the
    basic theory. RTS should be set to about 1/2 the size of the maximum
    fragment size in a network which has more than one client device.

    Hmmm.... I said fragment size in that last sentence... should make a
    good lead in to this paragraph. As it turns out packets in TCP/IP can
    be pretty darned big. These devices send data in chunks called
    fragments. There is a maximum fragment size for your device and on
    most devices it is around 2K bytes. When a radio receives a packet
    for transmission it breaks it into as many fragments as necessary
    before transmitting fragments one at a time across the wireless link.
    Now is your packet is say 16K bytes, your client radio is going to
    break that into about 8 fragments and if RTS is turned off (as it is
    by default), your radio is going to just burst out those 8 fragments
    without even bothering to see if some other device is also trying to
    use the medium you get a mess. Deciding what value to set for
    fragmentation is more problematic. On a network where lots of small
    packets are being sent by multiple clients, one would set
    fragmentation farily low. On a network where most clients are just
    browsing the web (big packets) one would set the fragmentation fairly
    high. A good compromise is something aroung 1024 bytes.

    If you have fragmentation set to 1024 bytes and you have RTS set to
    half of that (512 bytes), what you have told the system is this:


    Why is this important. It reduces latency and improves "sharing" of
    the channel between stations.

    Hope that helps
    Michael Erskine, Feb 8, 2004
  4. Thanks very much to both of you for taking the trouble to explain this
    to me. It's useful to know how to use something I've bought to best
    advantage, it's interesting in it's own right, and I find that I don't
    even need to be a rocket scientist to understand it. I suspect that most
    concepts in technology are really like this, requiring nothing more than
    a bit of thought and a bit of common sense, if only someone will explain
    it in the first place.

    I don't recall seeing anything in the literature that came with any of
    this equipment that even begins to address what most of the myriad
    settings and adjustments actually do, and I can't afford the time or the
    money for a college course for each one of them. As they can evidently
    spare enough paper to print their legal obligations in six languages,
    you'd think they could also tell us a bit more about the actual
    equipment than how to plug it in and not to cover the ventilation holes,
    etc. etc. Oh well. This is how we learn. Thanks.

    Roderick Stewart, Feb 9, 2004
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.