3 ms·

Discovery could take up to 100 milliseconds. All the others, if properly implemented, are speed-of-light things. Eg. RADIUS auth to an external database on t

Discovery could take up to 100 milliseconds. All the others, if properly implemented, are speed-of-light things. Eg. RADIUS auth to an external database on the same physical site should easily be doable within 1 millisecond. It's not like that database has a multi-second queue of other users to connect first.

Two4 2y ago
You've never dealt with enterprise networks where the auth server lived on a different continent
- nine_k 2y ago
  A different continent is usually a few hundred milliseconds away. (The worst delay I had in my life was between me in Europe and the target machines in Japan, and the round-trip still was about a second.) The response time of an under-provisioned or poorly implemented API endpoint on a machine in the same rack can be multiple seconds though :(
- lucb1e 2y ago
  an edge case you can come up with != typical experience. What you're saying is not far fetched, but also not the common case, especially at home and it's not like this latency only occurs on RADII networks
zamadatix 2y ago
While 100 milliseconds (well, slightly more actually - 100 time units != 100 ms, it's just very close) is the default beacon interval, most clients will scan for longer than that to ensure they hear the best SSID (and AP for that) before initiating a connection just to throw it away/immediately roam anyways. This allows higher beacon intervals to work without the clients thrashing themselves between advertising stations. Also, not every beacon will actually make it through heard so connections generally assume they shouldn't just go with the first time they hear it. As for how a RADIUS auth should take 1 ms... sure, and updating macOS on an M3 shouldn't take an hour either. I'm not saying how tech should be, I'm saying how it is and which steps often add significant latency as implemented. Even a dedicated Aruba ClearPass authentication server on prem scaled for 25k clients can't handle 1,000 auths/second (ignoring that AD would fall over before then). Usually the drivers are also part of the problem (both on the AP and the client). Same with OS software around it. Things that should be instant just aren't. E.g. go try to disconnect and reconnect to the same SSID on macOS via the GUI. If you do that in ~1 second you should get an error - not a delay, an error that it hadn't synced up with its own connection state and couldn't possibly figure out how to try to connect. None of that is actually Wi-Fi, if you implement an IoT device with an embedded radio and sidestep a lot of those layers suddenly the protocol is much quicker to connect (still not as fast as some simpler ones though).

Two4 2y ago

You've never dealt with enterprise networks where the auth server lived on a different continent

nine_k 2y ago
A different continent is usually a few hundred milliseconds away. (The worst delay I had in my life was between me in Europe and the target machines in Japan, and the round-trip still was about a second.) The response time of an under-provisioned or poorly implemented API endpoint on a machine in the same rack can be multiple seconds though :(
lucb1e 2y ago
an edge case you can come up with != typical experience. What you're saying is not far fetched, but also not the common case, especially at home and it's not like this latency only occurs on RADII networks

zamadatix 2y ago

While 100 milliseconds (well, slightly more actually - 100 time units != 100 ms, it's just very close) is the default beacon interval, most clients will scan for longer than that to ensure they hear the best SSID (and AP for that) before initiating a connection just to throw it away/immediately roam anyways. This allows higher beacon intervals to work without the clients thrashing themselves between advertising stations. Also, not every beacon will actually make it through heard so connections generally assume they shouldn't just go with the first time they hear it. As for how a RADIUS auth should take 1 ms... sure, and updating macOS on an M3 shouldn't take an hour either. I'm not saying how tech should be, I'm saying how it is and which steps often add significant latency as implemented. Even a dedicated Aruba ClearPass authentication server on prem scaled for 25k clients can't handle 1,000 auths/second (ignoring that AD would fall over before then). Usually the drivers are also part of the problem (both on the AP and the client). Same with OS software around it. Things that should be instant just aren't. E.g. go try to disconnect and reconnect to the same SSID on macOS via the GUI. If you do that in ~1 second you should get an error - not a delay, an error that it hadn't synced up with its own connection state and couldn't possibly figure out how to try to connect. None of that is actually Wi-Fi, if you implement an IoT device with an embedded radio and sidestep a lot of those layers suddenly the protocol is much quicker to connect (still not as fast as some simpler ones though).