[I took this direct...]
>If you are busy, you are busy, right?
Not. Different pieces of hardware are busy in those cases.
Thanks for the education..
Er. There's no such thing as perfect transport as long as TCP is
concerned. If end-hosts support large windows, even a single
TCP session will load the network to the point where it'll lose
packets.
What you say here makes sense to me. But, out of a 500
ping sample over the course of half a day, I was getting well
below one percent loss -- six months ago.
Now, my same sample group is going for more than three percent,
with many ten percent loss routes showing. This has changed and
has changed commensurately with the throughput problems shown
in TCP and name lookup problems via UDP.
It may not be scientific proof, but it could very well be a good
scientific indicator. An indicator is all I really need for the
most part.
What you say here makes sense to me. But, out of a 500
ping sample over the course of half a day, I was getting well
below one percent loss -- six months ago.
Now, my same sample group is going for more than three percent,
with many ten percent loss routes showing. This has changed and
has changed commensurately with the throughput problems shown
in TCP and name lookup problems via UDP.
It may not be scientific proof, but it could very well be a good
scientific indicator. An indicator is all I really need for the
most part.
There is considerable difference between forwarding a packet that happens
to contain ICMP data (destination not the router) and responding to a
packet that contains ICMP data (destination is the router). In the
former, priority in a Cisco is the same for ICMP as it is for UDP or TCP,
since this part of the packet is not even being examined. In the later,
priority is lower and can be ignored altogether.
I treat ignored (link good, but no response received) ICMP echo requests
as an indicator that a router is too loaded. If the router has been
pushed to the point of not being able to respond to an ICMP, how well is
it going to do when a bunch BGP updates occur? (rhetorical) Both are CPU
intensive operations.
Chris
Would someone please tell me just why icmp echos are "cpu intensive"?
Yes, I know they're in software. So what? A PC can respond to an
ethernet loaded with them with a trivial percentage of it's CPU cycles.
This sounds to me a whole lot more like a solution to an imagined
problem, but I'm prepared to be convinced that responding to pings
actually takes a great enough percentage of CPU cycles to slow down
packet delivery.....
Thanks,
David
a loaded ethernet is not the problem, a dozen OC3's worth of traffic is
the challenge.
Please let us not digress the NANOG list into "router design 101"
again.
thanks,
dave
Would someone please tell me just why icmp echos are "cpu intensive"?
Yes, I know they're in software. So what? A PC can respond to an
ethernet loaded with them with a trivial percentage of it's CPU cycles.
Recall that the high end routers do most of their forwarding in hardware.
So echos are "cpu intensive" in that they take many, many, many more CPU
cycles to process than packets which are forwarded by the hardware.
For example, in a cisco 7000, the main traffic flow is switched by the
silicon switch engine. Pings of the router themselves cause the packet to
leave the silicon switch engine and sit on a queue (consuming buffer
space), waiting for the CPU. When the CPU gets around to it, the packet is
then copied out of the hardware up to the CPU. The CPU then makes a normal
forwarding decision, and decides to receive the packet. It then decides to
format the reply. Now it makes another forwarding decision, copies the
packet back down into a hardware buffer and squirts it out.
This sounds to me a whole lot more like a solution to an imagined
problem, but I'm prepared to be convinced that responding to pings
actually takes a great enough percentage of CPU cycles to slow down
packet delivery.....
In fact, responding to pings does not directly affect the speed of the
hardware forwarding engine. However, it does increase buffer utilization
in the hardware. It also deters routing protocol processing from
happening, as it's consuming CPU.
Tony