Geekzone: technology news, blogs, forums
Guest
Welcome Guest.
You haven't logged in yet. If you don't have an account you can register now.
View this topic in a long page with up to 500 replies per page Create new topic
1 | 2 
2280 posts

Uber Geek
+1 received by user: 370

Trusted
Subscriber

  Reply # 540994 4-Nov-2011 01:52
Send private message

RE the deprioritisation of IcMP

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

27122 posts

Uber Geek
+1 received by user: 6563

Moderator
Trusted
Biddle Corp
Lifetime subscriber

  Reply # 541004 4-Nov-2011 06:21
Send private message

Morph:
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.


8027 posts

Uber Geek
+1 received by user: 387

Trusted
Subscriber

  Reply # 541154 4-Nov-2011 14:12
Send private message

insane: RE the deprioritisation of IcMP

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.

 

211 posts

Master Geek
+1 received by user: 21

Trusted

  Reply # 542687 8-Nov-2011 16:24
Send private message

Ragnor:
insane: RE the deprioritisation of IcMP

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.

1 | 2 
View this topic in a long page with up to 500 replies per page Create new topic

Twitter »

Follow us to receive Twitter updates when new discussions are posted in our forums:



Follow us to receive Twitter updates when news items and blogs are posted in our frontpage:



Follow us to receive Twitter updates when tech item prices are listed in our price comparison site:



Geekzone Live »

Try automatic live updates from Geekzone directly in your browser, without refreshing the page, with Geekzone Live now.



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.

Alternatively, you can receive a daily email with Geekzone updates.