Overview
Every Exinda appliance needs to maintain a queue of packets for each policy within their respective virtual circuits when shaping traffic as specified by the policies.
This article describes the different queuing methods used for the Exinda multi-processor appliance.
Information
There are three different queuing methods to address the needs of different use scenarios when using a multi-processor appliance.
- Single Queue Mode is the default. It is suitable for environments that require < 1.5 Gbps of traffic shaping.
- Multi-Queue Mode is suitable for environments that require 10 Gbps of traffic shaping and have many flows per virtual circuit. Education institutions are ideal for this queuing mode.
- Multi per VC Queue Mode is suitable for environments that require < 5 Gbps of traffic shaping, and there are potentially fewer flows per virtual circuit. For example, when the bandwidth of a particular virtual circuit is tested using a single-flow generator, such as speedtest.net.
The mode can be modified via CLI: Optimizer.
Single Queue Mode
The single queue mode uses a single global policy queue in memory to handle the traffic shaping of all virtual circuits. The bandwidth limit is due to limitations of accessing global memory with appropriate memory locks.
Multi-Queue Mode
The multi-queue mode uses one policy queue per CPU where the flows of a given virtual circuit are divided evenly among the policy queues. This eliminates the cross processor locking of global memory by distributing the policy queues among the processors. A single processor handles each flow within each policy.
Each CPU processes 1/N of each virtual circuit’s traffic, where N is the number of CPUs.
For example, if the virtual circuit is specified in the Optimizer as having 10 Mbps bandwidth, in an appliance with four CPUs, each CPU policy queue will be allowed 10 Mbps/4 = 2.5 Mbps per CPU.
In order to have even distribution, it assumes multiple flows that can be distributed among the N CPUs. This queueing method is not suitable for environments where customers validate the amount of bandwidth they receive by sending a single long flow through their virtual circuit.
In this case, the flow is handled by a single CPU, and the other CPUs are idle. It then appears that they are getting 1/N of the amount of traffic that they are expecting even though, in more realistic use of the network, where the flows can be distributed more evenly, they will get the appropriate amount of bandwidth.
Multi per VC Queue Mode
The multi per VC queue mode uses one policy queue per CPU, where each virtual circuit is assigned to a single policy queue. That is, the virtual circuits are distributed amongst the policy queues, but any given virtual circuit exists on a single policy queue. The flows for any given virtual circuit will be handled by a single CPU policy queue. Therefore, the flow will not be limited to 1/N of the traffic when a single flow is tested.
CAUTION
Each virtual circuit is assigned to individual policy queues and any given virtual circuit cannot use a policy queue that it has not been assigned to. Therefore, the virtual circuits cannot be oversubscribed, that is the sum of the desired bandwidths for the virtual circuits cannot be higher than the specified bandwidth of the circuit. This is because there can be no automatic redistribution of minimum bandwidth among the virtual circuits when the virtual circuits are oversubscribed.
If the circuits are oversubscribed, then the shaping queuing mode will revert to the multi-queue mode.