Hi Kalle,
For user experience scanning and DHCP are also important, what kind of > numbers you get when those are included? No need to have anything>
precise, I would like just to get an understanding where we are> nowadays.
Scanning heavily depends on the RF environment and the hardware. In our
testing ath9k takes stupid long to scan for example.
But in a sort of best case scenario, using limited scan and no mac
change, iwd connects in ~300ms. People have reported that they have not
finished opening their laptop screen and they're connected, so at that
level of latency, every millisecond is important and totally worth
fighting for. Randomizing the MAC would penalize our connection times
by 2X (300 ms at least). And Android folks have reported the penalty to
be as high as 3 seconds. So this needs to be fixed. And do note that
this is a feature every modern OS implements by default.
As you only provided one number it's clear that you are only working
with one driver. But for us it's not that simple, we have to support a
Please don't jump to conclusions like you seem to be doing here. James
gave you one number that is pretty typical. If you want us to provide
numbers for other drivers under given conditions, just ask. We have a
framework for timing these.
myriad of different types of hardware and there can be complications and
additions later on, even for simple features. Like the dynamic power
save support I submitted to mac80211 over 10 years which was supposed to
be simple, and still we talk almost every year how do we get it out of
mac80211 as it makes maintenance difficult.
I'm not sure what point you're trying to make here?
Regards,
-Denis
