With many core cisco routers/layer3 switches, such as the 6500 which can be found in probably most ISP networks, the ICMP responses are processed by the supervisor and not via the ASICS on the line cards which forward traffic.
The supervisors look after all manner of routing duties such as routing table updates, spanning tree etc etc and will for very short periods of time come under high load, which has no effect on performance but would appear to if using IcMP to judge performance.
This is why you sometimes see high latency in trace routes on some hops but normal latency to the destination. You can't have a low final destination if that traffic didnt go via the other hops quickly
Screeb: So I guess the national test didn't include any Wellington servers, because TelstraClear would probably come last if it did.
TelstraClear have fiber lines up and down the country and in so connect with many companies in Wellington .. Citylink is 1 they do not peer with , There are many they do.
CityLink / WIX is not the same thing. TelstraClear have a POP at WIX and lots of traffic is transited via this (Stuff and Trademe as two examples). They do not however publically peer at WIX, which means other connected WIX traffic such as the speedtest.net server do not benefit from peering.
With many core cisco routers/layer3 switches, such as the 6500 which can be found in probably most ISP networks, the ICMP responses are processed by the supervisor and not via the ASICS on the line cards which forward traffic.
The supervisors look after all manner of routing duties such as routing table updates, spanning tree etc etc and will for very short periods of time come under high load, which has no effect on performance but would appear to if using IcMP to judge performance.
This is why you sometimes see high latency in trace routes on some hops but normal latency to the destination. You can't have a low final destination if that traffic didnt go via the other hops quickly
Yeah that's a better explanation of what I was saying.
Something like tcptraceroute would give more interesting results imo.
With many core cisco routers/layer3 switches, such as the 6500 which can be found in probably most ISP networks, the ICMP responses are processed by the supervisor and not via the ASICS on the line cards which forward traffic.
The supervisors look after all manner of routing duties such as routing table updates, spanning tree etc etc and will for very short periods of time come under high load, which has no effect on performance but would appear to if using IcMP to judge performance.
This is why you sometimes see high latency in trace routes on some hops but normal latency to the destination. You can't have a low final destination if that traffic didnt go via the other hops quickly
Yeah that's a better explanation of what I was saying.
Something like tcptraceroute would give more interesting results imo.
If you use traceroute then you'll likely see anomalous results from the intermediate switches, since they process the ICMP packet. But, for a simple PING, the intermediate switches and routers look at the header, see that the destination is not them and pass it only quickly via ASIC. So in that case, end-to-end PINGs are probably fairly indicative of real-world results. The ideal of course would be timestamped UDP packets out of iperf. Actually, the modern ideal would be Y.1731 but that's impractical at the moment.
So, for measuring end to end latency, PING is probably good enough. As Ragnor says, a traceroute will show high latency on some hops but normal latency to the destination. But also, a switch might process switch ICMP even when it's NOT the final destination and delay it, resulting in slightly higher RTT results than a 'real' application would see.
Are you subscribed to our RSS feed? You can download the latest headlines and summaries from our stories directly
to your computer or smartphone by using a feed reader.
ID Verified
Trusted
2degrees
Retired Mod
