• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 40 subscribers
  • Views 517 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.

CC3100MOD: UDP latency increases to connected (always on) device when other (normal power policy) device connects to AP

Stanislav R
Prodigy 115 points
Part Number: CC3100MOD
Other Parts Discussed in Thread: CC3100

Hi,

I am working on CC3100 module and I am having some issues with the latency of UDP packets which is a key parameter in my project. Please read the following scenario:

Everything is good when one CC3100 (always on power policy) is connected to AP (commercial type); the time between packet transmission (broadcast) from LAN device and reception on CC3100 is about 0.7 milliseconds.If another CC3100 connects to AP (also in always-on power mode) measured time is not affected. However, when I switch power policy to normal on one of the connected CC3100, measured time is affected on both devices and reaches about 70 ms or more. The same behavior can be observed if I connect android phone to AP. Nevertheless, the ping command is without a change (1 ms). Moreover, after some time, measured times will reach the expected values (1.5 ms for normal mode power policy and 0.7 ms for always-on policy) and few tens of seconds later situation goes back to 70 ms or more. This repeats. 

Does anyone have any experience or hints?

Thanks,

Stanislav.

  • 0
    TI__Mastermind 30790 points

    Hi Stanislav,

    The normal policy allows the network processor system to enter a low-power deep sleep when activity is not predicted. The device is brought out of the low-power mode when a command is received from the host, but there will be overhead while the device is returning to the active state before the command (such as send) is completed. Refer to the Power Management guide for information on the different power policies:

    http://www.ti.com/lit/an/swra462/swra462.pdf

    There is a tradeoff in all of the modes between latency and low-power. The always-on policy prevents the network processor from going into a low-power state in exchange for higher power.

    Best Regards,

    Ben M

  • 0 in reply to Benjamin Moore
    Prodigy 115 points

    Hi Ben,

    Thank you for the information and document. However, this does not exactly resolve my issue. I will try to describe it in more detail. Please take a look at the attached picture:

    In the first scenario, both CC3100 works in always-on power policy mode. Travel time is about 0.7 ms.

    In the second case, one CC3100 is in the always-on mode and the second is in Normal mode. I would expect that travel time would be the same as in the first case for the device in always-on power policy mode, but it is not.

    In the last example, the situation is similar to the second scenario but (I assume) some kind of Normal power policy is substituted by android phone.

    I understand the delay caused by the awakening of CC3100 from sleep. What I don't understand is why the CC3100 with always-on policy is affected when CC3100 Normal power policy connects to AP (or switches to Normal during connection). I assume that AP works fine; ping goes through well. I have tested 2 different APs and the results were the same.

    Thanks,

    Stanislav.

  • 0 in reply to Stanislav R
    TI__Mastermind 30790 points
    Hi Stanislav,

    Thanks for the detailed description. The system is much clearer now. I have not heard of this behavior by an access point before, but that doesn't mean it is necessarily invalid. The third test case to me indicates that it may not be directly related to the CC3100 device, but the network itself. Specifically, (and this is speculation) if there is a client using power-save mode connected to the AP. I would imagine that if you replaced the CC3100 devices with other clients that are guaranteed to not use power-save mode, that you might observe similar behavior with them.

    Because it is broadcast data that you are measuring, the expectation is that this should go out on a DTIM. If that is set to DTIM = 1, that would be roughly every 100 ms. I could imagine that is what is happening in cases (2) and (3) and that you might be measuring an average delivery time of 50 ms due to it.

    The weird case (to me) is actually when you are observing a travel time of ~0.7 ms. This would be much too fast unless the AP is doing something unexpected, such as delivering the message as unicast rather than broadcast. I think this theory (or something comparable) could also be supported by your claim that the ping (unicast) works fine.

    I recommend taking a deeper look into the information on the APs that you have worked with and their behavior or trying to repeat the results with another client device that you can control the power policy on. It would also be interesting to see if you could adjust the DTIM to 2 or 3 and see how the times change. Go ahead and post the AP models here and I can let you know if I find any specific information supporting the theory.

    Thanks,
    Ben M
  • 0 in reply to Benjamin Moore
    Prodigy 115 points
    Hi Ben,

    Thank you for really fast responses! The AP modes are these two: N450R - AirLive (the one I work with) and D-Link DSL-2741B ( a bit older model, even picture of the device does not fit one on the website, just for the test) both with the newest firmware. I will test some new models in future.

    I have remembered that I could observe the change of behavior in the second scenario, where after about 1-minute the travel time was 0.7 for always-on and 1.5ms for normal power policy. However, this changes randomly back to >50 ms and repeats. It is really weird.
    I should add that the moment I disconnect the "problematic" device, the travel time goes back to 0.7 ms. Also, I've just recalled that situation depicted in the case one is valid only for standards 802.11g and 802.11n.

    For 802.11b there were 2 different outcomes for 2 different packet transmission periods:
    - 1 000 ms interval between transmissions: result as the second case
    - 50 ms interval between transmissions: result as the first case

    I am going to test DTIM and some UDP unicast by Friday so then I am going to post the results.

    Thanks,
    Stanislav.
  • 0 in reply to Stanislav R
    TI__Mastermind 30790 points
    If possible, I also recommend getting a sniffer capture of the traffic if you are not already.

    Best Regards,
    Ben M
  • 0 in reply to Benjamin Moore
    Prodigy 115 points

    Hi Ben,

    I have tested changes to DTIM and Beacon Interval and it is doing what it should do; broadcasts take more time to transfer with bigger DTIM. Unicasts are not affected (slightly are) by the sleepy CC3100 connected to AP. Unicast takes a bit more time to travel than broadcast on this old AP.

    I have also tested few new APs, where the situation is in contrast to the old one. That is, broadcasts take more time than unicasts but both times are acceptable. The weird behavior (mentioned above) cannot be seen in the new ones.

    Thanks.

    Best regards,

    Stanislav