From sacadmin Thu Feb 19 06:30:08 2004 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 19 Feb 2004 09:25:10 -0500 From: James Carlson To: psarc@sac.sfbay.sun.com cc: jeremy.harris@sun Subject: 2004/137 Submillisecond Ping Resolution Content-Length: 2586 I'm sponsoring this case on behalf of Jeremy Harris. I've marked it as "closed approved automatic," as the change seems quite obvious and unremarkable. If anyone disagrees, please speak up, and I'll set a timer on it. The output of ping is changed to display sub-millisecond precision for the "-s" option. The default output without "-s" is unchanged. The "-s" output format is assumed to be Unstable, and this change has minor release binding. Display is to 3 significant figures for each echo and the minumum/maximum figures, and to a number of figures depending on the number of sample for the average figure. A standard-deviation is also displayed. The example in the ping manpage will be updated and SUNWbip made dependent on SUNWlibmsr. The current output looks like this: # ping -s kriek PING kriek: 56 data bytes 64 bytes from kriek.UK.Sun.COM (129.156.199.248): icmp_seq=0. time=1. ms 64 bytes from kriek.UK.Sun.COM (129.156.199.248): icmp_seq=1. time=0. ms 64 bytes from kriek.UK.Sun.COM (129.156.199.248): icmp_seq=2. time=0. ms 64 bytes from kriek.UK.Sun.COM (129.156.199.248): icmp_seq=3. time=0. ms ^C ----kriek PING Statistics---- 4 packets transmitted, 4 packets received, 0% packet loss round-trip (ms) min/avg/max = 0/0/1 The proposed output will look like this: # ping -s kriek PING kriek: 56 data bytes 64 bytes from kriek.UK.Sun.COM (129.156.199.248): icmp_seq=0. time=1.08 ms 64 bytes from kriek.UK.Sun.COM (129.156.199.248): icmp_seq=1. time=0.480 ms 64 bytes from kriek.UK.Sun.COM (129.156.199.248): icmp_seq=2. time=0.476 ms 64 bytes from kriek.UK.Sun.COM (129.156.199.248): icmp_seq=3. time=0.434 ms ^C ----kriek PING Statistics---- 4 packets transmitted, 4 packets received, 0% packet loss round-trip (ms) min/avg+-sd/max = 0.434 / 0.617+-0.31 / 1.08 For comparison, here is the output from a modern BSD system: > ping 129.156.199.248 PING 129.156.199.248 (129.156.199.248): 56 data bytes 64 bytes from 129.156.199.248: icmp_seq=0 ttl=248 time=185.331 ms 64 bytes from 129.156.199.248: icmp_seq=1 ttl=248 time=182.973 ms 64 bytes from 129.156.199.248: icmp_seq=2 ttl=248 time=185.908 ms 64 bytes from 129.156.199.248: icmp_seq=3 ttl=248 time=184.619 ms ^C --- 129.156.199.248 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 182.973/184.708/185.908/1.101 ms -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Thu Feb 19 09:36:04 2004 Date: Thu, 19 Feb 2004 09:31:04 -0800 (PST) From: Glenn Skinner Subject: Re: 2004/137 Submillisecond Ping Resolution To: psarc@sac.sfbay.sun.com Cc: jeremy.harris@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: hlbVADGswN/o8uSLDiOLCg== Content-Length: 1956 Date: Thu, 19 Feb 2004 09:25:10 -0500 From: James Carlson Subject: 2004/137 Submillisecond Ping Resolution I'm sponsoring this case on behalf of Jeremy Harris. I've marked it as "closed approved automatic," as the change seems quite obvious and unremarkable. If anyone disagrees, please speak up, and I'll set a timer on it. I fear I do have one small question... ... The proposed output will look like this: # ping -s kriek PING kriek: 56 data bytes 64 bytes from kriek.UK.Sun.COM (129.156.199.248): icmp_seq=0. time=1.08 ms 64 bytes from kriek.UK.Sun.COM (129.156.199.248): icmp_seq=1. time=0.480 ms 64 bytes from kriek.UK.Sun.COM (129.156.199.248): icmp_seq=2. time=0.476 ms 64 bytes from kriek.UK.Sun.COM (129.156.199.248): icmp_seq=3. time=0.434 ms ^C ----kriek PING Statistics---- 4 packets transmitted, 4 packets received, 0% packet loss round-trip (ms) min/avg+-sd/max = 0.434 / 0.617+-0.31 / 1.08 For comparison, here is the output from a modern BSD system: > ping 129.156.199.248 PING 129.156.199.248 (129.156.199.248): 56 data bytes 64 bytes from 129.156.199.248: icmp_seq=0 ttl=248 time=185.331 ms 64 bytes from 129.156.199.248: icmp_seq=1 ttl=248 time=182.973 ms 64 bytes from 129.156.199.248: icmp_seq=2 ttl=248 time=185.908 ms 64 bytes from 129.156.199.248: icmp_seq=3 ttl=248 time=184.619 ms ^C --- 129.156.199.248 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 182.973/184.708/185.908/1.101 ms Why not make the summary part of the output identical to that of a modern BSD system? The difference seems gratuitous, and doesn't seem to be justifiable on grounds of upward compatibility from our current format -- in fact, the BSD output seems to be closer to our current format than the proposed format does. -- Glenn From sacadmin Thu Feb 19 10:00:26 2004 Date: Thu, 19 Feb 2004 17:55:23 +0000 From: Calum Mackay User-Agent: Mozilla Thunderbird 0.5+ (X11/20040218) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Glenn Skinner CC: psarc@sac.sfbay.sun.com, jeremy.harris@sun.com Subject: Re: 2004/137 Submillisecond Ping Resolution Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 1612 Glenn Skinner wrote: > From: James Carlson > For comparison, here is the output from a modern BSD system: > > > ping 129.156.199.248 > PING 129.156.199.248 (129.156.199.248): 56 data bytes > 64 bytes from 129.156.199.248: icmp_seq=0 ttl=248 time=185.331 ms > 64 bytes from 129.156.199.248: icmp_seq=1 ttl=248 time=182.973 ms > 64 bytes from 129.156.199.248: icmp_seq=2 ttl=248 time=185.908 ms > 64 bytes from 129.156.199.248: icmp_seq=3 ttl=248 time=184.619 ms > ^C > --- 129.156.199.248 ping statistics --- > 4 packets transmitted, 4 packets received, 0% packet loss > round-trip min/avg/max/stddev = 182.973/184.708/185.908/1.101 ms > > Why not make the summary part of the output identical to that of a > modern BSD system? The difference seems gratuitous, and doesn't seem > to be justifiable on grounds of upward compatibility from our current > format -- in fact, the BSD output seems to be closer to our current > format than the proposed format does. Out of interest, the current Linux format is very similar, although not identical: diz $ ping 192.168.254.1 PING 192.168.254.1 (192.168.254.1) 56(84) bytes of data. 64 bytes from 192.168.254.1: icmp_seq=1 ttl=64 time=0.059 ms 64 bytes from 192.168.254.1: icmp_seq=2 ttl=64 time=0.054 ms 64 bytes from 192.168.254.1: icmp_seq=3 ttl=64 time=0.056 ms 64 bytes from 192.168.254.1: icmp_seq=4 ttl=64 time=0.054 ms --- 192.168.254.1 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 2999ms rtt min/avg/max/mdev = 0.054/0.055/0.059/0.009 ms cheers, c. From sacadmin Thu Feb 19 10:23:45 2004 Date: Thu, 19 Feb 2004 18:19:27 +0000 From: Jeremy Harris User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3) Gecko/20030314 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Glenn Skinner CC: psarc@sac.sfbay.sun.com Subject: Re: 2004/137 Submillisecond Ping Resolution Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 2224 Glenn Skinner wrote: > I fear I do have one small question... > > ... > The proposed output will look like this: > > # ping -s kriek > PING kriek: 56 data bytes > 64 bytes from kriek.UK.Sun.COM (129.156.199.248): icmp_seq=0. time=1.08 ms > 64 bytes from kriek.UK.Sun.COM (129.156.199.248): icmp_seq=1. time=0.480 ms > 64 bytes from kriek.UK.Sun.COM (129.156.199.248): icmp_seq=2. time=0.476 ms > 64 bytes from kriek.UK.Sun.COM (129.156.199.248): icmp_seq=3. time=0.434 ms > ^C > ----kriek PING Statistics---- > 4 packets transmitted, 4 packets received, 0% packet loss > round-trip (ms) min/avg+-sd/max = 0.434 / 0.617+-0.31 / 1.08 > > For comparison, here is the output from a modern BSD system: > > > ping 129.156.199.248 > PING 129.156.199.248 (129.156.199.248): 56 data bytes > 64 bytes from 129.156.199.248: icmp_seq=0 ttl=248 time=185.331 ms > 64 bytes from 129.156.199.248: icmp_seq=1 ttl=248 time=182.973 ms > 64 bytes from 129.156.199.248: icmp_seq=2 ttl=248 time=185.908 ms > 64 bytes from 129.156.199.248: icmp_seq=3 ttl=248 time=184.619 ms > ^C > --- 129.156.199.248 ping statistics --- > 4 packets transmitted, 4 packets received, 0% packet loss > round-trip min/avg/max/stddev = 182.973/184.708/185.908/1.101 ms > > Why not make the summary part of the output identical to that of a > modern BSD system? The difference seems gratuitous, and doesn't seem > to be justifiable on grounds of upward compatibility from our current > format -- in fact, the BSD output seems to be closer to our current > format than the proposed format does. Certainly, that can be done. Proposed output matching the above: > ping 129.156.199.248 PING 129.156.199.248 (129.156.199.248): 56 data bytes 64 bytes from 129.156.199.248: icmp_seq=0 ttl=248 time=185. ms 64 bytes from 129.156.199.248: icmp_seq=1 ttl=248 time=183. ms 64 bytes from 129.156.199.248: icmp_seq=2 ttl=248 time=186. ms 64 bytes from 129.156.199.248: icmp_seq=3 ttl=248 time=185. ms ^C --- 129.156.199.248 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 183./185./186./1.1 ms Cheers, Jeremy From sacadmin Thu Feb 19 10:29:34 2004 Date: Thu, 19 Feb 2004 10:24:34 -0800 (PST) From: Glenn Skinner Subject: Re: 2004/137 Submillisecond Ping Resolution To: jeremy.harris@sun.com Cc: psarc@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: F2GmxI/Ww/YnRFOmPHlJiQ== Content-Length: 2736 Date: Thu, 19 Feb 2004 18:19:27 +0000 From: Jeremy Harris Subject: Re: 2004/137 Submillisecond Ping Resolution Glenn Skinner wrote: > I fear I do have one small question... > > ... > The proposed output will look like this: > > # ping -s kriek > PING kriek: 56 data bytes > 64 bytes from kriek.UK.Sun.COM (129.156.199.248): icmp_seq=0. time=1.08 ms > 64 bytes from kriek.UK.Sun.COM (129.156.199.248): icmp_seq=1. time=0.480 ms > 64 bytes from kriek.UK.Sun.COM (129.156.199.248): icmp_seq=2. time=0.476 ms > 64 bytes from kriek.UK.Sun.COM (129.156.199.248): icmp_seq=3. time=0.434 ms > ^C > ----kriek PING Statistics---- > 4 packets transmitted, 4 packets received, 0% packet loss > round-trip (ms) min/avg+-sd/max = 0.434 / 0.617+-0.31 / 1.08 > > For comparison, here is the output from a modern BSD system: > > > ping 129.156.199.248 > PING 129.156.199.248 (129.156.199.248): 56 data bytes > 64 bytes from 129.156.199.248: icmp_seq=0 ttl=248 time=185.331 ms > 64 bytes from 129.156.199.248: icmp_seq=1 ttl=248 time=182.973 ms > 64 bytes from 129.156.199.248: icmp_seq=2 ttl=248 time=185.908 ms > 64 bytes from 129.156.199.248: icmp_seq=3 ttl=248 time=184.619 ms > ^C > --- 129.156.199.248 ping statistics --- > 4 packets transmitted, 4 packets received, 0% packet loss > round-trip min/avg/max/stddev = 182.973/184.708/185.908/1.101 ms > > Why not make the summary part of the output identical to that of a > modern BSD system? The difference seems gratuitous, and doesn't seem > to be justifiable on grounds of upward compatibility from our current > format -- in fact, the BSD output seems to be closer to our current > format than the proposed format does. Certainly, that can be done. Proposed output matching the above: > ping 129.156.199.248 PING 129.156.199.248 (129.156.199.248): 56 data bytes 64 bytes from 129.156.199.248: icmp_seq=0 ttl=248 time=185. ms 64 bytes from 129.156.199.248: icmp_seq=1 ttl=248 time=183. ms 64 bytes from 129.156.199.248: icmp_seq=2 ttl=248 time=186. ms 64 bytes from 129.156.199.248: icmp_seq=3 ttl=248 time=185. ms ^C --- 129.156.199.248 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 183./185./186./1.1 ms I was careful just to ask for compatibility in the summary part. Including the hostname in the output for each individual ICMP message is useful, and I don't want to see you drop that. -- Glenn From sacadmin Thu Feb 19 10:34:00 2004 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 19 Feb 2004 13:28:58 -0500 From: James Carlson To: Glenn Skinner Cc: Jeremy.Harris@Sun.COM, psarc@sac.sfbay.sun.com Subject: Re: 2004/137 Submillisecond Ping Resolution Content-Length: 551 Glenn Skinner writes: > I was careful just to ask for compatibility in the summary part. > Including the hostname in the output for each individual ICMP message > is useful, and I don't want to see you drop that. I don't believe he was suggesting removing the hostname; just reformatting the std. dev. to the end of the line. -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Fri Feb 20 07:54:54 2004 Date: Fri, 20 Feb 2004 15:50:36 +0000 From: Jeremy Harris User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3) Gecko/20030314 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Glenn Skinner CC: psarc@sac.sfbay.sun.com Subject: Re: 2004/137 Submillisecond Ping Resolution Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 910 Glenn Skinner wrote: > > ping 129.156.199.248 > PING 129.156.199.248 (129.156.199.248): 56 data bytes > 64 bytes from 129.156.199.248: icmp_seq=0 ttl=248 time=185. ms > 64 bytes from 129.156.199.248: icmp_seq=1 ttl=248 time=183. ms > 64 bytes from 129.156.199.248: icmp_seq=2 ttl=248 time=186. ms > 64 bytes from 129.156.199.248: icmp_seq=3 ttl=248 time=185. ms > ^C > --- 129.156.199.248 ping statistics --- > 4 packets transmitted, 4 packets received, 0% packet loss > round-trip min/avg/max/stddev = 183./185./186./1.1 ms > > I was careful just to ask for compatibility in the summary part. > Including the hostname in the output for each individual ICMP message > is useful, and I don't want to see you drop that. I agree - the proposal doesn't change hostname inclusion in the output. In all situations it was previously there it will remain there. - Jeremy From sacadmin Fri Feb 20 08:06:45 2004 From: Joep.Vesseur@Sun.COM (Joep Vesseur) To: psarc@sac.sfbay.sun.com Subject: Re: 2004/137 Submillisecond Ping Resolution Date: Fri, 20 Feb 2004 17:01:44 +0100 Content-Length: 765 > > > ping 129.156.199.248 > > PING 129.156.199.248 (129.156.199.248): 56 data bytes > > 64 bytes from 129.156.199.248: icmp_seq=0 ttl=248 time=185. ms > > 64 bytes from 129.156.199.248: icmp_seq=1 ttl=248 time=183. ms > > 64 bytes from 129.156.199.248: icmp_seq=2 ttl=248 time=186. ms > > 64 bytes from 129.156.199.248: icmp_seq=3 ttl=248 time=185. ms > > ^C > > --- 129.156.199.248 ping statistics --- > > 4 packets transmitted, 4 packets received, 0% packet loss > > round-trip min/avg/max/stddev = 183./185./186./1.1 ms I guess I'm missing something here. Is this the proposed output of ping with 2004/137? Where's the submilisecond info? does this case also introduce ttl info? Or is this misedited BSD output? Joep From sacadmin Fri Feb 20 08:15:31 2004 Date: Fri, 20 Feb 2004 16:11:14 +0000 From: Jeremy Harris User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3) Gecko/20030314 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joep Vesseur CC: psarc@sac.sfbay.sun.com Subject: Re: 2004/137 Submillisecond Ping Resolution Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 871 Joep Vesseur wrote: >>> > ping 129.156.199.248 >>> PING 129.156.199.248 (129.156.199.248): 56 data bytes >>> 64 bytes from 129.156.199.248: icmp_seq=0 ttl=248 time=185. ms >>> 64 bytes from 129.156.199.248: icmp_seq=1 ttl=248 time=183. ms >>> 64 bytes from 129.156.199.248: icmp_seq=2 ttl=248 time=186. ms >>> 64 bytes from 129.156.199.248: icmp_seq=3 ttl=248 time=185. ms >>> ^C >>> --- 129.156.199.248 ping statistics --- >>> 4 packets transmitted, 4 packets received, 0% packet loss >>> round-trip min/avg/max/stddev = 183./185./186./1.1 ms > > > > I guess I'm missing something here. Is this the proposed output of > ping with 2004/137? Where's the submilisecond info? As the case said, three significant digits. Over one hundred milliseconds you won't see any decimals. > does this case > also introduce ttl info? No. -Jeremy From sacadmin Fri Feb 20 08:19:18 2004 From: Joep.Vesseur@Sun.COM (Joep Vesseur) To: psarc@sac.sfbay.sun.com Subject: Re: 2004/137 Submillisecond Ping Resolution Date: Fri, 20 Feb 2004 17:14:18 +0100 Content-Length: 170 > As the case said, three significant digits. Over one hundred milliseconds > you won't see any decimals. But we'll still see the '.' in "183." ? Remarkable... Joep From sacadmin Fri Feb 20 08:21:35 2004 Date: Fri, 20 Feb 2004 16:17:18 +0000 From: Jeremy Harris User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3) Gecko/20030314 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joep Vesseur CC: psarc@sac.sfbay.sun.com Subject: Re: 2004/137 Submillisecond Ping Resolution Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 345 Joep Vesseur wrote: >>As the case said, three significant digits. Over one hundred milliseconds >>you won't see any decimals. > > > But we'll still see the '.' in "183." ? > > Remarkable... If anyone can convince printf() to lose the '.' I'll be most happy. In the meantime, it is compatible with the previous Solarig ping output. -J From sacadmin Fri Feb 20 08:23:00 2004 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 20 Feb 2004 11:17:58 -0500 From: James Carlson To: Joep.Vesseur@Sun.COM (Joep Vesseur) Cc: psarc@sac.sfbay.sun.com, jeremy.harris@sun Subject: Re: 2004/137 Submillisecond Ping Resolution Content-Length: 3108 Joep Vesseur writes: > I guess I'm missing something here. Is this the proposed output of > ping with 2004/137? Where's the submilisecond info? does this case > also introduce ttl info? Or is this misedited BSD output? Cut-n-paste error. OK. Even though there shouldn't have needed to be any discussion on this at all, there was, so I'm marking it now as a fast-track to time out on 02/27/2004. Apologies to all. New spec is below. The output of ping is changed to display sub-millisecond precision for the "-s" option. The default output without "-s" is unchanged. The "-s" output format is assumed to be Unstable, and this change has minor release binding. Display is to 3 significant figures for each echo and the minumum/maximum figures, and to a number of figures depending on the number of sample for the average figure. A standard-deviation is also displayed. The example in the ping manpage will be updated and SUNWbip made dependent on SUNWlibmsr. The current output looks like this: # ping -s kriek PING kriek: 56 data bytes 64 bytes from kriek.UK.Sun.COM (129.156.199.248): icmp_seq=0. time=1. ms 64 bytes from kriek.UK.Sun.COM (129.156.199.248): icmp_seq=1. time=0. ms 64 bytes from kriek.UK.Sun.COM (129.156.199.248): icmp_seq=2. time=0. ms 64 bytes from kriek.UK.Sun.COM (129.156.199.248): icmp_seq=3. time=0. ms ^C ----kriek PING Statistics---- 4 packets transmitted, 4 packets received, 0% packet loss round-trip (ms) min/avg/max = 0/0/1 The proposed output will look like this: # ping -s kriek PING kriek: 56 data bytes 64 bytes from kriek.UK.Sun.COM (129.156.199.248): icmp_seq=0. time=1.08 ms 64 bytes from kriek.UK.Sun.COM (129.156.199.248): icmp_seq=1. time=0.480 ms 64 bytes from kriek.UK.Sun.COM (129.156.199.248): icmp_seq=2. time=0.476 ms 64 bytes from kriek.UK.Sun.COM (129.156.199.248): icmp_seq=3. time=0.434 ms ^C ----kriek PING Statistics---- 4 packets transmitted, 4 packets received, 0% packet loss round-trip (ms) min/avg/max/stddev = 0.434/0.617/1.08/0.31 For comparison, here is the output from a modern BSD system: > ping 129.156.199.248 PING 129.156.199.248 (129.156.199.248): 56 data bytes 64 bytes from 129.156.199.248: icmp_seq=0 ttl=248 time=185.331 ms 64 bytes from 129.156.199.248: icmp_seq=1 ttl=248 time=182.973 ms 64 bytes from 129.156.199.248: icmp_seq=2 ttl=248 time=185.908 ms 64 bytes from 129.156.199.248: icmp_seq=3 ttl=248 time=184.619 ms ^C --- 129.156.199.248 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 182.973/184.708/185.908/1.101 ms Note that we've always had the "(ms)" bit in the summary line, and there seems to be no reason to move this to the end of the line just to be "BSD compatible." Note also that name resolution is slightly different on the two versions, and that we don't show ttl, and we're keeping our own format for now. -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Fri Feb 20 08:24:50 2004 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 20 Feb 2004 11:19:47 -0500 From: James Carlson To: Jeremy Harris Cc: Joep Vesseur , psarc@sac.sfbay.sun.com Subject: Re: 2004/137 Submillisecond Ping Resolution Content-Length: 589 Jeremy Harris writes: > If anyone can convince printf() to lose the '.' I'll be most > happy. In the meantime, it is compatible with the > previous Solarig ping output. Argh. We crossed in the mail. So it seems we're truncating to three digits of precision. I don't see an obvious problem with that, but it's yet again slightly different from the BSD output. -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Fri Feb 20 08:42:20 2004 From: Joep.Vesseur@Sun.COM (Joep Vesseur) To: psarc@sac.sfbay.sun.com Subject: Re: 2004/137 Submillisecond Ping Resolution Date: Fri, 20 Feb 2004 17:37:19 +0100 Content-Length: 1383 > If anyone can convince printf() to lose the '.' I'll be most > happy. A small programming inconvenience... > In the meantime, it is compatible with the > previous Solarig ping output. I'm sorry to be a nit-picking pain in the rear, but I realy think this looks stupid, so... "compatible" with previous output? root@spar 12# ping -s enigma 56 3 PING enigma: 56 data bytes 64 bytes from enigma.Holland (129.159.201.43): icmp_seq=0. time=39. ms 64 bytes from enigma.Holland (129.159.201.43): icmp_seq=1. time=29. ms 64 bytes from enigma.Holland (129.159.201.43): icmp_seq=2. time=34. ms ----enigma PING Statistics---- 3 packets transmitted, 3 packets received, 0% packet loss round-trip (ms) min/avg/max = 29/34/39 root@spar 14# ping -s enigma 2000 3 PING enigma: 2000 data bytes 2008 bytes from enigma.Holland (129.159.201.43): icmp_seq=1. time=103. ms 2008 bytes from enigma.Holland (129.159.201.43): icmp_seq=2. time=104. ms ----enigma PING Statistics---- 3 packets transmitted, 2 packets received, 33% packet loss round-trip (ms) min/avg/max = 103/103/104 The dot on the "bytes from" line is from a "%d." which is not rounded as far as I can see. Probably put there for the same reason someone put a dot after "icmp_seq=%d." (end-of-line at the time.) The summary line does not contain dots (and avg is not rounded but chopped). Joep From sacadmin Fri Feb 20 09:14:44 2004 From: Bill Sommerfeld To: Joep.Vesseur@sun.com (Joep Vesseur) cc: psarc@sac.sfbay.sun.com Subject: Re: 2004/137 Submillisecond Ping Resolution Date: Fri, 20 Feb 2004 12:09:43 -0500 Content-Length: 475 I'm going to humbly suggest that it would be worthwhile for everyone considering sending something to this case to go off and read http://a.mongers.org/clueful/1999-phk-bikeshed . Since I've already done that, I'll weigh in and second Glenn's "Match BSD" request. Note that BSD uses "%.3f" format (3 digits after the decimal point) while the samples from the proposed version use %#.3g" (3 significant digits); and I think "%.3f" looks better in this case.. - Bill From sacadmin Mon Mar 1 06:38:40 2004 Date: Mon, 01 Mar 2004 14:30:37 +0000 From: Jeremy Harris User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3) Gecko/20030314 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sommerfeld@east.sun.com CC: Joep Vesseur , psarc@sac.sfbay.sun.com, Glenn Skinner Subject: Re: 2004/137 Submillisecond Ping Resolution Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 245 Just to recap: - The summary line will include a standard-deviation value; values will be in BSD order. - I do not wish to match BSD in displaying fixed microsecond precision. - Hostnames will be output as per current behaviour. -Jeremy From sacadmin Wed Mar 3 10:52:15 2004 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 3 Mar 2004 13:47:06 -0500 From: James Carlson To: psarc@sac.sfbay.sun.com cc: jeremy.harris@sun.com Subject: 2004/137 Submillisecond Ping Resolution Content-Length: 403 This fast-track case was approved during ARC business at today's meeting. As approved, the specification for the output format is not compatible with the BSD and Linux variants. -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677