Gary,

Thanks for your prompt and helpful reply with links to supporting resources.

Yes, when I run a continuous ping from command line [ping stingerj.rdhinc.net -t], I get from 3% - 10% packet loss.

I agree with you: the PingPlotter results don't show much of a problem. When I experience the problem with my application, there is a direct correlation with the lost packets reported in the ping.

The times at which my ping reports lost packets usually matches periods in which PingPlotter indicates lost packets at one of the intermediate hops.

I run PingPlotter on a computer with a wired connection to our Internet router. I am pretty confident that my network, and the connection to my ISP is solid. I also believe that the connection at the last hop is good. My gut is something in the middle is congested and causing the lost packets in my command - and affecting performance of my application.

Many of the supporting PingPlotter resources say to ignore "red herring" lost packets if they don't impact the last hop. Can you please elaborate on that? Why should lost packets between intermediate hops, that don't affect the last hop, be ignored if the ultimately manifest in last packets back to my router?

Here is one clue that I would like to describe to my ISP: before I experienced these lost packets (about two months ago), tracert showed a different path to the same destination than the packets take now.

I suspect my ISP has changed its "peering" which is causing these lost packets.

I will keep reviewing the PingPlotter support materials for ideas on how to report a specific issue about which I can seek support from my ISP.

Please let me know if you have any additional ideas.