In our battery powered device we waste 25% of the battery capacity on connecting to wifi, which usually takes 1-2s on a good Wi-Fi AP and 4s on a bad one. I want to reduce that time. I logged the time since start of the program (microseconds) until the imp is connected to wifi. See chart. I clearly see some bands in which IMP connects to wifi. Can you explain these bands? Is it possible that IMP connects somewhere in between these bands?
Do you have other tips to increase wifi connect speed? Does it help to set the Wi-Fi AP to 11b mode only? Or to remove the WPA2 TKIP authentication?
Are you testing from Europe? 1-2s seems long (it’s more like ~1s, at least west coast, but there are many round trips in a TCP and TLS setup).
The bands look like they are times when the wifi chip has not managed to connect and so the attempt has been restarted - particularly the higher ones.
How far from the AP is the device? Is the network responding quickly to the DHCP and DNS enquires? (ie have you tried dumping network traffic on the AP?)
Setting 11b mode may help depending on the AP, as there are differing fallback strategies. I wouldn’t remove WPA2, that’s not a large part of a connection.
Yes, now I am testing from Netherlands thru 40Mbps VDSL connection, I have 2.9s connect time. In the HackerDojo in Mountain View (gigabit fiber and Cisco Meraki Wi-Fi APs) I had 2.9s as well. At my old home in Mountain View (ComCast) I had 4.5s. On my neighbors Wifi in MV I had 2.7s. In the HackerDojo on the Wifi network for embedded devices (no password and not landing page) I had 1.2s connect time. So I think location Europe or US west coast should not differ much, I think biggest impact is the AP. You support Europe too right?
I placed the device is on top of the AP. I have no idea how fast the network is responding to DHCP and DNS enquiries. I hoped you had a good understanding what influences the connect time.
Putting the device on top of the AP is likely contributing to a bad connect time - this will overpower the LNA and cause bit errors. Put the device at least 2m away.
The ~1s connect times we see (both at our office and at my house, in my personal experience) were with WPA2; in my experience, WEP/WPA/WPA2 do not significantly influence connect time.
There are no servers in Europe at this point, so you have latency for TCP and TLS setup to west coast US.
We do have a great idea of what influences connect time, but we don’t see times as long as you do which means there’s something different with your network (ie DNS, DHCP servers) or wireless environment. Network dumps will help narrow that down - eg if you use an unencrypted wifi then a mac & wireshark can capture all the traffic on an AP and you’ll see exactly where the delays are. Can you do that?
Hugo. I have never captured traffic using mac & wireshark. I should because it can save battery life much. Do I need a mac computer? Can I use Windows? Do I need other hardware? Should Wi-Fi be unencrypted to analyze it? A short intro is appreciated
Hugo, can you explain the setup? Where do I capture the traffic? I have VDSL and Wifi AP in one device (Experia Box), I cannot put something in between. Should I buy a second Wifi AP? Should I buy other wifi capture hardware? Should I connect my laptop thru UTP to the internet, setup a wifi AP on my laptop and install software to capture traffic thru my laptop?
With a mac you can enable monitor mode, which means the mac will receive all data on the wifi network) not just that which is addressed to the mac. I believe you can do this on linux wireshark too, but you need to buy a special wifi adaptor to do it (google wireshark monitor mode).
You want to do this with encryption off on the network so you can see what’s going on.
You also want to do this on the wifi traffic (vs between a router and something else) as then you can see the time spent doing associate, DHCP etc that you wouldn’t see upstream of an AP. You can still get some info if you sit on a wired link between the AP and the internet, but you won’t see things like association requests.