"Time to connect" what does it indicate?

MarcelTempelman
Getting noticed

"Time to connect" what does it indicate?

Hello all,

 

We're troubleshooting some roaming issues at a customer site and the timeline shows this:

 

MarcelTempelman_0-1646907850097.png

 

What does the Time to Connect indicate? If that's the time needed to roam then it's ridiculously high and way too high for VoWLAN roaming. I cannot imagine this is the roaming time (everything above 150ms should be marked red) because even for data a 4 second roam is way too slow .

 

This is a SSID with WPA2/PSK encryption and layer 2 roaming so there's no external influence on the roaming speed. I'm accustomed to sub 10ms roaming in Cisco Enterprise with a PSK or 802.1X with .11r enabled.

 

Can someone clarify that number ?

 

With kind regards,

 

Marcel Tempelman.

15 REPLIES 15
cmr
Kind of a big deal
Kind of a big deal

I think it does mean what you said, here is a report from a Cisco wireless phone roaming about, with plenty of red!!  It does though seem a long time, I'll have to go to the site and see if that is the real experience...

cmr_0-1646918221332.png

 

cmr
Kind of a big deal
Kind of a big deal

Looking at other devices it seems that:

 

0-5s is green

5-10s is amber

10s or more is red

cmr
Kind of a big deal
Kind of a big deal

Interestingly a Wi-Fi security radio on the same SSID fares much better:

cmr_1-1646918777665.png

 

RaphaelL
Head in the Cloud

Out of curiosity , what MR firmware version are you running ? 

These access points are running MR28.5

I think 28.6 fixes some bugs related to PKMID which ''could'' slow association time. That might be worth a try !

cmr
Kind of a big deal
Kind of a big deal

We are running 28.6...

Ameya_Ahir
Meraki Employee

@cmr time to connect is the time delay between re-association/association sent by the client and the final acknowledgment sent by the AP. Can we have a support case opened for this issue? We would like to investigate this further and get some more information that we can track internally and fix, if we identify this as a bug.

cmr
Kind of a big deal
Kind of a big deal

@Ameya_Ahir case opened - 07776142

 

Thank you,

 

Charles

MarcelTempelman
Getting noticed

Any news on ths topic ? I still see 'time to connect' values between 2000-4500ms when roaming. Which is quite bad considering this is on a Voice SSID.I think I'll open a case as well.

cmr
Kind of a big deal
Kind of a big deal

Apologies, support did reply and they said that it reflects the time between the roaming starting and the client reporting a successfully completed roam.  We found many devices report about what you'd expect with roaming around 100ms but Cisco 8821 phones reported much longer roams.  I haven't had a chance to verify that it is just a reporting issue (client or cloud related) yet, but I think that is the issue.

 

 

MarcelTempelman
Getting noticed

Thanks for the update! This afternoon I'll be going on site and will try to collect some data about roaming (there are issues with a Gigaset android devices) with different devices and see if it corresponds with what the dashboard is telling me.

MarcelTempelman
Getting noticed

Yesterday I did some testing with a Android smartphone from Gigaset. These phones are horrible when it comes to roaming. So I made a round with my iPhone 8. If I look at the timeline from a wireless troubleshooting perspective then this is a useless tool. The reporting is not consistent (sometimes the time to connect is missing) and the reported time values are nowhere near what you want to see when checking requirements. For example if you check Voice over WLAN requirements you want to see if the device roams within 150ms. Do not know who developed this but this is developed without any knowledge about wireless troubleshooting.

 

MarcelTempelman_0-1652191016473.png

 

This is useful information (Cisco Wireless Debug Analyzer):

 

MarcelTempelman_1-1652191356791.png

 

 

cmr
Kind of a big deal
Kind of a big deal

In terms of timing I think I have figured it out, below I was on a call walking about and had no glitches or drop out - this is shown by the red bracket.  Where I was roaming with the phone in standby the roaming is horrible - this is the lower ones.  That makes sense as the radio is kind of sleeping in that state.

cmr_0-1652194647400.png

 

MarcelTempelman
Getting noticed

The Meraki example which I posted was during a MS Teams call from my iPhone 8 (started at 15:16 and took 6 minutes). The call was quite good (some glitches). The experience with the Gigaset smartphone was quite horrible but that's because it's crap hardware (sticking to APs up to -90+ dBm.......). But that aside when I look at the iPhone roaming the number do not make any sense to me. When I look at your example it seems to make sense.

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.