As a background, I work in the Field Services section of our State Governments WAN branch. We have over 2000 routers, running RIP, with connections that include Point to Point, Frame Relay and ATM. I discovered PP in October 98 and have used it consistently ever since, it is quite simply the 'only' program out there that performs this function to this degree of success. There are some suggestions I'd like to make though. <br><br>There have been occasions when an active route would drop causing the network to decide the IP Address being pinged was not within it's network and send the packets to the outside world (our internet connection). The Firewall would see the packets going out and, knowing that it 'was' within the network, send them back. The network again decides to send them outside, this repeats until the packets TTL is exhausted and is discarded. The problem is that when the 32 hops are recorded in the graph portion of the PP window it expands upward and conceals the trace window. There is not presently a method of grabbing that window to pull it back down, nor is it possible to grab the edge of the window before it expands. I know this because I tried! Maybe the window could be forcibly limited to its present size but allow the graphs to shrink to fit?<br><br>Sometimes, while plotting a specific address, the route will drop without it showing up on PP. I recently had a coworker disconnect his modem from the line without a hint of this occuring on PP. After PP is reset and restarted though it shows up, any ideas?<br><br>I find myself trying to double click on the desired address instead of hitting the trace button.<br><br>Could buttons be included to automatically expand and retract PP's graph\trace windows? The click and drag option is nice, but I find myself wishing for a easier way. This would help tremendously when multiple PP windows are open.<br><br>I sometimes use PP in conjuction with the throughput graph on "NetMedic" to check the utilization and throughput on circuits. Could a running throughput graph located directly below the others be included?. It would then be extremely easy to compare the throughput with the ping return times on the other graphs. During high throughput periods the response times will be useful in determining if the circuits are configured as contracted. <br> <br>The Ping Plotter program has become my most useful tool in troubleshooting, remotely, our circuits. Keep up the good work!<br><br><br>