• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 41 subscribers
  • Views 894 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

WL1837 jumpy WIFI bitrate

wifijacob
Expert 1245 points
Other Parts Discussed in Thread: WL1837

Hi!

We're seeing that the WL1837 seems to change bitrate very very often. This is a behavior we don't see of other devices. It occurs both on 2.4 and 5 GHz networks, and on different APs. No rate limitations are in use.

Please see the following image:

In general the bitrate chosen seems to be pretty low, and sometimes dangerously low for our application.

Is there any way to tune the rate selection algorithm somehow?

Thanks, Jacob

  • 0
    TI__Expert 5840 points

    Jacob,

    The rate adaptation algorithm can not be modify without a change in the code.

    In general, the algorithm will look for the best TP we can get (PHY Rate Vs. WIFI retry rate).

    The environment variables that can impact the rate, are, how clean is the environment and what is the TX/RX Packet RSSI.

    In addition there is the "Immediate Retry" (for the same frame that was not acknowledge) that need to make sure that if we will use all retries allowed (10) the last retry will run in 1M (to increase the chance of reception) 

    When working in clean environment, in RSSI value bigger than 70, the amount of retries should be low, and there for, the "jageling" in the PHY Rates.

    Please note that TCP data will have ~7-8% retry only due to the competition between the server to the client.

    If you specific explain on a specific location of Rate drop, please share the Sniffer logs and I will take a look.

    Shahar

  • 0 in reply to Shahar Patury
    Expert 2300 points

    Hi, questions:

    - The PHY Rate algorithm, does that have deps on actual traffic (tcp vs udp) being transmitted or received. 
      i.e. if no traffic is sent will the rate algo still run?

    - How can this be tweaked to tame this up/down behaviour, possibly avoid bumping the bitrate if the needed througput is known?

    - How do we explain other devices active on the same netowork with similar RSSI not showing this jumpiness!?

    /david

  • 0 in reply to Dav01
    TI__Expert 5840 points
    - The PHY Rate algorithm, does that have deps on actual traffic (tcp vs udp) being transmitted or received.
    i.e. if no traffic is sent will the rate algo still run?
    [Shahar] - No, the Rate Adaptation Algorithm is working according to the actual traffic

    - How can this be tweaked to tame this up/down behaviour, possibly avoid bumping the bitrate if the needed througput is known?
    [Shahar] - The Algorithm is hard coded, no option to tweak without a code change.

    - How do we explain other devices active on the same netowork with similar RSSI not showing this jumpiness!?
    [Shahar] - Each device have its own algorithm, each algorithm have it's ups and downs

    As I wrote, to see if the algorithm is working correctly, I would need to see a Sniffer Log

    Shahar
  • 0 in reply to Shahar Patury
    Expert 1245 points
    This seems to be very much improved with R8.6 (for the single-role case). It's much more stable.

    Thanks, Jacob