Thanks to Rob (fro)'s help, I think i made some progress.
I have been testing from the server side and these are my conclusions, based on my limited knowledge on networking:The "physical" route:
The route itself is physically very long. The rough distances between cities where route can be possibly done is:
FOR - NYC ~= 6000 km
NYC - LON ~= 5600 km
Based on the route i have with a direct cable to Miami, which is 5500 km away and I get around 68ms ping (ICMP), meaning i have around 12,36 ms for each thousand km, the 136ms ping result is better than I could expect.
In the other hand, as there must be many routers between client and server, the logical route must be nicely done in order to make things work as good as possible.The "logical" route:
I think that the problem is here. Level3 / globalcrossing bgp announcements are probably either duplicated or bad managed in any other way (probably bad route balancing). And I needed to trace the routes from server to client to see that.
I performed a few traceroutes from the quakeworld.co.uk server to my link, and its like every single one used random routes to reach the Level3 / globalcrossing routers at the other side of the Atlantic. Look:
1 [hop 1] 0.480 ms
2 [hop 2] 0.285 ms 3 [hop 3 / IP A.A.A.X] 184.909 ms
1 [hop 1] 17.648 ms
2 [hop 2] 0.221 ms 3 [hop 3 / IP A.A.A.Y] 175.637 ms
1 [hop 1] 18.646 ms
2 [hop 2] 0.270 ms 3 [hop 3 / IP A.A.A.X] 199.028 ms
1 [hop 1] 0.419 ms
2 [hop 2] 0.340 ms 3 [hop 3 / IP A.A.A.Z] 136.173 ms
There are a few other IPs i can see on the third HOP, and it all seems very random. Having said that, we can see that we have different ping results based on the router packets are flowing through. But, back to my problem, how can I have steady low ping on some ports and steady high at the others for hours?Guessing the problem:
Well, the only thing that came to my mind was caching. After a query on google I found this: http://linux-ip.net/html/routing-cache.html
. It says:
"The routing cache stores recently used routing entries in a fast and convenient hash lookup table, and is consulted before the routing tables. If the kernel finds a matching entry during route cache lookup, it will forward the packet immediately and stop traversing the routing tables.
So, whenever the route is cached, being it bad or good, it stays like that for some time, until some other process cleans the cache. I'm assuming that ICMP ping is ignored by the caching system, so you can always test the actual route table with a regular traceroute.Workaround:
As far as I know, we cannot force the packet to go through a specific route, meaning I can't write anything in a quakeworld UDP packet to force it to go through the good route. So, the only workaround I can see is as follows:
1) Have lots of proxy ports at the server
2) Try each one (since it's random) until get a good one with the good route
3) Play with it. If cache is flushed during the game and route changes to a bad one, back to step 2
In that case, any help on automating the step 2 would be very appreciated.
Anyone got better ideas?
Thanks.(Edited 2015-04-20, 18:27)