test content
What is the Arc Client?
Install Arc
Options

SUPER LAG, RUBBERBANDING

2456789

Comments

  • Options
    lordmerc22lordmerc22 Member Posts: 776 Arc User
    leemwatson wrote: »
    protoneous wrote: »
    trekpuppy wrote: »
    I take this opportunity to humbly remind people that traceroute doesn't use the same network protocol by default as the game does and as such you can't draw any conclusions of the game's behaviour based on traceroute data. You have no guarantee that routers on the path treat the different protocols equivalent. On the contrary we see multiple examples of nodes that don't respond to traceroute probes but forward gamedata correctly.
    Add to that that traceroute was created long before modern Internet infrastructure techniques like MPLS and traffic shaping and is therefore one of the most useless diagnostics tools today and should IMHO be removed from every Windows installation.
    Some nodes are set to not respond to traceroute probes for a specific reason. If the tool is really that outdated somebody should give a heads up to these people https://support.arcgames.com/app/answers/detail/a_id/4657/~/performing-a-traceroute-%28tracert%29 so they can provide some more up to date suggestions.

    leemwatson wrote: »
    Last year I diagnosed a line fault that my telecoms supplier couldn't diagnose (even after 4 home-visits!) just by checking my router diagnostics. It was in my local distribution cabinet. Did I ever once blame Cryptic for the SNR's...no. Problem is people are quick to blame another without looking at the wider picture. It's less stressful if I do the checking for myself :lol:
    That is so cool. So they finally made a router that can dial the appropriate test number for your Central Office to lift (temporarily disconnect) your line at their end and then not only perform basic DC testing but also throws in some of the same functionality of commercial testing gear that can give a distance to the line fault. This would be step number one for copper (although I'd usually suspect and test for a customer premise fault first). Fiber would be slightly different but having transmission and loss testing in a router would be great as well.

    Well, having worked for an EPoS company, I was taught a fair bit about error diagnostics, so looking for where the router reports the errors (Near or Far-end FEC, CRC etc) is key, and how I knew it wasn't my end, which the Telecoms company were insisting it was. Had 4 engineer visits to test my equipment, and that was more annoying for OpenReach, because the Telecoms company was supposed to request a line investigation, not a home visit. The routers I've had have always been the same manufacturer and for over 10 years, I've been able to view that diagnostic screen.

    But back to point, putting the blame on Cryptic for something that's not their fault or with-in their ability to fix is wrong. Akamai handle a considerable amount of net-traffic (up to 30% of it). My guess is they aren't playing fair with bandwidth or prioritization of traffic.

    Even if I accept this, how can you explain every other mmo out there I ever tried that isnt cryptic's doesnt have these problems. No I am not saying they are better games which is subjective anyways, but I am saying none has the problems here and they are getting dangerous for them - if they arent fixed we will see population drops

    Then it also comes to this - who chose that akamai server/service. In other words who's responsibility is it to replace the problematic service?(and again no other mmo games I ever tried are experiencing that)
  • Options
    It's always been like this and always will be. I get hung badly when trying to switch characters also, and it frequently takes me longer to simply switch to someone new than it takes me to then set admiralty, reputation projects and atm even a quick arena of sompek. The dread of setting the t5-t6 rep projects every day and going through this made me quit for a year.
    qaAuoh7.gif
  • Options
    leemwatsonleemwatson Member Posts: 5,344 Arc User
    lordmerc22 wrote: »
    leemwatson wrote: »
    protoneous wrote: »
    trekpuppy wrote: »
    I take this opportunity to humbly remind people that traceroute doesn't use the same network protocol by default as the game does and as such you can't draw any conclusions of the game's behaviour based on traceroute data. You have no guarantee that routers on the path treat the different protocols equivalent. On the contrary we see multiple examples of nodes that don't respond to traceroute probes but forward gamedata correctly.
    Add to that that traceroute was created long before modern Internet infrastructure techniques like MPLS and traffic shaping and is therefore one of the most useless diagnostics tools today and should IMHO be removed from every Windows installation.
    Some nodes are set to not respond to traceroute probes for a specific reason. If the tool is really that outdated somebody should give a heads up to these people https://support.arcgames.com/app/answers/detail/a_id/4657/~/performing-a-traceroute-%28tracert%29 so they can provide some more up to date suggestions.

    leemwatson wrote: »
    Last year I diagnosed a line fault that my telecoms supplier couldn't diagnose (even after 4 home-visits!) just by checking my router diagnostics. It was in my local distribution cabinet. Did I ever once blame Cryptic for the SNR's...no. Problem is people are quick to blame another without looking at the wider picture. It's less stressful if I do the checking for myself :lol:
    That is so cool. So they finally made a router that can dial the appropriate test number for your Central Office to lift (temporarily disconnect) your line at their end and then not only perform basic DC testing but also throws in some of the same functionality of commercial testing gear that can give a distance to the line fault. This would be step number one for copper (although I'd usually suspect and test for a customer premise fault first). Fiber would be slightly different but having transmission and loss testing in a router would be great as well.

    Well, having worked for an EPoS company, I was taught a fair bit about error diagnostics, so looking for where the router reports the errors (Near or Far-end FEC, CRC etc) is key, and how I knew it wasn't my end, which the Telecoms company were insisting it was. Had 4 engineer visits to test my equipment, and that was more annoying for OpenReach, because the Telecoms company was supposed to request a line investigation, not a home visit. The routers I've had have always been the same manufacturer and for over 10 years, I've been able to view that diagnostic screen.

    But back to point, putting the blame on Cryptic for something that's not their fault or with-in their ability to fix is wrong. Akamai handle a considerable amount of net-traffic (up to 30% of it). My guess is they aren't playing fair with bandwidth or prioritization of traffic.

    Even if I accept this, how can you explain every other mmo out there I ever tried that isnt cryptic's doesnt have these problems. No I am not saying they are better games which is subjective anyways, but I am saying none has the problems here and they are getting dangerous for them - if they arent fixed we will see population drops

    Then it also comes to this - who chose that akamai server/service. In other words who's responsibility is it to replace the problematic service?(and again no other mmo games I ever tried are experiencing that)

    How can you explain why I don't get these issues?? How do you know Cryptic had a choice in choosing Akamai? Rubber-banding is something literally every MMO I've ever played has had issues with (I play PC and XBOX MMO's), but I've never experienced it to the degree people are claiming here with the exception of the couple of months of Cyber-attacks Cryptic came under a couple of years ago.

    And going back to Akamai, the throttling they do is probably done by every other service in the US because of the lack of net-neutrality when it comes to bandwidth and traffic priority.
    "You don't want to patrol!? You don't want to escort!? You don't want to defend the Federation's Starbases!? Then why are you flying my Starships!? If you were a Klingon you'd be killed on the spot, but lucky for you.....you WERE in Starfleet. Let's see how New Zealand Penal Colony suits you." Adm A. Necheyev.
  • Options
    lordmerc22lordmerc22 Member Posts: 776 Arc User
    leemwatson wrote: »
    lordmerc22 wrote: »
    leemwatson wrote: »
    protoneous wrote: »
    trekpuppy wrote: »
    I take this opportunity to humbly remind people that traceroute doesn't use the same network protocol by default as the game does and as such you can't draw any conclusions of the game's behaviour based on traceroute data. You have no guarantee that routers on the path treat the different protocols equivalent. On the contrary we see multiple examples of nodes that don't respond to traceroute probes but forward gamedata correctly.
    Add to that that traceroute was created long before modern Internet infrastructure techniques like MPLS and traffic shaping and is therefore one of the most useless diagnostics tools today and should IMHO be removed from every Windows installation.
    Some nodes are set to not respond to traceroute probes for a specific reason. If the tool is really that outdated somebody should give a heads up to these people https://support.arcgames.com/app/answers/detail/a_id/4657/~/performing-a-traceroute-%28tracert%29 so they can provide some more up to date suggestions.

    leemwatson wrote: »
    Last year I diagnosed a line fault that my telecoms supplier couldn't diagnose (even after 4 home-visits!) just by checking my router diagnostics. It was in my local distribution cabinet. Did I ever once blame Cryptic for the SNR's...no. Problem is people are quick to blame another without looking at the wider picture. It's less stressful if I do the checking for myself :lol:
    That is so cool. So they finally made a router that can dial the appropriate test number for your Central Office to lift (temporarily disconnect) your line at their end and then not only perform basic DC testing but also throws in some of the same functionality of commercial testing gear that can give a distance to the line fault. This would be step number one for copper (although I'd usually suspect and test for a customer premise fault first). Fiber would be slightly different but having transmission and loss testing in a router would be great as well.

    Well, having worked for an EPoS company, I was taught a fair bit about error diagnostics, so looking for where the router reports the errors (Near or Far-end FEC, CRC etc) is key, and how I knew it wasn't my end, which the Telecoms company were insisting it was. Had 4 engineer visits to test my equipment, and that was more annoying for OpenReach, because the Telecoms company was supposed to request a line investigation, not a home visit. The routers I've had have always been the same manufacturer and for over 10 years, I've been able to view that diagnostic screen.

    But back to point, putting the blame on Cryptic for something that's not their fault or with-in their ability to fix is wrong. Akamai handle a considerable amount of net-traffic (up to 30% of it). My guess is they aren't playing fair with bandwidth or prioritization of traffic.

    Even if I accept this, how can you explain every other mmo out there I ever tried that isnt cryptic's doesnt have these problems. No I am not saying they are better games which is subjective anyways, but I am saying none has the problems here and they are getting dangerous for them - if they arent fixed we will see population drops

    Then it also comes to this - who chose that akamai server/service. In other words who's responsibility is it to replace the problematic service?(and again no other mmo games I ever tried are experiencing that)

    How can you explain why I don't get these issues?? How do you know Cryptic had a choice in choosing Akamai? Rubber-banding is something literally every MMO I've ever played has had issues with (I play PC and XBOX MMO's), but I've never experienced it to the degree people are claiming here with the exception of the couple of months of Cyber-attacks Cryptic came under a couple of years ago.

    And going back to Akamai, the throttling they do is probably done by every other service in the US because of the lack of net-neutrality when it comes to bandwidth and traffic priority.

    All of the games that dont lag also are based on US
  • Options
    baddmoonrizinbaddmoonrizin Member Posts: 10,320 Community Moderator
    Ok, those of you who are hung up on assigning blame are not helping. If you're not providing evidence to help diagnose the problem, then please exit the thread. The back and forth nonsense about who's at fault and who's responsible is not at all helpful or productive.
    GrWzQke.png
    Star Trek Online Volunteer Community Moderator and Resident She-Wolf
    Community Moderators are Unpaid Volunteers and NOT Employees of Gearbox/Cryptic
    Views and Opinions May Not Reflect the Views and Opinions of Gearbox/Cryptic
    ----> Contact Customer Support <----
    Moderation Problems/Issues? Please contact the Community Manager
    Terms of Service / Community Rules and Policies / FCT
    Want the latest information on Star Trek Online?
    Facebook / Twitter / Twitch
  • Options
    lordmerc22lordmerc22 Member Posts: 776 Arc User
    edited August 2019
    Ok, those of you who are hung up on assigning blame are not helping. If you're not providing evidence to help diagnose the problem, then please exit the thread. The back and forth nonsense about who's at fault and who's responsible is not at all helpful or productive.

    It's not a matter of blame even - its understanding where it comes from. The first step of solving a problem, any problem, is understanding it, owning it and solving it. And that hasnt happened yet even though multiple people have traced where the latency comes from and, most likely, the rubberbanding.

    that said they had patch a while ago that was supposed to ease lag - and while it didnt eliminate it, it had eased it indeed, till next patch came. So could it be it was accidently reverted?
  • Options
    davefenestratordavefenestrator Member Posts: 10,512 Arc User
    lordmerc22 wrote: »
    Ok, those of you who are hung up on assigning blame are not helping. If you're not providing evidence to help diagnose the problem, then please exit the thread. The back and forth nonsense about who's at fault and who's responsible is not at all helpful or productive.

    It's not a matter of blame even - its understanding where it comes from. The first step of solving a problem, any problem, is understanding it, owning it and solving it. And that hasnt happened yet even though multiple people have traced where the latency comes from and, most likely, the rubberbanding.

    that said they had patch a while ago that was supposed to ease lag - and while it didnt eliminate it, it had eased it indeed, till next patch came. So could it be it was accidently reverted?

    No, that change was to "save up" ship XP during TFOs then award it when you warped out. It has not been reverted.




  • Options
    evilspokevilspok Member Posts: 51 Arc User
    3 15 ms 16 ms 18 ms 10.196.48.1
    4 35 ms 13 ms 13 ms ten0-0-0-1.orld36-ser1.bhn.net [72.31.223.70]
    5 16 ms 18 ms 19 ms bundle-ether21.orld11-car1.bhn.net [71.44.60.120]
    6 29 ms 18 ms 18 ms 72-31-220-174.net.bhntampa.com [72.31.220.174]
    7 20 ms 23 ms 21 ms 72-31-188-170.net.bhntampa.com [72.31.188.170]
    8 29 ms 35 ms 33 ms 216.156.105.65.ptr.us.xo.net [216.156.105.65]
    9 36 ms 33 ms 33 ms 207.88.13.103.ptr.us.xo.net [207.88.13.103]
    10 52 ms 45 ms 48 ms 216.156.104.22.ptr.us.xo.net [216.156.104.22]
    11 46 ms 48 ms 48 ms po110.bs-a.sech-mia4.netarch.akamai.com [23.57.103.243]
    12 * * * Request timed out.
    13 48 ms 48 ms 48 ms ae120.access-a.sech-mia4.netarch.akamai.com [23.57.103.249]
    14 * * * Request timed out.
    15 67 ms 80 ms 62 ms a209-200-171-102.deploy.static.akamaitechnologies.com [209.200.171.102]
    16 74 ms 71 ms 65 ms 198.49.243.237
    17 57 ms 58 ms 58 ms patchserver.crypticstudios.com [208.95.184.200]

    Trace complete.

    Minus my own IP address, this also confirms that the issue is with akamai servers. As mentioned at the beginning of the thread, this is supposedly a "security server that Cryptic sends all data though which is causing problems for a large amount of players."

    If this is the case, how do we move on from here or address this?
  • Options
    seaofsorrowsseaofsorrows Member Posts: 10,918 Arc User
    edited August 2019
    The game has lag.. it has for a while. It's acknowledged by the developers and is a frequent subject here on the forums.

    While the severity of this lag varies greatly (I don't suffer nearly as bad as many on here) there is no point arguing rather or not there is lag and/or occasional rubber banding. If you're taking the side that it doesn't exist, you're either oblivious or being intentionally argumentative or deceptive.

    The good news is that the development team is aware and they have been actively working on it for some time now. Even the last change to the way XP was awarded on warp out seemed to help quite a bit from my perspective. Things like this are very hard to diagnose, they're doing the best they can and it does seem to be improving. Best advice I can give for now is give it more time.

    Trying to tell people that this issue does not exist is counterproductive and disingenuous.
    Post edited by seaofsorrows on
    Insert witty signature line here.
  • Options
    protoneousprotoneous Member Posts: 2,985 Arc User
    Wise words from Sea. My own results from the west coast of Canada are usually pretty decent. My in-game experience varies upon occasion, but has never been anything that would warrant an 'unplayable' label. I speak only for myself.
    evilspok wrote: »
    <snip>this also confirms that the issue is with akamai servers.
    I ask out of pure curiosity, how does your traceroute results confirm that the issue is with the akamai servers? A few of your numbers are better than my own.
  • Options
    protoneousprotoneous Member Posts: 2,985 Arc User
    trekpuppy wrote: »
    I take this opportunity to humbly remind people that traceroute doesn't use the same network protocol by default as the game does and as such you can't draw any conclusions of the game's behaviour based on traceroute data. You have no guarantee that routers on the path treat the different protocols equivalent. On the contrary we see multiple examples of nodes that don't respond to traceroute probes but forward gamedata correctly.
    Add to that that traceroute was created long before modern Internet infrastructure techniques like MPLS and traffic shaping and is therefore one of the most useless diagnostics tools today and should IMHO be removed from every Windows installation.
    It took some reading up but you are absolutely correct. Wow and thank you*
    leemwatson wrote: »
    Well, having worked for an EPoS company, I was taught a fair bit about error diagnostics, so looking for where the router reports the errors (Near or Far-end FEC, CRC etc) is key, and how I knew it wasn't my end, which the Telecoms company were insisting it was. Had 4 engineer visits to test my equipment, and that was more annoying for OpenReach, because the Telecoms company was supposed to request a line investigation, not a home visit. The routers I've had have always been the same manufacturer and for over 10 years, I've been able to view that diagnostic screen.

    But back to point, putting the blame on Cryptic for something that's not their fault or with-in their ability to fix is wrong. Akamai handle a considerable amount of net-traffic (up to 30% of it). My guess is they aren't playing fair with bandwidth or prioritization of traffic.
    Some more reading and a look at my own provider's router. Nicely done on your diagnostic job. My own training leans more heavily in the direction of analog even though I've spliced and tested miles of fiber. Getting back to the point, I agree with your assessment. It's been an educational evening. Another thank you.

    *Yes I bounced around a bit this evening on some maps, even though my traceroute and ping numbers looked fine. Go figure :|
  • Options
    pottsey5gpottsey5g Member Posts: 4,177 Arc User
    edited August 2019
    leemwatson wrote: »
    “But back to point, putting the blame on Cryptic for something that's not their fault or with-in their ability to fix is wrong.”
    It might take time but is should be within Cryptics power and ability to fit it. Cryptic choose to buy into a service which is causing the problems. Others online games for example Eve Online do investigate these kind of problems and get them fixed.

    A lot of us have ruled out the fault being on our end which means there is nothing we can do but wait for Cryptic to fix the problem.


    leemwatson wrote: »
    “How can you explain why I don't get these issues??”
    These types of problems don’t always affect every single player. Lag and rubberbanding can be 100% server related and only effect part of the player base. Location and timezone you play in can also be a factor.

    If you never get any of these issues, I would be interested in you joining a HSE run with me and seeing if you don’t get lag, don’t get ships disappearing so you cannot target them and then they reappear. Although I haven’t ran HSE in the past 3 patches the past 50+ times before that the entire group had problems nearly 100% of the time. So I am suspecting something in the builds we use is causing problems on top of the other causes of lag.

    Speaking of which, do others get the same problems in HSE all the time like I do? Ships disappear then reappear and are invisible on the map but still there. I have a very lose suspicion on what is causing it but no where near enough data or evidence. EDIT: Do full energy boat teams with limited or no mines, torpedoes, pets still get the ships going invisible problem in HSE?
    Post edited by pottsey5g on
  • Options
    warmaker001bwarmaker001b Member Posts: 9,205 Arc User
    Lag has been exquisite. Hell, at the start of the Summer Event, I remember doing a powerboard race and it was lagging so much, I jumped the same ramp 3 times in a row. I just kept on rubber banding right back to before the ramp :D
    XzRTofz.gif
  • Options
    pottsey5gpottsey5g Member Posts: 4,177 Arc User
    edited August 2019
    Lag has been exquisite. Hell, at the start of the Summer Event, I remember doing a powerboard race and it was lagging so much, I jumped the same ramp 3 times in a row. I just kept on rubber banding right back to before the ramp :D
    If that was at the very start of the event it was during the timeframe when we had server lag caused by misconfigured Risa zones. I cannot remember which day it was but in the first week the zones got changed which cleared up not all but the bulk of the Risa lag.
  • Options
    paladinrja#5247 paladinrja Member Posts: 155 Arc User
    Pretty sure the devs know there are issues with the network. So it's good you come in and point it out. I don't really have a suggestion as to what you can do (while they sort it out) because too many parties are involved in a project this big.

    Only suggestion I would have is towards the devs: Perhaps in the meantime, remove much of the animation locks on performing skills, etc? -- at least for the away-team section (ground), it would ease a lot of tension. -- It's honestly hard to tell whether the rubber banding is due to skills and abilities, or actual lag.

    In my case, I've stopped using auto-cast on away missions.
    XBOX One GT: Paladinrja
  • Options
    trekpuppytrekpuppy Member Posts: 446 Arc User
    evilspok wrote: »
    3 15 ms 16 ms 18 ms 10.196.48.1
    4 35 ms 13 ms 13 ms ten0-0-0-1.orld36-ser1.bhn.net [72.31.223.70]
    5 16 ms 18 ms 19 ms bundle-ether21.orld11-car1.bhn.net [71.44.60.120]
    6 29 ms 18 ms 18 ms 72-31-220-174.net.bhntampa.com [72.31.220.174]
    7 20 ms 23 ms 21 ms 72-31-188-170.net.bhntampa.com [72.31.188.170]
    8 29 ms 35 ms 33 ms 216.156.105.65.ptr.us.xo.net [216.156.105.65]
    9 36 ms 33 ms 33 ms 207.88.13.103.ptr.us.xo.net [207.88.13.103]
    10 52 ms 45 ms 48 ms 216.156.104.22.ptr.us.xo.net [216.156.104.22]
    11 46 ms 48 ms 48 ms po110.bs-a.sech-mia4.netarch.akamai.com [23.57.103.243]
    12 * * * Request timed out.
    13 48 ms 48 ms 48 ms ae120.access-a.sech-mia4.netarch.akamai.com [23.57.103.249]
    14 * * * Request timed out.
    15 67 ms 80 ms 62 ms a209-200-171-102.deploy.static.akamaitechnologies.com [209.200.171.102]
    16 74 ms 71 ms 65 ms 198.49.243.237
    17 57 ms 58 ms 58 ms patchserver.crypticstudios.com [208.95.184.200]

    Trace complete.

    Minus my own IP address, this also confirms that the issue is with akamai servers. As mentioned at the beginning of the thread, this is supposedly a "security server that Cryptic sends all data though which is causing problems for a large amount of players."

    If this is the case, how do we move on from here or address this?

    This is an example of a perfect traceroute with no indications of errors anywhere. Every node that is configured to respond to traceroute's probes does so on each of the three attempts. Latencies are low and stable, increasing slightly the further away the node is from you, as expected. What in this do you mean shows an error?
    ---
    "-Grind is good!" --Gordon Geko
    Accolades checklist: https://bit.ly/FLUFFYS
  • Options
    casualstocasualsto Member Posts: 672 Arc User
    Remember, guys. Each time you get a rubber-band or random server disconnect, to wiggle your wallet and then close it back. Maybe if you do it often enough, someone's gonna invest and put the fatty hamsters to run those wheels faster.
  • Options
    ussvaliant#6064 ussvaliant Member Posts: 1,006 Arc User
    edited August 2019
    Thought i'd try aTracert whilst the game is down for maintenance and the 93.191.173.11 i.p again has high returns

    1 <1 ms <1 ms <1 ms ttrouter [192.168.1.1]
    2 * * * Request timed out.
    3 9 ms 9 ms 8 ms host-78-151-230-241.as13285.net [78.151.230.241]
    4 9 ms 8 ms 9 ms host-78-151-230-226.as13285.net [78.151.230.226]
    5 12 ms 12 ms 12 ms host-78-144-0-81.as13285.net [78.144.0.81]
    6 13 ms 13 ms 13 ms akamai.prolexic.com [195.66.224.31]
    7 13 ms 13 ms 13 ms po110.bs-a.sech-lon2.netarch.akamai.com [72.52.60.192]
    8 13 ms 13 ms 13 ms a72-52-1-179.deploy.static.akamaitechnologies.com [72.52.1.179]
    9 17 ms 28 ms 29 ms ae120.access-a.sech-lon2.netarch.akamai.com [72.52.60.197]
    10 209 ms 281 ms 233 ms 93.191.173.11
    11 94 ms 95 ms 95 ms a72-52-27-212.deploy.static.akamaitechnologies.com [72.52.27.212]
    12 106 ms 101 ms 99 ms 198.49.243.237
    13 94 ms 94 ms 94 ms patchserver.crypticstudios.com [208.95.184.200]

    1 <1 ms <1 ms <1 ms ttrouter [192.168.1.1]
    2 * * * Request timed out.
    3 9 ms 9 ms 9 ms host-78-151-230-241.as13285.net [78.151.230.241]
    4 9 ms 9 ms 9 ms host-78-151-230-226.as13285.net [78.151.230.226]
    5 12 ms 11 ms 11 ms host-78-144-0-81.as13285.net [78.144.0.81]
    6 13 ms 14 ms 13 ms akamai.prolexic.com [195.66.224.31]
    7 13 ms 12 ms 13 ms po110.bs-a.sech-lon2.netarch.akamai.com [72.52.60.192]
    8 13 ms 13 ms 13 ms a72-52-1-179.deploy.static.akamaitechnologies.com [72.52.1.179]
    9 15 ms 16 ms 16 ms ae120.access-a.sech-lon2.netarch.akamai.com [72.52.60.197]
    10 233 ms 257 ms 312 ms 93.191.173.11
    11 95 ms 95 ms 94 ms a72-52-27-212.deploy.static.akamaitechnologies.com [72.52.27.212]
    12 109 ms 100 ms 97 ms 198.49.243.237
    13 94 ms 94 ms 94 ms patchserver.crypticstudios.com [208.95.184.200]

    Server now up tracert

    1 1 ms <1 ms <1 ms ttrouter [192.168.1.1]
    2 * * * Request timed out.
    3 9 ms 8 ms 9 ms host-78-151-230-241.as13285.net [78.151.230.241]
    4 15 ms 8 ms 9 ms host-78-151-230-226.as13285.net [78.151.230.226]
    5 21 ms 20 ms 15 ms host-78-144-0-81.as13285.net [78.144.0.81]
    6 13 ms 13 ms 13 ms akamai.prolexic.com [195.66.224.31]
    7 13 ms 13 ms 13 ms po110.bs-a.sech-lon2.netarch.akamai.com [72.52.60.192]
    8 13 ms 13 ms 13 ms a72-52-1-179.deploy.static.akamaitechnologies.com [72.52.1.179]
    9 48 ms 55 ms 98 ms ae120.access-a.sech-lon2.netarch.akamai.com [72.52.60.197]
    10 322 ms 238 ms 209 ms 93.191.173.11
    11 99 ms 94 ms 94 ms a72-52-27-212.deploy.static.akamaitechnologies.com [72.52.27.212]
    12 103 ms 101 ms 108 ms 198.49.243.237
    13 94 ms 94 ms 94 ms patchserver.crypticstudios.com [208.95.184.200]
    Post edited by ussvaliant#6064 on
    maR4zDV.jpg

    Hello rubber banding my old friend, time to bounce around the battlezone again, where are all my bug reports going?, out of love with this game I am falling, As Cryptic fail to acknowledge a problem exists, Shakes an angry fist, And from Support all I'm hearing are the sounds of silence.
  • Options
    trekpuppytrekpuppy Member Posts: 446 Arc User
    Thought i'd try aTracert whilst the game is down for maintenance and the 93.191.173.11 i.p again has high returns

    The game is not communicating with that node - it's sending data through it. If the node added a large latency to data sent through it you would have had the same high latency on the nodes behind it since traceroute shows the ackumulated latencies for each hop and this is not what your traceroute shows. You have a perfectly normal latency to the gameserver.
    ---
    "-Grind is good!" --Gordon Geko
    Accolades checklist: https://bit.ly/FLUFFYS
  • Options
    pottsey5gpottsey5g Member Posts: 4,177 Arc User
    edited August 2019
    trekpuppy wrote: »
    Thought i'd try aTracert whilst the game is down for maintenance and the 93.191.173.11 i.p again has high returns

    The game is not communicating with that node - it's sending data through it. If the node added a large latency to data sent through it you would have had the same high latency on the nodes behind it since traceroute shows the ackumulated latencies for each hop and this is not what your traceroute shows. You have a perfectly normal latency to the gameserver.
    I keep hearing that but why is it when that node has problems the game gets unplayable? As that node gets a slower response time the lag and rubberbanding get worse. Also that node at its worse often when its in the 1000ms+ range drops game packets. There seems to be a relationship between game lag and that node. It might not be the only cause but it looks like its part of the problem.
  • Options
    trekpuppytrekpuppy Member Posts: 446 Arc User
    pottsey5g wrote: »
    trekpuppy wrote: »
    Thought i'd try aTracert whilst the game is down for maintenance and the 93.191.173.11 i.p again has high returns

    The game is not communicating with that node - it's sending data through it. If the node added a large latency to data sent through it you would have had the same high latency on the nodes behind it since traceroute shows the ackumulated latencies for each hop and this is not what your traceroute shows. You have a perfectly normal latency to the gameserver.
    I keep hearing that but why is it when that node has problems the game gets unplayable? As that node gets a slower response time the lag and rubberbanding get worse. Also that node at its worse often when its in the 1000ms+ range drops game packets. There seems to be a relationship between game lag and that node. It might not be the only cause but it looks like its part of the problem.

    I don't have the means to verify such a correlation with any statistical and empirical confidence but I'm not saying it can't be true.

    However, let me point out some information that actually has been acknowledged by Cryptic themselves. Twice, as far as I know, they have admitted that parts of their server software has obnoxiously high cpu utilization. A couple of years ago the problem spurred some major reworking of how several mechanics worked in the game. Just a couple of weeks ago they did the same thing albeit the scope wasn't as big this time. Assuming they run their game with a normal server host, they're likely running on cpus with dozens of cores but with a low frequency as is normal in datacenters. Scaling a game properly over multiple cores is difficult work if not impossible. Consider for a while what will happen if they do it the straightforward and cost efficient way and let one core run one instance. It would scale well over the game as a whole but you could easily saturate a single core with a busy instance. Cryptic's constant lowering of populations in instances (as recently as Risa on the first week of the summer event) is a factor that makes me believe this is a serious culprit and at least a contributing factor to the lag we experience.

    Wherever the problem lies, none of us can determine the cause from the client side alone since there are no tools that can access the intermediate hardware in the way needed. Ultimately this is Cryptic's problem because they are delivering a service and need to make sure the quality of that service is high enough not to lose customers and income. It naturally means they have to optimize their server code to reduce bottlenecks but they also need to pay attention to what service provider they rely on to distribute their service so it doesn't lower the overall perceived quality. As customers we can only speak with our wallets.
    ---
    "-Grind is good!" --Gordon Geko
    Accolades checklist: https://bit.ly/FLUFFYS
  • Options
    ussvaliant#6064 ussvaliant Member Posts: 1,006 Arc User
    trekpuppy wrote: »
    However, let me point out some information that actually has been acknowledged by Cryptic themselves. Twice, as far as I know, they have admitted that parts of their server software has obnoxiously high cpu utilization. A couple of years ago the problem spurred some major reworking of how several mechanics worked in the game. Just a couple of weeks ago they did the same thing albeit the scope wasn't as big this time. Assuming they run their game with a normal server host, they're likely running on cpus with dozens of cores but with a low frequency as is normal in datacenters. Scaling a game properly over multiple cores is difficult work if not impossible. Consider for a while what will happen if they do it the straightforward and cost efficient way and let one core run one instance. It would scale well over the game as a whole but you could easily saturate a single core with a busy instance. Cryptic's constant lowering of populations in instances (as recently as Risa on the first week of the summer event) is a factor that makes me believe this is a serious culprit and at least a contributing factor to the lag we experience.

    I can agree the game is poorly optimised in certain areas. I remember a couple years back they broke Dyson Battlezone where it would cause my PC's memory to spike and crash me to desktop when in that zone.

    I would also say the huge amount of graphic spam especially in space during combat must tax machines and i'd like to see that addressed at some point.

    However there def is some networking issues as I can beam into SFA/ESD/DS9/Qo'nos or the Klingon Academy and rubberband just trying to get across the map in instances as low as 2/3 people in them.
    maR4zDV.jpg

    Hello rubber banding my old friend, time to bounce around the battlezone again, where are all my bug reports going?, out of love with this game I am falling, As Cryptic fail to acknowledge a problem exists, Shakes an angry fist, And from Support all I'm hearing are the sounds of silence.
  • Options
    trekkiejedigirl#9564 trekkiejedigirl Member Posts: 163 Arc User
    edited August 2019
    Uh-Oh, its them darn squirrels again!

    To the OP:
    Seriously I had the same problem not too long ago and long story short, as it turned out squirrels had been chewing on my line from the pole to my house. Which, in turn allowed water to get in it and I had rubber banding and server disconnects from hell. Once line was replaced Bingo, end of problem. In addition the tech found a filter in my line that is no longer used further messing things up. I tell you it surprised me immensly how these critters can cause sooooo much trouble with internet services especially where gaming is affected.
    Hey it's worth looking into.

    To all:
    I agree this placing blame game has to stop. I've had several instances over the years where I've had to file tickets and/or contact cryptic. And they have always been the most curtious and helpful ppl I've ever dealt with and they stayed with me until the issue was solved. So how about we stop placing blame and really try and post some helpful suggestions for the OP K? Just a suggestion. :)
  • Options
    evilspokevilspok Member Posts: 51 Arc User
    trekpuppy wrote: »
    evilspok wrote: »
    3 15 ms 16 ms 18 ms 10.196.48.1
    4 35 ms 13 ms 13 ms ten0-0-0-1.orld36-ser1.bhn.net [72.31.223.70]
    5 16 ms 18 ms 19 ms bundle-ether21.orld11-car1.bhn.net [71.44.60.120]
    6 29 ms 18 ms 18 ms 72-31-220-174.net.bhntampa.com [72.31.220.174]
    7 20 ms 23 ms 21 ms 72-31-188-170.net.bhntampa.com [72.31.188.170]
    8 29 ms 35 ms 33 ms 216.156.105.65.ptr.us.xo.net [216.156.105.65]
    9 36 ms 33 ms 33 ms 207.88.13.103.ptr.us.xo.net [207.88.13.103]
    10 52 ms 45 ms 48 ms 216.156.104.22.ptr.us.xo.net [216.156.104.22]
    11 46 ms 48 ms 48 ms po110.bs-a.sech-mia4.netarch.akamai.com [23.57.103.243]
    12 * * * Request timed out.
    13 48 ms 48 ms 48 ms ae120.access-a.sech-mia4.netarch.akamai.com [23.57.103.249]
    14 * * * Request timed out.
    15 67 ms 80 ms 62 ms a209-200-171-102.deploy.static.akamaitechnologies.com [209.200.171.102]
    16 74 ms 71 ms 65 ms 198.49.243.237
    17 57 ms 58 ms 58 ms patchserver.crypticstudios.com [208.95.184.200]

    Trace complete.

    Minus my own IP address, this also confirms that the issue is with akamai servers. As mentioned at the beginning of the thread, this is supposedly a "security server that Cryptic sends all data though which is causing problems for a large amount of players."

    If this is the case, how do we move on from here or address this?

    This is an example of a perfect traceroute with no indications of errors anywhere. Every node that is configured to respond to traceroute's probes does so on each of the three attempts. Latencies are low and stable, increasing slightly the further away the node is from you, as expected. What in this do you mean shows an error?

    Well, because of the 2 timeouts that seem to be associated with the akamai servers discussed earlier in the thread.
    However, let's go with your conclusion that it is a "perfect traceroute with no indications of errors anywhere" this traceroute is a very consistent result on my end, which only leads me to the conclusion that it is a problem on THEIR end.
  • Options
    ltminnsltminns Member Posts: 12,569 Arc User
    Funny, when I first ran into Akamai years ago, before I knew, I always assumed they were 'legitimate spam' servers. Things like Wild Tangent and the like. :)
    'But to be logical is not to be right', and 'nothing' on God's earth could ever 'make it' right!'
    Judge Dan Haywood
    'As l speak now, the words are forming in my head.
    l don't know.
    l really don't know what l'm about to say, except l have a feeling about it.
    That l must repeat the words that come without my knowledge.'
    Lt. Philip J. Minns
  • Options
    trekpuppytrekpuppy Member Posts: 446 Arc User
    evilspok wrote: »
    trekpuppy wrote: »
    This is an example of a perfect traceroute with no indications of errors anywhere. Every node that is configured to respond to traceroute's probes does so on each of the three attempts. Latencies are low and stable, increasing slightly the further away the node is from you, as expected. What in this do you mean shows an error?

    Well, because of the 2 timeouts that seem to be associated with the akamai servers discussed earlier in the thread.
    However, let's go with your conclusion that it is a "perfect traceroute with no indications of errors anywhere" this traceroute is a very consistent result on my end, which only leads me to the conclusion that it is a problem on THEIR end.

    The timeouts are not an indication of error. Just nodes configured not to respond to traceroute probes and as such you will never get a reply from them. They still do the work they're intended for - forwarding data to other routers. If they hadn't done that you wouldn't have gotten a response from anything behind those nodes.

    ---
    "-Grind is good!" --Gordon Geko
    Accolades checklist: https://bit.ly/FLUFFYS
  • Options
    evilspokevilspok Member Posts: 51 Arc User
    trekpuppy wrote: »
    evilspok wrote: »
    trekpuppy wrote: »
    This is an example of a perfect traceroute with no indications of errors anywhere. Every node that is configured to respond to traceroute's probes does so on each of the three attempts. Latencies are low and stable, increasing slightly the further away the node is from you, as expected. What in this do you mean shows an error?

    Well, because of the 2 timeouts that seem to be associated with the akamai servers discussed earlier in the thread.
    However, let's go with your conclusion that it is a "perfect traceroute with no indications of errors anywhere" this traceroute is a very consistent result on my end, which only leads me to the conclusion that it is a problem on THEIR end.

    The timeouts are not an indication of error. Just nodes configured not to respond to traceroute probes and as such you will never get a reply from them. They still do the work they're intended for - forwarding data to other routers. If they hadn't done that you wouldn't have gotten a response from anything behind those nodes.

    Understandable.

    Except that over multiple pc's, locations, providers and years I've had disconnects and lag, and apparently there is nothing I can do about it except wait for someone else to decide it's an issue. I assume most people aren't as patient as me.
  • Options
    trekpuppytrekpuppy Member Posts: 446 Arc User
    edited August 2019
    evilspok wrote: »
    trekpuppy wrote: »
    evilspok wrote: »
    trekpuppy wrote: »
    This is an example of a perfect traceroute with no indications of errors anywhere. Every node that is configured to respond to traceroute's probes does so on each of the three attempts. Latencies are low and stable, increasing slightly the further away the node is from you, as expected. What in this do you mean shows an error?

    Well, because of the 2 timeouts that seem to be associated with the akamai servers discussed earlier in the thread.
    However, let's go with your conclusion that it is a "perfect traceroute with no indications of errors anywhere" this traceroute is a very consistent result on my end, which only leads me to the conclusion that it is a problem on THEIR end.

    The timeouts are not an indication of error. Just nodes configured not to respond to traceroute probes and as such you will never get a reply from them. They still do the work they're intended for - forwarding data to other routers. If they hadn't done that you wouldn't have gotten a response from anything behind those nodes.

    Understandable.

    Except that over multiple pc's, locations, providers and years I've had disconnects and lag, and apparently there is nothing I can do about it except wait for someone else to decide it's an issue. I assume most people aren't as patient as me.

    It's in Cryptic's interest to resolve this regardless of where the problem lies since it affects the perceived quality of their service, which in the end translates to a worse or better revenue for them. I can only speculate over what business decisions are behind their stonewalling and I'll refrain from that since it's not constructive.
    ---
    "-Grind is good!" --Gordon Geko
    Accolades checklist: https://bit.ly/FLUFFYS
This discussion has been closed.