The number of intermediate buffers determines the driver's capture capability. To estimate the number of buffers driver creates for a specified number of 64K segments, do the following calculations:
The intermediate buffers are organized into two lists: empty buffers list and loaded buffers list. At start time, the empty buffers list holds all the buffers constructed, and the loaded buffers list is empty.
Every time a frame comes, it needs a separate intermediate buffer. The driver operates independently from the NTRACE.EXE application when receiving frames. It looks first for a buffer in the empty buffers list. Filled up buffer is queued up for application processing into the loaded buffers list.
The NTRACE.EXE application, in its turn, waits for buffers to appear in the loaded buffers list. It copies the payload of the buffer into its own large capture buffer and returns the intermediate buffer into the empty buffers list.
The rate of incoming frames determines the rate of consumption of empty buffers. The speed of application determines the rate of returning empty buffers. Obviously, there can be situations when incoming frames consume buffers faster then application is able to process and return in time. Eventually, the driver runs out of empty frames. In this case it borrows the oldest loaded frame for reuse. This case is counted as a frame loss.
When the capture session stops, the driver releases the global memory used for internal buffers back to the system. As a feedback, it posts internal buffers usage statistics to the application to be made visible. This may make a next capture session more effective.
The capture session needs a number of GDT selectors. Every 64K segment of global system memory allocated for use as intermediate buffers requires a GDT selector. Besides that, three GDT selectors are used to access the large capture buffer in ring 3 while the capture session is active: