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>