The Swimming Pool and the Drain Pipe

With the introduction of Network Monitor 3.2, we have introduced a new feature that allows us to buffer frames so that packets are not dropped. While this is a wonderful improvement this new feature introduces some side effects that you may be interested in.

First there was just a Drain Pipe

Before NM3.2, we had only a Drain Pipe. The problem was that if you tried to cram enough network data through that pipe, it could overflow and drop packets. This was a problem we wanted to fix for NM3.2, so we built up a swimming pool around our drain pipe. As long as the pipe can drain the information quickly enough the swimming pool will never fill up. But if a burst of data comes in and the speed of the information overwhelms the drain pipe, the swimming pool can hold the data until the drain has time to process that information.

Why not a Liquid Plumber Instead?

Data could not be processed in the first place due to two halves of the same resource problem: the CPU and the Network Speed. The CPU speed amounts to the size of the drain pipe, and the Network Speed to the rate at which you are dumping in water. If your CPU can’t keep up, then it may not be able to process the frames quickly enough. And on the other side of the seesaw, if the rate of network data is too fast then you may have the same problem regardless of how fast your CPU is. So there can always be a bottle neck given a fast enough network data rate, or an over utilized CPU.

How Big is this Swimming Pool?

This is actually a very good question because as you may be asking, what if my whole disk fills up? Currently we’ve limited the size of the capture buffer to 20 Gigabytes. You can also change this value via the registry if you need to. That registry key is a DWORD and it located here:

HKCUSoftwareMicrosoftNetmon3SettingsCaptureRootChainCaptureSizeLimit

The value of the registry key is the maximum size of the capture buffer in MB. We will also honor the MinDiskQuotaPercentage which by default is set to stop when only 2% of the free disk space is left. When either limit it reached, the new incoming frames will be dropped.

Things that Effect Draining Speed

In general if you are capturing data with no filters the speed at which we can drain the swimming pool is the fastest. As soon as you apply a capture filter, we must inspect each packet and determine if it passes. The more complex the filter, the more time it takes to process each packet. Therefore this will affect the rate at which the pool can fill up. When you start capturing, you can look at the pending frame count and determine if it is rising. If it is, then you may be in a situation where your swimming pool will continue to fill up over time. Of course traffic is not always predictable, but you should be able to get confidence about your particular capturing scenario.

Capturing and Applying Filters

Another thing you may notice is that one you stop a capture, any pending data in the buffer will continue to be processed until its emptied. With NMCap we will continue to process frames until all pending frames are done. The same holds true when taking a capture with the API. In fact we have created two options to determine how you want StopCapture to react. You can now stop immediately or stop when the pending data is cleared out. When applying a capture filter we actually keep track of the packet as it enters the buffer, so that the filter is applied correctly in regards to when you applied it as opposed to when the packet is actually inspected.

Swimming Season is Open

The best thing about this new feature is that you can be confident that you have gathered all the frames from a network trace. In the rare case there are dropped frames, then the number of dropped frames will be displayed for you in the UI and when using NMCap.

Comments

• Anonymous
  January 01, 2003
  thanks