Knowledge Base

Gray periods in the timeline graph.

Question

I have gray periods in the timeline graph. What does that mean?

Solution

A gray (ie: background) period in a time graph means that PingPlotter didn't expect any data from that host during that timeframe (think "disabled"). There are a few possibilities why this might happen:

PingPlotter was paused

PingPlotter (or MultiPing) was paused or stopped during this time. We obviously don't expect any results if we're not sending out any requests, so the background shows gray. Upon resuming a trace, PingPlotter will automatically notate the timeline graph with a comment that reads "Resume from sleep/ powersave" in these instances.

There was a route change

A route change happened, and another router was participating in routing data rather than the router you're currently looking at. Setting "Samples to Include" to a small value (or 0) will allow you to double-click on that period in the time graph, which will show the route that was participating at that point in time.

Often, you'll have a single hop that normally "oscillates" between several similar IP addresses. If this is the case, it might make sense to combine these two (or three) routers so that PingPlotter treats them as a single router. To do this, right-click on the hop in question and select "Add route change mask." This will add a mask and combine data for the routers existing in the current route. This should remove the gray periods.

There was a high volume of requests

PingPlotter uses the packet drivers installed on the device. For default ICMP packets, we use ICMP.dll — the same as your traditional command line ping. However, there are instances where the Windows ICMP.dll or other resources will back up with outstanding requests. This can be for a number of reasons, but PingPlotter may contribute through:

• Aggressive trace intervals (<1s)
• Low packet send delay
• Exceedingly large target lists (100+ targets)

If it does not appear the grey areas are caused by a paused trace or a change in route, the Windows ICMP.dll may be to blame. Here are some possible fixes:

• If it isn’t already, set the trace interval to 2.5 seconds. Usually, you’ll be safe with a one-second trace interval, but sometimes it can help to increase the time between packets just to see where you’re at.
• In PingPlotter’s settings, under Engine. You will find a “Packet Send Delay” option. By default, it’s set to “Auto,” which means PingPlotter is sending out packets as fast as possible. Set this value to 10-20 ms. By doing this, you’ll cause the engine to wait for a brief moment (you won’t even notice it) before sending out its packets.
• Reduce the number of trace targets. PingPlotter itself can normally handle over a thousand targets (trust us, we’ve seen it). However, if hardware resources on the machine can’t handle the high volume, you may need to reduce the number of targets.
• You can also make use of different named configurations to generate packets using different protocols, which will help ease stress on ICMP.dll. You can either set all your targets to a different protocol or split them up between ICMP, UDP, and TCP. Read more about named configurations here.

As always, if you need any help, feel free to email us by using Help -> Email PingPlotter Support. Make sure you include as many details as you can!