The "Engine" settings control what and how PingPlotter sends data.
The "Packet Type" settings allows you to pick what kind of data you want to send to tailor PingPlotter to your network needs. PingPlotter supports 4 packet types:·
- ICMP using Windows DLL. This method is the traditional method and matches the data that the Windows TRACERT command uses. It works on all Windows operating systems, and is a good balance of reliability and capability. This is reliable with the least CPU usage (on most operating systems). This method will automatically do manual timings on less-than-accurate operating systems to attempt to get accuracy to 1ms. This method does not require administrative rights, and should be the first choice for most users.
- ICMP using Raw Sockets (advanced use only). In some rare cases, the standard Windows method doesn't work. PingPlotter can compose its own ICMP packets - although in most cases this is no more reliable or better than ICMP.DLL. This requires administrative rights and doesn't work reliably on Windows Vista or newer.
- UDP Packets (Unix-Style). This uses ports 33434 – 33500 and closely mirrors Unix’s traceroute command. This method will sometimes allow you to trace to a destination that isn’t reachable via ICMP, or might allow you to reach the internet even if your ISP is blocking ICMP echo requests. Though not the cure-all for "Destination Unreachable" issues, this is worth a try, especially if you’re getting erratic packet loss or unreachable destination. This requires administrative rights, and doesn't work reliably on Windows Vista or newer (including Windows 8).
- TCP Packets. This method gives you the opportunity to send TCP packets. If a firewall is blocking ICMP packets, it’s sometimes possible to get a response using TCP packets instead. TCP is the protocol used for all web browsers in addition to FTP, Telnet, and others. This requires Administrative user rights and the installation of Npcap.
- Trace Via Remote Agent. This method allows you to start traces on a remote machine using the Legacy Remote Agent.
Time to wait for ping replies
This option allows you to fine-tune your performance a little. When PingPlotter sends out a packet, it waits a certain amount of time for a response. The longer it waits, the more resources it needs to use (to keep sockets open), but the more likely that it will get a response By default, PingPlotter will wait for 3 seconds for any packet to return. If the packet doesn't return in 3 seconds, then it is counted as a lost packet. If patience isn't one of your virtues, you can turn this down somewhat. No matter what your value is here, timed out packet will show with the time "9999."
Because of the performance enhancements offered by PingPlotter, it's unlikely that this option needs to be changed. If it's set too low, it can cause misleading data to be generated.
Packet Send Delay
This can be an interesting number to manipulate. It's really meant for "advanced" users, so you don't NEED to change it.
PingPlotter sends out multiple packets at the same time and times everything at once. Actually, it leaves a tiny interval between each packet so as not to completely saturate your bandwidth when it sends out 30 packets. This time interval is adjusted by this parameter. Most of the time, 25ms is good. This falls within realm of what a 28.8 modem can perform. If you've adjusted your packet size, or your connection to the internet is really slow, you might want to crank this number up a little. If you have just oodles of bandwidth, you can crank it down a little. Be aware that a too-small number can adversely affect your data.
The Packet Size can make a considerable difference in latency performance. Normally, you want to use a relatively small number here. The default is 56 bytes, but in some cases, you might need to lower this (especially on TCP port 80 packets, which sometimes get dropped unless they are 40 bytes). 1500 is a lot of data and should be used with great care. A 1500 byte packet means PingPlotter will be sending out 30-50 K per second worth of data, which can cause its own problems (and makes measuring latency more challenging).
If more than one Network Interface is connected to the machine, this option allows you to select which interface PingPlotter will use to send packets.
Start traces as final hop only
Select this option if you only need to ping the final hop. The route will not be mapped. Helpful if you only care if the target is up or down.
TCP Specific Settings
When using TCP packets, you can specify which target port to use. Usually, you’ll want to use port 80 here, but you’re welcome to use any reasonable port. Windows firewall blocks the creation of TCP packets, so you’ll need to use the Npcap packet driver to create packets under that OS (and possibly others).
**Some of the features listed in this topic are only available in PingPlotter Pro and/or PingPlotter Standard. See our product comparison page for more details**