Any TCP/IP or UDP errors that impacted PingPlotter's data collection will be shown as lost packets in PingPlotter. There are a few numbers in Netstat that have a direct relationship to PingPlotter data.

Destination Unreachable - in UDP mode, this will increment based reaching the final target.

Time Exceeded - intermediate hops use Time Exceeded packet, so both ICMP and UDP traces will increment this number pretty quickly.

Echos - Sent - in ICMP mode, each sample will increment this for each hop - so PingPlotter will change this number relatively rapidly - this is the number *sent*, so the number doesn't really mean anything for stability / connection.

There is no direct relationship between "Errors" and PingPlotter data, although if an error happens while sending a PingPlotter packet, it will be captured in PingPlotter.

I would suggest trying to correlate the real-life results with PingPlotter data. When a disconnect happens, go to PingPlotter, right-click the lower graph at the time-point where the disconnect occurred, and then record "Service got disconnected, couldn't reconnect for 30 seconds", or "Painfully slow performance - lasted 10 minutes", or whatever symptom is being observed. After recording a few of these, examine the PingPlotter data for events that might have caused these events - if PingPlotter is showing solid latencies and no packet loss, then the problem might be something that PingPlotter can't help capture (ie: application problems, network problems specific to the application in use, or similar).