My simulation is taking up a lot of memory because there are a lot of packets in the system. How can I quickly tell where the packets are building up in the network using the pkmap stats, pkmap all, and/or pkmap <id> commands?

My simulation is taking up a lot of memory because there are a lot of packets in the system. How can I quickly tell where the packets are building up in the network using the pkmap stats, pkmap all, and/or pkmap <id> commands?

Packets may build up or queue if they are being generated at a rate that is faster than a processing rate at a queue that does not have a fixed size. You may wish to start by examining the rate at which you are generating traffic and considering if this is too fast for your current network configuration.For example, in older versions of OPNET, one somewhat typical cause of this was that workstations by default had an IP forwarding rate of 5,000 packets per second. If you were generating application traffic at a rate greater than 5,000 packets per second, this would have been an unstable queue (that is, packets could build up). The solution was to increase the IP forwarding rate, or reduce the rate of traffic generation.There are currently several ways of using the 'pkmap' command in the OPNET Simulation Debugger (ODB):pkmap allpkmap <id>Starting with OPNET software release 8.0.C PL13, there is a new argument to pkmap: 'stats'Using the 'pkmap stats' command will generate a table listing the number (quantity) of packets owned by a particular object ID in the simulation (processor or queue module, transceiver, etc.) Also, an entry called Simulation Kernel is used to denote all packets owned by the simulation kernel.This command is useful for debugging packet memory leaks, to determine whether there is a packet buildup at a particular module. For additional techniques, you may wish to read the following FAQ:FAQ 554 -- What does a 'Allocation of memory failed; data segment size = XXXX bytes, request = YYYY bytes' recoverable error indicate? What is some general advice for tracking down memory leaks or queues that grow without bound?

DES Kernel->Error Messages/Logs