Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

How accurate is ping?

558 views
Skip to first unread message

Marc Fouquet

unread,
Apr 7, 2004, 7:39:49 AM4/7/04
to
When I ping machines in my 100 MBit Network it appears to me like ping can
measure times very accurately (+- 100 microseconds or better).

However when ones reads about timing measurements in Linux it always sounds
like +-10 ms are the best accuracy one can expect from any program because
of "ticks", taskswitching etc.

How reliable are the mesurements performed by ping? Does it use special
techniques to be more precise than other "user mode" programs (I read that
root rights are needed to send ICMP packets)?

Thanks
Marc


Jerry Smiley

unread,
Apr 7, 2004, 7:49:02 AM4/7/04
to
Marc Fouquet wrote:

man ping

May answer some of your questions...also giving an user root priv will
allow you to run 'icmp' packets too...

Cameron Kerr

unread,
Apr 7, 2004, 7:49:52 PM4/7/04
to

By itself, an ICMP echo-request and echo-response packet are no more
accurate than a UDP packet.

It becomes more accurate as the result of averaging a series of ping
packets (ignoring the first packet, as it takes longer due to ARP
requests).

You can see the effect of ticking (I suspect this will be more noticible
on x86 compared to say Sparc machines, as Sparcs have a smaller jiffy
time), by plotting the time taken to respond to a series of pings.

I have attached a Perl script that produces such a graph (though that is
not its primary purpose)

---- cut here (wrel.pl) ----
#!/bin/sh
#
# Create a gnuplot generated graph showing the distribution of the round-trip
# time (RTT) of a number of packets sent across a network link. Meant to be
# used for showing the reliability of a wireless link.
#
# Cameron Kerr
# 22 Jan 2004

if [ $# -lt 2 ]; then
echo "Usage: wrel <host> <file.png> [count] [topologydesc]" >&2
echo " count defaults to 1000" >&2
echo " topologydesc is the subtitle of the graph, and defaults to" >&2
echo " \$host <--> \$thishost" >&2
exit 1
fi

function pinggauge()
{
perl -we '
my $host = shift;
my $count = shift;

open PING, "ping -c $count $host|";
open GAUGE, "|dialog --gauge \"Pinging $host $count times\" 6 50";
select GAUGE; $|=1;
select STDOUT; $|=1;

while( <PING> ) {
next unless m/ icmp_seq=/;
my($seq,$rtt)=m/ icmp_seq=(\d+) .* time=([\d.]+)/;
print int($rtt*100) / 100, "\n";
print GAUGE int($seq/$count*100), "\n";
}

close PING;
close GAUGE;
' $1 $2
}

host=$1; shift
file=$1; shift
count=${1:-1000}; shift
topology=$1; shift

if [ -z $topology ]; then
topology="`hostname` <--> $host"
fi

tmpfile=`mktemp -p ${TMPDIR:-/tmp} wrel.XXXXXX`

echo "Pinging $host $count times"
#ping -c "$count" -n "$host" | \
# tee /dev/stderr | \
# sed -ne 's/.* time=\([0-9.]\+\) ms/\1/p' | \
pinggauge $host $count | \
sort -n | uniq -c | awk '{print $2,$1}' > "$tmpfile"

gnuplot > $file <<EOF
set terminal png color
set title "Distribution of packet RTT\n$topology"
set xlabel "RTT (msecs.)"
set ylabel "Frequency"
plot "$tmpfile" notitle with impulses
EOF

rm -f $tmpfile

---- cut here ----

--
Cameron Kerr
camero...@paradise.net.nz : http://nzgeeks.org/cameron/
Empowered by Perl!

Marc Fouquet

unread,
Apr 8, 2004, 5:52:21 AM4/8/04
to
> man ping
>
> May answer some of your questions...also giving an user root priv will
> allow you to run 'icmp' packets too...

To be honest I had not yet read the manpage and it actually was quite
interesting. However it did not answer my question regarding the precision
of pings timing measurements.

Marc

Grant Edwards

unread,
Apr 8, 2004, 10:03:14 AM4/8/04
to
On 2004-04-07, Marc Fouquet <no...@none.com> wrote:

> When I ping machines in my 100 MBit Network it appears to me like ping can
> measure times very accurately (+- 100 microseconds or better).
>
> However when ones reads about timing measurements in Linux it always sounds
> like +-10 ms are the best accuracy one can expect from any program because
> of "ticks", taskswitching etc.

You're conflating several different things.

It's possible to read the current "time" with an accuracy of
about 1us. That makes it possible to timestamp events quite
accurately, especially when the timestamping is done in an ISR
or tasklet.

The system timer tick, however, happens once every 10ms. That's
one of the main points where scheduling happens, so you
generally can't count on a task scheduling resolution smaller
than 10ms.

> How reliable are the mesurements performed by ping?

I used an oscilloscope to verify the measurements performed by
Ethereal, and they were accurate to within a hundred
microseconds or so. I've never verify the measurements
performed by ping, but I presume they're based on the same
packet-timestamping mechanism used by Ethereal (libpcap,
actually).

> Does it use special techniques to be more precise than other
> "user mode" programs

I would guess that it uses the timestamps placed on network
packets by the network stack.

That said, any user-mode program can measure time with an
accuracy of about 1us. See the man page for gettimeofday().
Just remember that the time interval you're measuring may
include time when other tasks are running, and those times
often come in 10ms chunks.

> (I read that root rights are needed to send ICMP packets)?

--
Grant Edwards grante Yow! Can I have an IMPULSE
at ITEM instead?
visi.com

Grant Edwards

unread,
Apr 8, 2004, 10:10:33 AM4/8/04
to
On 2004-04-07, Cameron Kerr <camero...@paradise.net.nz> wrote:

> You can see the effect of ticking (I suspect this will be more noticible
> on x86 compared to say Sparc machines, as Sparcs have a smaller jiffy
> time), by plotting the time taken to respond to a series of pings.

The timestamps on network packets aren't limited by the jiffy
size. Even though the IA32 Linux jiffy size is 10ms, network
packets are timestamped with a resolution of about 1us.[1] Of
course there are interrupt and tasklet scheduling latencies
that impact the accuracy of those timestamps. IOW the
resolution of the timestamps is 1us, but the accuracy may be
something on the order of 100us.

[1] This may only be true on Pentium-class processors with a
particular option enabled in the kernel. It has been true
in all the kernels I've seen in the past several years, but
I do remember a case a few years ago where a specific
kernel produced packet timestamps with a 10ms resolution.

--
Grant Edwards grante Yow! Did we bring enough
at BEEF JERKY?
visi.com

Floyd L. Davidson

unread,
Apr 8, 2004, 11:35:48 AM4/8/04
to
Grant Edwards <gra...@visi.com> wrote:
>On 2004-04-07, Cameron Kerr <camero...@paradise.net.nz> wrote:
>
>> You can see the effect of ticking (I suspect this will be more noticible
>> on x86 compared to say Sparc machines, as Sparcs have a smaller jiffy
>> time), by plotting the time taken to respond to a series of pings.
>
>The timestamps on network packets aren't limited by the jiffy
>size. Even though the IA32 Linux jiffy size is 10ms, network

The timing for ping packets is produced using gettimeofday and
passing the value as the first 8 bytes of the data in the ICMP
packet.

The timing for transmitting ping packets is provided by using
SIGALRM interupts. The receive is controlled with a call to
select() in a forever loop.

Hence once should expect to see erratic results in the timing,
depending on the round trip timing and its relationship to
scheduling. If an echoed packet is received before the process
gives up its timeslice, the round trip time is going to have
jitter based on the granularity of gettimeofday(). If the
process gives up its time slice, the jitter will be based on the
(greater) granularity of the scheduler.

Note that in distribution kernels through 2.4 the schedular has
10 ms granularity, but in 2.6 kernels (and patched 2.4 kernels)
the granularity is 1 ms.

--
Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) fl...@barrow.com

0 new messages