"The 5 GHz signal is just as strong" Interesting. My dormitory at MIT has both 2.4GHz and 5GHz signals. The 5GHz is extremely weak but my Android devices love to pick a weak 5GHz signal over the 2.4GHz and subsequently have terrible speeds.
On another note, I wish that browsers and applications would keep firing spawning and firing requests at a rate beyond human perception, until one succeeds. The state of browsing the web over Wi-Fi while moving from access point to access point is equally sad. I get an IP address, but applications almost universally refuse to retry their connections until the first zombie socket times out. Seriously, I shouldn't have to wait 10 seconds after each access point change. Should be more like <0.1 second after getting an IP.
OSes/Applications should be thinking "This is Wi-Fi. Wi-Fi is supposed to be fast. Since no bytes came in for a full 0.5 seconds, something is wrong. I'm going to keep opening/closing sockets like hell, change networks, change frequencies, whatever it takes to get data to come in the next 0.3 seconds and make the user happy."
Building devices with dual Wi-Fi cards may also offer ways to help alleviate the handover problem.
> I wish that browsers and applications would keep firing spawning and firing requests at a rate beyond human perception, until one succeeds.
I do not think you would enjoy the network conditions that come with that behavior. The point about killing old sockets early when switching wifi makes a lot of sense, however.
Well, the problem is really that the network isn't even connected properly in the first place. I agree that it shouldn't behave badly while actually on the network. It's just odd that madly hitting refresh while wifi is reconnecting actually gives me a sooner and faster page load than letting the machine load by itself. That means there is something can be automated but unfortunately isn't being automated.
Network stacks are layered and even after 40+ years, on every OS I've seen, L4 (TCP) never queries nor uses any L1/L2/L3 link quality/stability/availability information when computing retrans intervals, etc. Doing that would indeed be an aesthetically distasteful layering violation, but it would enable much more optimal behavior in a lot of wifi & cell network scenarios, as you've said.
It will probably happen eventually, at least in Linux, after a few more years of commercial pressure to make it suck less.
On another note, I wish that browsers and applications would keep firing spawning and firing requests at a rate beyond human perception, until one succeeds. The state of browsing the web over Wi-Fi while moving from access point to access point is equally sad. I get an IP address, but applications almost universally refuse to retry their connections until the first zombie socket times out. Seriously, I shouldn't have to wait 10 seconds after each access point change. Should be more like <0.1 second after getting an IP.
OSes/Applications should be thinking "This is Wi-Fi. Wi-Fi is supposed to be fast. Since no bytes came in for a full 0.5 seconds, something is wrong. I'm going to keep opening/closing sockets like hell, change networks, change frequencies, whatever it takes to get data to come in the next 0.3 seconds and make the user happy."
Building devices with dual Wi-Fi cards may also offer ways to help alleviate the handover problem.