just add the keyword besteffort into its invocation (at which point cake will ignore DSCPs and there will be no prioritization). In sqm_scripts /etc/config/sqmjust make sure to add besteffort to the end of the listed keywords, e.g.:
option eqdisc_opts 'nat dual-srchost memlimit 32mb besteffort'
Hello segal_
I've Seen this vidƩo
Can You post gameplay
Thanks
These ping/mtr/traceroute/... results are so much easier to make some sense out if you also post e.g. the per hop number, the per hop dns name and most importantly the per hop ip address....
Latency to the final hop you show was 27ms with a tight distribution of just a few ms. It isn't going to be the cause of your problems.
I would suggest you find a game where you can host the game server. For example Minecraft or CS:GO or similar. Put the server on a VPS or a machine owned by a friend or something, and play with some friends. Run continuous pings to your server during game. See how much game latency and network latency you experience.
I suspect if you control the server and the network is between you and a friend in the same general region (ie. Central Europe) you will find there is no latency experience.
Forget the server for a moment, it's not the cause of the latency ... play against a friend involved in p2p and the result is identical: latency! On the other hand, after spending some time in Italy, I noticed that the outward and return paths do not have the same number of hops! Italy to Switzerland pings are regular (looks like a straight line) but Switzerland to Italy pings vary and form a ripple in summary I note that the isp gives priority to entry and none to exit
Ah, maybe you can do a traceroute ad a reverse traceroute/mtr between your home and your italian location, would be interesting to see some indication of both the forward (home-italy) and the reverse (italy-home) pathes, asymmetric routing can in itself cause issues...
absolutely, mtr between these two locations, the full results would be very interesting.
These two forms of latency may or may not be the same reason though. Is the machine hosting the P2P server overloaded? Does the friend have bufferbloat?
Another way to think about it is this, do you have latency when playing two machines P2P within your house? there the network is for sure not the cause you should 100% never have latency. Have you tested that?
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 192.168.1.1 0.0% 454 0.7 0.6 0.3 2.8 0.2
2. dynamic.wline.res.cust.swisscom.ch 0.0% 453 2.8 3.6 2.4 26.7 2.0
3. (waiting for reply)
4. i68geb-015-ae30.bb.ip-plus.net 0.0% 453 3.4 4.9 2.1 30.5 4.1
5. i69lsp-015-ae1.bb.ip-plus.net 0.0% 453 3.5 5.8 2.9 43.6 4.7
6. i69lss-015-ae6.bb.ip-plus.net 0.0% 453 4.0 5.9 2.9 60.1 5.4
7. i00mil-015-ae4.bb.ip-plus.net 0.0% 453 9.2 11.4 8.0 63.3 6.4
8. 193.134.95.251 0.0% 453 12.6 12.2 8.1 100.5 8.1
9. (no route to host)
All the MTRs of any IP address show me peaks of instability from 29 to 100 ms, constantly, every 4 sends I have a peak, I have no stability.
All the hops belong to my ISP!
Hello @segal_72 . Iāve read the whole thread. What a journey. I too suffer with the same problem. Suffered for years. I have 20 ping on average on the Spanish server on FIFA and I live in Portugal, sometimes it is unplayable and I have a better connection to the French server.
I have something in common with you that mightāve been overlooked even though you have low ping. The copper connection inside the house instead of fiber. Have you given any thought to this? Do you have fiber to the curb or is it copper all the way? Cheers
I have fibre to the pavement then copper to the house (61 metres) my ISP found an anomaly in RFC1918... unwanted flow circulates and causes a lot of drop by security, this consumes a lot of bandwidth which can affect game flows such as udp. All this is being repaired, I'm waiting for the moment!
Sounds promising.
Wow! amazing that somehow you finally managed to get your ISP to figure something out. This sounds like yet another reason to drop ipv4 as quickly as possible and get the transition to ipv6 done. Their private networks are probably overlapping, sending packets around in circles. I hate ipv4 post-NAT. Fortunately Ipv6 is actually moving forward pretty well. https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption
here in the US we're at about 50% of google traffic via ipv6. My suspicion is US govt requirements are going to push that a lot higher in the next 12 months.
Itāe be quite cool if after all these years the issue is solved. Are you still playing FIFA @segal_72?
I was very lucky to come across an AS network engineer who believed in me and wanted to understand. We immediately switched to full ipv6 dualstack and downgraded the firmware to an older version! For the moment the latency is still there, almost worse! I've got an appointment for a live session to understand what's going on live, for an hour I just have to play! Technician, engineer and router firmware developer will be there to analyse all this!
@dlakelan Remember my pcap captures from 2020, the graphs you deployed here, you said, strange so much tcp traffic it looks like you're playing tcp there was so much! The cause: the IP address of RFC1918 tries to communicate constantly with the outside without going through the Nat and therefore public IP!
I am really confused... was the ISP originally assigning an rfc1918 address to your wan, or did the ISP-modem/router accidentally leak rfc1918 addresses (so likely packets that should only have been delivered internally in your home network) into the wan side?
Both seem "not ideal", as the traffic inflation/looping should have been caught by your ISP's monitoring (independent on whether it is ultimately caused by ISP or customer equipment).
But as I said I am confused and happily wait for your conclusion in the future without conducting any further wild speculations 
Presumably the router is to blame, the isp would have intercepted it via its System configuration and of course drop.
I don't know which way the traffic was flowing, but certainly from the inside to the outside.
Seems incredible. Are they nervous or something? Just canāt imagine something like that from any ISP Iāve ever dealt with, but then mediocrity is the order of the day in Britain and why itās no longer Great Britain.
@anon78773196 has been quite consistent... and if there is truly an issue in the ISPs's network that ISP's NOC will be interested in it, it is just normally NOC network magicians are shielded from end-user support requests almost completely...
I recently had a similar situation, where I reported an issue (random packet loss in the 0.5-1.-% range even without any load, but only for traffic crossing a few specific access routers of that ISP); and after a while they started to care and managed to ultimately change that behaviour (and they reportedly also dragged the equipment manufacturers technicians into fixing it, unfortunately they did not want to reveal the root cause after fixing it).
So my take is, all ISPs have people willing to go to town on problems like this, but typically make sure mere end user problem reports never reach those folks...
Traffic originating from RFC 1918 private addresses should not normally appear on the Internet as ISPs should block these packets at the edge of their network to prevent exposure of internal networks and reduce the risk of address conflicts and security breaches. The fact that this traffic appears in an external log could indicate a configuration problem in the user's network equipment or a failure in the ISP's filtering policies.