Contents | Previous | Next

Advanced Topics - Thread Count

When tracing to a host where there are unresponsive "hops" just before the target hop, PingPlotter can seem to pause for about 5-7 seconds or so after a few passes, then perform a few more passes and pause again, etc. Here's an explanation on how PingPlotter allocates threads, and tips on how to reduce the overloading of the thread queues.

By default, PingPlotter 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 (i.e. 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.

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 (for example, in the case of zd.net that's about 25 of them) are pushed into a queue that is serviced as threads free up.

Anytime the thread queue is full, there's an asterisk displayed beside the word "Querying" in the status bar.

By the way, DNS lookups also use a thread and this comes from the pool of 45.

Now there's a couple ways to reduce the overloading of the thread queues.

The most resource friendly way is to go to Edit/Options and in the Packet section 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.

A less resource friendly way to handle this is to up the number of threads that PingPlotter will allocate. Under Windows NT/2K, this doesn't seem to cause much of a 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 high "Timeout speed".

To change the number of threads that PingPlotter can use, you have to manually edit the PingPlotter.INI file. Add the following to the advanced section:

[Advanced]
MaxThreadCount = 45

Obviously in place of 45 above you'd set it to whatever value you want.

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.