Re: Congestion Apex Legends

Been there done that, didn’t change the outcome of getting Congestion, no offense but I clearly stated that in my post. 

It’s clearly on your end!!!! I don’t have this problem with any other game. It’s not on my end nor my ISP’s end. 

---

@TR_SnakeShot wrote:

Been there done that, didn’t change the outcome of getting Congestion, no offense but I clearly stated that in my post. 

---

You're totally right. That was absent-minded of me. Would it be possible to grab a UO Trace so we can take a look? That gives us a detailed look at the connection between your PC and our servers, so if there's something happening along the way we should be able to spot it. You can find more info on how to gather the UO trace over at the Connection Troubleshooting page on the EA Help site. 

The results of the trace will have your IP address visible, so if you'd like to send them to me in a private message that would be OK. Thanks!

/Kent

EDIT: Posting a third time, this post is helpful for anyone unfamiliar with networking and the UO Tool.  If I edit my post too many times, it is marked as spam so this will be the last edit on this post.

Basically the tool is doing exactly what's described below.  Scroll down on the link provided and you will see instructions for running the UO tool on Mac's.  I'll save you the time and say, they don't have a tool for Mac but they do give the alternative - traceroute & pathping from the CLI.  Pathping is basically traceroute with pings to each node along the way (same as what UO tool does, only from the command line instead of a GUI).  Take the data you see from this tool with a huge grain of salt and don't exactly believe what's said about packet loss because it just isn't accurate.

@EA_Kent  What exactly does this tool do?  I raise this question because i'm concerned how anyone would get a response further upstream if 3 nodes in the middle of the path experience 100% packet loss.

Here's what I think is happening.

The UO Tool simply does two network troubleshooting functions [1] traceroute to find all the nodes from your PC to the endpoint (easo - whatever that is) and [2] ping the nodes it finds to death to supply a packet loss metric.

Why would this be a problem?  It's bad data.

Traceroute's are limited on what they can and cannot tell you, but together with other tools paints a bigger picture.  Here we see 3 nodes with packet loss, but many more nodes further upstream that are responding.  Routers have the option to participate in ICMP responses but they are not required to participate.  What this tells me is that the 3 nodes experiencing 100% packet loss simply have that feature turned off.

Why do I think it uses traceroute?  For starters, because the tool is old and the data received mirrors that of a traceroute.  100% is 100% and if it was truly dropping every single packet, you would never receive a reply from anything upstream of that node.  If a node has ICMP responses turned off, it would mimic that of 100% packet loss but you would then see responses from nodes upstream that do reply to ICMP responses (which is what we see in the picture provided by @TR_SnakeShot.

Why do I think it uses ping?  Because it allows you to build up a packet count.  Generally traceroute is a few packets and then it moves on, here we see the ability to continuously build a packet-loss metric, likely because it is using ping continuously and averaging the responses.

Why is this also a problem?  It's bad data.

Ping has the same flaw that traceroute does, it has the option of responding to ICMP packets but it is not required to participate.  Meaning, you will see 100% packet loss, because it threw every packet away. Combine this with the data from the image and we see responses further upstream, again, how would you get a response beyond a node that is experiencing 100% full packet loss?

Another reason it's a problem?  The definition under packet-loss in your link isn't wrong, but it's pretty much the de facto standard of IT deflecting any issue away from yourself first which is exactly what we do in IT.  The other problem I have is that it completely ignores results other than 100%, which is a flaw in itself.  Basically it's saying - if you have anything other than 100% call your ISP, it's their problem.  But as explained above, that's clearly not the case all of the time and it's also not unheard of for engineers to turn off ICMP replies on their devices.

The bigger picture: The UO tool is likely just giving you compounding bad data if it is using traceroute and ping as the source of it's data.  This tool is likely a red herring in this scenario and while it shouldn't be completely disregarded.

Good Stuff: A usable endpoint!!  Since we have no easy way of determining the exact servers we're connecting to, at least now we have a starting point (easo).  It also shows the majority of the path along the way, which can be useful.

What I would ask:  What's the difference, application wise, between running traditional Apex (via ranked or unranked gameplay) or running the Winter Express mode?  There was no packet loss during winter express, but disconnects and packet loss for traditional modes.

Disclaimer: This is all specific to @TR_SnakeShot's issue, for anyone else experiencing similar issues - I'd be happy to help take a look at what you have, just message me!  I have 10+ years in networking so this is my day-to-day.  Also, I don't work for EA either so I won't cut corners around my responses.

EDIT:  I decided to go a step further and show how this data can be deceiving by running the same instructions listed for Mac users on the UO Tool website on my own PC.  Please note that the network is separate from your OS so it does not matter which OS you are using, the tool is the same and the results will be the same.  In addition, please note that I do not have issues playing Apex.  Notice how my traceroute makes it all the way to the destination, but my pathping dies?  There's really nothing to conclude about the data other than it's just not good data.