Los Angeles Tunnel Server Stats.

[snarked]

The usage statistics used to indicate TTLs that were under 1ms (for a rare few at the top of the list) when the server was first rolled out.  Today, only one user is under (but close to) 2ms.  Is there so much traffic going through the server that pings to determine RTT are now being delayed?

Using the looking glass tool, pings from both of the Los Angeles locations to my box (in LA) are less than 1ms consistently:

core1.lax1.he.net> ping 67.43.172.250 numeric count 5 Count 5
Size 16 byte(s)
Target 67.43.172.250
Timeout 5000ms
TTL 64
Type Source Bytes Time TTL
Reply 67.43.172.250 16 1 ms 60
Reply 67.43.172.250 16 <1 ms 60
Reply 67.43.172.250 16 <1 ms 60
Reply 67.43.172.250 16 <1 ms 60
Reply 67.43.172.250 16 <1 ms 60
Percent Count Fastest Average Slowest
100% 5/5 0 ms 0 ms 1 ms
core1.lax2.he.net> ping 67.43.172.250 numeric count 5 Count 5
Size 16 byte(s)
Target 67.43.172.250
Timeout 5000ms
TTL 64
Type Source Bytes Time TTL
Reply 67.43.172.250 16 1 ms 60
Reply 67.43.172.250 16 <1 ms 60
Reply 67.43.172.250 16 <1 ms 60
Reply 67.43.172.250 16 <1 ms 60
Reply 67.43.172.250 16 <1 ms 60
Percent Count Fastest Average Slowest
100% 5/5 0 ms 0 ms 1 ms

And Traceroutes:

core1.lax1.he.net> traceroute 67.43.172.250 numeric
1 <1 ms <1 ms <1 ms t0-1.cs1.lax1.xfernet.net (65.19.143.10)
2 <1 ms <1 ms <1 ms g50.ar9.lax1.xfernet.net (67.43.160.90)
3 <1 ms <1 ms <1 ms mail.snarked.org (67.43.172.250)
core1.lax2.he.net> traceroute 67.43.172.250 numeric Target 67.43.172.250
Hop Start 1
Hop End 30
Hop Packet 1 Packet 2 Packet 3 Router
1 <1 ms <1 ms <1 ms 10gigabitethernet2-1.core1.lax1.he.net (72.52.92.121)
2 <1 ms <1 ms <1 ms t0-1.cs1.lax1.xfernet.net (65.19.143.10)
3 <1 ms <1 ms <1 ms g50.ar9.lax1.xfernet.net (67.43.160.90)
4 <1 ms <1 ms <1 ms mail.snarked.org (67.43.172.250)

So why are the tunnel server ping times so high?  Has the LA server been so successful, it's overloaded now?  It reports 621 tunnels, 25% of your most loaded server (Frankfurt).

Return traceroutes (assymetrical):

From www.snarked.org [67.43.172.253] to core1.lax1.he.net
1  snarked.ipv4-gw.xfernet.net (67.43.172.249)  0.547 ms  0.514 ms  0.380 ms
2  vl50.cs2.lax1.xfernet.net (67.43.160.97)  0.297 ms  0.374 ms  0.248 ms
3  ge1-12-17.cr01.lax03.mzima.net (216.193.192.141)  0.586 ms  0.497 ms  0.362 ms
4  xe2-0.cr01.lax01.us.mzima.net (216.193.255.181)  2.465 ms  0.576 ms  0.475 ms
5  core1.lax1.he.net (216.218.252.166)  0.630 ms  0.617 ms  0.499 ms

From www.snarked.org [67.43.172.253] to core1.lax2.he.net
1  snarked.ipv4-gw.xfernet.net (67.43.172.249)  0.680 ms  0.504 ms  0.375 ms
2  vl50.cs2.lax1.xfernet.net (67.43.160.97)  0.274 ms  0.333 ms  0.250 ms
3  ge1-12-17.cr01.lax03.mzima.net (216.193.192.141)  10.815 ms  0.485 ms  0.363 ms
4  xe2-0.cr01.lax01.us.mzima.net (216.193.255.181)  7.064 ms  0.602 ms  0.485 ms
5  equinix-lax.he.net (206.223.123.37)  9.840 ms  0.637 ms  0.483 ms
6  core1.lax2.he.net (216.218.252.178)  0.597 ms  0.611 ms  0.534 ms

From www.snarked.org [67.43.172.253] to tserv15.lax1.ipv6.he.net
1  snarked.ipv4-gw.xfernet.net (67.43.172.249)  1.573 ms  0.524 ms  0.386 ms
2  vl50.cs2.lax1.xfernet.net (67.43.160.97)  0.276 ms  0.365 ms  0.250 ms
3  ge1-12-17.cr01.lax03.mzima.net (216.193.192.141)  3.903 ms  0.482 ms  0.388 ms
4  xe2-0.cr01.lax01.us.mzima.net (216.193.255.181)  9.290 ms  0.584 ms  0.474 ms
5  equinix-lax.he.net (206.223.123.37)  0.499 ms  0.602 ms  0.512 ms
6  tserv15.lax1.ipv6.he.net (66.220.18.42)  1.422 ms  0.754 ms  0.947 ms

Yet today, I didn't even make the top 20 for this tunnel server, meaning >12.386 ms.  Hmmmmm?  With the RTTs I'm seeing, I should not only be listed, but take the top spot!  ;-)  I don't care about being first (but I'm usually about #5).  I'm concerned about the load and possible "truth" of the statistics.

[broquea]

You are #11 (at this time). There is an additional service running on that tserv that might be causing about 1-2ms difference because of how it operates on the current platform. There is a new roll-out in the works to change platforms that should increase throughput and help reduce latency. Also all your tests are v4, this latency checker is IPv6. Also I cannot seem to ping6 your side of the tunnel from anywhere except the tunnel-server, although I can ping6 the server's side of the tunnel, so clearly nothing wrong on the tunnel-server. guessing you filter ICMPv6.

[snarked]

Pings - Correct:  I restrict in my firewall the pings to verify that the tunnel is alive to the tunnel server's IPv6 address.  Pings to my tunnel PTP IPv6 address from elsewhere are dropped.

Yes, I tested in the IPv4 domain as the tunnel is a "6in4" service, and if IPv4 takes longer than 2ms, then the encapsulated IPv6 service must also be longer.  Since you have identifed "an additional service" that may be causing delays, that alone satisfies my question.  Thank you.

[piojan]

Some time ago I made some stats for the frankfurt tserv.
Best pings time that I could get (messured with mtr over different time of day and without any ddos like simptoms):
ipv4 - hurricane-ic-129711-ffm-b2.c.telia.net- 36.8 ms
ipv4 - tserv6.fra1.ipv6.he.net- 37.1 ms
ipv6 - tserv6.fra1.ipv6.he.net- 42.3 ms
ipv6 - gige-g2-4.core1.fra1.he.net- 39.5 ms

The minimal jump between ipv4 and ipv6 is 2,7ms.

HE is my primary ipv6 link but I also have a different ipv6 tunnel - there the difference is <1,1ms.

Frankfurt had a lot of users and mayby there was also a "additional service running on that tserv".
Looking forward for the new roll-out of tservs :)

[snarked]

It's now a couple of years later.

Traceroute RTTs indicate <400ms:

6  tserv15.lax1.ipv6.he.net (66.220.18.42)  0.382 ms  0.378 ms  0.362 ms

Yet the tunnel server latency on http://www.tunnelbroker.net/usage/tunnels_by_latency.php lists the best RTT as 3.724 ms (not me).  Hmmmmm.

[broquea]

None of the pings are IPv4, they are all against your Client IP side of the IPv6 tunnel from the tserv. What does it look like over IPv6?

[snarked]

How do I test that when "tserv15.lax1.ipv6.he.net" has no IPv6 address?

Using my allocated server tunnel endpoint, I still get about 400ms.

PING 2001:470:c:4::1(2001:470:c:4::1) 56 data bytes
64 bytes from 2001:470:c:4::1: icmp_seq=1 ttl=64 time=0.419 ms
64 bytes from 2001:470:c:4::1: icmp_seq=2 ttl=64 time=0.468 ms
64 bytes from 2001:470:c:4::1: icmp_seq=3 ttl=64 time=0.450 ms
64 bytes from 2001:470:c:4::1: icmp_seq=4 ttl=64 time=0.375 ms
...
--- 2001:470:c:4::1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2997ms
rtt min/avg/max/mdev = 0.375/0.428/0.468/0.035 ms

[broquea]

I'll look at scripts on Weds when I'm in the office again. Also I think you meant to say .400ms

[snarked]

Yes, ... and that's why women hate periods too!  ;)