Joint IEEE-SA and ITU Workshop on Ethernet
Overview of IEEE 802.1Qbv
Time Aware Shaping
Don Pannell,
Principal Systems Architect
Marvell Semiconductor
Geneva, Switzerland, 13 July 2013
Need/Desire/Goal of Qbv
Get The Lowest Latency Possible – Any Way
Possible
Want Many Long, ~32 hop, Daisy Chains
Small 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
2
How Fast Can A Bridge Go?
Total time for the Critical frame is:
Internal delay of the Bridge
Plus the time to transmit the max size interfering frame
Plus the time to get the bits down a 100 meter cable
Tx of max frame overlaps the Rx of the Critical frame
Detailed analysis is shown in
http://www.ieee802.org/1/files/public/docs2011/newpannell-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
3
How Fast If No Interference?
Total time for the Critical frame is:
Internal delay of the Bridge
Plus the time to transmit the largest frame size of the
Critical stream
Plus 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 Bridges
Since most Critical streams use small frames this is a
great improvement
And the Critical stream frame size can be part of the
‘Engineering of the Network’
Geneva, Switzerland, 2 13 July 2013
4
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 Delay
With 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
5
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
Geneva, Switzerland, 2 13 July 2013
6
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
Bridge
t0-16.000 uSec
n
m
AVB Bridge
7
Inside an Qbv Bridge (example)
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
Bridge
t0-3.664 uSec
16.000-12.336=
n
m
AVB Bridge
8
300+20 bytes = 2.560
Inside an Qbv Bridge (example)
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
Bridge
t0-1.104 uSec
3.664-2.560=
64+20 bytes = 672
n
m
AVB Bridge
9
Inside an Qbv Bridge (example)
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
Bridge
t0-0.432 uSec
1.104-0.672=
64+20 bytes = 672
n
m
AVB Bridge
10
Inside an Qbv Bridge (example)
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
Bridge
t0
n
m
AVB Bridge
11
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 guaranteed
With Qbv the improved latency can be guaranteed
Cut-through only works when the target ports are
idle and Qbv does exactly that – thus the
guarantee
With Cut-through the Bridge latency is:
Geneva, Switzerland, 2 13 July 2013
12
Latency By The Numbers
Non-Qbv Bridge Latency is 13.898 uSec
Due to the Max Size interfering frame
Store & Forward Qbv Bridge Latency is 4.122 uSec
Assuming a 300 byte maximum size AVB/TSN frame
This number will go up with increasing Critical frame sizes
Cut Through Qbv Bridge Latency is 2.074 uSec!
Assuming a 64 byte Cut Through Point
This number does NOT change due to frame size!
And this performance can be Guaranteed!
Geneva, Switzerland, 2 13 July 2013
13
Latency By The Numbers
Qbv supports the lowest latency possible
But only if the network is ‘Engineered’
It won’t work for all topologies
And 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’ timing
Multiple timing ‘gate’ windows will be supported per port
with each window having nSec configuration resolution
TSN Bridges already have network timing information by
their support of IEEE 802.1AS
Geneva, Switzerland, 2 13 July 2013
14
Questions?
Geneva, Switzerland, 2 13 July 2013
15