System Memory Usage

Intermediate Buffers

When idle, the driver consumes very little memory (see OS/2 Driver INIT processing). When a capture session starts, the driver allocates some system global memory for its exclusive use. This memory is allocated in 64K segments and is permanently resident (locked) during entire capture session. The driver creates its intermediate buffers there. The total number of segments allocated is controlled by NTRACE.EXE application when it starts the capture session.

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:

  1. in sliced protocol mode, take slice size, otherwise take the maximum frame size for your network;
  2. round it up to double word boundary;
  3. add 16 to take in account headers;
  4. divide 65536 by that number and take the integer part of the result.
This calculation gives the number of buffers per 64K segment. The total can be calculated as a product of this number and number of segments.

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.

GDT Usage

GDT stands for Global Descriptors Table. GDT contains selectors to memory objects addressable at any time. This is why GDT selectors are so important for driver/application communications. GDT holds up to 8192 selectors and by nature is a global system object, so all the drivers and kernel routines have to share it.

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:

Unfortunately, GDT selectors can not be acquired and released at application time (this is what Physical Device Driver manual states, though it may be true for OS/2 versions before 2.0 only). This limitation dictates a strategy chosen. There is a maximal number of GDT selectors to reserve at system initialization time.

© 2000 Golden Code Development Corporation.  ALL RIGHTS RESERVED