Hello,
I'm playing a game which is developed in TCP and I've found that the game feels smoother/more responsive after playing it for many hours during a session. My network (and system) latency is low and pretty stable, there's no packet loss (that my very amateur TCP analysing skills can tell), and it stays this way during both the smooth and not-so-smooth times of play. Don't get me wrong, it's still playable during this time but it "feels" like a lot more than 30ms latency, which is apparently what I get. I've tried all-sorts of optimisations and tweaks and have never found anything that makes the game feel like that so I'm confident something else is at play.
I was looking at TCP Slow Start but not sure if that's relevant in this case. It could very well be my ISP changing something but the ping doesn't change. It could very well be the game server changing but nobody else who plays seems to recognise the change of smoothness when I get it.
I know I haven't given much here (apologies!) but I'm clutching at straws and am wondering why a TCP game may perform better after hours of playing and how to have it behave that way all the time?
Thanks,
Steve
TCP Game "Smoother" After Long Session Playing
Hi Steve, welcome to SG.
Could be something other than TCP settings, related to time of day, how overloaded your neighborhood connections are, or the game server... Or it can even be your PC caching up more of the game content over time into memory.
I'd look at the Network adapter optimizations (turn off TCP offloads, power saving, etc.).. https://www.speedguide.net/articles/net ... ation-3449
I assume you're not using WiFi for gaming? If you are, you can also look over the wireless tweaks in the main site articles.
I assume you've already tried the TCP Optimizer tweaks.
Could be something other than TCP settings, related to time of day, how overloaded your neighborhood connections are, or the game server... Or it can even be your PC caching up more of the game content over time into memory.
I'd look at the Network adapter optimizations (turn off TCP offloads, power saving, etc.).. https://www.speedguide.net/articles/net ... ation-3449
I assume you're not using WiFi for gaming? If you are, you can also look over the wireless tweaks in the main site articles.
I assume you've already tried the TCP Optimizer tweaks.
Linux is user friendly, it's just picky about its friends...
Disclaimer: Please use caution when opening messages, my grasp on reality may have shaken loose during transmission (going on rusty memory circuits). I also eat whatever crayons are put in front of me.
๑۩۞۩๑
Disclaimer: Please use caution when opening messages, my grasp on reality may have shaken loose during transmission (going on rusty memory circuits). I also eat whatever crayons are put in front of me.
๑۩۞۩๑
Thanks for the reply, Philip.
I think out of all the possibilities it is likely down to the time of day or it's ISP-related.
I'm on Ethernet and have tried tweaking the TCP offloads, power saving features, as well as using the the Optimizer (great app, by the way), but they don't seem to do the trick for this particular application.
The game has a tick rate of 50 which to my understanding means an update should be sent from the game server to the players once every 20ms (on average), but during the "not-so-smooth" times of play, it is almost as if I'm not receiving all 50 of these ticks, or perhaps they're not arriving uniformly.
This is what I believe the issue to be, but I might be way off.
My latency to the server is consistent and low. I used PowerShell to ping the server a decent-sized byte once every 20ms for a while and was getting zero packet loss. But does that mean that server's latency/packet loss to me is the same? (Not sure if that question makes sense.)
Could it be congestion?
One night, it did suddenly feel smooth which makes me think it is down to the time of day, but recently, it happened on a mid-week afternoon, so I'm not sure what to believe anymore...
I'm in an email conversation with my ISP to see if there's something technical happening their end but I fear that they won't be able to help because they won't look at the problem too closely or whether it's something out of their hands like a hop along the trace route causing the issue.
Anyway, like I said, clutching at straws, but if anyone has any advice on what to ask of my ISP or anything else, that would be much appreciated.
Steve
I think out of all the possibilities it is likely down to the time of day or it's ISP-related.
I'm on Ethernet and have tried tweaking the TCP offloads, power saving features, as well as using the the Optimizer (great app, by the way), but they don't seem to do the trick for this particular application.
The game has a tick rate of 50 which to my understanding means an update should be sent from the game server to the players once every 20ms (on average), but during the "not-so-smooth" times of play, it is almost as if I'm not receiving all 50 of these ticks, or perhaps they're not arriving uniformly.
This is what I believe the issue to be, but I might be way off.
My latency to the server is consistent and low. I used PowerShell to ping the server a decent-sized byte once every 20ms for a while and was getting zero packet loss. But does that mean that server's latency/packet loss to me is the same? (Not sure if that question makes sense.)
Could it be congestion?
One night, it did suddenly feel smooth which makes me think it is down to the time of day, but recently, it happened on a mid-week afternoon, so I'm not sure what to believe anymore...
I'm in an email conversation with my ISP to see if there's something technical happening their end but I fear that they won't be able to help because they won't look at the problem too closely or whether it's something out of their hands like a hop along the trace route causing the issue.
Anyway, like I said, clutching at straws, but if anyone has any advice on what to ask of my ISP or anything else, that would be much appreciated.
Steve
It can definitely be congestion.
Pings/latency measure the roundtrip time to the server and back, so it measures packets in both directions. Again, the only caveat being that pings (ICMP packets) get low priority to begin with. TCP is different than UDP traffic, in that all packets get acknowledged, so there is proof of delivery, and they may need to be in order, depending on the application. UDP otoh can drop stale/unnecessary packets and keep going, usually more relevant for video/audio and some gaming content that doesn't care about "old" data.
Traceroutes measure latency along the route to the server, so you may look for big spikes of latency at certain hops. The closer those hops with ping spikes are to you, the more likely it is your ISP, the further those hops are, the more likely it is to be congestion at your target server.
It is hard to get much out of your ISP tech support in general with intermittent problems, unless you have traceroutes showing exactly where/what the problem seems to be, and find a knowledgeable tech willing to help.
Pings/latency measure the roundtrip time to the server and back, so it measures packets in both directions. Again, the only caveat being that pings (ICMP packets) get low priority to begin with. TCP is different than UDP traffic, in that all packets get acknowledged, so there is proof of delivery, and they may need to be in order, depending on the application. UDP otoh can drop stale/unnecessary packets and keep going, usually more relevant for video/audio and some gaming content that doesn't care about "old" data.
Traceroutes measure latency along the route to the server, so you may look for big spikes of latency at certain hops. The closer those hops with ping spikes are to you, the more likely it is your ISP, the further those hops are, the more likely it is to be congestion at your target server.
It is hard to get much out of your ISP tech support in general with intermittent problems, unless you have traceroutes showing exactly where/what the problem seems to be, and find a knowledgeable tech willing to help.
Is there anything I can do at the OS (Windows 10) or driver (Realtek PCIe GbE Family Controller) level to specifically help with congestion on my end (should there be any)? I tried using the CTCP and NewReno congestion algorithms but no luck.
Yeah, with regards to this game, the developers used TCP as the data needs to arrive and be in order as you are viewing old and new data as you play.
Here is one trace route: (https://ibb.co/p0L90dd)
There's a little spike at the beginning, but to be fair, the other trace routes I ran showed consistently low numbers across the board, which makes me think it was a one-off, but then again these are only ICMP packets like you say.
I installed Wireshark and I captured data from a smooth run of the game and a not-so-smooth run and I tried comparing them but it's a bit advanced for me so I have no idea if there's any difference.
The only thing that was noticeable to me was that there were less regular TCP packets coming from the server to me while the incoming TLSv1.2 packets and outgoing TCP packets remained the same, but I could be looking at it wrong. The source port was also different.
Hopefully, I'll be able to speak to a tech that can help.
Thanks for all your help.
Steve
Yeah, with regards to this game, the developers used TCP as the data needs to arrive and be in order as you are viewing old and new data as you play.
Here is one trace route: (https://ibb.co/p0L90dd)
There's a little spike at the beginning, but to be fair, the other trace routes I ran showed consistently low numbers across the board, which makes me think it was a one-off, but then again these are only ICMP packets like you say.
I installed Wireshark and I captured data from a smooth run of the game and a not-so-smooth run and I tried comparing them but it's a bit advanced for me so I have no idea if there's any difference.
The only thing that was noticeable to me was that there were less regular TCP packets coming from the server to me while the incoming TLSv1.2 packets and outgoing TCP packets remained the same, but I could be looking at it wrong. The source port was also different.
Hopefully, I'll be able to speak to a tech that can help.
Thanks for all your help.
Steve
That trace looks fine, nothing stands out. As a side note, traceroutes and pings use ICMP (not TCP or UDP) in most operating systems, including Windows. This means its packets can be treated differently than TCP in congested environments.
Congestion usually occurs where your traffic is mixed with many other clients, overloaded local nodes, or ISP's backbones/interconnects, not at your location. Seems you've done most of the tweaks on your end already. CTCP or Cubic are your best bets for congestion control protocol.
Good luck with it.
Congestion usually occurs where your traffic is mixed with many other clients, overloaded local nodes, or ISP's backbones/interconnects, not at your location. Seems you've done most of the tweaks on your end already. CTCP or Cubic are your best bets for congestion control protocol.
Good luck with it.
So, after much playing around with different TCP settings, I *think* I've found the solution to my smoothness issue: enabling RFC 1323 Timestamps. But with my very basic understanding of what it offers I don't see how it's helping, unless something has happened ISP-end... or I'm going mad...
Have you any idea how it could help in this case (if at all)?
Thanks!
Have you any idea how it could help in this case (if at all)?
Thanks!
It depends on the server end what it does with, and whether it uses packets timestamps I suppose.
I can see it helping if the server uses timestamps to measure the roundtrip time/latency and serves content to you accordingly.
I can see it helping if the server uses timestamps to measure the roundtrip time/latency and serves content to you accordingly.
Linux is user friendly, it's just picky about its friends...
Disclaimer: Please use caution when opening messages, my grasp on reality may have shaken loose during transmission (going on rusty memory circuits). I also eat whatever crayons are put in front of me.
๑۩۞۩๑
Disclaimer: Please use caution when opening messages, my grasp on reality may have shaken loose during transmission (going on rusty memory circuits). I also eat whatever crayons are put in front of me.
๑۩۞۩๑
Thanks for the response.
I've another question if you don't mind...
With regards to Nagle's Algorithm and games such as this, I understand that disabling it is usually the way to go, but would that mean sending an acknowledgement packet every 20ms (for this game) as well as individual packets for each action I make in the game (such as turning left and right)? If that is so, could this then increase congestion and therefore latency?
Can acknowledgments be included in the same packet a game action is in? Such as a single "left turn + ack of received data since last ack" packet?
If that's the case, my thinking is that by keeping the algorithm enabled, and tweaking TcpAckFrequency to its upper limit (255) and TcpDelAckTicks to its upper limit (600ms), these criteria would never be met, and an acknowledgement will never be sent by itself and only with the game action packets I send, thus lowering congestion.
Apologies as I'm likely misunderstanding something.
I've another question if you don't mind...
With regards to Nagle's Algorithm and games such as this, I understand that disabling it is usually the way to go, but would that mean sending an acknowledgement packet every 20ms (for this game) as well as individual packets for each action I make in the game (such as turning left and right)? If that is so, could this then increase congestion and therefore latency?
Can acknowledgments be included in the same packet a game action is in? Such as a single "left turn + ack of received data since last ack" packet?
If that's the case, my thinking is that by keeping the algorithm enabled, and tweaking TcpAckFrequency to its upper limit (255) and TcpDelAckTicks to its upper limit (600ms), these criteria would never be met, and an acknowledgement will never be sent by itself and only with the game action packets I send, thus lowering congestion.
Apologies as I'm likely misunderstanding something.