Those rules makes little to no sense to me. When you connect to whatever service, be it port 80, ssh or whatever, client (your external part in the image) will usually use some random port from 49152 through 65535, but you set fixed ports, eg. you need to connect with port 80 to 192.168.0.11:80.
Actually I did what one guy on the official ESO boards suggested (he also suggested NOT opening 433 and 80 ports) with Advanced Port Triggering. Yes, that’s the place for this to try but sadly nothing worked.
As MrLavander concluded:
I don’t think your router is the problem anyway given that it works fine in Windows.
Exactly. It doesn’t work better. Also, the information about the router ports was from 2014 when the game was released. Rarely anyone now opens any ports for playing this game.
Well you have both opened, but no one will ever connect to them for the reasons in my previous post. Also I have no idea what 433 is for, perhaps you mean 443?
Anyway, I haven’t read what the topic is about, everything I said is about nonsensical ports you have opened. Highly doubt you need either 80 or 443 opened at all unless you are hosting a webserver.
1 Like
Mods at the forum suggested to try traceroute method.
Well this is what I got for this
EU IP Addresses: 159.100.230.1 for game connection/disconnect
traceroute to 159.100.230.1 (159.100.230.1), 30 hops max, 60 byte packets
1 _gateway (192.168.0.1) 0.201 ms 0.245 ms 0.228 ms
2 100.64.112.1 (100.64.112.1) 7.821 ms 7.874 ms 11.987 ms
3 172.31.255.2 (172.31.255.2) 13.893 ms 14.890 ms 12.777 ms
4 172.31.255.2 (172.31.255.2) 12.759 ms 12.671 ms 12.584 ms
5 bg-ne-m-0-be4-100.sbb.rs (89.216.12.16) 14.879 ms 14.933 ms 14.843 ms
6 at-vie-r-2-be1.sbb.rs (89.216.5.78) 28.556 ms 27.368 ms 27.341 ms
7 193.203.0.236 (193.203.0.236) 25.594 ms 19.013 ms 19.060 ms
8 po110.bs-a.sech-vie.netarch.akamai.com (23.57.104.243) 16.781 ms 18.146 ms 18.755 ms
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
Well traceroute is a good method, but mtr combines it with pings, what is much better:
pamac install mtr
mtr --report --report-wide manjaro.org
or
mtr -4 --report --report-wide --tcp --port 80 manjaro.org
mtr -6 --report --report-wide --tcp --port 80 manjaro.org
More parameters: mtr --help.
You can also loop it by adding --curse, so that you get a realtime output:
mtr -4 --curse --tcp --port 80 manjaro.org
mtr -6 --curse --tcp --port 80 manjaro.org
Some servers on the route have problem with ipv6, what can definitely delay the connection.
Probably ipv6 is disabled on Windows and not on Linux? Or maybe on Windows it forces the connection to ipv4 while on Linux not?
1 Like
I’m yet to try that but what seems very promising so far was the update of kernel.
For some strange and unknown reasons (my fresh xfce install is barely 3-4w old) I had old EOL kernel installed. I updated it to 6.6.7 LTS and there seems to be big improvement in network stability of this game.
So far
- No disconnects
- Lag spikes are far less and the game is overall much more fluid.
The only difference between W11 and Lin now, in W11 it’s almost always fluid, while in Linux when there’s a high-pop on the screen at once, the game lags for a tiny bit and then continues without ever lagging again there.
Almost if the game is ‘caching’ people on the screen and once done, it flawlessly continues going, even during massive fights. Animations also seem better so maybe the new kernel influenced better GPU support, even though there was never a FPS drop before.
Yeah, seems then your lagging issue was not the connection to the server, but the shader cache which is needed on linux beforehand because of vulkan. DirectX has in my opinion a better technique to compile the shaders asynchronous when needed, while vulkan lags a feature here (DirectX is translated to Vulkan). You also shouldn’t ignore the overhead that is generated during translation and that leads to problems in some situations.
1 Like
Yes, I think you have a point. The ping is now more stable however. For example, during massive fights latency remains within 80-140 range, while before the kernel update it was over 200-500, with frequent 999+ spikes during which the connection crashed if it remained for too long.
But I agree with you, I think the shader caching or something related to GPU helped as well.
Your router settings in windows were previously the same and it was OK. What made you think you need to alter anything in router to fix linux issues? Revert all the changes you made to your router (whatever inbound ports you opened, better close them again, just in case) and stop touching it (when it works perfectly in windows).
What kernel do you use? If it’s 6.6.x, then try previous LTS (6.1.x) and see if the problem persists.
(6.6.x has some new effd up scheduler called EEVDF, that acts up quite badly in my system also. ESPECIALLY when I lets say move 10+GB file from SSD to external NAS – my entire KDE desktop freezes and becomes unresponsive (even the mouse cursor doesn’t move) for like 20+ seconds occasionally. several times in a row (mouse cursor moves for half of a second and then freezes again for 10-20 seconds) until the file has been moved.) So I assume there’s something seriously wrong with the network driver+scheduler combo there in kernel 6.6.x. It might get slightly better with consequent updates (6.6.5 => 6.6.6 => 6.6.7 etc) buuuut… just in case try 6.1.x
perhaps an issue of cpu starvation due to proton leading to network thread being bottlenecked and coughing. Linux 6.6 EEVDF scheduler ensures that the network thread gets served appropriately.
deemon: curious that you have the opposite experience to most everyone else. Previously people used customs kernels with out of tree schedulers like BFS to work around CFS. But since EEVDF there is no need any longer, as it works so well.
1 Like
Out of curiosity, do you use Xorg or Wayland? I swapped to Wayland around the same time I switched to Linux 6.6.x.
EDIT: I just tested this stuff. weirdly enough when I do the file moving in terminal (konsole), there is 0 freezes and everything works as intended! But usually I do all the file copy/move stuff with doublecmd, which might work through xwayland/xorg, which… for some reason or not gets different scheduling going on? So the issue might not be (for me) with network scheduling by itself and only, but with xwayland (+network, +gui)?
So as OP is using XFCE, which is still on xorg, my problem with kernel 6.6.x most likely should not affect him at all. But if you have second LTS kernel installed anyway, doesn’t hurt to try maybe?
I’m still on xorg, plan to switch with plasma6
This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.