[CT420]: WK07 Lecture 2 materials

year4/semester2/CT420/notes/CT420.tex

@@ -581,7 +581,148 @@ Finally, the \textbf{clock combining algorithm} averages the time offsets of sur
 The \textbf{combining algorithm} provides a final offset, so the client clock can be adjusted.
 The UNIX Clock Model provides the kernel variable \verb|tickadj| which amortises the required change gradually by making adjustments every tick e.g., every 10 milliseconds.
 
+\section{Soft RTS}
+A \textbf{soft RTS} is a RTS in which performance is degraded but not destroyed by failure to meet response time constraints, e.g., multimedia systems.
 
+\subsection{Quality of Service (QoS)}
+\textbf{Perceived QoS} reflects the subjective evaluation of service quality from the end user's perspective and overall satisfaction.
+It encompasses factors like application responsiveness, ease of use, consistency, reliability, and the overall user interface delay.
+It is challenging to measure accurately as it involves subjective experiences \& user feedback, often gathered through surveys, user studies, or feedback mechanisms.
+\\\\
+\textbf{Intrinsic QoS} refers to the technical \& measurable characteristics of a network or service that directly affects its performance \& reliability.
+Intrinsic QoS parameters include bandwidth, latency, packet loss rate, jitter, \& throughput.
+Intrinsic QoS measures are typically quantifiable and can be objectively measured using various tools \& monitoring techniques.
+
+\subsubsection{QoS Metrics}
+\textbf{Latency} is the time it takes to send a packet from point $A$ (say, the client) to point $B$ (say, the server).
+It is physically limited by how fast signals can travel in wires or the open air.
+Latency depends on the physical, real-world distance between $A$ and $B$.
+Typical latencies are conceptually small, between roughly 10 and 200 milliseconds.
+High latency can result in delays between user actions and system responses, leading to sluggish or unresponsive behaviour in real-time applications.
+\\\\
+\textbf{Jitter} is the inconsistency or fluctuations in the arrival time of data packets at the receiver.
+It can be caused by various factors, such as network congestion, packet loss, routing changes, etc.
+It can have significant implications for real-time communication applications, particularly voice \& video sharing.
+Inconsistent packet arrival times can lead to disruptions, distortion, and out-of-sync audio or video playback.
+\\\\
+\textbf{Bandwidth} measures the amount of data that is able to pass through a network at a given time.
+It is measured in bits per second.
+Real-time applications with high-bandwidth requirements, such as high-definition video streaming \& VOIP may experience performance issues if the available bandwidth is insufficient to accommodate the data transmission demands.
+
+\subsection{Real-Time Multimedia Technologies}
+\subsubsection{Transport Layer for Real-Time Media}
+\textbf{TCP} provides reliability, ordered delivery, \& congestion control.
+Retransmissions can lead to high delay and cause delay jitter.
+TCP is not suitable for real-time systems and does not support mulitcast.
+\\\\
+\textbf{UDP} has no built-in reliability or congestion control, and no defined technique for synchronising.
+It has low latency and minimal overhead (no handshake, no retransmissions).
+A feedback channel must be defined for quality control.
+
+\subsubsection{Service Requirements for Real-Time Flows (Voice / Video)}
+\begin{itemize}
+    \item   \textbf{Sequencing:} the process of maintaining the correct order of data packets during transmission and ensuring that they are re-assembled correctly at the receiver's end.
+    \item   \textbf{Synchronisation:} ensures that different types of data streams (such as audio \& video) are aligned in time during playback.
+    \item   \textbf{Payload identification:} different media types (MPEG1, MPEG2, H.261) may require different handling in terms of decoding or processing.
+    \item   \textbf{Frame indication:} specifying which packets belong to the same frame or video sequence and helps with decoding \& rendering video frames accurately.
+\end{itemize}
+
+\subsubsection{RTP}
+\textbf{Real-time Transport Protocol (RTP)} provides end-to-end transport functions suitable for real-time audio/video applications over multicast \& unicast network services.
+It works in user space over UDP.
+The working model is as follows:
+\begin{itemize}
+    \item   The multimedia application generates multiple streams (audio, video, etc.) that are fed into the RTP library.
+    \item   The library multiplexes the streams \& encodes them in RTP packets which are fed to a UDP socket.
+\end{itemize}
+
+\textbf{Secure RTP (SRTP)} is used by applications including WhatsApp, Zoom, Skype, etc. for transporting voice \& video streams.
+
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=\textwidth]{./images/RTP.png}
+    \caption{ RTP protocol}
+\end{figure}
+
+RTP services include:
+\begin{itemize}
+    \item   Payload type identification: determination of media encoding.
+    \item   Synchronisation source identification: assigned to each distinct media source (such as a microphone or a camera).
+            Enables synchronisation of multiple streams coming from the same source (e.g., lip-syncing audio \& video).
+    \item   Sequence numbering: a counter is used which is incremented on each RTP packet send and is used to detect lost packets.
+    \item   Time-stamping: time monitoring, synchronisation, jitter calculation.
+    \item   RTP issues: no QoS guarantees, no guarantee of packet delivery.
+\end{itemize}
+
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=\textwidth]{./images/RTPpheader.png}
+    \caption{ RTP header}
+\end{figure}
+
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=\textwidth]{./images/RTPdatadelirvery.png}
+    \caption{ RTP data delivery}
+\end{figure}
+
+\textbf{RTP Control Protocol (RTCP)} is a companion protocol to RTP that is used periodically to transmit control packets to participants in a streaming multimedia session.
+It gathers statistics on the media connection, including bytes sent, packets sent, lost packets, jitter, feedback, \& round-trip delay. 
+It provides feedback on the quality of the service being provided by RTP but does not actually transport any data.
+The application may use this information to increase the quality of service, perhaps by limiting flow or using a different codec.
+
+\subsubsection{Mouth-to-Ear M2E Delay}
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=\textwidth]{./images/m2e.png}
+    \caption{ M2E delay }
+\end{figure}
+
+M2E delay consists of:
+\begin{itemize}
+    \item   Sender:
+            \begin{itemize}
+                \item   Packetisation delay.
+                \item   Encoding delays.
+                \item   OS/Application/Driver software.
+                \item   MAC delays.
+            \end{itemize}
+
+    \item   Network:
+            \begin{itemize}
+                \item   Propagation delay.
+                \item   Queuing delays.
+                \item   Processing/serialisation delays in routers.
+            \end{itemize}
+
+    \item   Receiver:
+            \begin{itemize}
+                \item   NIC delays.
+                \item   OS/Application/Driver software.
+                \item   Jitter buffer delays.
+                \item   Decoding delays.
+            \end{itemize}
+\end{itemize}
+
+VOIP QoS strategies include:
+\begin{itemize}
+    \item   Sender-based:
+            \begin{itemize}
+                \item RTCP feedback with adaptive codeces: if loss/delay excessive, switch to lower-bandwidth code or implement Forward Error Correction (FEC) strategy.
+            \end{itemize}
+
+    \item   Network-based:
+            \begin{itemize}
+                \item   Prioritising delay-sensitive traffic flows.
+            \end{itemize}
+
+    \item   Receiver-based:
+            \begin{itemize}
+                \item   Buffering strategies: the human ear is not sensitive to short-term variations;
+                    the buffer ``absorbs'' variation in network queueing delays and the voice can be reconstructed using RTP timestamps, but this adds to overall M2E delay.
+                \item   Packet Loss Concealment (PLC) and FEC.
+            \end{itemize}
+\end{itemize}
 
 
 

year4/semester2/CT420/notes/[

@@ -0,0 +1,660 @@
+% ! 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{enumerate}
+    \item   There is an ordered list of logical clocks, with one per process.
+            Each process $P_i$ maintains a vector $\vec{V_i}$, initially containing all zeroes.
+            Each index $k$ of a vector clock $\vec{V_i}[k]$ represents the number of events that process $P_i$ knows have occurred in process $P_k$.
+            $\vec{V_i}[i]$  is the count of events that have occurred locally at process $P_i$, while $\vec{V_i}[k]$ (for $k\neq i$) is the count of events in process $P_k$ that $P_i$ is aware of.
+
+    \item   On a local event $e$, $P_i$ increments its own clock component $\vec{V_i}[i]$.
+            If the event is ``message send'', a new $\vec{V_i}$ is copied into the packet, so that on message sends the current vector state is included in the message.
+
+    \item   If $P_i$ receives a message from $P_m$, then each index $\vec{V_i}[k]$ where $k \neq i$ is set to $\text{max}(\vec{V_m}[k], \vec{V_i}[k])$, and $\vec{V_i}[i]$ is incremented.
+\end{enumerate}
+
+Intuitively, $\vec{V_i}[k]$is the number of events in process $P_k$ that have been observed by $P_i$.
+
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=\textwidth]{./images/vector_clocks_example.png}
+    \caption{Vector clocks example}
+\end{figure}
+
+In the above example, when process $P_2$ receives message $m_1$, it merges the entries from $P_1$'s clock by choosing the maximum value of each position.
+Similarly, when $P_3$ receives $m_2$, it merges in $P_2$'s clock, thus incorporating the changes from $P_1$ that $P_2$ already saw. 
+Vector clocks explicitly track the transitive causal order: $f$'s timestamp captures the history of $a$, $b$, $c$, \& $d$.
+\\\\
+To use vector clocks for ordering, we can compare them piecewise:
+\begin{itemize}
+    \item   We say $\vec{V_i} = \vec{V_j}$ if and only if $\vec{V_i}[k] = \vec{V_j}[k] \forall k$.
+    \item   We say $\vec{V_i} \leq \vec{V_j}$ if and only if $\vec{V_i}[k] \leq \vec{V_j}[k] \forall k$.
+    \item   We say $\vec{V_i} < \vec{V_j}$ if and only if $\vec{V_i} \leq \vec{V_j}$ and $\vec{V_i} \neq \vec{V_j}$.
+    \item   We say $\vec{V_i} \sim \vec{V_j}$ otherwise, e.g., $\vec{V_i} = [2,0,0]$ and $\vec{V_j} = [0,0,1]$.
+\end{itemize}
+
+For any two event timestamps $T(a)$ \& $T(b)$:
+\begin{itemize}
+    \item   if $a \rightarrow b$, then $T(a) < T(b)$; \textbf{and}
+    \item   if $T(a) < T(b)$, then $a \rightarrow b$.
+\end{itemize}
+
+Hence, we can use timestamps to determine if there is a causal ordering between any two events.
+
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=\textwidth]{./images/vector_vs_lamport.png}
+    \caption{Lamport clocks versus vector clocks}
+\end{figure}
+
+\section{The NTP Protocol}
+The options for computer clocks are essentially as follows:
+\begin{itemize}
+    \item   \textbf{Option A:} stick to crystals.
+            \begin{itemize}
+                \item   Costly precision manufacturing.
+                \item   Works indoors.
+                \item   Temperature Compensated Crystal Oscillator (TCXO).
+                \item   Oven Controlled Crystal Oscillator (OCXO).
+            \end{itemize}
+
+    \item   \textbf{Option B:} buy an atomic clock (\$50,000 -- \$100,000) or a GNSS receiver (based on an atomic clock, but doesn't work indoors), or a time signal radio receiver if you are based in central Europe.
+
+    \item   \textbf{Option C:} use software-based approaches to discipline cheap crystal clocks.
+            Less quality, but useful for certain applications, and works indoors.
+\end{itemize}
+
+\textbf{Distributed master clocks} provide a time reference to hosts that are inter-connected via a network.
+The underlying time-synchronisation protocols combine aspects of Cristian's algorithm (i.e., RTD calculation) and Berkeley's algorithm (i.e., combining multiple reference time sources).
+Good time synchronisation requires:
+\begin{itemize}
+    \item   Good time references: easily done with GPS, atomic clocks, etc.
+    \item   Predictable / symmetric / deterministic network latencies: doable in LAN setups, but not guaranteed in Internet data communication.
+\end{itemize}
+
+There are two main distributed master clock protocols:
+\begin{itemize}
+    \item   \textbf{Network Time Protocol (NTP):} defined in RFC 5905, originally used in the Unix-based NTP daemon, one of the first Internet protocols that ever evolved.
+    \item   \textbf{Precision Time Protocol (PTP):} designed for managed networks, e.g., LAN.
+\end{itemize}
+
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=0.7\textwidth]{./images/ntpvsptp.png}
+    \caption{NTP \& PTP characteristics}
+\end{figure}
+
+In \textbf{uni-directional synchronisation} a reference clock sends a timestamp to a host via a network.
+The host then uses the timestamp to set its local clock.
+Useful when message latencies are minor relative to the synchronisation levels required.
+\\\\
+In \textbf{round-trip synchronisation (RTS)} a host sends a request message, receives a reference clock response message with known (local) submission \& arrival times, allowing for the calculation of the round-trip delay (1) and the host clock error (2), i.e., the phase offset.
+Variations of RTS form the basis for NTP \& PTP.
+
+\begin{align}
+    \delta = (T_{i+3} - T_i) - (T_{i+2} - T_{i+1})
+\end{align}
+\begin{align}
+    \theta = (T_{i+1}-T_i) + \frac{(T_{i+2}-T_{i+3})}{2}
+\end{align}
+
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=0.4\textwidth]{./images/rts.png}
+    \caption{ RTS example }
+\end{figure}
+
+\subsection{NTP}
+The NTP architecture, protocol, \& algorithms have evolved over the last 40 years to the latest NTP Version 4.
+NTP is the standard Internet protocol for time synchronisation \& co-ordinated UTC time distribution.
+It is a fault-tolerant protocol, as it automatically selects the best of several available time sources to synchronise with.
+It is highly scalable, as the nodes form a hierarchical structure with reference clock(s) at the top:
+\begin{itemize}
+    \item   Stratum 0: Time Reference Source (e.g., GPS, TAI atomic clocks, DCF 77).
+    \item   Stratum 1: Primary Time Server.
+\end{itemize}
+
+NTP applies some general aforementioned principles such as avoiding setting clocks backwards and avoiding large step changes;
+the required change (positive or negative) is amortised over a series of short intervals (e.g., over multiple ticks).
+\\\\
+NTP is the longest-running and continuously operating Internet protocol (since around 1979).
+Government agencies in many other countries and on all continents (including Antarctica) operate public NTP primary servers.
+National \& regional service providers operate public NTP secondary servers synchronised to the primary servers.
+Many government agencies, private \& public institutions including universities, broadcasters, financial institutions, \& corporations operate their own NTP networks. 
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=0.5\textwidth]{./images/ntphierarchy.png}
+    \caption{ NTP hierarchy }
+\end{figure}
+
+In \textbf{client/server mode}, UDP is used for data transfer (no TCP), i.e., NTP over UDP on UDP port 123.
+There is also the optional use of broadcasting or multicasting (not covered here).
+Several packet exchanges between the NTP client and the Stratum server take place to determine the client offset:
+\begin{enumerate}
+    \item   The client sends a packet with \textbf{originate timestamp} $A$.
+    \item   The server receives the packet and returns a response containing the originate timestamp $A$ as well as the \textbf{receive timestamp} $B$ and the \textbf{transmit timestamp} $C$.
+    \item   The client receives this packet and processes $A$, $B$, $C$, as well as the packet arrival time $D$ of the received packet; it then determines the offset and the round-trip delay (RTD).
+\end{enumerate}
+
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=0.7\textwidth]{./images/ntpoperation.png}
+    \caption{ NTP operation }
+\end{figure}
+
+The above example is of a symmetric network with a 15ms delay each way; the client's clock lags 5ms behind the server's clock:
+\begin{align*}
+    \text{RTD}      = (D-A)-(C-B) = 32-2 =& 30\text{ms} \\
+    \text{Offset}   = \frac{((B-A)+(C-D))}{2} = \frac{(20 + (-10))}{2} =& 5\text{ms}
+\end{align*}
+
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=0.7\textwidth]{./images/networkdelayasymmetry.png}
+    \caption{ Network delay asymmetry }
+\end{figure}
+
+In the above example, the client's clock still lags 5ms behind the servers clock, but there is an asymmetric network latency: 10ms versus 20ms:
+\begin{align*}
+    \text{RTD}      = (D-A)-(C-B) = 32-2                                =& 30\text{ms} \\
+    \text{Offset}   = \frac{((B-A)+(C-D))}{2} = \frac{(15 + (-15))}{2}  =& 0\text{ms}
+\end{align*}
+
+Typical NTP performance for various set-ups is as follows:
+\begin{itemize}
+    \item   Small LAN: \sim10 microseconds best possible case on a 2-node LAN, \sim220 microseconds on a real-world small LAN.
+    \item   Typical large-building LAN: \sim2ms.
+    \item   Internet with a few hops: 10–20ms.
+    \item   Long distance and/or slow or busy link: 100ms–1s.
+\end{itemize}
+
+Accuracy is further degraded on networks with asymmetric traffic delays.
+\\\\
+The \textbf{NTP time format} has a reference scale of UTC.
+Time parameters are 64 bits long:
+\begin{itemize}
+    \item   Seconds since January 1, 1900 (32 bits, unsigned).
+    \item   Fraction of second (32 bits, unsigned).
+\end{itemize}
+The NTP time format has a dynamic range of 136+ years, with rollover in 2036.
+Its resolution is 2\textsuperscript{-32} seconds \sim232 picoseconds.
+
+\subsubsection{NTP Protocol Header}
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=0.7\textwidth]{./images/ntpheader.png}
+    \caption{ NTP protocol header }
+\end{figure}
+\begin{itemize}
+    \item   \verb|LI| (\textbf{Leap Indicator}) 2-bit:
+            \begin{itemize}
+                \item   \verb|0|: no warning;
+                \item   \verb|1|: last minute of the day has 61 seconds;
+                \item   \verb|2|: last minute of the day has 59 seconds.
+            \end{itemize}
+
+
+    \item   \verb|VN| (\textbf{Version Number}) 2-bit: currently 4. 
+
+    \item   \verb|Mode|: 3-bit integer, including:
+            \begin{itemize}
+                \item   \verb|3|: client;
+                \item   \verb|4|: server.
+            \end{itemize}
+
+    \item   \verb|Stratum|: 8-bit integer for Stratum server hierarchy level, including:
+            \begin{itemize}
+                \item   \verb|1|: primary server (i.e., stratum 1);
+                \item   \verb|2|–\verb|15|: secondary server.
+            \end{itemize}
+
+    \item   \verb|Poll|: 8-bit signed integer representing the maximum interval between successive message, in $\log_2$ seconds.
+            This field indicates the interval at which the client will poll the NTP server for time updates.
+            The client dynamically adjusts this interval based on its clock's stability \& the network conditions to balance accuracy \& network load.
+
+    \item   \verb|Precision|: 8-bit signed integer representing the resolution of the system clock (the tick increment) in $\log_2$ seconds;
+            e.g., a value of -18 corresponds to a resolution of about one microsecond (2\textsuperscript{-18}) seconds.
+
+    \item   \verb|Root Delay|: round-trip packet delay from a client to a stratum 1 server.
+            It gives a crude estimate of the worst-case time transfer error between a client and a stratum 1 server due to network asymmetry, i.e., if all of the round-trip delay was in one direction and none in the other direction.
+\end{itemize}
+
+For a single client clock, the \textbf{dispersion} is a measure of how much the client's clock might drift during a synchronisation cycle:
+\begin{align*}
+    \text{Dispersion} = \textit{DR} \times (D-A) + \textit{TS}
+\end{align*}
+where $(D-A)$ is the duration of a synchronisation cycle, with $A$ being the first timestamp and $D$ being the last timestamp, \textit{DR} being the local clock skew (i.e., the deviation of actual clock tick frequency to nominal clock tick frequency), and \textit{TS} being the timestamping errors due to the finite resolution of the clock and delays in reading the clock when fetching a timestamp.
+\\\\
+The \textbf{root dispersion} of a client clock is the combined dispersions of all stratum servers along the path to a Stratum 1 server.
+\\\\
+The \textbf{root distance} is the sum of root dispersion and half the root delay.
+It provides a comprehensive measure of the maximum error in time synchronisation as the total worst case timing error accumulated between the Stratum 1 server and the client.
+
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=0.7\textwidth]{./images/rootdispersion.png}
+    \caption{ Example root dispersion \& root delay }
+\end{figure}
+
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=0.7\textwidth]{./images/annotatedntpheader.png}
+    \caption{ Annotated NTP protocol header }
+\end{figure}
+
+A \textbf{reference ID (refid)} is a 32-bit code (4 ASCII bytes) identifying the particular server or reference clock, e.g.,:
+\begin{itemize}
+    \item   \verb|GPS|: Global Positioning System;
+    \item   \verb|GAL|: Galileo Positioning System;
+    \item   \verb|PPS|: Generic Pulse-Per-Second;
+    \item   \verb|DCF|: LF Radio DCF77 Mainflingen, DE 77.5 kHz;
+    \item   \verb|WWV|: HF Radio WWV Fort Collins, Colorado;
+    \item   \verb|GOOG|: unofficial Google refid used by Google NTP servers as \verb|time4.google.com|.
+\end{itemize}
+
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=0.7\textwidth]{./images/ntparchitecuraloverview.png}
+    \caption{ NTP architectural overview }
+\end{figure}
+
+An NTP client synchronises with multiple stratum servers.
+It uses a range of algorithms to deal with variable \& asymmetric non-deterministic network delays and to determine its most likely offset, thereby running a series of processes:
+\begin{itemize}
+    \item   The peer process runs when a packet is received;
+    \item   The poll process sends packets at intervals determined by the clock discipline process \& remote server;
+    \item   The system process runs when a new update is received;
+    \item   The clock discipline process implements clock time adjustments;
+    \item   The clock adjust process implements periodic clock frequency (VFO) adjustments.
+\end{itemize}
+
+For each stratum there is a \textbf{poll process} that sends NTP packets at intervals ranging from 8 seconds to 36 hours.
+The corresponding \textbf{peer processes} receive NTP packets and, after performing some packet sanity tests, $T1$ – $T4$ are determined / extracted.
+The NTP daemon calculates offset \& delay as seen before.
+The time series of offset \& delay values calculated by multiple peer processes are processed by a sequence of algorithms, thus eliminating servers with long RTD or servers that show ``strange'' offsets which, for example, are often the result of network asymmetries.
+
+\subsubsection{Mitigation Algorithms}
+The \textbf{clock filter algorithm} uses a sliding window of eight samples for each stratum server and picks out the sample with the least expected error, i.e., it chooses the sample with the minimum RTD.
+It is effective at removing spikes resulting from intermittent network congestions.
+
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=0.7\textwidth]{./images/clockfilteralg.png}
+    \caption{ Clock filter algorithm before and after }
+\end{figure}
+
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=0.7\textwidth]{./images/clockfilteralgmotivation.png}
+    \caption{ 
+        The wedge scattergram plots sample points of offset versus delay (RTD) collected over a 24-hour period by a client clock communicating with a single stratum server.
+        For this experiment, the client clock is externally synced to the stratum server, so the offset should be zero;
+        however, as the (network) round trip delay increases, the offset variability increases, resulting in increasingly larger offset errors.
+        Therefore, the best samples are those at the lowest delay.
+        This is taken into account by the clock filter algorithm.
+    }
+\end{figure}
+
+The \textbf{intersection algorithm} selects a subset of peers (i.e., stratum servers) and identifies truechimers \& truetickers based on the intersection of confidence (offset) intervals (i.e., min/max offsets of a clock over $x$ readings determines its invterval).
+
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=0.7\textwidth]{./images/intersectional.png}
+    \caption{ Plot range of offsets calculated by each peer with 1, 2, \& 3 overlapping}
+\end{figure}
+
+\textbf{Marzullo's algorithm} is an agreement protocol for estimating accurate time from a number of noisy time sources by intersecting offset intervals; if some intervals don't intersect, it considers the intersection of the majority of intervals.
+It eliminates false tickers.
+\\\\
+The \textbf{clock cluster algorithm} processes the truechimers returned by the clock intersection algorithm.
+It produces a list of survivors by eliminating truechimers that have a comparably large root delay \& root dispersion.
+Finally, the \textbf{clock combining algorithm} averages the time offsets of survivors using their root dispersions as a weight, i.e., survivors with a small root dispersion have a higher weight.
+\\\\
+The \textbf{combining algorithm} provides a final offset, so the client clock can be adjusted.
+The UNIX Clock Model provides the kernel variable \verb|tickadj| which amortises the required change gradually by making adjustments every tick e.g., every 10 milliseconds.
+
+\section{Soft RTS}
+A \textbf{soft RTS} is a RTS in which performance is degraded but not destroyed by failure to meet response time constraints, e.g., multimedia systems.
+
+\subsection{Quality of Service (QoS)}
+\textbf{Perceived QoS} reflects the subjective evaluation of service quality from the end user's perspective and overall satisfaction.
+It encompasses factors like application responsiveness, ease of use, consistency, reliability, and the overall user interface delay.
+It is challenging to measure accurately as it involves subjective experiences \& user feedback, often gathered through surveys, user studies, or feedback mechanisms.
+\\\\
+\textbf{Intrinsic QoS} refers to the technical \& measurable characteristics of a network or service that directly affects its performance \& reliability.
+Intrinsic QoS parameters include bandwidth, latency, packet loss rate, jitter, \& throughput.
+Intrinsic QoS measures are typically quantifiable and can be objectively measured using various tools \& monitoring techniques.
+
+\subsubsection{QoS Metrics}
+\textbf{Latency} is the time it takes to send a packet from point $A$ (say, the client) to point $B$ (say, the server).
+It is physically limited by how fast signals can travel in wires or the open air.
+Latency depends on the physical, real-world distance between $A$ and $B$.
+Typical latencies are conceptually small, between roughly 10 and 200 milliseconds.
+High latency can result in delays between user actions and system responses, leading to sluggish or unresponsive behaviour in real-time applications.
+\\\\
+\textbf{Jitter} is the inconsistency or fluctuations in the arrival time of data packets at the receiver.
+It can be caused by various factors, such as network congestion, packet loss, routing changes, etc.
+It can have significant implications for real-time communication applications, particularly voice \& video sharing.
+Inconsistent packet arrival times can lead to disruptions, distortion, and out-of-sync audio or video playback.
+\\\\
+\textbf{Bandwidth} measures the amount of data that is able to pass through a network at a given time.
+It is measured in bits per second.
+Real-time applications with high-bandwidth requirements, such as high-definition video streaming \& VOIP may experience performance issues if the available bandwidth is insufficient to accommodate the data transmission demands.
+
+\subsection{Real-Time Multimedia Technologies}
+\subsubsection{Transport Layer for Real-Time Media}
+\textbf{TCP} provides reliability, ordered delivery, \& congestion control.
+Retransmissions can lead to high delay and cause delay jitter.
+TCP is not suitable for real-time systems and does not support mulitcast.
+\\\\
+\textbf{UDP} has no built-in reliability or congestion control, and no defined technique for synchronising.
+It has low latency and minimal overhead (no handshake, no retransmissions).
+A feedback channel must be defined for quality control.
+
+\subsubsection{Service Requirements for Real-Time Flows (Voice / Video)}
+\begin{itemize}
+    \item   \textbf{Sequencing:} the process of maintaining the correct order of data packets during transmission and ensuring that they are re-assembled correctly at the receiver's end.
+    \item   \textbf{Synchronisation:} ensures that different types of data streams (such as audio \& video) are aligned in time during playback.
+    \item   \textbf{Payload identification:} different media types (MPEG1, MPEG2, H.261) may require different handling in terms of decoding or processing.
+    \item   \textbf{Frame indication:} specifying which packets belong to the same frame or video sequence and helps with decoding \& rendering video frames accurately.
+\end{itemize}
+
+\subsubsection{RTP}
+\textbf{Real-time Transport Protocol (RTP)} provides end-to-end transport functions suitable for real-time audio/video applications over multicast \& unicast network services.
+It works in user space over UDP.
+The working model is as follows:
+\begin{itemize}
+    \item   The multimedia application generates multiple streams (audio, video, etc.) that are fed into the RTP library.
+    \item   The library multiplexes the streams \& encodes them in RTP packets which are fed to a UDP socket.
+\end{itemize}
+
+\textbf{Secure RTP (SRTP)} is used by applications including WhatsApp, Zoom, Skype, etc. for transporting voice \& video streams.
+
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=\textwidth]{./images/RTP.png}
+    \caption{ RTP protocol}
+\end{figure}
+
+RTP services include:
+\begin{itemize}
+    \item   Payload type identification: determination of media encoding.
+    \item   Synchronisation source identification: assigned to each distinct media source (such as a microphone or a camera).
+            Enables synchronisation of multiple streams coming from the same source (e.g., lip-syncing audio \& video).
+\end{itemize}
+
+
+
+
+
+
+
+\end{document}