Latency issues after Heist announcement
|
did you try this -->
https://www.pathofexile.com/forum/view-thread/2898400 |
|
|
Reboot did not change anything as expected.
I did not know about this gateway. I will try it out and keep you updated. |
|
|
I could log in to the Canada gateway. Between 30 and 50ms. Much better. The game feels as usual.
Thanks for your help. |
|
|
Still lagging hard, but not as often.
Pretty noticeable, since the game pushes me meters to where i was seconds ago. Any fix date fr this? It's starting to affect gameplay really bad. |
|
" You keep breaking forum guidelines in the way you are posting here.... Please stop this or you risk that GGG take action against your account. |
|
|
Holy cow, this is like Evolve the game. First we blame patches for bad performance, now it's announcements? What's next? Bex makes a post and someone's FPS halves?
No rest for the wicked.
|
|
" well the biggest problem must still be that he doesn't follow any forum guidelines for posting in tech or bug section of the forum...... |
|
|
By "since announcement" I meant patch that came with the said announcement. This is when I noticed the problem. I know an announcement can't cause a bug.
But I don't mind the other guy posting in my thread. Don't ban him for that. He was just trying to get help for his issue. |
|
|
2020/09/09 11:16:12 7158203 103 [INFO Client 10900] Connecting to instance server at 158.176.145.143:6112
2020/09/09 11:16:12 7158234 1bd [DEBUG Client 10900] Connect time to instance server was 31ms MTR to 158.176.145.143 |------------------------------------------------------------------------------------------| | WinMTR statistics | | Host - % | Sent | Recv | Best | Avrg | Wrst | Last | |------------------------------------------------|------|------|------|------|------|------| | 192.168.1.254 - 0 | 82 | 82 | 0 | 0 | 0 | 0 | | 10.226.128.1 - 0 | 82 | 82 | 12 | 22 | 6 | 11 | | telepac14-hsi.cprm.net - 0 | 82 | 82 | 8 | 10 | 31 | 18 | | lis2-cr1-bu10-200.cprm.net - 0 | 82 | 82 | 2 | 4 | 19 | 4 | | lon3-cr1-be3.cprm.net - 0 | 82 | 82 | 30 | 33 | 65 | 31 | | bbr01.lon01.networklayer.com - 2 | 79 | 78 | 29 | 31 | 65 | 38 | | ae5.cbs01.tg01.lon01.networklayer.com - 61 | 23 | 9 | 0 | 31 | 36 | 32 | | ae0.dar01.lon06.networklayer.com - 0 | 82 | 82 | 30 | 33 | 67 | 31 | | 83.76.b09e.ip4.static.sl-reverse.com - 0 | 82 | 82 | 30 | 33 | 66 | 33 | | 9f.76.b09e.ip4.static.sl-reverse.com - 0 | 82 | 82 | 30 | 32 | 66 | 31 | | 8f.91.b09e.ip4.static.sl-reverse.com - 0 | 82 | 82 | 30 | 32 | 66 | 31 | |________________________________________________|______|______|______|______|______|______| WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider Also, although this excuse might be applied often correctly, ICMP applies to slow-paths and packet policies, all within layer 3. For this to be the case, your ISP should not see any CER/CCER on your part. A slow path is not a broken path. My ISP network has no active DPI's on this traffic. Furthermore, once the packet leaves your ISP network, it's not their issue. The affected hop appears obvious on ae5.cbs01.tg01.lon01.networklayer.com. This is not the first thread i see about this. Nor the same "treatment". MercilessOnslaught, thx. |
|
" So first you are told to do a WinMTR of minimum 300 packets and better still 500 packets. You did 82 = pretty useless. Also regarding packet loss, then if it really would be packet loss at the node with 61% then ALL the packets after that node should be lost. Since it's not the case, then we are talking about a device with icmp prioritization policy active. |
|
