server latency varies between ideal and non ideal

[JKist3]

Hi,

So first of all I am not a current customer or player on nfo servers, but I am a potential customer in the somewhat distant future ( at least 6 months away, probably longer). I came across your servers while reading up on peering agreements and the way they are advertised with internap sounds awesome. I went to your site last night: http://www.nfoservers.com/networklocations.php ,hoping to see pings reflecting ideal routing. Some of the servers reflected great routing, others didn't. Not really sure what to make of it.

I currently live in Chicago and have a pretty low latency connection (I am on cogent/steadfast backbone in ~1ms).

Last night I was pinging ~20ms to your chicago test server. Wasn't really sure how this was possible from how I understand (misunderstand evidently) internap bandwidth. I created an account tonight to ask what was wrong, but my ping now shows 1ms which is what I would expect. Last night however I was pinging the Atlanta test server at 16 ms and tonight it is at 32ms. So there is clearly some inefficiency going on somewhere. I would assume this is abnormal to see such variation in pings to your servers? Any idea what could be going on?

Atlanta Test Server:
I didn't do a traceroute last night, only know that the ping was 16...

PING 64.94.238.13 (64.94.238.13) 56(84) bytes of data.

64 bytes from 64.94.238.13: icmp_req=1 ttl=54 time=32.6 ms

64 bytes from 64.94.238.13: icmp_req=2 ttl=54 time=32.4 ms

64 bytes from 64.94.238.13: icmp_req=3 ttl=54 time=32.5 ms

64 bytes from 64.94.238.13: icmp_req=4 ttl=54 time=32.5 ms

64 bytes from 64.94.238.13: icmp_req=5 ttl=54 time=32.9 ms

64 bytes from 64.94.238.13: icmp_req=6 ttl=54 time=32.6 ms

^C

--- 64.94.238.13 ping statistics ---

6 packets transmitted, 6 received, 0% packet loss, time 5007ms

rtt min/avg/max/mdev = 32.471/32.625/32.930/0.276 ms

jkist@lup-jkist01:~$ tracepath 64.94.238.13

1: lup-jkist01.local 0.128ms pmtu 1500

1: 108.160.206.1 1.082ms

1: 108.160.206.1 1.121ms

2: 172.16.1.114 18.509ms

3: 172.16.1.193 1.370ms

4: te0-0-2-3.nr11.b000368-0.ord01.atlas.cogentco.com 1.664ms

5: te0-3-0-6.agr21.ord01.atlas.cogentco.com 1.632ms

6: be2521.ccr41.ord01.atlas.cogentco.com 1.975ms

7: be2099.ccr42.atl01.atlas.cogentco.com 19.606ms

8: be2034.ccr21.atl04.atlas.cogentco.com 21.171ms

9: 38.104.182.242 33.368ms asymm 11

10: border10.tge4-1-bbnet2.acs.pnap.net 34.126ms asymm 11

11: atlanta-ventrilo.nfoservers.com 33.022ms reached



Chicago Test Server:
last night everything was ~1 or 2 ms until there was a 20ms hop to get onto the nfo server

PING 216.52.148.4 (216.52.148.4) 56(84) bytes of data.

64 bytes from 216.52.148.4: icmp_req=1 ttl=53 time=1.23 ms

64 bytes from 216.52.148.4: icmp_req=2 ttl=53 time=1.37 ms

64 bytes from 216.52.148.4: icmp_req=3 ttl=53 time=1.27 ms

64 bytes from 216.52.148.4: icmp_req=4 ttl=53 time=1.41 ms

64 bytes from 216.52.148.4: icmp_req=5 ttl=53 time=1.30 ms

64 bytes from 216.52.148.4: icmp_req=6 ttl=53 time=1.24 ms

64 bytes from 216.52.148.4: icmp_req=7 ttl=53 time=1.34 ms

^C

--- 216.52.148.4 ping statistics ---

7 packets transmitted, 7 received, 0% packet loss, time 6008ms

rtt min/avg/max/mdev = 1.239/1.313/1.411/0.063 ms

jkist@lup-jkist01:~$ tracepath 216.52.148.4

1: lup-jkist01.local 0.137ms pmtu 1500

1: 108.160.206.1 1.031ms

1: 108.160.206.1 1.106ms

2: 172.16.1.114 1.549ms

3: 172.16.1.193 1.482ms

4: te0-0-2-3.nr11.b000368-0.ord01.atlas.cogentco.com 1.658ms

5: te0-3-0-6.agr21.ord01.atlas.cogentco.com 1.669ms

6: be2522.ccr42.ord01.atlas.cogentco.com 1.946ms

7: be2005.ccr21.ord03.atlas.cogentco.com 2.218ms

8: 38.122.180.138 2.069ms asymm 10

9: border6.po1-bbnet1.chg.pnap.net 2.405ms asymm 11

10: chicago-ventrilo.nfoservers.com 2.069ms reached

[JKist3]

ok so I just rechecked the servers after writing this post. Atlanta is back to where it was last night... Any ideas what's up?


PING 64.94.238.13 (64.94.238.13) 56(84) bytes of data.
64 bytes from 64.94.238.13: icmp_req=1 ttl=54 time=16.8 ms
64 bytes from 64.94.238.13: icmp_req=2 ttl=54 time=16.9 ms
64 bytes from 64.94.238.13: icmp_req=3 ttl=54 time=17.6 ms
64 bytes from 64.94.238.13: icmp_req=4 ttl=54 time=17.3 ms
64 bytes from 64.94.238.13: icmp_req=5 ttl=54 time=17.0 ms
64 bytes from 64.94.238.13: icmp_req=6 ttl=54 time=17.1 ms
64 bytes from 64.94.238.13: icmp_req=7 ttl=54 time=17.0 ms
64 bytes from 64.94.238.13: icmp_req=8 ttl=54 time=17.0 ms
^C
--- 64.94.238.13 ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7009ms
rtt min/avg/max/mdev = 16.875/17.149/17.697/0.303 ms
jkist@lup-jkist01:~$ tracepath 64.94.238.13
1: lup-jkist01.local 0.138ms pmtu 1500
1: 108.160.206.1 1.123ms
1: 108.160.206.1 1.119ms
2: 172.16.1.114 1.660ms
3: 172.16.1.193 2.070ms
4: te0-0-2-3.nr11.b000368-0.ord01.atlas.cogentco.com 1.799ms
5: te0-3-0-6.agr21.ord01.atlas.cogentco.com 2.308ms
6: be2521.ccr41.ord01.atlas.cogentco.com 2.091ms
7: be2099.ccr42.atl01.atlas.cogentco.com 19.573ms
8: be2035.ccr21.atl04.atlas.cogentco.com 19.833ms
9: 38.104.182.242 17.986ms asymm 10
10: border10.tge3-1-bbnet1.acs.pnap.net 18.073ms
11: atlanta-ventrilo.nfoservers.com 17.702ms reached

[soja]

If your connection exclusively uses cogent, there isn't much Internap can do for you when the issue is on cogent's side. In your traces I see the ping raise inside cogent's network.

Internap chooses the best route by having numerous connections to NSPs and routing packets on the best path among those connections. As for packets coming from you, it is my understanding that Internap cannot control this.

[kraze]

Even if you are not a customer it's still ok to contact us and ask that we investigate personal routing issues to our services. It's also not uncommon for a continuous ping to show a sudden spike in latency, this is because ICMP is generally assigned a lower priority for routers and will always be thrown to the bottom of the pile if something more important comes along(real traffic, BGP update).

There's a pretty long list of items that could cause an increase in ping, so it's be hard to diagnose these issues after the fact or without both inbound and outbound traces. If you'd like to us to take a deeper look definitely send us an email to support@nfoservers.com with current inbound traces and your home IP so we can run some additional test.

Internap chooses the best route by having numerous connections to NSPs and routing packets on the best path among those connections. As for packets coming from you, it is my understanding that Internap cannot control this.

It's pretty iffy to control the inbound route as it requires us to adjust big knobs on our end. Which really only influence the traffic to come over a more desired upstream, but it is feasible in some cases.