In some *very* isolated cases, I've seen a difference in packet loss based on the *contents* of the packets. Ping -t uses a repeating sequence of "abcdefghijklmnopqurstuvw" while Ping Plotter uses repeating $AA. You can change Ping Plotter to be the same as Ping by creating a text file with the same thing that PING sends (ie: create the file with abcdefghijklmnopqrstuvw in it), and then go to Advanced options and change the packet cargo to use this file. This is kind of a long shot, though, as in all cases where I've seen this make a difference, Ping Plotter was used to simulate and extrodinary bytes sequence that stimulated the packet loss, and the $AA wasn't that sequence. This is worth trying those - since it's quite easy to do.<br><br>Also, I'm wondering if this same packet loss results when you use a smaller packet size (ie: 32 bytes or similar).<br><br>Just to put my mind at ease here, as well, please re-check to make sure there are not multiple threads involved. You should be able to recognize a non-threaded Ping Plotter by seeing that the results come in very much 1 at a time. When using threads, your hop 12 may come in before the timeouts in hop 10 and 11 happen. When not using threads, hop 10 and 11 have to return results (timeouts in your case) before hop 12 can even be dispatched. This should be very noticable in the performance of your trace. Once you've verified that this is happening, make sure your "Trace Interval" on the main screen gives you enough time to make it through all hosts. Ideally, you'd have this set to be at least (Number of hops times Timeout Speed (set in advanced options)) plus some headroom. For example, in your case, you might have your Timeout Speed set to 1000ms (1 second), you'd want to have your trace interval set to at least 15 seconds (13 hops at 1 second each plus some headroom).<br><br>I'm not saying that Ping Plotter never makes mistakes, but in 99.8% of the cases where PING and Ping Plotter show different results, it's been some kind of a networking issue and the packet loss shown in Ping Plotter is *actual* packet loss. Finding the difference often helps troubleshoot the network and shows ways that ICMP echo requests can be lost (which doesn't always translate into packet loss on other kinds of traffic, to be sure).<br><br>Let me know if any of this gets rid of the packet loss in Ping Plotter.<br><br>