284 lines
16 KiB
TeX
284 lines
16 KiB
TeX
% ! TeX program = lualatex
|
|
\documentclass[a4paper,11pt]{article}
|
|
% packages
|
|
\usepackage{censor}
|
|
\StopCensoring
|
|
\usepackage{fontspec}
|
|
\setmainfont{EB Garamond}
|
|
% for tironian et fallback
|
|
% % \directlua{luaotfload.add_fallback
|
|
% % ("emojifallback",
|
|
% % {"Noto Serif:mode=harf"}
|
|
% % )}
|
|
% % \setmainfont{EB Garamond}[RawFeature={fallback=emojifallback}]
|
|
|
|
\setmonofont[Scale=MatchLowercase]{Deja Vu Sans Mono}
|
|
\usepackage[a4paper,left=2cm,right=2cm,top=\dimexpr15mm+1.5\baselineskip,bottom=2cm]{geometry}
|
|
\setlength{\parindent}{0pt}
|
|
|
|
\usepackage{fancyhdr} % Headers and footers
|
|
\fancyhead[R]{\normalfont \leftmark}
|
|
\fancyhead[L]{}
|
|
\pagestyle{fancy}
|
|
|
|
\usepackage{microtype} % Slightly tweak font spacing for aesthetics
|
|
\usepackage[english]{babel} % Language hyphenation and typographical rules
|
|
\usepackage{xcolor}
|
|
\definecolor{linkblue}{RGB}{0, 64, 128}
|
|
\usepackage[final, colorlinks = false, urlcolor = linkblue]{hyperref}
|
|
% \newcommand{\secref}[1]{\textbf{§~\nameref{#1}}}
|
|
\newcommand{\secref}[1]{\textbf{§\ref{#1}~\nameref{#1}}}
|
|
|
|
\usepackage{mathtools}
|
|
\usepackage{changepage} % adjust margins on the fly
|
|
|
|
\usepackage{minted}
|
|
\usemintedstyle{algol_nu}
|
|
|
|
\usepackage{pgfplots}
|
|
\pgfplotsset{width=\textwidth,compat=1.9}
|
|
|
|
\usepackage{caption}
|
|
\newenvironment{code}{\captionsetup{type=listing}}{}
|
|
\captionsetup[listing]{skip=0pt}
|
|
\setlength{\abovecaptionskip}{5pt}
|
|
\setlength{\belowcaptionskip}{5pt}
|
|
|
|
\usepackage[yyyymmdd]{datetime}
|
|
\renewcommand{\dateseparator}{--}
|
|
|
|
\usepackage{enumitem}
|
|
|
|
\usepackage{titlesec}
|
|
|
|
\author{Andrew Hayes}
|
|
|
|
\begin{document}
|
|
\begin{titlepage}
|
|
\begin{center}
|
|
\hrule
|
|
\vspace*{0.6cm}
|
|
\Huge \textsc{ct420}
|
|
\vspace*{0.6cm}
|
|
\hrule
|
|
\LARGE
|
|
\vspace{0.5cm}
|
|
Real-Time Systems
|
|
\vspace{0.5cm}
|
|
\hrule
|
|
|
|
\vfill
|
|
|
|
\hrule
|
|
\begin{minipage}{0.495\textwidth}
|
|
\vspace{0.4em}
|
|
\raggedright
|
|
\normalsize
|
|
\begin{tabular}{@{}l l}
|
|
Name: & Andrew Hayes \\
|
|
Student ID: & 21321503 \\
|
|
E-mail: & \href{mailto://a.hayes18@universityofgalway.ie}{a.hayes18@universityofgalway.ie} \\
|
|
\end{tabular}
|
|
\end{minipage}
|
|
\begin{minipage}{0.495\textwidth}
|
|
\raggedleft
|
|
\vspace*{0.8cm}
|
|
\Large
|
|
\today
|
|
\vspace*{0.6cm}
|
|
\end{minipage}
|
|
\medskip\hrule
|
|
\end{center}
|
|
\end{titlepage}
|
|
|
|
\pagenumbering{roman}
|
|
\newpage
|
|
\tableofcontents
|
|
\newpage
|
|
\setcounter{page}{1}
|
|
\pagenumbering{arabic}
|
|
|
|
\section{Introduction}
|
|
\subsection{Lecturer Contact Information}
|
|
\begin{itemize}
|
|
\item Name: Dr. Michael Schukat.
|
|
\item E-mail: \href{mailto://michael.schukat@universityofgalway.ie}{michael.schukat@universityofgalway.ie}.
|
|
\item Office: CSB-3002.
|
|
\end{itemize}
|
|
|
|
\begin{itemize}
|
|
\item Name: Dr. Jawad Manzoor.
|
|
\item E-mail: \href{jawad.manzoor@universityofgalway.ie}{jawad.manzoor@universityofgalway.ie}.
|
|
\item Office: CSB-3012.
|
|
\end{itemize}
|
|
|
|
\subsection{Assessment}
|
|
\begin{itemize}
|
|
\item 2 hours of face-to-face \& virtual labs per week from Week 03.
|
|
\item 30\% Continuous Assessment:
|
|
\begin{itemize}
|
|
\item 2 assignments, 10\% each.
|
|
\item 2 in-class quizzes between Week 07 \& Week 12, worth 5\%.
|
|
\end{itemize}
|
|
\end{itemize}
|
|
|
|
\subsection{Introduction to Real-Time Systems}
|
|
A system is said to be \textbf{real-time} if the total correctness of an operation depends not only upon its logical correctness but also upon the time in which it is performed.
|
|
Contrast functional requirements (logical correctness) versus non-functional requirements (time constraints).
|
|
There are two main categorisation factors:
|
|
\begin{itemize}
|
|
\item \textbf{Criticality:}
|
|
\begin{itemize}
|
|
\item \textbf{Hard RTS:} deadlines (responsiveness) is critical.
|
|
Failure to meet these have severe to catastrophic consequences (e.g., injury, damage, death).
|
|
\item \textbf{Soft RTS:} deadlines are less critical, in many cases significant tolerance can be permitted.
|
|
\end{itemize}
|
|
|
|
\item \textbf{Speed}
|
|
\begin{itemize}
|
|
\item \textbf{Fast RTS:} responses in microseconds to hundreds of microseconds.
|
|
\item \textbf{Slow RTS:} responses in the range of seconds to days.
|
|
\end{itemize}
|
|
\end{itemize}
|
|
|
|
A \textbf{safety-critical system (SCS)} or life-critical system is a system whose failure or malfunction may result in death or serious injury to people, loss of equipment / property or severe damage, \& environmental harm.
|
|
|
|
\section{The Essence of Time: From Measurement to Navigation \& Beyond}
|
|
\textbf{Time} is the continued sequence of existence \& events that occurs in an apparently irreversible succession from past, through the present, into the future.
|
|
Methods of temporal measurement, or chronometry, take two distinct forms:
|
|
\begin{itemize}
|
|
\item The \textbf{calendar}, a mathematical tool for organising intervals of term;
|
|
\item The \textbf{clock}, a physical mechanism that counts the passage of time.
|
|
\end{itemize}
|
|
|
|
Global (maritime) exploration requires exact maritime navigation, i.e., longitude \& latitude calculation.
|
|
\textbf{Latitude} (north-south) orientation is straightforward; \textbf{longitude} (east-west orientation) requires a robust (maritime) clock.
|
|
\\\\
|
|
\textbf{Ground-based navigation systems} like LORAN (LOng RAnge Navigation) were developed in the 1940s and were in use until recently, and required fixed terrestrial longwave radio transmitters, and receivers on-board of ships \& planes.
|
|
They are also referred to as hyperbolic navigation or multilateration.
|
|
The principles of ground-based navigation systems is as follows:
|
|
\begin{enumerate}
|
|
\item A \textbf{master} with a known location broadcasts a radio pulse.
|
|
\item Multiple \textbf{slave} stations with a known distance from the master send their own pulse, upon receiving the master pulse.
|
|
\item A \textbf{receiver} receives master \& slave pulses and measures the delay between them.
|
|
\item This allows the receiver to deduce the distance to each of the stations, providing a fix.
|
|
\end{enumerate}
|
|
|
|
NEED TO FINISH
|
|
|
|
\section{Time Synchronisation in Distributed Systems}
|
|
A \textbf{distributed system (DS)} is a type of networked system wherein multiple computers (nodes) work together to perform a task.
|
|
Such systems may or may not be connected to the Internet.
|
|
Time \& synchronisation are important issues here: think of error logs in distributed systems -- how can error events recorded in different computers be correlated with each other if there is no common time base?
|
|
The problem is that GNSS-based time synchronisation may or may not be available, as GPS signals are absorbed or weakened by building structures.
|
|
There is no other time reference such systems can rely on because in such a distributed system there are just a series of imperfect computer clocks.
|
|
\\\\
|
|
In distributed systems, all the different nodes are supposed to have the same notion of time, but quartz oscillators oscillate at slightly different frequencies.
|
|
Hence, clocks tick at different rates (called \textit{clock skew}), resulting in an increasing gap in perceived time.
|
|
The difference between two clocks at a given pot is called \textit{clock offset}.
|
|
The \textbf{clock synchronisation problem} aims to minimise the clock skew and subsequently the offset between two or more clocks.
|
|
A clock can show a positive or negative offset with regard to a reference clock (e.g., UTC), and will need to be resynchronised periodically.
|
|
One cannot just set the clock to the ``correct'' time: jumps, particularly backwards, can confuse software and operating systems.
|
|
Instead, we aim for gradual compensation by correcting the skew: if a clock runs too fast, make it run slower until correct and if a clock runs too slow, make it run faster until correct.
|
|
\\\\
|
|
Synchronisation can take place in different forms:
|
|
\begin{itemize}
|
|
\item Based on \textbf{physical} clocks: absolute to each other by synchronising to an accurate time source (e.g., UTC), absolute to each other by synchronising to locally agreed time (i.e., no link to a global time reference), where the term \textit{absolute} means that the differences in timestamps are proper time intervals.
|
|
|
|
\item Based on \textbf{logical} clocks (i.e., clocks are more like counters): timestamps may be ordered but with no notion of measurable time intervals.
|
|
\end{itemize}
|
|
|
|
In either case, the DS endpoints synchronise using a shared network.
|
|
For physical clock synchronisation, network latencies must be considered as packets traverse from a sending node to a receiving node.
|
|
In a \textbf{perfect network}, messages \textit{always} arrive, with a propagation delay of \textit{exactly} $d$;
|
|
the sender sends time $T$ in a message, the receiver sets its clock to $T + d$, and synchronisation is exact.
|
|
\\\\
|
|
In a \textbf{deterministic network}, messages arrive with a propagation delay $0 < d \leq D$;
|
|
the sender sends time $T$ in a message, the receiver sets its clock to $T + \frac{D}{2}$, and therefore the synchronisation error is at most $\frac{D}{2}$.
|
|
\textbf{Deterministic communication} is the ability of a network to guarantee that a message will be transmitted in a specified, predictable period of time.
|
|
|
|
\subsection{Synchronisation in the Real World}
|
|
Most off-the-shelf networks are \textit{asynchronous}, that is, data is transmitted intermittently on a best-effort basis.
|
|
They are designed for flexibility, not determinism, and as a result, propagation delays are arbitrary and sometimes even unsymmetric (i.e., upstream \& downstream latencies are different).
|
|
Therefore, synchronisation algorithms are needed to accommodate these limitations.
|
|
|
|
\subsubsection{Cristian's Algorithm}
|
|
\textbf{Cristian's algorithm} attempts to compensate for symmetric network delays:
|
|
\begin{enumerate}
|
|
\item The client remembers the local time $T_0$ just before sending a request.
|
|
\item The server receives the request, determines $T_S$, and sends it as a reply.
|
|
\item When the client receives the reply, it notes the local arrival time $T_1$.
|
|
\item The correct time is then approximately $(T_S + \frac{(T_1 - T_0)}{2} )$.
|
|
\end{enumerate}
|
|
|
|
The algorithm assumes symmetric network latency.
|
|
If the server is synced to UTC< all clients will follow UTC.
|
|
Limitations of Cristian's algorithm include:
|
|
\begin{itemize}
|
|
\item Assumes a symmetric network latency;
|
|
\item Assumes that timestamps can be taken as the packet hits the wire / arrives at the client;
|
|
\item Assumes that $T_S$ is right in the middle of the server process; for example, consider the server process being pre-empted just before it sends the response back to the client, which will corrupt the synchronisation of the client.
|
|
\end{itemize}
|
|
|
|
\subsubsection{Berkeley Algorithm}
|
|
In the \textbf{Berkeley algorithm}, there is no accurate time server: instead, a set of client clocks is synchronised to their average time.
|
|
The assumption is that offsets / skews of all clocks follow some symmetric distribution (e.g., a normal distribution) with some clocks going faster and others slower, and therefore a mean value close to 0.
|
|
\begin{enumerate}
|
|
\item One node is designated to be the \textbf{master node} $M$.
|
|
\item The master node periodically queries all other clients for their local time.
|
|
\item Each client returns a timestamp or their clock offset to the master.
|
|
\item Cristian's algorithm is used to determine and compensate for RTTs, which can be different for each client.
|
|
\item Using these, the master computes the average time (thereby ignoring outliers), calculates the difference to all timestamps it has received, and sends an adjustment to each client.
|
|
Again, each computer gradually adjusts its local clock.
|
|
\end{enumerate}
|
|
|
|
Client clocks are adjusted to run faster or slower, to be synced to an overall agreed system time.
|
|
The client networks is an intranet, i.e., an isolated system.
|
|
Therefore, the Berkeley algorithm is an \textbf{internal clock synchronisation algorithm}.
|
|
The Berkeley algorithm was implemented in the TEMPO time synchronisation protocol, which was part of the Berkelely UNIX 4.3BSD system.
|
|
|
|
\subsection{Logical Clocks}
|
|
\textbf{Logical clocks} are another concept linked to internal clock synchronisation.
|
|
Logical clocks only care about their internal consistency, but not about absolute (UTC) time;
|
|
subsequently, they do not need clock synchronisation and take into account the order in which events occur rather than the time at which they occurred.
|
|
In practice, if clients or processes only care that event $a$ happens before event $b$, but don't care about the exact time difference, they can make use of a logical clock.
|
|
\\\\
|
|
We can define the \textbf{happens-before relation} $a \rightarrow b$:
|
|
\begin{itemize}
|
|
\item If events $a$ and $b$ are within the same process, then $a \rightarrow b$ if $a$ occurs with an earlier local timestamp: \textbf{process order}.
|
|
\item If $a$ is the event of a message being sent by one process, and $b$ is the event of the message being received by another process, then $a \rightarrow b$: \textbf{causal order}.
|
|
\item We also have \textbf{transitivity:} if $a \rightarrow b$ and $b \rightarrow c$, then $a \rightarrow c$.
|
|
\end{itemize}
|
|
Note that this only provides a \textit{partial order}:
|
|
if two events $a$ and $b$ happen in different processes that do not exchange messages (not even indirectly), then neither $a \rightarrow b$ nor $b \rightarrow a$ is true.
|
|
In this situation, we say that $a$ and $b$ are \textbf{concurrent} and write $a \sim b$, i.e., nothing can be said about when the events happened or which event happened first.
|
|
\\\\
|
|
Happens-before can be implemented using the \textbf{Lamport scheme:}
|
|
\begin{enumerate}
|
|
\item Each process $P_i$ has a logical clock $L_i$, where $L_i$ can be simply an integer variable initialised to 0.
|
|
\item $L_i$ is incremented on every local event $e$; we write $L_i(e)$ or $L(e)$ as the timestamp of $e$.
|
|
\item When $P_i$ sends a message, it increments $L_i$ and copies its content into the packet.
|
|
\item When $P_i$ receives a message from $P_k$, it extracts $L_k$ and sets $L := \text{max}(L_i, L_k)$ and then increments $L_i$.
|
|
\end{enumerate}
|
|
|
|
This guarantees that if $a \rightarrow b$, then $L_i(a) < L_k(b)$, but nothing else.
|
|
\\\\
|
|
The primary limitation of Lamport clocks is that they do not capture \textbf{causality}.
|
|
Lamport's logical clocks lead to a situation where all events in a distributed system are ordered, so that if an event $a$ (linked to $P_i$) ``happened before'' event $b$ (linked to $P_k$), i.e., $a \rightarrow b$, then $a$will allso be positioned in that ordering before $b$ such that $L_i(a) < L_k(b)$ or simply $L(a) < L(b)$;
|
|
however, nothing can be said about the relationship between two events $a$ \& $b$ by merely comparing their time values $L_i(a)$ and $L_k(b$.): we can't tell if $a \rightarrow b$ or $b \rightarrow a$ or $a \sim b$ unless they occur in the same process.
|
|
|
|
\subsubsection{Vector Clocks}
|
|
In practice, causality is captured by means of \textbf{vector clocks}:
|
|
\begin{itemize}
|
|
\item There is an ordered list of logical clocks, with one per process.
|
|
\item Each process $P_i$ maintains a vector $\vec{V_i}$, initially containing all zeroes.
|
|
\item On a local event $e$, $P_i$ increments $\vec{V_i}[i]$ (the $i$\textsuperscript{th} vector component).
|
|
If the event is ``message send'', a new $\vec{V_i}$ is copied into the packet.
|
|
\item If $P_i$ receives a message from $P_m$, then, for all $k$
|
|
\end{itemize}
|
|
|
|
|
|
|
|
|
|
\end{document}
|