Reduce number of queues?

[Manfred Arndt]

Hi RicN,

Sorry, almost forgot to respond to your second question...

Changing the number of queues does not affect the switch forwarding capacity.

What it does is change the amount of memory that is assigned to the various queues.

Deeper buffers can help smooth out short TCP data bursts that exceed the available egress link capacity.

Cheers,
Manfred

[RicN]

Hello Manfred and thank you for your reply!

This was the information I originaly wanted. If I understand you correctly then the high number of queues on for example the 5400 could in fact result in somewhat lower performance, i.e. more potential drops due to each queue is smaller?

Is it correct that the buffer sizes are fixed and not dynamicly relocated? For example, if queue 7 buffer is empty and never used, and all other queues are full - then the memory for queue 7 would not be used?

Can I use the bandwidth-min command to change the queue-sizes or does that command does something else?

Grateful for any more information, since this is very interesting.

[Manfred Arndt]

Hi RicN,

Correct, the buffer sizes are fixed and not dynamicaly relocated on the HP ProCurve 8200/6200/5400/3500 switch series. In your example, the memory in queue 7 is not used and held in reserve in case priority 7 traffic were to arrive when the system is congested.

This is important to insure that the switch performs well when forwarding traffic on multiple ports and/or queues simultaneously to prevent starvation that can cause applications to fail or time out.

The bandwidth-min command does not affect the queue sizes. What it does is adjust the queue servicing algorithm to insure that lower priority packets are not starved when there is lots of higher priority traffic.

If you disable the bandwidth-min command on an interface, you turn the queue servicing into strict priority.

# no interface bandwidth-min output

Bandwidth min is enabled by default, so that the switch does a weighted fair queueing.


Hope that helps,
Manfred

[RicN]

Thank you again for your answers!

Could it be said the a good general recommendation should be to tune the number of queue to the avarage number of priority values used on the network?

Or would it generaly be best to leave it alone?

As I read from the paper you supplied earlier it seems like the queue sizes would not really change except for the normal queue? That is, if I am using all eight queues then each of the not-normal queue would have around 70 kB of memory (for example queue for prio 7), but if I lower the amount of queues to four then the queue for prio-value 6 and 7 seems to have also only 70 kb (all memory "won" is taken to the normal queue). I assume that this could mean that if I later use both prio-values 6 and 7 then the queue for both of them would be of larger risk to be filled?

[Manfred Arndt]

Reducing the number of queues is a good recommendation for many/most customers.

The 4 queue model works well if you have or are thinking of using VoIP (and/or real-time video).

The 2 queue model works best for high-performance applications that require no QoS.

The high priority queues are intended for real-time latency or jitter sensitive applications, like VoIP and video conferencing. High priority queues are not recommended for use with bursty TCP protocols or video on demand.

Most real time applications send a low rate of smoothly distributed packets. For these, 70KB is much more than required and rarely at risk of being filled (even when supporting a large number of concurrent real-time sessions).

[RicN]

Thanks for your answers Manfred! I see from your profile that you work for HP and it is very nice to be able to get this kind of help on the forums!

I have some more questions in this matter:

1. If I am having, say, four queues and 802.1p priority level 6 and 7 is sharing the same queue - will there be any difference to the handling of frames INSIDE that queue, that is - will the prio 7 frames get any better treatment than frames with prio 6? Or does everything that ends up in the same queue use the same first in - first out ordinary sequence?

2. The buffer memory that makes up the actual queues on the switch, is that something that is physicaly bound to the port or is a part of the main RAM of the switch?

3. It was interesting to see the memory allocation sizes for the 5400-family, and I am wondering if this is different between different switch models? Does the older/cheaper models have less buffer memory attached to the ports?

4. Does it make any difference to what criterion I bind to the QOS value when speaking of performance (VLAN, incoming port, IP address, tcp/udp ports)? What I mean is, it should (?) be easier for the switch if I map a certain 802.1p priority to an entire VLAN, than if I say that traffic with a certain TCP destination port should have some priority.

Do I lose something if I make use of QOS markings depending of layer 4 information, which I guess, makes the switch forced to inspect each frame much deeper?

[Manfred Arndt]

1. If multiple 802.1p priorities are sharing the same queue - then everything that ends up in the same queue use the same first in - first out sequence.

2. The queue buffer memory is dedicated "high-speed" memory bound to the ports. This memory is significantly more expensive than the main CPU RAM, as it must keep up with the fabric packet rates (in excess of 10GbE).

3. The amount of buffer memory can vary dramatically between different switches and competitor models.

While most switches can keep up at full line rates with IXIA packet blaster tests where all ports are set at the same speed. Many will perform less than ideal under load in real-world situations with bursty TCP traffic (due to link-speed mismatch)...resulting in packet loss which can impact the aggregate network performance.

The 5400 Intelligent Edge family has significantly deeper buffer memory than most other models.

4. The 5400 family can keep up with full line rate traffic, independant of the number of packet classification and/or ACL rules you define. So go ahead and define QoS and security rules that meet your needs and don't worry about the impact on performance.

[RicN]

Many thanks again for the answers!

I think most of my questions regarding QoS has now solved!

>The 5400 family can keep up with full line
>rate traffic, independant of the number of
>packet classification and/or ACL rules you
>define.

That is of course very impressive by the 5400-family! Does it differ between different Procurve switches at what subjects you can base 802.1p at? That is, can a more ordinary edge switch (2800 series for example) also classify at layer 4 and do it with good performance?