MemPool

The “MemPool” parameter specifies the maximum amount of memory which is to be reserved for buffering outgoing frames of data. Unlike the receive buffers, which must be large enough to receive any possible frame (up to the given maximum size), outgoing data need only occupy enough memory to hold itself and a few bytes of overhead for internal management by the LSL and/or board driver that will be transmitting the frame. Consequently, only a single contiguous memory pool is reserved to be shared by all outgoing frames.

The default value for “MemPool” used by LSL is 8192 (or 8Kb). This is not adequate for an AspeNet Server to queue and transmit outgoing data in the most efficient possible manner for any significant number of users. The recommended value is “40K”, representing 40Kb (it could also be expressed as 40960). The given value represents that maximum amount of memory that the LSL will reserve for the memory pool. The actual amount reserved may be less, but by specifying 40K we guarantee that as much as possible up to that amount will be allocated.

Exactly how much memory is allocated to the memory pool is affected by a set limitation of 64Kb on the total aggregate amount of memory that can be reserved by LSL.COM. The LSL requires memory for its own executable code, for miscellaneous uses, for the receive buffers, and for the memory pool. The following formula summarizes the relationship between these competing requirements:

Receive buffers)+(Memory Pool)+(8Kb code & misc.)<64Kb

Subtracting the constant size of the LSL module (6Kb) and miscellaneous-use memory (2Kb) from both sides of the equation, we get:

(Receive buffers) + (Memory Pool) < 56Kb

Receive buffers are next in priority. Every receive buffer actually reserves the given size plus an additional 52 bytes. Thus, the amount of memory reserved for 32 receive buffers with a given size of 638 bytes is: 32 x (638 + 52) = 32 x 690 = 22080 bytes (or nearly 22Kb). Substituting the value of 22Kb into the primary equation gives:

22Kb + (Memory Pool) < 56Kb
or

(Memory Pool) < 34Kb.

From this we know that when using 32 buffers of 638 bytes the size of the memory pool will never exceed about 34Kb.

Can the requested maximum size of the memory pool be reduced? Yes. But doing so may reduce the capacity of the server to transmit information to workstations in a timely manner. On a server with fewer than 30 active users, a reduced memory pool would probably be quite adequate, but we do not recommend ever reducing the requested memory pool size below 20Kb. If not constrained to do otherwise due to DOS memory limitations, the recommended value of 40K should always be used. Too small a memory pool can impede the ability of the network hardware to transmit frames onto the network at peak efficiency, resulting in slower response to workstation requests and possibly delaying the delivery of live trading information.

One additional word of caution needs to be detailed with respect to the loading of the LSL.COM module and its use of DOS memory. Not only is the LSL module limited to a total aggregate usage of 64Kb, but all of the memory it reserves must be contiguous as a whole. That is to say, it must all be allocated in one single block, not in pieces scattered throughout the system's available memory space. If LSL.COM is loaded into conventional DOS memory there will be no problem obtaining all the space it requires. If LSL.COM is loaded into an upper memory region by the DOS LoadHigh command or any other type of memory-manager's “load-it-high” command, the largest single block of upper memory might not be big enough to provide all of the memory the LSL desires.

For example, the recommended server configuration discussed above results in a single 64Kb block of memory containing: 8Kb of LSL code and miscellaneous-use memory, 22Kb for receive buffers, and 34Kb for the memory pool. If the largest upper memory block is only 43Kb in size, then the memory pool, which is lowest in allocation priority, will be reduced by the amount of memory that couldn't be allocated, which is: 64Kb - 43Kb = 21Kb. Applying that reduction to the 34Kb possible allocation size, the memory pool will only get 34Kb - 21Kb, or 13Kb total. That is too low to maintain good performance under pressure, so you may be forced to reduce the declared number of receive buffers, thus shifting the use of some memory from the receive buffers to the memory pool. Experimentation will show what balance provides the best overall performance in any given environment.

Any time LSL.COM is loaded into upper memory, you should observe carefully how successful it is in allocating the desired amount of memory; as it loads, LSL.COM will display both the parameters it was given and the actual allocations that succeeded.