Skip to content
Projects
Groups
Snippets
Help
Loading...
Sign in
Toggle navigation
W
White Rabbit Standardization
Project
Project
Details
Activity
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
0
Issues
0
List
Board
Labels
Milestones
Merge Requests
0
Merge Requests
0
Wiki
Wiki
image/svg+xml
Discourse
Discourse
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Commits
Issue Boards
Open sidebar
Projects
White Rabbit Standardization
Commits
18666653
Commit
18666653
authored
May 11, 2012
by
Maciej Lipinski
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
presentation: WR presentation for IEEE AVB - hopefully final version
parent
c7e36f60
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
124 additions
and
42 deletions
+124
-42
WhiteRabbit.tex
presentations/WR_IEEE-AVB-York2012/WhiteRabbit.tex
+124
-42
No files found.
presentations/WR_IEEE-AVB-York2012/WhiteRabbit.tex
View file @
18666653
...
...
@@ -3,8 +3,8 @@
\setbeamertemplate
{
navigation symbols
}{}
\usepackage
{
pgfpages
}
\setbeameroption
{
show notes
}
\setbeameroption
{
show notes on second screen=right
}
%
\setbeameroption{show notes}
%
\setbeameroption{show notes on second screen=right}
\usetheme
{
Warsaw
}
...
...
@@ -70,17 +70,15 @@
\institute
{
\begin{center}
on behalf of
\\
{
\bf
Maciej Lipi
\'
{
n
}
ski
}
\\
Hardware and Timing Section / ~~~ Institute of Electronic Systems
\\
~~~~~~~~~~~~~~~~~~~~~CERN ~~~~~~~~~~~~~~~~ / Warsaw University of Technology
\\
\end{center}
}
\author
{
Rodney Cummings
\\
Maciej Lipi
\'
{
n
}
ski
\\
% on behalf of Maciej Lipi\'{n}ski
}
\date
{
May 2012
}
\date
{
presented by Rodney Cummings
\\
May 2012
}
...
...
@@ -149,6 +147,89 @@ delivery and network-wide, transparent, high-accuracy timing distribution.
The White Rabbit Network (WRN) is based on existing standards, namely Ethernet,
Synchronous Ethernet and PTP.
}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%\section{Introduction}
%\subsection{}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
{
Why White Rabbit?
}
\begin{itemize}
\item
White Rabbit started within renovation effort of General Machine Timing (GMT) -- the
current control and timing system at CERN
\item
GMT works great but has some disadvantages:
\begin{itemize}
\item
Based on RS-422, low speed (500kbps)
\item
Unidirectional communication (controller
$
-
>
$
end stations)
\item
Separate network required for end station
$
-
>
$
controller communication
\item
Custom design, complicated maintenance
\end{itemize}
\item
White Rabbit is meant to solve these problems
\end{itemize}
\end{frame}
\note
{
\tiny
{
\it
CERN started thinking about a suitable successor for the
timing system of the LHC injectors in 2006. The main
drawbacks of the current system (General Machine Timing)
are its limited bandwidth
(500 kb/s on a multi-drop RS-422 line) and its lack of bi-
directionality. Limited bandwidth results in an otherwise
unnecessary proliferation of different timing networks for
each accelerator, and this extra complication propagates
through low-level software making maintenance harder.
Lack of bi-directionality has two main disadvantages:
\begin{itemize}
\item
Stand-alone timing receivers, though requested by
clients, cannot be designed because there is no way to
read status information back from the cards remotely.
\item
Cabling delay compensation cannot be automated.
Instead, manual calibration using traveling clocks
is used, resulting in manpower-intensive error-prone
campaigns.
\end{itemize}
At the same time, GSI began brainstorming about the timing system for the FAIR facility,
and since other collaborations with CERN were already underway it seemed natural to try
to come up with a single timing system which served both sets of requirements.
The similarities of the two complexes in terms of timing precision and sequencing
needs helped in this regard. The requirement for a high-bandwidth full-duplex link
quickly resulted in the choice of Ethernet for the physical layer. Indeed, Ethernet is not
only a very high-performance and well known solution but also one where long-term support
is beyond doubt, and this was an important requirement for both CERN and GSI.
\\
}
Reference [8]
}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%\section{Introduction}
%\subsection{}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
{
When/where White Rabbit?
}
\begin{itemize}
\item
Current status of the project:
\begin{itemize}
\item
{
\bf
NOW:
}
WR-based timing installation deployed for CERN Neutrino to Gran Sasso (CNGS) project
\item
{
\bf
End of 2012:
}
(commercial) release of (basic) WR~Switch
\end{itemize}
\item
Foreseen applications: CERN, GSI (Darmstadt, Germany) and DESY (Gamma-Ray and Cosmic-Ray experiment)
\item
Potential applications: Cherenkov Telescope Array,
The Large High Altitude Air Shower Observatory,
The~Cubic Kilometre Neutrino Telescope
\end{itemize}
\end{frame}
\note
[itemize]
{
\item
See project website for news
\\
www.ohwr.org/projects/white-rabbit
\item
See presentations from the latest workshop for the latest developments
\\
www.ohwr.org/projects/white-rabbit/wiki/Mar2012Meeting
\item
See a list of potential users
\\
www.ohwr.org/projects/white-rabbit/wiki/WRUsers
}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section
{
CERN Control System
}
...
...
@@ -261,8 +342,8 @@ central control system.
\begin{itemize}
\item
Each event (ID) has a trigger time associated
\item
A set of events is sent as a single
{
\bf
Control Message (CM)
}
\item
CM is broadcast
ed
to all the end devices (nodes)
\item
CM is sent in advance (
{
\bf
Granu
al
ity Window
}
)
\item
CM is broadcast to all the end devices (nodes)
\item
CM is sent in advance (
{
\bf
Granu
lar
ity Window
}
)
\end{itemize}
\end{frame}
...
...
@@ -332,13 +413,13 @@ central control system.
\end{frame}
\note
[itemize]
{
\item
Accelerators at CERN are grouped into 4 accelerator networks which should be as independ
a
nt
\item
Accelerators at CERN are grouped into 4 accelerator networks which should be as independ
e
nt
as possible but interaction between them is inherent
\item
Devices connected to each accelerator network are controlled (mostly) by it's own Data Master
\item
Since LIC provides beam to LHC/AD/ISOLDE, the LIC Data Master sometimes needs to control
devices connected to other networks
\item
Communication between Data Masters is necessary
\item
All the devices in a given accelerat
ro
network need to receive all the Control Messages
\item
All the devices in a given accelerat
or
network need to receive all the Control Messages
sent to this network (the device decides how/whether to use events from the Control Message)
\item
Some Control Messages need to be send on more then one accelerator networks (the case when
LIC Data Master controls devices in more then one network during injection)
...
...
@@ -357,12 +438,12 @@ central control system.
\textbf
{
Requirement
}
&
{
\bf
Case 1
}
&
{
\bf
Case 2
}
\\
\hline
Synchronization accuracy
&
\multicolumn
{
2
}{
|c|
}{
\bf
sub-ns
}
\\
\hline
Synchronization precision
&
\multicolumn
{
2
}{
|c|
}{
\bf
picoseconds
}
\\
\hline
Granuality Window (GW)
&
{
\bf
1000us
}
&
{
\bf
1
00us
}
\\
\hline
Granuality Window (GW)
&
{
\bf
1000us
}
&
{
\bf
2
00us
}
\\
\hline
Network span
&
{
\bf
10km
}
&
{
\bf
2km
}
\\
\hline
End device number
&
\multicolumn
{
2
}{
|c|
}{
\bf
2000
}
\\
\hline
Control Message size
&
{
\bf
1500-5000 bytes
}&
{
\bf
300-
500 bytes
}
\\
\hline
Control Message size
&
{
\bf
1500-5000 bytes
}&
{
\bf
$
<
$
1
500 bytes
}
\\
\hline
Control Message frequency
&
\multicolumn
{
2
}{
|c|
}{
\bf
every GW
}
\\
\hline
Data Master
/Stream number
&
{
\bf
4
}
&
{
\bf
a few
}
\\
\hline
Data Master
number
&
{
\bf
4
}
&
{
\bf
1
}
\\
\hline
Traffic characteristics
&
\multicolumn
{
2
}{
|c|
}{
\bf
one-to-alot
}
\\
\hline
Number of CM lost per year
&
\multicolumn
{
2
}{
|c|
}{
\bf
1
}
\\
\hline
\end{tabular}
...
...
@@ -484,7 +565,7 @@ to Gran Sasso (CNGS) experiment.
\end{itemize}
\item
Extension to PTP -- defined as PTP Profile:
{
\bf
WRPTP
}
\begin{itemize}
\item
delay-request two-step mechani
ms
\item
delay-request two-step mechani
sm
\item
modified BMC (reliability-oriented)
\item
Mapping onto Ethernet
\end{itemize}
...
...
@@ -622,8 +703,8 @@ preliminary tests through 2013
\end{itemize}
\item
FEC + eRSTP/eLACP = seamless redundancy (FEC used in both ideas)
\item
Redundant data received in end stations
\item
{
\bf
Solutions take advantage of
broadcast characteristic of Control Data
traffic (within VLAN)
}
\item
{
\bf
Solutions take advantage of
\textcolor
{
red
}{
broadcast characteristic
}
of Control Data
traffic (within VLAN)
}
\end{itemize}
\end{frame}
...
...
@@ -634,12 +715,11 @@ preliminary tests through 2013
\begin{frame}
{
eLACP (short explanation)
}
\begin{center}
Control Message encoded into 4 Ethernet Frames (F1,F2,F3,F4). Reception of any two
enables to recover Control Message.
enables to recover Control Message.
{
\it
(PhD thesis by Cesar Prados)
}
\end{center}
\begin{center}
\includegraphics
[width=.
8
\textwidth]
{
fig/WR
_
LA
_
3.ps
}
\includegraphics
[width=.
75
\textwidth]
{
fig/WR
_
LA
_
3.ps
}
\end{center}
\end{frame}
\note
[itemize]
{
...
...
@@ -695,12 +775,11 @@ preliminary tests through 2013
\begin{itemize}
\item
eRSTP+FEC=seamless redundancy
$
<
=
>
$
max 2 frames
\item
500 bytes message (288 byte FEC) -- max re-conf
:
{
\bf
$
\approx
$
2.3us
}
\item
eRSTP+FEC=seamless redundancy
$
<
=
>
$
max 2 frames
(
{
\bf
broadcast critical data
}
)
\item
500 bytes message (288 byte FEC) -- max re-conf
{
\bf
$
\approx
$
2.3us
}
\item
Possible only if information about alternative/backup ports known a priori and
switch-over in hardware --
{
\bf
possible since we consider only broadcast traffic
(within VLAN) and no update of Forwarding Data Base is required
}
\item
{
\bf
The simplest
}
case below
switch-over in hardware --
{
\bf
\textcolor
{
red
}{
only broadcast
}
traffic (within VLAN) and no update of Forwarding Data Base is required
}
\end{itemize}
\begin{center}
\includegraphics
[width=.7\textwidth]
{
fig/RSTPsimple.ps
}
...
...
@@ -811,6 +890,8 @@ preliminary tests through 2013
\column
{
0.75
\textwidth
}
\begin{itemize}
\item
Broadcast communication: DM-to-nodes
\item
Multicast communication: nodes-to-DM
\item
Multicast address used for Data Masters (DM-A and DM-B)
\item
Seamless switch over between DMs: time-triggered synchronous reconfiguration
of 1-Layer switches
...
...
@@ -852,10 +933,6 @@ preliminary tests through 2013
{
\bf
AVB gen2 vs. WR
}
\end{center}
\vspace
{
0.6cm
}
\begin{center}
Both solutions, WR and AVB, work only over WR/AVB-compatible devices but provide interoperability
with standard Ethernet.
\end{center}
\end{frame}
...
...
@@ -873,6 +950,7 @@ preliminary tests through 2013
\item
AVB: logical syntonization is optional
\item
WR: request-response mechanism (no technical problem to align with AVB)
\item
AVB: peer-delay mechanism
\item
WR: phase alignment
\end{itemize}
\item
Similarities
\begin{itemize}
...
...
@@ -896,7 +974,7 @@ preliminary tests through 2013
\item
WR statically reserves (single) resource for all (altogether) Control Data (streams)
\item
Static stream (Control Data) reservation in WR
\item
Stream in WR is broadcast within a VLAN - stream in WR defined by VLAN
\item
WR Control Data distribution -- a corner cas
t
e of AVB Stream
\item
WR Control Data distribution -- a corner case of AVB Stream
\end{itemize}
\end{frame}
...
...
@@ -926,8 +1004,7 @@ preliminary tests through 2013
\begin{itemize}
\item
Strict priority output queue scheduling for Control Data is considered
\item
Time Aware Shaper (both at end stations and WR Switches) is worth considering for WR,
especially to fulfill "Case 2" requirements from slide 10
\item
Time Aware Shaper (both at end stations and WR Switches) is worth considering for WR
\item
Preemption was considered in WR, it is currently stated an obsolete idea
\item
Cut-through forwarding in WR Switches
\end{itemize}
...
...
@@ -955,19 +1032,21 @@ preliminary tests through 2013
\subsection
{}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
{
WR requirements in AVB terms (Case 1)
}
\footnotesize
\begin{itemize}
\item
max latency:
{
\bf
$
<
$
1000us
}
over
{
\bf
$
\approx
$
5 hops
}
@
{
\bf
1Gbps
}
\item
max latency:
{
\bf
$
<
$
1000us
}
over
{
\bf
$
\approx
$
5 hops
\footnote
{
hop=switch
}
}
@
{
\bf
1Gbps
}
\\
\item
guaranteed latency over
{
\bf
tree-like (meshed) topology
}
\item
main network characteristics:
{
\bf
2000 end stations
}
, links of max 10km,
max
network span
:
{
\bf
10km
}
max
controller-to-node distance
:
{
\bf
10km
}
\item
traffic characteristics: "control data" size (payload):
{
\bf
500-5000 bytes
}
(in FEC scheme:
encoded into 4 or 6 frames of size 300-1500 bytes and sent in burst),
$
\approx
$
8
"control streams" (defined within separate VLANs) sent every
{
\bf
1000us
}
,
critical stream is one-to-many, "normal data" size (payload): ~1500 bytes
\item
Support for VLAN and multicast
\item
Seamless redundancy or ultra fast dynamic reconfiguration (
$
<
$
2.3 us)
\item
Seamless redundancy or ultra fast dynamic reconfiguration
for critical data
(
$
<
$
2.3 us)
\item
Sub-nanosecond accuracy and picoseconds precision of synchronization
% \item {\it Case 2: max latency {\bf $<$ 100us} over {\bf $\approx$ 4 hops} @ {\bf 1Gbps} and {\bf 2km}
% with "control data" size (payload): {\bf 200-500 bytes} and {\bf 1 stream}}
\end{itemize}
\end{frame}
...
...
@@ -977,17 +1056,17 @@ preliminary tests through 2013
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
{
WR requirements in AVB terms (Case 2)
}
\footnotesize
\begin{itemize}
\item
max latency:
{
\bf
100us
}
over
{
\bf
$
\approx
$
4 hops
}
@
{
\bf
1Gbps
}
\item
max latency:
{
\bf
200us
}
over
{
\bf
$
\approx
$
5 hops
\footnote
{
hop=switch
}
}
@
{
\bf
1Gbps
}
\item
guaranteed latency over
{
\bf
tree-like (meshed) topology
}
\item
main network characteristics:
{
\bf
2000 end stations
}
, links of max 2km,
max
network span
:
{
\bf
2km
}
\item
traffic characteristics: "control data" size (payload):
{
\bf
200-
500 bytes
}
(in FEC scheme:
encoded into 4 frames of size
150-300 bytes and sent in burst), sent every
{
\bf
1
00us
}
,
\item
main network characteristics:
{
\bf
2000
-4000
end stations
}
, links of max 2km,
max
controller-to-node distance
:
{
\bf
2km
}
\item
traffic characteristics: "control data" size (payload):
{
\bf
$
<
$
1
500 bytes
}
(in FEC scheme:
encoded into 4 frames of size
300-1000 bytes and sent in burst), sent every
{
\bf
2
00us
}
,
critical stream is one-to-many, "normal data" size (payload): ~1500 bytes
\item
Support for VLAN and multicast
\item
Seamless redundancy or ultra fast dynamic reconfiguration (
$
<
$
2.3 us)
\item
Seamless redundancy or ultra fast dynamic reconfiguration
for critical data
(
$
<
$
2.3 us)
\item
Sub-nanosecond accuracy and picoseconds precision of synchronization
\end{itemize}
...
...
@@ -1030,6 +1109,7 @@ preliminary tests through 2013
\end{frame}
\note
[enumerate]
{
\tiny
\item
White Rabbit Project homepage
\\
http://www.ohwr.org/projects/white-rabbit
\item
White Rabbit Specification
\\
http://www.ohwr.org/documents/21
\item
White Rabbit Standardization wiki
\\
ttp://www.ohwr.org/projects/wr-std/wiki/WRinAVBgen2
...
...
@@ -1038,8 +1118,10 @@ preliminary tests through 2013
\item
White Rabbit and Robustness
\\
http://www.ohwr.org/documents/103
\item
Topology Resolution, Redundant Links Handling and Fast Convergence in White Rabbit Network
\\
http://www.ohwr.org/documents/103
\item
THE WHITE RABBIT PROJECT (ICALEPCS2009)
\\
http://www.ohwr.org/attachments/312/
}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\ No newline at end of file
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment