Commit 18666653 authored by Maciej Lipinski's avatar Maciej Lipinski

presentation: WR presentation for IEEE AVB - hopefully final version

parent c7e36f60
......@@ -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 broadcasted to all the end devices (nodes)
\item CM is sent in advance ({\bf Granuality Window})
\item CM is broadcast to all the end devices (nodes)
\item CM is sent in advance ({\bf Granularity 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 independant
\item Accelerators at CERN are grouped into 4 accelerator networks which should be as independent
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 acceleratro network need to receive all the Control Messages
\item All the devices in a given accelerator 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 100us } \\ \hline
Granuality Window (GW) & {\bf 1000us } & {\bf 200us } \\ \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 $<$ 1500 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 mechanims
\item delay-request two-step mechanism
\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 caste 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 100us},
\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 $<$ 1500 bytes} (in FEC scheme:
encoded into 4 frames of size 300-1000 bytes and sent in burst), sent every {\bf 200us},
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
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment