Irritation regarding precision of ping(8)...

[Sean Chittenden]

This has long bugged me and tonight I finally snapped and had to do 
something about it.  Example output:

64 bytes from a.b.c.d: icmp_seq=935 ttl=126 time=33.824 ms
64 bytes from a.b.c.d: icmp_seq=936 ttl=126 time=29.138 ms
64 bytes from a.b.c.d: icmp_seq=937 ttl=126 time=28.262 ms
64 bytes from a.b.c.d: icmp_seq=938 ttl=126 time=29.67 ms
64 bytes from a.b.c.d: icmp_seq=939 ttl=126 time=30.963 ms
64 bytes from a.b.c.d: icmp_seq=940 ttl=126 time=30.283 ms
64 bytes from a.b.c.d: icmp_seq=941 ttl=126 time=29.455 ms

The source of irritation being line seq 930.  The time should be 29.670 
since we are accurately measuring the precision to the thousands place.

On a less scientific basis (and the actual reason this bothered me), 
not having the trailing zero disrupts the continuity of a stream of 
ping times.  The attached patch simply fixes the various formatting 
statements introduced in version 1.2(!!!!) to use %.30f instead of 
%.3f.  It's now possible to see '28.200' ms ping times instead of just 
'28.2 ms'.

Anyone mind if I commit the attached patch?  I'm sure I'm not the only 
one who's wanted to commit the following.  -sc

-------------- next part --------------
Index: ping.c
===================================================================
RCS file: /home/ncvs/src/sbin/ping/ping.c,v
retrieving revision 1.106
diff -u -r1.106 ping.c
--- ping.c	30 Sep 2004 07:35:56 -0000	1.106
+++ ping.c	31 Oct 2004 09:40:35 -0000
@@ -998,7 +998,7 @@
 			   seq);
 			(void)printf(" ttl=%d", ip->ip_ttl);
 			if (timing)
-				(void)printf(" time=%.3f ms", triptime);
+				(void)printf(" time=%.30f ms", triptime);
 			if (dupflag)
 				(void)printf(" (DUP!)");
 			if (options & F_AUDIBLE)
@@ -1293,7 +1293,7 @@
 		double avg = tsum / n;
 		double vari = tsumsq / n - avg * avg;
 		(void)printf(
-		    "round-trip min/avg/max/stddev = %.3f/%.3f/%.3f/%.3f ms\n",
+		    "round-trip min/avg/max/stddev = %.30f/%.30f/%.30f/%.30f ms\n",
 		    tmin, avg, tmax, sqrt(vari));
 	}
 
-------------- next part --------------


-- 
Sean Chittenden