Unreliable ping in server overview

[jx35552zza 1]

Hello.

I have a minor, yet quite an annoying problem here.
After switching OS (Windows -> Linux), I have noticed pings in the server overview being quite a bit higher.
Has anyone had the same problem? Maybe any suggestions?

I use:
Arch Linux x86_64
Eddie 2.19.7
I'm using NetworkManager

I tried comparing the results from Eddie with results from pinging using the terminal.
With the first four results, I picked the first server on list from each country (sorted by lowest latency)
With the last two I picked one near 100ms and a server near 150ms to hopefully see a pattern in the results.
The IPs I pinged, are the ones you find if you right click a server, click more, and then take the IP from "remote".
These are my results:

Anser (Netherlands)
Eddie:    19ms
Terminal: 12.5ms

Arion (UK)
Eddie:    24ms
Terminal: 16.8ms

Cervantes (Germany)
Eddie:    25ms
Terminal: 16.4ms

Algorab (Sweden)
Eddie:    26ms
Terminal: 15.1ms

Dimidium (NY USA)
Eddie:    104ms
Terminal: 93ms

Ran (Texas USA)
Eddie:    150ms
Terminal: 121ms

[Stalinium 18]

What are you using NetworkManager for? Don't use it for the VPN connection, its OpenVPN plugin does NOT support OpenVPN fully and hence you won't get IPv6 routing through AirVPN (see this topic for details and discussion)
I wonder if the increased Eddie ping is related to Linux' CPU scheduler. On modern Windows (Windows 10 have changed the internals, it's a variable value) the (time slot) quant is 1ms, on Linux by default it was higher. That might be the ping difference you're witnessing. Very technical stuff. My theory now is that a properly written application (like ping, unlike .NET libraries that Eddie relies on - Eddie not at fault) should still get the lower latency value under real conditions.

[OpenSourcerer 1033]

2 hours ago, Stalinium said:

I wonder if the increased Eddie ping is related to Linux' CPU scheduler.

How did you get that idea?

[Stalinium 18]

@OpenSourcerer If the networking/ICMP implementation in .NET used is async and polls the OS API to see if there's a response. It would be possible for this scenario to raise the input delay anywhere (0; sleep time/scheduler quant). Or there's some other kind of inner working between threads (multithreading) and GC (multithreading and VM pauses?)

[OpenSourcerer 1033]

Thing is, if it was related in any way, my instance of Arch Linux compared to Windows would show the same thing. Both are quite on par for me.

While it seems to be true that certain .NET libraries are used to invoke ping (I think in line 49), the underlying program executed is still ping, but with a few arguments in tow. Try comparing the results of ping -c 1 someip and this:

/bin/ping -q -n -c 1 -w 4 -t 128 -M dont someip

I've got a small degree of difference there…

@OP, If you want to start tweaking networking performance, I suggest the ever wonderful Arch wiki.

[Stalinium 18]

@OpenSourcerer Alright I looked at .NET Core and the Unix pings are sent via raw socket if the program is permitted to use them (this scenario is indeed prone to what I described) or instead uses the ping utility. I don't know what's actually used under the hood with Eddie (or on his OS), hence tuning the networking stack can be a valid suggestion too then. Maybe we'll need someone on Windows to test if there's a difference there.