115 lines
5.2 KiB
TeX
115 lines
5.2 KiB
TeX
\chapter{Preliminaries}
|
|
\section{Magnetic Induction}
|
|
\gls{mi}, also known as magnetic flux density or simply the magnetic field, is a
|
|
physical quantity measured in Tesla \si{\tesla}. The movement of electric
|
|
charges in a conductor produces a magnetic field around the conductor. This
|
|
phenomena also happens when in a CPU \cite{magneticFluxDensity}.
|
|
|
|
In \autoref{figure:magnetic_induction_cpu} the difference of the magnetic field
|
|
of a CPU in idle (first 10 seconds) and under 100\% load can be seen.
|
|
|
|
\begin{figure}[H]
|
|
\includegraphics[width=\textwidth]{magnetic_induction_cpu.png}
|
|
\caption{Magnetic Field of a CPU}
|
|
\label{figure:magnetic_induction_cpu}
|
|
\end{figure}
|
|
|
|
\section{Hall Effect Sensor}
|
|
\label{section:hallEffectSensor}
|
|
A Hall Effect Sensor is a type of sensor to measure the strength of magnetic
|
|
fields. This type of magnetometer is found in many smartphones today
|
|
\cite{hallEffectSensor} and is generally used for compass capabilities and for
|
|
positioning \cite{smartphoneSensors}.
|
|
|
|
It utilizes the so-called hall effect to do so. The hall effect is the voltage
|
|
between two sides of a current-carrying conductor inside a magnetic field
|
|
\cite{hallEffect,hallEffect2}.
|
|
|
|
\section{Thermal Throttling}
|
|
\label{section:thermal_throttling}
|
|
CPUs utilize a lot of power when under load, and thus they get hotter. When they
|
|
get too hot, they throttle by reducing clock speeds. This process is designed to
|
|
protect the CPU from overheating \cite{thermalThrottling}.
|
|
|
|
When stress is put on the CPU, the CPU begins to throttle and the resulting CPU
|
|
loads gets dampened after a while (see \autoref{figure:throttle}).
|
|
|
|
\begin{figure}[H]
|
|
\fbox{\includegraphics[width=1\textwidth]{benchmarking/1bps_25.png}}
|
|
\caption{CPU Utilization with Thermal Throttling}
|
|
\label{figure:throttle}
|
|
\end{figure}
|
|
|
|
\section{CRC}
|
|
\label{section:crc}
|
|
|
|
\gls{crc} is a family of error detection codes designed to check if a message
|
|
has been corrupted during transmission. To check if any errors ocurred during
|
|
transmission, the checksum that was transmitted with the message, and the
|
|
checksum that is calculated from the received message are compared, if they
|
|
don't match, the message contains an error.
|
|
|
|
For calculating a \gls{crc} value, the message, which is treated as a binary
|
|
number, is divided by another value, the so-called generator polynomial. The
|
|
remainder of this division is the checksum value. The order of the generator
|
|
polynomial defines the bit-length of the resulting checksum \cite{crcGuide}.
|
|
|
|
Depending on the chosen generator polynomial, different groups of errors can be
|
|
detected \cite{crcErrors}:
|
|
\begin{itemize}
|
|
\item{A single, and double bit errors can always be detected}
|
|
\item{Depending on the polynomial, more bit errors can be detected inside
|
|
specific message lengths}
|
|
\item{Using an n-bit generator polynomial can detect burst errors of up to
|
|
n-bits in length}
|
|
\item{A generator polynomial with an even number of terms can detect errors
|
|
with an odd number of bits}
|
|
\end{itemize}
|
|
|
|
Because of these small variations, there are many implementations of
|
|
\gls{crc} algorithms in use and defined by different parties
|
|
\cite{crcCatalogue}.
|
|
|
|
The specific algorithm used in this thesis is the CRC-8-AUTOSAR algorithm with
|
|
the polynomial $x^{8} + x^{5} + x^{3} + + x^{2} + x + 1$ and an initial value
|
|
of $\mathtt{0xFF}$. This algorithm was created by AUTOSAR \cite{AutosarCrc} and
|
|
according to the CRC Polynomial Zoo, it can detect up to 4 single bit errors in
|
|
a message length of 119 bits \cite{CrcPolynomialZoo}. As our maximum payload
|
|
size is 128-bit, this is a fitting CRC algorithm to use.
|
|
|
|
CRC is widely used in networks for detecting transmission errors and is simple
|
|
to implement. \cite{Crc}
|
|
|
|
\section{Manchester Code}
|
|
\label{section:manchester}
|
|
Manchester is a simple encoding code for the transmission of binary data. The
|
|
data is encoded in the transitions of the signal instead of simple high or low
|
|
values. A transition from low to high indicates a 0 and a transition from high
|
|
to low indicates a 1 in the original definition by G. E. Thomas. In the
|
|
definition from IEEE the values of the transitions are swapped
|
|
(see \autoref{figure:manchester_code}).
|
|
|
|
\begin{figure}[H]
|
|
\includegraphics[width=\textwidth]{manchester_code.png}
|
|
\caption{Manchester Code\cite{manchesterCodeImage}}
|
|
\label{figure:manchester_code}
|
|
\end{figure}
|
|
|
|
The advantages of manchester encoding are, that there are no prolonged high or
|
|
low signals. Furthermore, the original clock signal can be extracted from the signal and
|
|
doesn't need to be synchronized between the sender and receiver. On the other
|
|
side the bandwidth requirements are doubled as two code bits in the signal are
|
|
needed to encode one bit of the original data \cite{manchesterCode}.
|
|
|
|
For the work in this thesis, I use the definition of Manchester Code by G.E
|
|
Thomas.
|
|
|
|
\section{Web Worker}
|
|
\label{section:webworkers}
|
|
Web Workers are a web API that allows running JavaScript code in background
|
|
threads in the browser. This way you can run CPU intensive processes without
|
|
stalling the main thread and locking up the UI.
|
|
|
|
There are a few limitations with Web Workers. A Web Worker doesn't have access
|
|
to the \gls{dom}, to the window object, and to some web APIs. The communication
|
|
between the main thread, and the web workers occurs via messages \cite{WebWorkers}.
|