Reduce number of queues?

[RicN]

In a switch with, say, eight queues on the interface ports and you are not using QoS at all or perhaps just use two QoS priorities (normal and high), would it be to any benefit to reduce the number of queues on the switch?

If I understand it correctly the switch allocates some amount of port buffer memory to each queue, and I am wondering if a large number of unused queues would actually decrease the switch forwarding capacity?

[Mohieddin Kharnoub]

Hi

Great way of thinking,

however,

I'm not sure if your question is same to :
Would be the Switches with 4 Queues faster than the ones with 8 ? :)

For my understanding, if the QoS been used, then its great to have 8 Queues so we can have 8 Levels even we are not using all of them.

And i can't find any reason for the allocated buffer to be a factor in reducing the Switching/Forwarding speed, since all been considered in the design.

Anyway, the Lower Priority Queues should go after the Higher priority one.

Good Luck !!!

[RicN]

Thank you for a good reply!

What I was after was something like this:

Assume that each port has a total of e.g. 100kb memory available to use as a buffer. If this 100kb is divided by eight queues then we would have a lower amount of buffer memory available per queue, than if we would have used only four queues.

If my network only uses for example 802.1p priorities 0 and 3 then six of the interface queues would always be empty. And that would lead to a greater risk to the buffers on the two active queues would be full and frames dropped.

If this is how it is working of course! :) That is why I am asking.

[Mohieddin Kharnoub]

Hi

I guess you have an important point of view here.

Basically, switches varies between each other in many Key features and Specifications, and Buffer is a MAJOR one.

I've read before in Juniper CoS how they size buffer fullness and the percentage of queue buffer fullness of high packets after which high packets are dropped.

Good Luck !!!

[Jeff Carrell]

"if my network only uses for example 802.1p priorities 0 and 3 then six of the interface queues would always be empty. And that would lead to a greater risk to the buffers on the two active queues would be full and frames dropped."


it doesn't work that way, when the switch starts its processing cycle, it looks (ahead) at the queues and starts processing based on what's in the queue...if there is nothing in the 1st queue, it moves to the next and so on...so if there is data in q3, then the switch sees that and starts process q3 using q7,q6,q5,q4 times and its q3 time, then q0 (as its next), then q2,q1 times are used still processing q0 (normal pri)...and then the process starts over again...

this is called weighted round robin (WRR) queuing...very efficient use of time...no queue gets all the cycle of time and every queue gets a percentage of the processing cycle...

the result, the switch is never "idle" between queues, it is always processing queues...


hth...jeff

[André Beck]

Hi RicN,

"capacity" is the word things revolve around here. Indeed there are traffic flows where the available buffer space in an egress queue can't be large enough, that's usually throughput-oriented bulk traffic. On the other hand, queues (especially priority queues) for realtime traffic *have* to be short, as it makes no sense to hold up packets in them forever and neither to starve other queues.

So I expect a switch vendor to supply detailed information as to how the hardware in question is implemented regarding its QoS features, how the memory is split between ingress and egress queues, how the dequeueing at the egress is scheduled, how the triggers for WRED, ECN and tail drop are wired (as well as how 802.3 PAUSE kicks in) and what is to be tuned for which traffic class. I haven't yet read up on what HP provides here (didn't have a real QoS-sensitive deployment with ProCurves so far). What I'd expect is something akin to the Cisco 3560/3750 class docs, where you can essentially tune your heart out after having a tough time understanding the hardware Qos model (and they like to supply auto-macros and whole design guides that apply and describe the best practices).

There's no simple answer without knowing the details of a switch implementation and the default configuration. When there's really fixed chunks of memory wasted by unused egress queues and maximizing throughput as well as sustaining microbursts/overfeeds longer are the main goals, then "reducing the number of queues" could well help (but I'd actually expect to be able to assign the memory to queues on demand, sizing unused ones to zero in the process, and sizing the used queues so they best serve their respective traffic classes).

HTH,
Andre.

[Matt Hobbs]

On certain switches with smaller buffers, there can be a benefit in consolidating the queues if there are frequent Gig to 100 transfers. (Such as the 2800). If the small queues get filled, packets get dropped and transfer rates suffer.

[RicN]

Thank you all for your answers!


Jeff:

>this is called weighted round robin (WRR) queuing...
>very efficient use of time...no queue gets all the
>cycle of time and every queue gets a percentage of
>the processing cycle...

What you are describing is of course correct, but what I was wondering was not the actual scheduling of the queues, but the the memory allocations to them.

Andre, very good answer! And it would indeed be very interesting to know how Procurve has implemented the things you have mentioned. I wonder if the Procurve documentation give that much technical details?

Andre:

>but I'd actually expect to be able to assign the
>memory to queues on demand, sizing unused ones to
>zero in the process, and sizing the used queues
>so they best serve their respective traffic classes

I suppose that would be the key to it all. If that is how it is actually implemented then you would not have to worry about the not-used queues wasted memory resources.


Do anyone know by the way how much memory a port has available to buffers on a, say, 5400?

[André Beck]

Re RicN,

>>but I'd actually expect to be able to assign the
>>memory to queues on demand, sizing unused ones to
>>zero in the process, and sizing the used queues
>>so they best serve their respective traffic classes
>
>I suppose that would be the key to it all.
>If that is how it is actually implemented
>then you would not have to worry about the
>not-used queues wasted memory resources.

The yl/zl class is doing this to some extend via "GMB" (guaranteed minimum bandwidth) configuration (see "Port Traffic Controls" in the management guide). This should be read together with the 70 pages of QoS chapter in the advanced traffic management guide. For this platform, it's probably best to first configure the number of queues your QoS design really needs and then size them using GMB. Apparently it redistributes available memory to the queues as needed, even down to zeroing a queue (but I'm not sure, it might just define the WRR dequeueing schedule).

Now, just for the fun of it, compare to this chapter:

http://www.cisco.com/en/US/docs/switches/lan/catalyst3750e_3560e/software/release/12.2_46_se/configuration/guide/swqos.html

Especially the part starting at "Queueing and scheduling overview"...

HTH,
Andre.

[Manfred Arndt]

Hi RicN,

Yes, for high performance deployments with link speed mismatches (e.g. Gig-to-100Mb) or oversubscribed links there is a benefit in reducing the number of queues if supported on the switch. This can help reduce packet loss due to microburst congestion caused by TCP data applications on the default priority queue.

On certain HP ProCurve switches you can choose 2, 4, or 8 queue modes to optimize how the memory buffer are assigned per queue. For example, if you are only using 3 priorities (say voice, video and data), then best performance will be achieved in the 4 queue mode.

To set the number of queues to 4 on the HP 5400/6200/3500 switch series use:

# qos queue-config 4-queues

Here is the link to the 5400 reviewers guide that describes the per-port buffer sizes (pg 30):

http://www.hp.com/rnd/pdfs/ProCurve_Switch_5400zl_Series_Reviewers_Guide.pdf

Cheers,
Manfred