Out of Pod Experience

ib4 "just connect to the modem", wrong answer.

Earliest reply that works wins.

Specs: 2 networked computers running Win7 64x, one wired, one wireless.
Router Netgear WNR2000v3, latest firmware (issue started before I updated to latest firmware, though it has persisted through update)
TimeWarner Cable, Cleveland, OH area.

Thursday night I noticed the game started lagging and disconnecting badly. I have no idea when it started, I was autopiloting to Jita while reading a book.. thought it was just Jita lag at first. It took awhile to figure out it wasn't an issue with the server, nor an issue in my service area.

Running tracert using PingPlotter, I eventually found out I was having severe packet loss to TQ. Running another tracert to SiSi along with numerous other websites, I realized it is only this server I am having horrible packet loss with.

I checked and both computers were having the same issue, with PingPlotter showing roughly the same % of packet loss. I made sure firewall was off, and that the game wasn't inhibited by it in any way.

Then I cut out the router and plugged directly into the modem, and packet loss dropped to 0%.

I tried resetting the router, and although it reset my settings to default, the firmware stayed the same. I've tried hard resets to factory firmware but nothing happens (I've tried holding reset for 30, turning router off but plugged in for 30, and the 30-30-30 method).


Here's my tracerts for the two servers. Note that though there's high packet loss on hops 4 and 10, it doesn't affect the connection to the test server. These were very quick tracerts, 50 samples @ 1 sec each, but they have the same return as a 1500 sample @ 2.5sec run from last thursday.

And again, this is only with the router plugged in. When I'm connected directly to the modem, I have no packet loss with either server.

Smart ass replies like "Buy a new router" would get you wardec'd, except I can't log in so I'll just think bad thoughts about you.

TQ:

Target Name: srv200-g.ccp.cc
IP: 87.237.38.200
Date/Time: 7/22/2012 4:56:43 AM to 7/22/2012 4:57:33 AM

Hop Sent Err PL% Min Max Avg Host Name / [IP]
1 50 0 0.0 0 72 6 [192.168.1.1]
2 50 0 0.0 7 42 11 [10.***.***.1]
3 50 0 0.0 5 19 8 gig1-1.lksdoh1-rtr1.neo.rr.com [24.164.111.52]
4 50 20 40.0 6 113 14 tge2-0-0.clevoh1-rtr01.neo.rr.com [24.164.113.130]
5 50 0 0.0 8 14 10 tge11-0-0.ncntoh1-rtr1.neo.rr.com [24.164.118.96]
6 50 0 0.0 12 28 15 tge3-0-1.ar01.clmkohpe.mwrtn.rr.com [65.25.137.73]
7 50 0 0.0 12 48 16 ae1.tr00.clmkohpe.mwrtn.rr.com [65.189.140.128]
8 50 0 0.0 23 38 28 ae-9-0.cr0.chi30.tbone.rr.com [107.14.19.16]
9 50 0 0.0 23 81 29 [107.14.17.147]
10 50 23 46.0 23 53 27 [66.109.11.18]
11 50 0 0.0 22 55 28 xe-1-3-0.cr2.ord2.us.above.net [64.125.30.146]
12 50 0 0.0 29 67 36 xe-2-0-0.cr2.lga5.us.above.net [64.125.24.29]
13 50 0 0.0 30 45 33 ge-1-2-0.mpr2.lga5.us.above.net [64.125.29.58]
14 50 0 0.0 97 165 101 so-3-0-0.mpr1.lhr3.uk.above.net [64.125.28.65]
15 50 0 0.0 98 273 115 213-152.240-254.PXu259.above.net [213.152.240.254]
16 50 0 0.0 99 259 116 srv245-e.ccp.cc [87.237.36.245]
17 50 0 0.0 99 116 102 srv248-e.ccp.cc [87.237.36.248]
18 50 23 46.0 99 212 115 srv200-g.ccp.cc [87.237.38.200]


SiSi:

Target Name: srv50-g.ccp.cc
IP: 87.237.38.50
Date/Time: 7/22/2012 4:43:52 AM to 7/22/2012 4:44:41 AM

Hop Sent Err PL% Min Max Avg Host Name / [IP]
1 50 0 0.0 0 4 0 [192.168.1.1]
2 50 0 0.0 5 14 7 [10.***.***.1]
3 50 0 0.0 5 13 8 gig1-1.lksdoh1-rtr1.neo.rr.com [24.164.111.52]
4 50 26 52.0 5 103 18 tge2-0-0.clevoh1-rtr01.neo.rr.com [24.164.113.130]
5 50 0 0.0 8 15 10 tge11-0-0.ncntoh1-rtr1.neo.rr.com [24.164.118.96]
6 50 0 0.0 12 57 16 tge0-0-1.ar01.clmkohpe.mwrtn.rr.com [65.25.137.193]
7 50 0 0.0 12 42 17 ae0.tr00.clmkohpe.mwrtn.rr.com [65.189.140.142]
8 50 0 0.0 24 35 28 ae-9-0.cr0.chi30.tbone.rr.com [107.14.19.16]
9 50 0 0.0 22 69 27 [107.14.17.147]
10 48 27 56.3 23 71 27 [66.109.11.18]
11 50 0 0.0 23 65 27 xe-2-1-0.cr2.ord2.us.above.net [64.125.26.253]
12 50 0 0.0 23 193 31 xe-1-0-0.cr1.ord2.us.above.net [64.125.28.237]
13 50 0 0.0 34 65 38 xe-3-0-0.cr1.lga5.us.above.net [64.125.24.37]
14 50 0 0.0 101 204 108 ge-2-1-0.mpr1.lhr3.uk.above.net [64.125.26.38]
15 50 0 0.0 101 453 124 213-152.240-254.PXu259.above.net [213.152.240.254]
16 50 0 0.0 103 636 128 srv245-e.ccp.cc [87.237.36.245]
17 50 0 0.0 103 112 105 srv248-e.ccp.cc [87.237.36.248]
18 50 0 0.0 103 133 106 srv50-g.ccp.cc [87.237.38.50]

Sorry to say; but this is an interesting problem...

Also,I do doubt that your router specifically dislikes Tranquility and nothing else; but for now I'll trust your analysis and play along :)

Did you try to only power on one of the computers behind the router?
Is anything funny with the Local IP you get when behind the router?
If so, do you have an LSP in your stack that kicks in then? From. My experience, the vast majority of wierdconnection problems people have are from LSPs that are buggy, from viruses or certain personal firewalls. "netsh winsock reset" is a good start.

Long shot, but a first step.

Second step; try using a VPN/anonymizer service.

And good luck!

Both tracerts have package lost to 66.109.11.18. Looks like a routing problem on ISP/Carrier site. Similar problems occur due to bad peering/transfers on exchange nodes. I think the explanation why SiSi works and TQ doesn't might be in the amount of data transfered. Due to the loss rate maybe important data is missing which couldn't be send within the timeout limit, while on SiSi the server has not a huge load and can more easily deal with resending TCP packages (you will probably get disconnects cduring SiSi mass testing).

My recommendation:
Have a server in the US to which you usually dont have any package lost. Server should be not using the same ISP in the same region. Use SSH tunneling or other forms of proxy to tunnel the data and circumvent the routing problems. SSH tunneling for eve is described in http://www.eve-wiki.net/index.php?title=EVE_via_an_SSH_tunnel

Have you tried adjusting the MTU size on the router? The MTU size on your computer may match the modem's setting, but if the router's setting is different it may cause packet loss.

I use an MTU size of 1458 on my Netgear router.

There have been reports of some ISP's treating traffic to and from TQ as Torrent traffic and they end up "shaping" it. You could try contacting your ISP to find out if this is the case.

try disabling HPET

I do PC/Network repair (not professionally, on the side) and live just south of cleveland. I can come take a look once I get my rear bearings replaced.

Or you could try throwing your PC in the DMZ. If that works, you have a firewall blocking traffic and/or incorrect port forwarding.

And honestly, as long as you 'know what you're doing' on the internet, there is no need for firewalls. 8 years DMZ + No firewall, 8 years spam/mal/adware free. No identity compromises. Nothing.

Edit: Ive even got a spare router I can bring that 'should' work.

The switching section of the router might have gone bad. I have seen switches do this and have trouble-shot them out by bypassing them. You can get a connection, but packet loss and speed suffer.

I recommend you attempt a new router, but before you do that, bypass it. When the trouble occurs, plug one of your systems zirecrtly to modem and see if it persists. if so, your router might be on its way out. In almost every case I have seen of router death, the switch went first.

Just want to point out a couple things that might help you in the future. This falls under "top 10 most misunderstood things on the internet"

Traceroute is effective for showing a path, but you can't see loss on one particular hop and think you actually have packet loss to that point.

If I'm traveling 10 hops, and I'm getting bad packet loss at say, hop 5, that packet loss (if real) will propagate through all consecutive hops.

Nothing about removing your router from the equation should change anything about this, because when you usually see isolated "packet loss" on a particular hop/hops and then see the path pick back up again no problem, this is usually the device on that hop/hops metering their ICMP (ping/tracert) replies to you (or blocking them altogether, which is very common)

So in short, if you can trace to the server, and better yet, if you can open a dos prompt and ping x.x.x.x -t to the tranq server and not see any significant (greater than 1%) loss to the server, the issue isn't on your route path.

In light of a good route path I'd say a port is getting blocked somewhere or someone is doing something with your traffic that they shouldn't be. And all that's providing you've eliminated your equipment from the equation... which since you can jack into your modem and see no issues, I'd say you've isolated the fault to your router.

Or incorrect settings on the router itself. I had an issue with my wireless once and for the life of me couldn't figure it out. Finally realized I had the wrong frequency set. Another time I thought someone was leeching of my wireless, so I disabled it, and still had crap latency. Come to find out, I somehow had set up QoS unintentionally. Turned it off, everything was back to normal.