Pause during trace with unresponsive hops

Posted by: jbrunette

Pause during trace with unresponsive hops - 06/07/00 01:48 PM

Not sure if this is an issue or if it's by design or if it's "just the way it is" :-) ...<br><br>When tracing to a host like updates.zdnet.com (where there are unresponsive "hops" just before the target hop), ping plotter seems to pause for about 5-7 seconds or so after a few passes, then perform a few more passes and pause again, etc. I imagine this has to do with waiting for those unresponsive hops to time-out and threads and such. Are there any plans in the future to somehow eliminate those pauses? Thanks :-)<br><br>Jason<br><br>
Posted by: Pete Ness

Re: Pause during trace with unresponsive hops - 06/07/00 02:18 PM

This is by design. By default, Ping Plotter allocates a maximum of 45 threads it can use. Each ping request takes one thread. As a ping returns, the thread can be re-used for another ping. After 5 minutes of inactivity (ie: there are more threads allocated than being used), a thread is freed. If you're running under NT, you can see your thread count under the task manager...<br><br>If there are a lot of unresponsive hops, then there's an opportunity for a LOT of threads to be tied up waiting for responses. If all 45 threads are being used, every trace attempt will be discarded until there are free threads (this is so it doesn't queue up a bunch of requests that finally get serviced a LONG time after they're asked for - you can imagine if your service rate was less than your request rate that this would continue to grow forever). If only 44 threads are in use, then the entire batch needed for the next request (in the case of zd.net, that's about 25 of them) are pushed into a queue that is serviced as threads free up.<br><br>Anytime the thread queue is full, there's an asterisk displayed beside the word "Querying" in the status bar.<br><br>BTW, DNS lookups also use a thread - and this comes from the pool of 45.<br><br>Now there's a couple ways to reduce the overloading of the thread queues.<br><br>The most resource friendly way is to go to advanced options and change your "Timeout Speed" to something other than 10 seconds. If you get responses back in 350 ms, it's pretty safe to reduce this to something like 2000. This means that any thread will only wait 2 seconds instead of 10 for a packet to timeout. Depending on your network, a lower number may work also.<br><br>A less resource friendly way to handle this is to up the number of threads that Ping Plotter will allocate. Under Windows NT (or 2000), this doesn't seem to cause much problem, but under Windows 98, too many threads allocated seems to actually lock up the system at some point. Keep in mind also that fast attack rates can really use a LOT of threads if you have a lot of timeouts and a highe "Timeout speed".<br><br>To change the number of threads that Ping Plotter can use, you have to manually edit the PingPlotter.INI file. Add the following to the advanced section:<br><br>[Advanced]<br>MaxThreadCount = 45<br><br>(Obviously, change the 45 to the number you want). <br><br>Keep in mind that the initial burst that happens on hop 1 will always use 35 threads. Changing this to a number less than 35 can severely affect your starting performance if there are any timeouts. (Although some fast responding hops in the route can make it so it's not noticeable.)<br><br>Hope all this makes sense!<br><br>