canadian poe server problem

"

Robilar a écrit :

Drakier I have noticed your posts in many threads on this issue, I think you are a little confused with what is going on so let me highlight with the last posted WinMTR here

router.asus.com - 0 | 1049 | 1049 | 0 | 0 | 8 | 0 |
| 192.168.0.1 - 0 | 1048 | 1048 | 1 | 1 | 5 | 1 |
| No response from host - 100 | 210 | 0 | 0 | 0 | 0 | 0 |
| rd3st-tge0-12-0-14-1.vc.shawcable.net - 0 | 1049 | 1049 | 9 | 17 | 574 | 12 |
| rc2wh-tge0-14-0-12.vc.shawcable.net - 0 | 1049 | 1049 | 8 | 21 | 477 | 16 |
| rc2bb-tge0-13-0-6.vc.shawcable.net - 0 | 1047 | 1047 | 9 | 17 | 448 | 12 |
| 66.163.75.98 - 0 | 1048 | 1048 | 32 | 44 | 579 | 38 |
| te1-7.bbr01.eq01.sjc01.networklayer.com - 0 | 1049 | 1049 | 42 | 49 | 608 | 47 |
| ae7.bbr02.eq01.sjc02.networklayer.com - 0 | 1048 | 1048 | 32 | 41 | 573 | 33 |
| ae0.bbr02.cs01.lax01.networklayer.com - 0 | 1047 | 1047 | 38 | 46 | 519 | 41 |
| ae7.bbr01.cs01.lax01.networklayer.com - 0 | 1049 | 1049 | 39 | 47 | 526 | 44 |
| ae19.bbr01.eq01.dal03.networklayer.com - 2 | 982 | 965 | 70 | 82 | 577 | 72 |
| ae0.dar01.sr01.dal01.networklayer.com - 2 | 1002 | 990 | 70 | 84 | 560 | 72 |
| po1.fcr05.sr06.dal01.networklayer.com - 0 | 1047 | 1047 | 70 | 79 | 580 | 75 |
| patch101.pathofexile.com - 2 | 982 | 965 | 74 | 85 | 559 | 76 |

the bolded section is where the packet loss is, as you can see from start(players home) up until you hit the Dallas server hub ae19.bbr01.eq01.dal03.networklayer.com everything is fine, this is most likely where GGG has a server and coming from the East the problem starts in Chicago te1-7.bbr01.eq01.chi01.networklayer.com
So please stop trying to tell everyone that it is their internet connection as clearly it is not

First, I never said anything was wrong with THEIR internet... I said something was wrong with THE internet... IE: something going on in the routing between users in canada/eastern US and the GGG network.

That said, you also don't know how to read a trace properly. The outlined hops don't actually show a necessary problem. See how 1049 packets were sent/received from the first node... then look at the second to last node... 1047... that's almost 1049. That means that the 2 nodes before it (with the perceived packet loss) were NOT actually dropping packets.. If they had dropped the packets, then the node afterward wouldn't have sent/received 1047 packets. The sent might be the same, but the received would be much less (based on the prior two nodes).

That is a common misconception by people untrained in reading these traces. Just because it said there was 2% packet loss on a node or two, does NOT mean that there was ACTUAL packet loss.. more than likely, it is data mitigation and dropping ICMP (low priority) packets addressed to itself.

Think of it like this... lets say you have 10 friends all standing in a line. Now, you address an envelope to each friend individually, then hand them to the friend closest to you in line. The first friend takes his envelope off the stack, then hands the rest of the envelopes to the person next to them. This continues through the whole line. Now... each of those friends puts your name on an envelope, then hands it to the person next to them up the line (reverse of what was just sent). This is a standard ping.

Now lets say that some of these friends decided not to send a reply back because they're too important to send a letter back... but they stil continue to pass the letters back and forth. They just take the envelopes addressed to themselves, and dump them... while continuing to pass the rest of them properly. This is what you're seeing happening with these nodes (mostly).

If it was REAL packet loss, what would happen is that these friends would just not pass anything past them. They'd simply just trash-bin every envelope that they touched... whether it was addressed to them or not.

Now hopefully you can see how one of them is an ACTUAL issue, and the other is just an issue with replying to your request. Replying to a request doesn't actually prohibit the network from operating properly and getting packets sent back and forth. Same with NOT replying to a request. What DOES impact the network however is just dropping every packet that comes through you.

This isn't what is happening.

Chris and NetworkLayer are working on diagnosing the issue further. Just be patient and wait for them to figure it out

But I'd also recommend learning what it is you're talking about before attempting to call someone out about it. It's never a good idea to call someone out on a topic unless you're more knowledgable about the topic than they are and you are 100% certain you are correct. I hope I have enlightened you to how to properly read a trace so you won't make the same mistake next time.

Cheers.