Hi.

This one goes to the ezquake / quakeworld networking experts (dimman?)...

What can possibly cause the following scenario?

- ICMP ping command return 136ms
- In-game ping 181ms at port #1
- In-game ping 142ms at port #2
- Not using proxies to connect to any of the ports

Thanks!

--
dev

Let me guess, this is @ foppa, right? I have exactly the same thing. Port 27504 gives me 34ms which is lower than the other ports.... without proxy.

No its not. And i dont think this is a server issue.

I noticed it very clearly in nl.besmella.com and quakeworld.co.uk.

--
dev

I had the same issue with ezquake (don't know why), after switching to fodquake i got 12ms on both servers and 38ms with ezquake :/

perhaps someone is tapping the traffic?

Is cl_proxyaddr set to ""?

Yes it is.

check the servers maxfps.

Always 77. All ports/servers.

Hello guys,

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:

--01--
1 [hop 1] 0.480 ms
2 [hop 2] 0.285 ms
3 [hop 3 / IP A.A.A.X] 184.909 ms

--02--
1 [hop 1] 17.648 ms
2 [hop 2] 0.221 ms
3 [hop 3 / IP A.A.A.Y] 175.637 ms

--03--
1 [hop 1] 18.646 ms
2 [hop 2] 0.270 ms
3 [hop 3 / IP A.A.A.X] 199.028 ms

--04--
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)

!

We should have neutrino based communication systems deployed on Earth before this millenium runs out. Send data in a beam of neutrinos at near light speed, straight through the Earth's core directly to your destination. US to Australia, 50 ms? Make sure you're located close to a neutrino comm hub.

Routes are only based on IP and not port so a typical device will always route in the same way however if they are load balancing traffic over multiple links or routers then this could explain what you are seeing with a different path being taken. The router will choose one path for one session and another path for another session.

I know dopeskillz consistently got a lower ping on 1 out of the 4 ports of qw.co.uk which is kinda weird as it never changed.

It should be like that if there was no cahe. Then, simple reconnections should fix ping. The only explanation i can find is that the cache works with tcp/udp packet header information, so when I reconnect using different port it makes a different header and then bypasses cache and randomly get routed based on load balancing.

The workaround is solving the problem anyways. Thanks to fro.