Andrea Planet
Home Page

True Ping

SourceForge

Welcome to the Web Page
of the open-source program 
TRUE PING  

Idea: The standard ping program of Windows 9x, NT and 2000 calculate wrong the timings. Windows XP does a better job. So True Ping is exactly the same as ping except that it calculate better the timings. The program use also a random buffer (that changes at every ping) so it give more realistic results under a network with realtime compression typically with Dial-Up connections.

Technical Details

Example:
Example of standard PING:

C:\>ping andreaplanet.com

Pinging andreaplanet.com [66.175.18.161] with 32 bytes of data:

Reply from 66.175.18.161: bytes=32 time=220ms TTL=228
Reply from 66.175.18.161: bytes=32 time=211ms TTL=228
Reply from 66.175.18.161: bytes=32 time=210ms TTL=228
Reply from 66.175.18.161: bytes=32 time=210ms TTL=228

Ping statistics for 66.175.18.161:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 210ms, Maximum = 220ms, Average = 212ms

Example of TPING:

C:\>tping andreaplanet.com

Pinging andreaplanet.com [66.175.18.161] with 32 bytes of data:

Reply from 66.175.18.161: bytes=32 time 226.87 ms (231 ms), TTL=228
Reply from 66.175.18.161: bytes=32 time 226.43 ms (220 ms), TTL=228
Reply from 66.175.18.161: bytes=32 time 226.59 ms (220 ms), TTL=228
Reply from 66.175.18.161: bytes=32 time 226.11 ms (221 ms), TTL=228
Reply from 66.175.18.161: bytes=32 time 226.28 ms (220 ms), TTL=228

Ping statistics for 66.175.18.161
Packets: Sent = 5, Received = 5, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 226.11ms, Maximum = 226.87ms, Average = 226.46ms

As you can see there are several milliseconds of difference, and especially with low values (20 ms) this can be up to 50% wrong values. TPing report two values, the first calculated exactly and the second
using the standard ping program under Windows 9x, NT or 2000.

Bad timings of the standard Ping program:
First of all the standard ping program use bad timings, this is the reason why the values have always an error of around 5 ms. For example:

C:\>tping maya.ngi.it -c

Pinging maya.ngi.it [194.177.103.3] with 32 bytes of data: 

Reply from 194.177.103.3: bytes=32 time 30.72 ms (30 ms) TTL=194 
Reply from 194.177.103.3: bytes=32 time 26.82 ms (20 ms) TTL=194 
Reply from 194.177.103.3: bytes=32 time 25.46 ms (20 ms) TTL=194 
Reply from 194.177.103.3: bytes=32 time 25.47 ms (20 ms) TTL=194 
Reply from 194.177.103.3: bytes=32 time 25.66 ms (20 ms) TTL=194 

As you see there are about 5 ms of difference due to the bad timing (its because the ping program use GetTickCount()). The ping under Windows XP does not have this problem. 


Realtime compression:
If you have a connection with real time compression then the ping values are not realistic. This because the standard ping use a simple buffer of type  'abcdefghijklmnopqrstuvw'. In a realistic situation the buffer is more random and it is different at each sent. By default the tping program use always a different random buffer. 

Example with standard buffer like in the standard ping:

C:\>tping maya.ngi.it -c

Pinging maya.ngi.it [194.177.103.3] with 32 bytes of data:

Reply from 194.177.103.3: bytes=32 time 31.91 ms (30 ms), TTL=253
Reply from 194.177.103.3: bytes=32 time 24.15 ms (20 ms), TTL=253
Reply from 194.177.103.3: bytes=32 time 26.52 ms (20 ms), TTL=253
Reply from 194.177.103.3: bytes=32 time 24.49 ms (20 ms), TTL=253
Reply from 194.177.103.3: bytes=32 time 24.26 ms (20 ms), TTL=253

Ping statistics for 194.177.103.3
Packets: Sent = 5, Received = 5, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 24.15ms, Maximum = 31.91ms, Average = 26.27ms


Example using a random buffer (different at each ping):

C:\>tping maya.ngi.it

Pinging maya.ngi.it [194.177.103.3] with 32 bytes of data:

Reply from 194.177.103.3: bytes=32 time 32.91 ms (30 ms), TTL=253
Reply from 194.177.103.3: bytes=32 time 33.93 ms (30 ms), TTL=253
Reply from 194.177.103.3: bytes=32 time 32.00 ms (30 ms), TTL=253
Reply from 194.177.103.3: bytes=32 time 32.65 ms (30 ms), TTL=253
Reply from 194.177.103.3: bytes=32 time 32.45 ms (30 ms), TTL=253

Ping statistics for 194.177.103.3
Packets: Sent = 5, Received = 5, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 32.00ms, Maximum = 33.93ms, Average = 32.79ms

As you can see there is a difference of more than 7 ms. ISDN connection with compression and multilink on single chanel. Firewall ZoneAlarm (the ping is higher). With no compression the two pings are equal in timings.

Using a second thread of the receiving:
In a real program the reading of the network data is in a different thread than the sending data. The standard ping program use the same thread, first sent then receive. By default the tping use a different thread (but using -p you can use only one). 
The differences are within the local lan, where the ping is very low.

Scheduling of the processes under Windows:
Due to the scheduling of the processes under Windows the timings are often different (because of the wakeup time necessary for the sleeping process). Using the localhost and the parameter -d 0, there is no delay between the ping, so the responses are faster because the program have a different scheduling (no sleep at all).

C:\>tping localhost

Pinging 127.0.0.1 with 32 bytes of data:

Reply from 127.0.0.1: bytes=32 time 0.21 ms (0 ms), TTL=128
Reply from 127.0.0.1: bytes=32 time 0.12 ms (0 ms), TTL=128
Reply from 127.0.0.1: bytes=32 time 0.13 ms (0 ms), TTL=128
Reply from 127.0.0.1: bytes=32 time 0.14 ms (0 ms), TTL=128
Reply from 127.0.0.1: bytes=32 time 0.16 ms (0 ms), TTL=128

C:\>tping localhost -d 0

Pinging 127.0.0.1 with 32 bytes of data:

Reply from 127.0.0.1: bytes=32 time 0.21 ms (0 ms), TTL=128
Reply from 127.0.0.1: bytes=32 time 0.04 ms (0 ms), TTL=128
Reply from 127.0.0.1: bytes=32 time 0.04 ms (0 ms), TTL=128
Reply from 127.0.0.1: bytes=32 time 0.04 ms (0 ms), TTL=128
Reply from 127.0.0.1: bytes=32 time 0.03 ms (0 ms), TTL=128

Note: To have a very high sent rate use:

tping hostOnLocalLan -d 0 -n 1000 > out.txt

Jitter Formula :

tping calculate two different Jitter values. A Real Time value printed at every received packet and a Statistical value printed at the end of the program.

The Real Time Jitter value is updated everytime a packet is received using the formula described in RFC 1889:
   Jitter = Jitter + (abs( ElapsedTime - OldElapsedTime ) - Jitter) / 16

The Statistical Jitter value is calculated on the first 100 packets received usinge the statistical variance formula:
   Jitter Statistical = SquareRootOf(SumOf((ElapsedTime[i]-Average)^2)/(ReceivedPacketCount-1))

 

 

Download
Contact the author for any suggestions or improvements on the code.

Main Program

tping1.16.zip
(28 KByte)

True Ping 1.16
The little command line program. Copy it to your Path for easy use.
tping-source 1.16.zip
(74 KByte)
Source code of True Ping 1.16 - C++ with Visual Studio 2017
License Open-Source - GNU General Public License version 2
True Ping is also hosted on http://sourceforge.net/projects/tping/

 

Screenshot

History

Release 1.16 - 2 February 2018:
News: Added -S sourceAddress option.
News: Added manifest file for Administrative permission with UAC.

Release 1.14 - October 2006:
News: If Ctrl+C is pressed program print statistics and terminate.
News: If Ctrl+Break is pressed program print statistics but does not terminate.
Update: The program doesnt stop if an error occurs on sending i.e. "Destination Host Unreachable".

Release 1.13 - 16 September 2006:
News: Added Realtime Jitter calculation as described in RFC 1889.
News: Added Timestamp option printed at every received packet.
BugFix: Fixed bug in Jitter calculation.

18 July 2006 - Release 1.12:
News: Added Jitter calculation on the first 100 received packets.
News: Added Set Don't Fragment Flag in Packet.
Update: Changed Banner.

15 December 2004 - Release 1.11:
News: Implemented option -a for reverse hostname resolving.
News: Implemented option -z count that skips the first count received packets in the
statistic calculation. Useful if the first packets are slower than the average.

Release 1.10:
News: Implemented option -v for Type of Service.
News: Implemented return value of the program.
if ERRORLEVEL 1 THEN the remote server replied successfully.
Useful for batch calls to check if the server is available.

Release 1.09:
Update: Added correct HOP calculation if starting TTL=31 on remote server
Bug fix: some messages was fixed (grammatically)
Bug fix: the Average is calculated correctly now, in case of Packet Loss.

Release 1.08:
Bug fix: the parameter -t was handled wrong in previous release
Bug fix: the parameter  -j let start TTL from 2 and not 1, so the first HOP was not counted.

Release 1.07:
News:  The program with option -j report a very little trace route but with only one ping for each hop. 

Release 1.06:
News: The program report also the number of HOPS (i.e. number of routers between your 
computer and the machine you are pinging) based on the TTL. 

Release 1.05:
News: Option for delay between ping. 
Update: If a parameter in the commandline is wrong you get an error message instead of ignoring the parameter.

Release 1.04:
News: Option for using the standard Buffer like in the ping 'abcdefghiklmnopqrstuvw' or a random buffer that is different at each sent (default random buffer). By using the same buffer the software compression on ISDN for example reduce the ping time to a not realistic value.
With 32 bytes of buffer the difference can be of 8 ms for 32 bytes (31 ms instead of 23 ms).

Release 1.03:
News: Statistics like in standard ping
News: Option for using a different thread (default yes)
News: Buffer is randomly generated
News: Improvements of the code.


Release 1.02:
Bugfix: Error Thread creation under Windows 9x.

Release 1.01:
Bugfix: TTL value is read correctly.

Release 1.00:
First Release


Copyright © 2001-2018 Andrea Denzler - denzler(at)usa.net