DropBear wrote on Sep 8
th, 2014 at 4:32am:
Losing 150-170ms crossing the Pacific - taking the scenic route.
Leaves my island and goes via Hong Kong, bounces around HK for a bit, then visits Taiwan (where it joins the cogent network) and then it next pops up in Wichita Kansas some time later? Kansas - WTF? Do they even have internet there?? (just jokes for those Kansas folks).
Fully appreciate that point.
But as you pointed out, they potentially have a weak spot in their trunk access that they cannot mitigate, they could perhaps take measures to compensate for latency issues. Auto-detect features that modify certain settings....
I do realise the vast majority of their customers are US, so they're not going to design content for 100ms+ latency, but it would appear that many US customers are also being adversely affected by those trunk access issues you highlighted.
Well you could have taken the southern route in the US : from Frisco, to Denver, to Houston, Atlanta, and then Boston. so that bit could have been worse.
But I fully expected a link to Hawai from Oz and Kiwi Country. I know the Frog Lands over there have one.
As for mitigating latencies... the Problem of TCP/IP ( and all the stuff piled on top of it in the stack ) is that it's basically unaware of what happens at a lower layer and how said lower layer works. ( in TCP/IP and UDP it means that the packets have no clue of the medium they are carried on, and as long as they reach destination before the protocol timeout, everything is fine... protocol timeout is.... Long... Think that the stack was designed in the dawn of the seventies, when long distance communication between computers meant 600 bauds modems... ).
and the Ethernet/TCP/IP/UDP suite is not the worst... Take X.25 ( designed more or less at the same time, for Telecoms ).... Time out between a packet and it's retransmission can be up to two seconds ( it's configurable )... and you can retransmit the packet up to 20 times before you go in timeout... so that's basically 40 fucking seconds... Talk about a very long time ( ok, it's way shorter in Ethernet/TCP/IP/UDP, but it's still a matter of several hundred of milliseconds. )
And contrary to X.25, in TCP/IP you cannot configure the timout values...
Add to that the fact that UDP ( that's the protocol used for many things in game ) is basically a connection less, unreliable protocol ( you send the packets with the information and pray that they will reach destination )... So everything is against auto-detecting features to streamline network communication.
100+ms is propagation time expected, 300+ not anymore in modern days... except in Telecoms, because we have protocols that way longer than that to react ( see X.25... default propagation time is 800ms. ).