Playing this weekend after a while of not doing anything, most of the time, everything is fine, outside of a small hiccup here and there, but then, suddenly, it will become terrible. Massive rubberbanding and something that is even worse. I don't know if there's a real name for it, but I'm calling it "de-synchronization".
This is where my client will continue to receive updates from the server, but the server has apparently decided to ignore me. On my screen, my ship will continue to move forward, and the client will dutifilly inform me of all the damage I'm taking. However, my ship stops firing, ignores command inputs, will not accept window interaction that involves the server, etc. This can last several minutes, I found it's better to just alt-f4 and restart the client. (Can't logout, since the client won't tell the server I'm logging out, so it does nothing) Eventually, it will either decide to kick me off with a disconnect, or "catch up" running all my commands at once as I rubberband back across time and space. If it's in the middle of combat, chances are I'm quite dead.
On the ground, what I'll see is myself moving, but my bridge officers will stop following, all the command inputs won't work anymore. If I stop moving, my character won't return to stand animation, but remain in mid-run while not moving. Other characters and people will continue to move around me.
This is NOT an ISP issue. It's not my local ISP nor is it Cogent (as some people have blamed). This is the STO's servers. I have a program that does continuous traceroutes while I was playing. The network is clear.
The route is clear throughout, despite significant rubberbanding and getting desync'd from the server. My avg ping to cryptic was 18.2 ms, and never worse than 53.9 ms.
EDIT: Anyone know how to get this damned editor not to collapse spaces? Most have a pre or code tag, but this one doesn't seem to.
Yea... You really think thats not a cogentco issue?
That's a router that isn't responding to ICMP packets, not a broken connection. You can tell because the hops beyond it do not show packet loss, most importantly the endpoint. Indeed, the endpoint is the only one that absolutely matters. The ones before can help you see where an issue comes up, but if the endpoint is clean of both packet loss and ping spikes, then the hops in between are irrelevent.
When diagnosing these sorts of network issues, what you look for is a sudden jump in ping times or packet loss that continue down the route.
Busy routers are frequently set up to drop icmp packets, because those packets aren't used for real data, but can still clog the system. That is what that router is doing. If the router was, in fact, overloaded, you'd see a ping spike to it. You don't see that here. Packets that it responds to are clean. It's likely set to only respond to ICMP packets from a particular IP address once every two seconds or something and I was sending it pings once per second.
That's a router that isn't responding to ICMP packets, not a broken connection. You can tell because the hops beyond it do not show packet loss, most importantly the endpoint. Indeed, the endpoint is the only one that absolutely matters. The ones before can help you see where an issue comes up, but if the endpoint is clean of both packet loss and ping spikes, then the hops in between are irrelevent.
When diagnosing these sorts of network issues, what you look for is a sudden jump in ping times or packet loss that continue down the route.
Busy routers are frequently set up to drop icmp packets, because those packets aren't used for real data, but can still clog the system. That is what that router is doing. If the router was, in fact, overloaded, you'd see a ping spike to it. You don't see that here. Packets that it responds to are clean. It's likely set to only respond to ICMP packets from a particular IP address once every two seconds or something and I was sending it pings once per second.
You do realize if there is a loss of packets ANYWHERE along the point that can mess things up because tada the data was lost along the way :P
Yes, I'm that Askray@Batbayer in game. Yes, I still play. No, I don't care. Former Community Moderator, Former SSR DJ, Now Full time father to two kids, Husband, Retail Worker. Tiktok: @Askray Facebook: Askray113
You do realize if there is a loss of packets ANYWHERE along the point that can mess things up because tada the data was lost along the way :P
That's not how a traceroute works. If there was a packet lost along the way, it would appear as loss as the endpoint (in fact it would appear on every hop after the first one dropping packets).
What the program does is send a ping packet to each individual router along the route, so each hop listed is from a packet that passed through all the ones before it. Additionally, ping packets, since they are not moving real data, are given the lowest priority on the routers, and many routers specifically throttle them. It's to prevent denial of service attacks. Before that was common practice, servers could be overwhelmed by simple ping packets sent in large enough quantity.
When you see packet loss on a router, but not the router before nor the router after, that's a clear indication that the router is simply set to throttle the number of ping packets it responds to. Additionally, if you look at he ping times, it's quite clear that this isn't a case of a router overloading, as you would see slower pings and more variation.
It's even common to have routers along the way that won't respond to ping packets at all, showing 100% packet loss for one hop. Normal traffic and ping packets that are set to pass through it go just fine. The router just doesn't answer queries sent specifically to it.
This is where my client will continue to receive updates from the server, but the server has apparently decided to ignore me. On my screen, my ship will continue to move forward, and the client will dutifilly inform me of all the damage I'm taking. However, my ship stops firing, ignores command inputs, will not accept window interaction that involves the server, etc.
same problem for me; i was around vulcan and impossible to leave this place; my ship advances and suddendly, she is returned at the same place.
my only solution was to leave the game, 5 minutes ago.
the more insulting thing for me is that nobody from cryptic/pwe or whatever, try to explain to us; why there is this problem
and, no, no, no; the problems doesn't come from my connection. i tried to play at other mmos and i had no problems with these games.
same problem for me; i was around vulcan and impossible to leave this place; my ship advances and suddendly, she is returned at the same place.
my only solution was to leave the game, 5 minutes ago.
the more insulting thing for me is that nobody from cryptic/pwe or whatever, try to explain to us; why there is this problem
and, no, no, no; the problems doesn't come from my connection. i tried to play at other mmos and i had no problems with these games.
Yeah, it's crazy that they can keep blaming ISPs and people buy it. I'm sitting here watching the pings go through clean one one screen, meanwhile I'll see rubberbanding and desynch's happening on the other screen in game.
So, I decided to leave the ping running overnight after my last server disconnect disgusted me too much to keep going. Over 26,000 pings, 0.0% packet loss. Worst ping time: 47.3 ms. Avg ping: 16 ms.
Can you guys FINALLY admit this isn't a damned ISP issue? Or are you still going to hide behind misunderstanding how traceroute works? And why did you banish this thread to the PC/Networking issues forum WHEN THE WHOLE POINT OF THE THREAD IS TO SHOW IT IS NOT A PC/NETWORKING ISSUE!
Comments
Yea... You really think thats not a cogentco issue?
Been around since Dec 2010 on STO and bought LTS in Apr 2013 for STO.
That's a router that isn't responding to ICMP packets, not a broken connection. You can tell because the hops beyond it do not show packet loss, most importantly the endpoint. Indeed, the endpoint is the only one that absolutely matters. The ones before can help you see where an issue comes up, but if the endpoint is clean of both packet loss and ping spikes, then the hops in between are irrelevent.
When diagnosing these sorts of network issues, what you look for is a sudden jump in ping times or packet loss that continue down the route.
Busy routers are frequently set up to drop icmp packets, because those packets aren't used for real data, but can still clog the system. That is what that router is doing. If the router was, in fact, overloaded, you'd see a ping spike to it. You don't see that here. Packets that it responds to are clean. It's likely set to only respond to ICMP packets from a particular IP address once every two seconds or something and I was sending it pings once per second.
You do realize if there is a loss of packets ANYWHERE along the point that can mess things up because tada the data was lost along the way :P
Former Community Moderator, Former SSR DJ, Now Full time father to two kids, Husband, Retail Worker.
Tiktok: @Askray Facebook: Askray113
That's not how a traceroute works. If there was a packet lost along the way, it would appear as loss as the endpoint (in fact it would appear on every hop after the first one dropping packets).
What the program does is send a ping packet to each individual router along the route, so each hop listed is from a packet that passed through all the ones before it. Additionally, ping packets, since they are not moving real data, are given the lowest priority on the routers, and many routers specifically throttle them. It's to prevent denial of service attacks. Before that was common practice, servers could be overwhelmed by simple ping packets sent in large enough quantity.
When you see packet loss on a router, but not the router before nor the router after, that's a clear indication that the router is simply set to throttle the number of ping packets it responds to. Additionally, if you look at he ping times, it's quite clear that this isn't a case of a router overloading, as you would see slower pings and more variation.
It's even common to have routers along the way that won't respond to ping packets at all, showing 100% packet loss for one hop. Normal traffic and ping packets that are set to pass through it go just fine. The router just doesn't answer queries sent specifically to it.
This is just how the internet works.
same problem for me; i was around vulcan and impossible to leave this place; my ship advances and suddendly, she is returned at the same place.
my only solution was to leave the game, 5 minutes ago.
the more insulting thing for me is that nobody from cryptic/pwe or whatever, try to explain to us; why there is this problem
and, no, no, no; the problems doesn't come from my connection. i tried to play at other mmos and i had no problems with these games.
Can you guys FINALLY admit this isn't a damned ISP issue? Or are you still going to hide behind misunderstanding how traceroute works? And why did you banish this thread to the PC/Networking issues forum WHEN THE WHOLE POINT OF THE THREAD IS TO SHOW IT IS NOT A PC/NETWORKING ISSUE!
(0.0.0.0) Thu Apr 9 10:19:34 2015
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. x.x.x.x 0.0% 26295 7.5 6.6 5.9 36.6 3.2
2. x.x.x.x 0.0% 26295 9.1 6.8 6.1 50.2 3.2
3. x.x.x.x 0.0% 26294 9.4 8.0 7.3 38.0 2.4
4. x.x.x.x 0.0% 26294 9.4 7.9 7.2 37.4 2.4
5. 64.15.2.74 0.0% 26294 11.2 9.6 8.8 42.3 2.7
451be0de.cst.lightpath.net
6. te0-3-0-6.rcr21.ewr02.atlas.cogentco 49.9% 26294 10.7 9.6 8.7 35.5 2.2
7. be2324.ccr41.jfk02.atlas.cogentco.co 0.0% 26294 10.7 10.3 9.6 477.1 4.4
be2601.rcr22.jfk01.atlas.cogentco.com
8. be2094.ccr21.bos01.atlas.cogentco.co 0.1% 26294 18.5 10.6 9.9 652.1 9.4
be2356.ccr42.jfk02.atlas.cogentco.com
9. be2096.ccr22.bos01.atlas.cogentco.co 0.0% 26294 17.9 16.3 15.8 44.7 2.4
te0-0-1-0.rcr11.b002133-1.bos01.atlas.cogentco.com
10. te0-0-0-0.rcr11.b002133-1.bos01.atla 0.0% 26294 23.1 16.5 15.4 56.0 5.4
38.111.40.114
11. 38.111.40.114 0.0% 26294 19.3 16.2 15.1 49.5 5.6
patchserverrebirth.crypticstudios.com
12. patchserverrebirth.crypticstudios.co 0.0% 26294 16.5 16.0 15.0 47.3 3.4