Stephen Wille Padnos wrote: > Jon Elson wrote: > > > That's true, but is also generally not needed. Since you don't care how > long it takes to get from switch 1 to switch 2 (unless you're > considering eliminating one or more of them), you don't need to see the > intermediate times. The time ping reports is the cumulative time. > There's a program called "mtr" which gives a very nice display of ping > times, by the way. > Well, I get huge differences between ping and traceroute for remote nodes. The ping might be 68 ms, but when I do traceroute, I get several nodes showing 100+ ms delay EACH. Now, maybe it is traceroute that is giving the horribly inflated numbers. >> Still, 300 uS is not such a great time if you need 3 >> messages to propagate >> within one millisecond. >> >> > Note that ping is one outbound and one reply packet. The pinging > machine has to get a response back before it can know the delay time. I > don't know how ping calculates the delay time though - start of send to > end of receive, end of send to end of receive, compensation for the > number of bytes, etc. > I would assume it times from when the packet is queued to when the checked reply packet is handed back to ping. But, this is very apropos to a real time controller sending a request to a device and waiting to get a response back. (Ask for encoder position, get the position back, then send velocity update.)
Jon ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
