Correct thesis report
Signed-off-by: Severin Kaderli <severin@kaderli.dev>
This commit is contained in:
parent
2f8b0b524a
commit
1862068f09
10 changed files with 70 additions and 50 deletions
|
@ -2,7 +2,7 @@
|
|||
\label{chapter:benchmarking}
|
||||
This chapter will research the real world capabilities of MagSend. I attempt to transmit a message using different speeds of MagSend under different system CPU loads to see how it performs and which transfer speed is the most reliable to use.
|
||||
|
||||
The following benchmark test are structured in the same way. I run each test 5 times to get a more accurate view of the test. For each test I note if MagSend can detect the preamble, the received payload length, whether the \gls{crc} is valid and the received message.
|
||||
The following benchmark tests are all structured in the same way. I run each test 5 times to get a more accurate view of the test. For each test, I wrote down if MagSend can detect the preamble, the received payload length, the received message, and whether the \gls{crc} is valid.
|
||||
|
||||
The message used in the test transmissions is "\textbf{Test}".
|
||||
|
||||
|
@ -68,9 +68,9 @@ The following benchmarks were run with 25\% CPU utilization. The tool \texttt{st
|
|||
\subsection{Results}
|
||||
As one can see in the benchmarks, the most successful configuration was running MagSend with \SI{1}{\bit\per\second} at with an idle CPU followed by \SI{0.5}{\bit\per\second} at an idle CPU.
|
||||
|
||||
The benchmarks with 25\% CPU load were mostly failing, with some few ones being able to detect the preamble and one even being able to receive the payload length from the message. There might be a few reasons why the results are like this. The first one is thermal throttling (see \autoref{section:thermal_throttling}).
|
||||
The benchmarks with 25\% CPU load were mostly failing, with a few being able to detect the preamble, and one even being able to receive the payload length from the message. There might be a few reasons why the results are like this. The first one is thermal throttling (see \autoref{section:thermal_throttling}).
|
||||
|
||||
The laptop that was used for running the benchmarks, already reaches CPU temperatures of over \SI{90}{\celsius} when only running at around 25\% CPU load (see \autoref{figure:cpu_temperatures}).
|
||||
The laptop that was used for running the benchmarks already reaches CPU temperatures of over \SI{90}{\celsius} when only running at around 25\% CPU load (see \autoref{figure:cpu_temperatures}).
|
||||
|
||||
\begin{figure}[H]
|
||||
\fbox{\includegraphics[width=1\textwidth]{benchmarking/cpu_temperatures.png}}
|
||||
|
@ -78,4 +78,4 @@ The laptop that was used for running the benchmarks, already reaches CPU tempera
|
|||
\label{figure:cpu_temperatures}
|
||||
\end{figure}
|
||||
|
||||
The other problem with the failing benchmarks is on the receiving side. The interval at which the sensor provides data to the application is not guaranteed and thus introduces some jitter \cite{androidSensorMonitor}.
|
||||
The other problem with the failing benchmarks is on the receiving side. The interval at which the sensor provides data to the application is not guaranteed and thus introduces some jitter \cite{androidSensorMonitor}, which is not yet handled perfectly in the app.
|
||||
|
|
Reference in a new issue