Switching delay added by each L2 switch

[Vivek Batra]

Hi,

We need to provide specific information to our customer that how much delay will be added by L2 switch (2960) while switching packets from one port to other port.

Let say we are forwaring voice RTP stream which needs 64 Kbps of bandwidth, when it passes through switch, what will be the delay added by L2?

I know there could be various factors but considering no traffic congestion and swithcing capacity of L2 switch, Is there any parameter to get this calculated?

- Vivek

[Vivek Batra]

No one....

- Vivek

[pwwiddicombe]

Even using 100 Meg only, there would be negligible delay in a L2 environment in passing through one additional switch - in the order of possibly several milliseconds (assuming no other congestion, and that speed/duplex are properly negotiated or hardcoded both sides).

Even though the voice stream is 64k, you will be packetizing into Ethernet frames which travel at the configured (or negotiated) network speed, which will be much higher.  Delay would be same if the stream was 16k or 128k.

The only caveat is that OTHER traffic on the network, if excessive, could cause delays, jitter, etc.; if that is anticipated, then QoS and prioritization might be needed.  However, the addition of your switch would not affect that scenario.

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Traditionally one factor to consider with any store-and-forward switch not using cut-through switching, the whole frame needs to be received before it can be forwared.  How long this take depends on the ingress link speed and the size of the frame.

For example, if ingress frame was 1518 bytes arriving on 10 Mbps it would take 1,518 * 8 / 10,000,000 = 1.2144 ms.  The switch would also add latency for making its switching decision, but that's probably in the microsecond range.  FE would add 1/10 the latency, and gig would add 1/100 the latency.  (If fact, when FE came to the market, cut through switching sort of fell out of vogue until it's reappearance for ultra low switching latency that some applications now want.)

As VoIP frames tend to be small, a switch's store-and-forward latency isn't usually even a consideration.  More of a concern is other traffic that might interleave itself with VoIP traffic, and its impact.  To mitigate such impact, instead of worrying about a switch's latency, worry about that other traffic and worry about a QoS policy that "guarantees" SLA for VoIP.