Understood it is hard to fix or control from your end. Just keep in mind:This has been brought up with the same response I gave in IRC: "we can't do anything".
As the connection failure happens at a step that's outside the actual RoM server or your ISP, there is little ANY of us can do, especially considering the packet loss occurs more towards the server side but not at the server or even at the datacenter hosting the RoM servers. The best we can do is forward to the IT folks that some are experiencing packet loss (we HAVE done this) and hope for the best, but it'll probably be a "we can just wait until it blows over like any routing failure on the internet can do".
Ignore it and maybe it will go away? THATs the strategy? Really? Can we at least pretend we care a bit more about the people playing RoM in the US? If this was occurring on the DE servers it would have been fixed by now or at the very least we would have a bunch of blue posts saying they are working it.This has been brought up with the same response I gave in IRC: "we can't do anything".
As the connection failure happens at a step that's outside the actual RoM server or your ISP, there is little ANY of us can do, especially considering the packet loss occurs more towards the server side but not at the server or even at the datacenter hosting the RoM servers. The best we can do is forward to the IT folks that some are experiencing packet loss (we HAVE done this) and hope for the best, but it'll probably be a "we can just wait until it blows over like any routing failure on the internet can do".
Ignore it and maybe it will go away? THATs the strategy? Really? Can we at least pretend we care a bit more about the people playing RoM in the US? If this was occurring on the DE servers it would have been fixed by now or at the very least we would have a bunch of blue posts saying they are working it.This has been brought up with the same response I gave in IRC: "we can't do anything".
As the connection failure happens at a step that's outside the actual RoM server or your ISP, there is little ANY of us can do, especially considering the packet loss occurs more towards the server side but not at the server or even at the datacenter hosting the RoM servers. The best we can do is forward to the IT folks that some are experiencing packet loss (we HAVE done this) and hope for the best, but it'll probably be a "we can just wait until it blows over like any routing failure on the internet can do".

|
|
Source code |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
|------------------------------------------------------------------------------------------| | WinMTR statistics | | Host - % | Sent | Recv | Best | Avrg | Wrst | Last | |------------------------------------------------|------|------|------|------|------|------| | 192.168.2.101 - 0 | 381 | 381 | 0 | 0 | 0 | 0 | | c-67-184-220-1.hsd1.il.comcast.net - 0 | 381 | 381 | 8 | 12 | 27 | 12 | |te-0-3-0-12-sur03.mchenry.il.chicago.comcast.net - 0 | 381 | 381 | 9 | 12 | 27 | 15 | |te-2-3-0-0-ar01.elmhurst.il.chicago.comcast.net - 0 | 381 | 381 | 10 | 15 | 33 | 12 | |he-1-6-0-0-11-cr01.seattle.wa.ibone.comcast.net - 0 | 381 | 381 | 12 | 16 | 33 | 14 | |be-10412-cr01.56marietta.ga.ibone.comcast.net - 0 | 381 | 381 | 30 | 34 | 52 | 37 | |pos-0-11-0-0-pe01.56marietta.ga.ibone.comcast.net - 0 | 381 | 381 | 30 | 36 | 77 | 34 | |as4436-1-c.56marietta.ga.ibone.comcast.net - 0 | 381 | 381 | 29 | 37 | 98 | 32 | | ae4-69.atl11.ip4.gtt.net - 0 | 381 | 381 | 29 | 35 | 79 | 36 | | xe-0-2-3.mia12.ip4.gtt.net - 0 | 381 | 381 | 42 | 45 | 60 | 44 | | gtt-gw.ip4.gtt.net - 0 | 381 | 381 | 42 | 48 | 82 | 64 | | vl901-ibr4.vaultnetworks.com - 1 | 377 | 376 | 0 | 45 | 114 | 46 | | car4.te1-1.v944.vaultnetworks.com - 1 | 377 | 376 | 0 | 46 | 104 | 47 | | 206.253.171.6 - 1 | 377 | 376 | 0 | 46 | 66 | 43 | | 206.253.173.50 - 0 | 381 | 381 | 42 | 45 | 93 | 46 | |________________________________________________|______|______|______|______|______|______| WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider |
|
|
Source code |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
|------------------------------------------------------------------------------------------| | WinMTR statistics | | Host - % | Sent | Recv | Best | Avrg | Wrst | Last | |------------------------------------------------|------|------|------|------|------|------| | 192.168.2.254 - 0 | 101 | 101 | 0 | 0 | 1 | 0 | | hlrn-dsl-gw02.hlrn.qwest.net - 0 | 101 | 101 | 27 | 44 | 239 | 28 | | hlrn-agw1.inet.qwest.net - 0 | 101 | 101 | 25 | 28 | 53 | 29 | | dvr-brdr-02.inet.qwest.net - 0 | 101 | 101 | 27 | 35 | 133 | 30 | | 63.146.26.130 - 0 | 101 | 101 | 27 | 31 | 64 | 28 | | vb2000d1.rar3.denver-co.us.xo.net - 0 | 101 | 101 | 77 | 82 | 93 | 78 | | te-4-2-0.rar3.dallas-tx.us.xo.net - 0 | 101 | 101 | 75 | 80 | 92 | 85 | | 207.88.14.158.ptr.us.xo.net - 2 | 97 | 96 | 74 | 75 | 104 | 75 | |ip67-94-116-38.z116-94-67.customer.algx.net - 0 | 101 | 101 | 75 | 81 | 91 | 78 | | border1.po2.bbnet2.mia007.pnap.net - 2 | 97 | 96 | 74 | 85 | 246 | 75 | | vaultnet-7.border2.mia007.pnap.net - 0 | 101 | 101 | 74 | 80 | 276 | 78 | | car3.te1-1.v933.vaultnetworks.com - 0 | 101 | 101 | 74 | 79 | 103 | 78 | | 206.253.171.2 - 0 | 101 | 101 | 74 | 80 | 92 | 80 | | ROM-US-WORLD1 - 0 | 101 | 101 | 74 | 80 | 127 | 76 | |________________________________________________|______|______|______|______|______|______| WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider |
This post has been edited 1 times, last edit by "Annadiana" (Dec 1st 2014, 7:51pm)