Hello Philip. Ping relies heavily on the system's CPU. That is why it is considered unreliable for measuring when you are pinging CPU loaded machines/devices. The CPU on the probe is a n ARM7TDMI running at 55MHz, based on information from this link: <a href="http://www.digi.com/products/wireless-wired-embedded-solutions/solutions-on-module/digi-connect/digiconnectme#specs">http://www.digi.com/products/wireless-wired-embedded-solutions/solutions-on-module/digi-connect/digiconnectme#specs</a> Regards, Stelios Mersinas <div class="gmail_quote">On Wed, Jun 20, 2012 at 11:48 AM, Philip Homburg <<a href="mailto:philip.homburg@ripe.net" target="_blank">philip.homburg@ripe.net</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 6/20/12 9:11 , Randy Bush wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> we want to use atlas probes in an experiment. being prudent (you can tell it was not i), we decided to try to get some basic calibration. one run was just on a local LAN. three hosts on the same gige switch o probe 2285 o <a href="http://psg.com" target="_blank">psg.com</a>, a not very fancy or fast freebsd 9 box with intel/pro1000 gige ports o <a href="http://bbgp.psg.com" target="_blank">bbgp.psg.com</a>, a funky older freebsd 9 box with bge gige probe 2285 pinging <a href="http://bbgp.psg.com" target="_blank">bbgp.psg.com</a>, average RTT: 1.5606994382 [0], number of pings: 356*3 <a href="http://psg.com" target="_blank">psg.com</a> pinging <a href="http://bbgp.psg.com" target="_blank">bbgp.psg.com</a>, average RTT: 0.253424332344 [0], number of pings: 674 has anyone done similar probe calibration experiments? does anyone have any clue as to why the difference? </blockquote></div> Just to confirm my suspicion, I tried to other way around: This is an old AMD64 running FreeBSD pinging an Atlas probe on the same LAN: $ ping 130.37.15.50 PING 130.37.15.50 (130.37.15.50): 56 data bytes 64 bytes from <a href="http://130.37.15.50" target="_blank">130.37.15.50</a>: icmp_seq=0 ttl=64 time=2.515 ms 64 bytes from <a href="http://130.37.15.50" target="_blank">130.37.15.50</a>: icmp_seq=1 ttl=64 time=0.913 ms 64 bytes from <a href="http://130.37.15.50" target="_blank">130.37.15.50</a>: icmp_seq=2 ttl=64 time=0.915 ms 64 bytes from <a href="http://130.37.15.50" target="_blank">130.37.15.50</a>: icmp_seq=3 ttl=64 time=0.929 ms And this is the same FreeBSD box pinging a Celeron 766 MHz, running a micro kernel operating system, also on the same LAN: $ ping prism PING <a href="http://prism.hq.phicoh.net" target="_blank">prism.hq.phicoh.net</a> (130.37.15.36): 56 data bytes 64 bytes from <a href="http://130.37.15.36" target="_blank">130.37.15.36</a>: icmp_seq=0 ttl=96 time=0.364 ms 64 bytes from <a href="http://130.37.15.36" target="_blank">130.37.15.36</a>: icmp_seq=1 ttl=96 time=0.210 ms 64 bytes from <a href="http://130.37.15.36" target="_blank">130.37.15.36</a>: icmp_seq=2 ttl=96 time=0.211 ms 64 bytes from <a href="http://130.37.15.36" target="_blank">130.37.15.36</a>: icmp_seq=3 ttl=96 time=0.214 ms This does not involve any of the Atlas software, just the ucLinux kernel running on the probe. My conclusion is: probes are just very slow. They are fine for measuring multi millisecond delays on WAN links but not for sub-millisecond delays on local links. </blockquote></div>