any knowledgeable volunteers to take a quick look at a log for me issues with an online game provider they keep blaming our ISP our ISP blames them Thanks Andy. asked 03 Mar '14, 10:51  Andy Taylor edited 03 Mar '14, 16:04  Kurt Knochner ♦ |
One Answer:
canopy? Are you sure it's not your wireless connection that has way too high latency for online gaming !?! 42 ms to google is not what I would call good/fast. Even on my worst internet connection I still get 15 ms to google (well, they do geo balancing, so that's not really comparable to your values). And 155 ms to the target server is probably too much latency for that specific online game !?! Anyway: What is the RTT (ping time) you get to the nearest hop, directly 'after' the canopy link? Regards answered 03 Mar '14, 16:09 Kurt Knochner ♦ Hi Kurt thanks for your time first and foremost, I am really sure it's not at our end, they love blaming the end user. If I test with say Speedtest we get returns of 42 ms, however from Kixeye returns come back at over 140 (varies between 185 avg 150 min and 185 max ATM) . If we ping say Google, Yahoo show the same 42 MS but the way KOS has it set up it is shown as a peering point the connection between the tower point and what I'm sure is Bell's Internet infrastructure,as Kingston Online subs out their services, does not show . If I return to Yahoo or Google or a major IP it's always 42 or lower. We do however using a packet logger get tons of keep Stay alive acks and this message in red in the logger: 273 8.194927000 192.168.1.137 64.74.130.75 TCP 54 venus-se > https [RST] Seq=746986586 Win=0 Len=0 272 8.194913000 64.74.130.75 192.168.1.137 TCP 54 [TCP ACKed unseen segment] https > venus-se [ACK] Seq=1 Ack=746986586 Win=12672 Len=0 461 9.375984000 192.168.1.137 63.251.19.21 TCP 66 [TCP Dup ACK 444#1] venus > https [ACK] Seq=1533 Ack=4495 Win=65536 Len=0 TSval=192566 TSecr=952753794 these are coming in in black & red in the log. Andy. (03 Mar '14, 16:30) Andy Taylor That's a sign for packet loss. However with only a capture at the client, you won't be able to figure out where the packet loss occurs. It could be the local network, the canopy link, 'the Internet' or the target server. (03 Mar '14, 16:45) Kurt Knochner ♦ One way to get a better global view is to check a few looking glasses (http://www.bgp4.as/looking-glasses). 150ms might not be the cause of your performance problems, and to be honest I don't think it is. I'm actually seeing packet loss when doing extended pings from a few different ISPs. For example, from route-views.oregon-ix.net: Sending 5, 100-byte ICMP Echos to 64.74.130.75, timeout is 2 seconds: !.!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 256/286/368 ms route-views>ping 64.74.130.75 Followed a few minutes later by: Sending 5, 100-byte ICMP Echos to 64.74.130.75, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 24/24/24 ms That might be something local to them though, since LG's like route-server.cbbtier3.att.net and route-server.ip.att.net showed no packet loss at the time that that one did. I suggest you do traces and pings across a distribute set of looking glasses when you get this performance issue on your game (assuming this is intermittent?). If you can map out multiple ISPs with measurable performance issues toward them that could help pinpoint the problem. (03 Mar '14, 21:18) Quadratic Thanks a ton I'll do that there are a bunch of packets coming in with invalid checksums and being re-requested I'm seeing using capsa so I will look into it.the info from the capsa reports are much easier for a newb to understand. Thanks Again, Andy. (06 Mar '14, 09:37) Andy Taylor can you post a sample capture file, that contains both the frames with invalid checksum and the 're-requested' ones (on google drive, dropbox, cloudshark.org)? (06 Mar '14, 13:16) Kurt Knochner ♦ |
what is the problem with the game?
BTW: Please add (much) more details about your environment. At least, but not limited to
lag, dropped connects, general un playability. OS win7 Ultimate
========================================================================== VisualRoute trace to bp-fb-vip.sjc2.kixeye.com ==========================================================================
This trace was started on 3-Mar-2014 6:31:22 PM. The host 'bp-fb-vip.sjc2.kixeye.com' has been found, and is reachable in 4 hops. Also, it responded to HTTP requests on port 80 (it is running server nginx/1.0.6, which responded in 3346ms). The TTL value of packets received from it is 49.In general this route offers a good throughput, with hops responding on average within 53ms. However, hop 3 in network '[Network for 64.74.130.75]' is noticeably slower than others. The DNS lookup was completed almost instantaneously (less than 2ms - this may be the result of caching).
Log snapped as text for a traceroute
on a wireless canopy 4MBS connection our ping to somewhere like google returns slowest hop is 42 seconds
We know damn well it is at their end they keep claiming it is our internet, was hoping someone could look at an actual log and tell us what is going on or give me a site where I can look up what the traffic really is.
Thanks Andy.