Geneva, Switzerland, 13 July 2013

Overview of IEEE 802.1QbvTime Aware Shaping

Don Pannell,Principal Systems Architect

Marvell Semiconductor

Joint IEEE-SA and ITU Workshop on Ethernet

Geneva, Switzerland, 2 13 July 2013 2

Need/Desire/Goal of Qbv

Get The Lowest Latency Possible – Any Way Possible

Want Many Long, ~32 hop, Daisy ChainsSmall Bursts of frames at known regular intervals (e.g., a 40 uSec long burst of data every 125 uSec)

Willing to Engineer Network Segments to meet this goal

Non-Engineered (i.e., Consumer) Networks will not be able to depend on this very low latency as it can’t be guaranteed in their Networks

The Network Structure and Usage will have to be Engineered, Managed and Controlled

Geneva, Switzerland, 2 13 July 2013 3

How Fast Can A Bridge Go?

Total time for the Critical frame is:Internal delay of the BridgePlus the time to transmit the max size interfering frame Plus the time to get the bits down a 100 meter cableTx of max frame overlaps the Rx of the Critical frameDetailed analysis is shown in http://www.ieee802.org/1/files/public/docs2011/new-pannell-latency-options-0311-v1.pdf

The max size interfering frame is the determining factor

How does this improve if the interfering frame wasn’t there?

Geneva, Switzerland, 2 13 July 2013 4

How Fast If No Interference?

Total time for the Critical frame is:Internal delay of the BridgePlus the time to transmit the largest frame size of the Critical streamPlus the time to get the bits down a 100 meter cable

Now the max size of the Critical frame is the determining factor

This is due to the Store & Forward nature of most BridgesSince most Critical streams use small frames this is a great improvementAnd the Critical stream frame size can be part of the ‘Engineering of the Network’

Geneva, Switzerland, 2 13 July 2013 5

Interfering Frames are the Problem

Some GE speed examples with numbers:The Bridge Latency with Interfering Frame is:

Equal to the Size of Interfering frame + Bridge Delay + Cable Delay (max size interfering frame = 1522 bytes) With Max Size interfering frame this is 13.898 uSec

The Bridge Latency without an Interfering Frame is:Equal to the Size of AVB/TSN frame + Bridge Delay + Cable DelayWith a 300 byte AVB/TSN frame this is 4.122 uSec

Can we get rid of the Interfering Frames to get the better latency?

Geneva, Switzerland, 2 13 July 2013 6

Qbv – Time Aware Shaper

Qbv takes advantage of the target low latency data pattern

i.e., That they are typically Small Bursts of frames at known regular intervals (for example: a 40 uSec long burst of data every 125 uSec)

Then use this information to delay the start of non-Critical frames just before the start of the Burst Window

This insures the egress port is idle so the Critical burst is not interfered – All interference is removed!Smart designs can allow non-Critical frames that fit to use the available bandwidth

7

Inside an Qbv Bridge (example)Qbv Time Progression – Fig 1

• At Bridge t0-16.000 uSec before the start of the Burst Window the Green AVB Class B frames are being Shaped (gated) by Qav and can’t Transmit

• So the Red Max size non-AVB High Priority frame ‘n’ can start

AVB Bridge

Bridge t0-16.000 uSec

n m

8

Qbv Time Progression – Fig 2• At Bridge t0-3.664 uSec before the start of the Burst Window the interfering Red Non-AVB frame is done

• Now the Green AVB Class B frames are available for transmit with enough credits to burst two frames

16.000-12.336= 300+20 bytes = 2.560

AVB Bridge

Bridge t0-3.664 uSec

n m

Inside an Qbv Bridge (example)

9

Qbv Time Progression – Fig 3• At Bridge t0-1.104 uSec before the start of the Burst Window the 1st Green AVB Class B frame is done

• Now the next Green AVB Class B frame has credit to go, but it can’t because there is not enough time before t0 - the start of the Burst Window nor can the Red ‘m’ frame

• But the 64 byte low priority Yellow non-AVB frame can go and does

3.664-2.560= 64+20 bytes = 672

AVB Bridge

Bridge t0-1.104 uSec

n m

Inside an Qbv Bridge (example)

10

Qbv Time Progression – Fig 4• At Bridge t0-0.432 uSec before the start of the Burst Window the 64 byte Yellow frame is done

• The next Green AVB Class B frame has credit to go, but it still can’t because there is not enough time before t0 (its credits are actually increasing) nor can the Red ‘m’ frame

• The next low priority 64 byte frame can’t go either – not enough time

1.104-0.672= 64+20 bytes = 672

AVB Bridge

Bridge t0-0.432 uSec

n m

Inside an Qbv Bridge (example)

11

Qbv Time Progression – Fig 5• At Bridge t0 - the start of the Burst Window the port is idle so the newly arrived Blue Critical frames are allowed to egress without any interference!

• The burst of Blue frames will continue as long as Qbv leaves it queue open for transmission as they are the highest priority queue

AVB Bridge

Bridge t0

n m

Inside an Qbv Bridge (example)

Geneva, Switzerland, 2 13 July 2013 12

Qbv – With Cut Through

Cut-through bridges generally don’t help normal network performance due to the low percentage of improved latency and that this improvement cannot be guaranteedWith Qbv the improved latency can be guaranteedCut-through only works when the target ports are idle and Qbv does exactly that – thus the guaranteeWith Cut-through the Bridge latency is:

Geneva, Switzerland, 2 13 July 2013 13

Latency By The Numbers

Non-Qbv Bridge Latency is 13.898 uSecDue to the Max Size interfering frame

Store & Forward Qbv Bridge Latency is 4.122 uSecAssuming a 300 byte maximum size AVB/TSN frameThis number will go up with increasing Critical frame sizes

Cut Through Qbv Bridge Latency is 2.074 uSec!Assuming a 64 byte Cut Through PointThis number does NOT change due to frame size!And this performance can be Guaranteed!

Geneva, Switzerland, 2 13 July 2013 14

Latency By The Numbers

Qbv supports the lowest latency possibleBut only if the network is ‘Engineered’

It won’t work for all topologiesAnd proper configuration of the timing ‘gates’ is not easy

The Qbv Standard will support Control of the timing ‘gates’ – but will not figure the timing out

3rd Party tools will be required to compute the ‘gate’ timingMultiple timing ‘gate’ windows will be supported per port with each window having nSec configuration resolutionTSN Bridges already have network timing information by their support of IEEE 802.1AS

Geneva, Switzerland, 2 13 July 2013 15

Questions?