hunspell-check

bericht/batch/bat-installation.tex

@@ -9,7 +9,7 @@ dem Head-Node erstellten Schlüssel auf die anderen Nodes
 (\emph{/etc/munge/munge.key}).
 
 SLURM setzt für die Authentifizierung voraus, das der in der Konfiguration
-festgelege Nutzer auf allen Systemen die gleiche UID besitzt:
+festgelegten Nutzer auf allen Systemen die gleiche UID besitzt:
 
   \shellcmd{sudo usermod -u 992 slurm}
 

bericht/batch/bat-konfiguration.tex

@@ -1,11 +1,11 @@
 \subsection{Konfiguration}
 
-Die Konfiguration der Queues (in SLURM Partitions genannt) erfolgt über die
+Die Konfiguration der Queues (in SLURM \texttt{Partitions} genannt) erfolgt über die
 Konfigurationsdateien im Ordner \emph{/etc/slurm/} (auch zu finden in \emph{aufgabe5.2/slurm}).
 Die Prioritäten wurden in folgender Reihenfolge absteigend vergeben: benchmark, express, small, long
-Die benchmark-Partition bekam die größte Priorität, so das Jobs aus anderen
+Die \texttt{benchmark}-Partition bekam die größte Priorität, so das Jobs aus anderen
 Queues angehalten werden. Die anderen Queues wurden umgekehrt proportional zur Zeitdauer
-priorisiert. Dadurch werden Nutzer des Batchssystems dazu bewegt Jobs, die
+priorisiert. Dadurch werden Nutzer des Batchsystems dazu bewegt Jobs, die
 weniger Zeit benötigen, den richtige Queue zu zu ordnen.
 
 Zusätzlich zur Verwaltung der Cores haben wir SLURM für die Verwaltung der GPUs

bericht/bench/bench-hpl.tex

@@ -6,7 +6,7 @@ Der HPL-Benchmark wurde mit folgenden Befehlen durchgeführt:
 \shellcmd{mpirun -x LD\_LIBRARY\_PATH -np 8 -hostfile allnodes -npernode 2 \textbackslash} \\
 \shellcmd{\hspace{1cm} /cluster/software/hpl/run\_hpl > hpl.out}
 
-In der Datei \emph{allnodes} sind die Hostnames der Computenodes hinterlegt.
+In der Datei \emph{allnodes} sind die Hostnames der Compute-Nodes hinterlegt.
 Beim Basislauf wurde ein maximaler Wert von $3,842 \cdot 10^{-4}$ GFlops mit folgender Konfiguration erreicht:
 
 \begin{lstlisting}
@@ -15,7 +15,7 @@ Beim Basislauf wurde ein maximaler Wert von $3,842 \cdot 10^{-4}$ GFlops mit fol
 	WR00L2L2          35     4     1     4
 \end{lstlisting}
 
-Der optimierte Lauf mit der Standard BLAS-Library des Systems mit der Konfiguration:
+Der optimierte Lauf mit der Standard-BLAS-Bibliothek des Systems mit der Konfiguration:
 
 \begin{lstlisting}
 	T/V                N    NB     P     Q
@@ -36,7 +36,7 @@ einen Wert von {\bf 4,076 GFlops}.
 
 \subsubsection{Auswertung}
 
-Verglichen mit der theoretischen Floating Point Peak Performance von: \\ $1,6$
+Verglichen mit der theoretischen Floating-Point-Peak-Performance von: \\ $1,6$
 GHz $\cdot 2$ CPU-Kerne pro Prozessor $\cdot 2$ Instruktion pro Takt $\cdot 4$
 CPUs $ = 25,6$ GFlops \\ erreichten wir also ca. 16 \% der maximal möglichen
 Leistung, was in Anbetracht des langsamen Verbindungsnetzwerkes ein akzeptabler

bericht/bench/bench-iozone.tex

@@ -27,7 +27,7 @@ Testaufruf:
 
 \shellcmd{./iozone -azcR -+q 1 -U /fastfs -f /fastfs/testfile -b excel-fastfs.xls}
 
-Der Parameter \emph{-+q 1} sorgt für einen Delay zwischen den einzelnen Tests, ohne den der Benchmark fehlerhaft läuft.\\
+Der Parameter \emph{-+q 1} sorgt für einen Verzögerung zwischen den einzelnen Tests, ohne den der Benchmark fehlerhaft läuft.\\
 
 \subsubsection{Auswertung}
 
@@ -35,14 +35,14 @@ Die Lesegeschwindigkeit von NFS entspricht mit als Maximalwert gemessenen 109 Mi
 
 \shellcmd{hdparm -t /dev/sda}
 
-Die Schreibegeschwindigkeit liegt bei maximal 62 MiB/s und sollte auch in etwa
+Die Schreibgeschwindigkeit liegt bei maximal 62 MiB/s und sollte auch in etwa
-der Leistungsfähigskeit der Festplatte entsprechen.
+der Leistungsfähig der Festplatte entsprechen.
 
 GlusterFS liegt in der Lesegeschwindigkeit von maximal 104 MiB/s etwa mit NFS
-gleich auf. Die Schreibegeschwindigkeit hingegen erreicht lediglich 28 MiB/s und
+gleich auf. Die Schreibgeschwindigkeit hingegen erreicht lediglich 28 MiB/s und
 liegt damit weit hinter NFS. Dies lässt sich im Wesentlichen darauf
 zurückführen, dass GlusterFS ein FUSE-Dateisystem ist und es deshalb bei jeder
-Schreibeoperation es etliche Kontextwechsel und Kopiervorgänge gibt, weil die
+Schreiboperation es etliche Kontextwechsel und Kopiervorgänge gibt, weil die
 einzelnen Nodes miteinander kommunizieren müssen, um die Daten verteilt
 schreiben zu können.  Zusätzlich stellen hier also auch die Atom-Prozessoren
 durch ihre begrenze Leistungsfähigkeit einen limitierenden Faktor dar.

bericht/bs/bs-git.tex

@@ -20,7 +20,7 @@ Nun kann die eigentliche Konfiguration per git heruntergeladen werden:
 Wir legten in dieser Konfiguration das Repository \emph{lctp} an und gaben allen
 Benutzern Zugriff darauf. Die gitolite-Konfiguration befindet sich als
 Git-Submodule im Verzeichnis \emph{aufgabe2.4/gitolite-admin}.
-Das lctp-Repository wiederum lässt sich mit folgendem Befehl clonen:
+Das lctp-Repository wiederum lässt sich mit folgendem Befehl klonen:
 
 \shellcmd{git clone git@141.76.90.104:lctp.git lctp-gruppe4}
 
@@ -55,7 +55,7 @@ vorrangig ausgeführt. Die Wrapper befinden sich in \emph{aufgabe2.4/yaourt}
 sowie in \emph{aufgabe2.4/pacman}. Darüber hinaus haben wir das Shell-Script für
 tägliche automatische Commits, welches sich im
 \href{https://github.com/joeyh/etckeeper/blob/master/debian/cron.daily}{Git-Repository}
-(Stand 07.11.2013) von \emph{etckeeper} liegt, als Cronjob eingerichtet (siehe
+(Stand 07.11.2013) von \emph{etckeeper} liegt, als Cron-Job eingerichtet (siehe
 \emph{aufgabe2.4/cron.daily/etckeeper}).
 
 \subsubsection{Logs in git}

bericht/bs/bs-pdsh.tex

@@ -9,7 +9,7 @@ Das entsprechende Paket war nicht im offiziellen Arch Linux Repository
 vorhanden, deshalb haben wir es über das AUR (siehe \ref{sec:aur}) installiert.
 
 \subsubsection{Gruppenverwaltung} Zur Verwaltung mehrerer Rechner in Gruppen (in
-unserem Fall Headnode und Computenodes) greift \emph{Pdsh} auf die
+unserem Fall Head-Node und Compute-Nodes) greift \emph{Pdsh} auf die
 Gruppenbeschreibungsdatei \texttt{ /etc/genders} (siehe
 \emph{aufgabe2.5/genders}) zurück. Dort können mehrere Hosts in verschiedene
 Gruppen eingeteilt werden. Um zu gewährleisten, dass Pdsh den richtigen Befehl

bericht/bs/bs-ssh.tex

@@ -43,4 +43,4 @@ Das automatisierte Hinzufügen neuer Nutzer haben wir über ein Script
 \texttt{newuser} (siehe \emph{aufgabe2.3/newuser}) gelöst. Dieses Script legt
 einen neuen Benutzer an, erstellt dessen  Home-Verzeichnis, generiert ein neues
 Public-Private-Key-Paar für SSH und trägt den eigenen Public-Key in die
-\emph{authorized\_keys} ein und ermöglich den Zugriff auf das git-Repository.
+\emph{authorized\_keys} ein und ermöglicht den Zugriff auf das git-Repository.

bericht/bs/bs.tex

@@ -1,6 +1,6 @@
-\section{Betriebsysteminstallation}
+\section{Betriebssysteminstallation}
 
-\subsection{Wahl des Betriebsystems}
+\subsection{Wahl des Betriebssystems}
 \label{sub:wahl_des_betriebsystems}
 
 Wir haben \href{http://www.archlinux.org/}{Arch Linux} als Betriebssystem gewählt. Es hat mit \emph{Systemd} ein modernes und robustes init-System. Systemd verwaltet Abhängigkeiten zwischen den verschiedenen Systemdiensten. Gestartete Dienste werden überwacht und können im Fehlerfall neu gestartet werden.
@@ -31,21 +31,23 @@ Die Partitionierung haben wir wie im Cluster-Layout angegeben mit \emph{fdisk} v
 
 Nach ursprünglichen Schwierigkeiten mit dem Internet-Zugang im TGI-Labor (keine IP-Adresse über DHCP erhalten), konnten wir dann das Basis-System mittels \emph{pacstrap} installieren und danach mittels \emph{arch-chroot} in dieses wechseln. Dort wurden nach der Anleitung die Sprache, das Konsolen-Tastaturlayout, die Zeitzone, Datum und Uhrzeit und die Hostnames festgelegt sowie den Bootloader \emph{GRUB} installiert und konfiguriert.
 
-Nach dem erfolgreichen Reboot haben wir dann das Netzwerk auf eine statische IP-Adresse mittels \emph{netctl} konfiguriert. Damit waren sowohl die Headnode als auch der erste Computenode grundsätzlich einsatzfähig.
+Nach dem erfolgreichen Reboot haben wir dann das Netzwerk auf eine statische
+IP-Adresse mittels \emph{netctl} konfiguriert. Damit waren sowohl die Head-Node
+als auch der erste Compute-Node grundsätzlich einsatzfähig.
 
 \subsubsection{Netzwerk-Konfiguration}
 
-Auf dem Headnode bzw. Computenode haben wir mit \emph{netctl} die beiden
+Auf dem Head-Node bzw. Compute-Node haben wir mit \emph{netctl} die beiden
 Netzwerk-Interfaces \emph{eth0} und \emph{eth1} bzw. \emph{enp1s0} auf eine
 statische IP-Adresse (wie im Cluster-Layout angegeben) konfiguriert (siehe
 \emph{aufgabe2.2/headnode/network} und \emph{aufgabe2.2/headnode/internal} bzw.
 \emph{aufgabe2.2/computenode/internal}).
 
-Auf dem Headnode mussten wir noch mittels \emph{iptables} das \texttt{
+Auf dem Head-Node mussten wir noch mittels \emph{iptables} das \texttt{
 MASQUERADE}-Target in der \emph{POSTROUTING}-Chain in der \emph{nat}-Tabelle auf
 dem \emph{eth0}-Interface setzen (siehe \emph{aufgabe2.3/iptables.rules}) und mit
 \emph{sysctl} (\emph{/etc/sysctl.d}) die Option \emph{net.ipv4.ip\_forward = 1}
-(siehe \emph{aufgabe2.2/10-ip-forward-conf}) freischalten, damit die Computenodes auch auf das Internet zugreifen können (Paketinstallationen, Updates, etc.).
+(siehe \emph{aufgabe2.2/10-ip-forward-conf}) freischalten, damit die Compute-Nodes auch auf das Internet zugreifen können (Paketinstallationen, Updates, etc.).
 
 \input{bs/bs-ssh}
 

bericht/burnin.tex

@@ -8,12 +8,12 @@ Zur Überwachung und Aufzeichnung des Systems während des Burnin haben wir
 \texttt{Munin} eingerichtet. Munit besteht aus einem Masterprozess, welches
 die gewünschten Daten aufzeichnet und einem Nodeprozess, welches die Daten
 bereitstellt. Die Darstellung erfolgt über ein Webinterface, welches die Graphen
-aus einer \emph{Rddtool}-Datenbank generiert. Auf dem Headnode haben wir den
+aus einer \emph{Rddtool}-Datenbank generiert. Auf dem Head-Node haben wir den
 Masterprozess installiert:
 
 \shellcmd{pacman -S munin}
 
-Auf dem Computenode die Nodekomponente:
+Auf dem Compute-Node die Nodekomponente:
 
 \shellcmd{pacman -S munin-node}
 
@@ -39,7 +39,7 @@ klein ist, haben wir uns für die Aktualisierung der Leistungsdaten mithilfe
 
 Munin bringt bei der Installation schon eine Vielzahl von Plugins mit. Manche
 von dieser Plugins benötigen wiederum für die Datenerfassung andere Programme.
-Auf dem Computenode haben wir folgende Plugins aktiviert:
+Auf dem Compute-Node haben wir folgende Plugins aktiviert:
 
 \begin{itemize}
 \item cpu

bericht/cluster-layout.tex

@@ -33,7 +33,7 @@ Wir haben uns folgendes Cluster-Layout überlegt: (Details auf nächster Seite)
 {\bf Compute-Nodes:} \\
 
 \begin{tabularx}{45em}{l|X|X|X|X}
-  Hostnames   & \texttt{zotac1}\footnote{330er Board und 1. Computenode}  & \texttt{zotac2}  & \texttt{zotac3}    & \texttt{zotac4}   \\
+  Hostnames   & \texttt{zotac1}\footnote{330er Board und 1. Compute-Node}  & \texttt{zotac2}  & \texttt{zotac3}    & \texttt{zotac4}   \\
   \hline
   Interne IPs & \texttt{\small 10.20.0.101} & \texttt{\small 10.20.0.102} & \texttt{\small 10.20.0.103} & \texttt{\small 10.20.0.104} \\
   \hline

bericht/hardware.tex

@@ -12,7 +12,7 @@ In die beiden zur Verfügung stehenden Gehäuse bauten wir jeweils zwei Mainboar
 Da nur drei ZOTAC-Boards vorhanden waren, mussten wir als vierten Compute-Node
 ein normales Intel-Mainboard (ohne nVidia-Chip) verwenden. \\
 
-Beide Boards waren jeweils ausgestattet mit: %\footnote{330er Board und 1. Computenode}
+Beide Boards waren jeweils ausgestattet mit: %\footnote{330er Board und 1. Compute-Node}
 
 \begin{itemize}
   \item einem (bereits fest verbautem) Intel Atom 330 Prozessor

bericht/ori/ori-inst.tex

@@ -2,7 +2,14 @@
 
 \subsubsection{Vorbereitungen}
 
-Da Ori seine Configs und Repositorien unter \emph{.ori} im Home-Verzeichnis des jeweiligen Nutzers ablegt und dieses auf allen Nodes eingebunden wird, würden zwangsweise Fehler auftreten. Deshalb wurde auf allen Computenodes eine neue Partition erstellt und unter \emph{/ori} gemounted. Mit \emph{useradd ori} wurde ein neuer User ori angelegt, dem mit \emph{chown /ori/home ori:ori} und \emph{usermod --home /ori/home ori} das Home-Verzeichnis \emph{/ori/home} zugeteilt wurde. Mit \emph{ssh-keygen} wurden auf Computenode 1 die ssh-Schlüssel erstellt und anschließend auf Computenode 2 übertragen. Desweiteren wurde der Public-Key in die \emph{authorized\_keys} eingetragen. Mit diesen Arbeitsschritten war nun ein passwortloser Zugriff für den Nutzer ori auf die beiden Coputenodes gewährleistet. 
+Da Ori seine Configs und Repositorien unter \emph{.ori} im Home-Verzeichnis des
+jeweiligen Nutzers ablegt und dieses auf allen Nodes eingebunden wird, würden
+zwangsweise Fehler auftreten. Deshalb wurde auf allen Compute-Nodes eine neue
+Partition erstellt und unter \emph{/ori} gemounted. Mit \emph{useradd ori} wurde
+ein neuer User ori angelegt, dem mit \emph{chown /ori/home ori:ori} und
+\emph{usermod --home /ori/home ori} das Home-Verzeichnis \emph{/ori/home}
+zugeteilt wurde. Mit \emph{ssh-keygen} wurden auf Compute-Node 1 die
+ssh-Schlüssel erstellt und anschließend auf Compute-Node 2 übertragen. Desweiteren wurde der Public-Key in die \emph{authorized\_keys} eingetragen. Mit diesen Arbeitsschritten war nun ein passwortloser Zugriff für den Nutzer ori auf die beiden Coputenodes gewährleistet. 
 
 \subsubsection{Installation}
 

bericht/prov/prov-backup.tex

@@ -4,7 +4,7 @@
 Wir haben uns für \href{http://www.rsnapshot.org/}{Rsnapshot} aus folgenden Gründen entschieden:
 
 \begin{itemize}
-  \item Die Backups liegen als Ordner mit den gleichen Rechten wie im zu backupenden System.
+  \item Die Backups liegen als Ordner mit den gleichen Rechten wie im zu sichernden System.
     Dies hat den Vorteil, dass andere Nutzer diese einsehen können und
     selbständig Dateien wiederherstellen können.
   \item Rsnapshot erstellt differentielle Backups. Dabei werden Dateien, die

bericht/prov/prov-provisioning.tex

@@ -12,14 +12,14 @@ da auf den Festplatten der Compute-Nodes genügend Speicher für das
 Betriebssystem vorhanden ist und bei jedem Zugriff auf das Dateisystem unnötigen
 Latenzen entstehen würden.
 
-Um Clonezilla auf den Computenodes zu booten, haben wir den
+Um Clonezilla auf den Compute-Nodes zu booten, haben wir den
 \emph{in.tftpd}-Server installiert und das Service-File für \emph{Systemd}
 angepasst (siehe \emph{aufgabe4.4/tftpd.service}). Außerdem haben wir die
 Konfiguration des DHCP-Servers so angepasst, dass nun jede Compute-Node eine
 eigene Konfigurationsdatei in \emph{/etc/dhcpd.d/} hat, die jeweils von
 \emph{/etc/dhcpd.d/all} inkludiert wird.
 
-Außerdem haben wir ein Script \emph{ cluster} geschrieben, mit dem die Computenodes verwaltet werden können. Mit
+Außerdem haben wir ein Script \emph{ cluster} geschrieben, mit dem die Compute-Nodes verwaltet werden können. Mit
 \begin{lstlisting}
 cluster add <HOSTNAME> <IP> <MAC>
 \end{lstlisting}
@@ -42,22 +42,22 @@ Konfigurationsdateien liegen in \emph{/srv/tftp/pxelinux/pxelinux.cfg}.
 
 \end{sloppypar}
 
-\subsubsection{Provisionierung der Computenodes}
+\subsubsection{Provisionierung der Compute-Nodes}
 
 \begin{sloppypar}
 
 Um den Clone-Vorgang zu starten, führten wir nun mit dem Befehl \emph{sudo
 cluster set-clone <HOSTNAME>} aus. Durch Neustart des Nodes wird das Clonezilla
-Live Image gebootet. Dieses holt sich nun vom Headnode ein Script und führt es
+Live Image gebootet. Dieses holt sich nun vom Head-Node ein Script und führt es
 aus. In diesem Script haben wir alle nötigen Befehle eingetragen, um das Clonen
 vorzubereiten und zu starten (siehe \emph{aufgabe4.4/clone.sh}). Dazu wird per
-NFS das \emph{/cluster}-Verzeichnis des Headnodes eingebunden und dort im
+NFS das \emph{/cluster}-Verzeichnis des Head-Nodes eingebunden und dort im
-Unterverzeichnis \emph{images} das Image der Festplatte abgelegt. Geclont werden
+Unterverzeichnis \emph{images} das Image der Festplatte abgelegt. Geklont werden
 nur die \emph{/}- und die \emph{/boot}-Partition.
 
 Zum Wiederherstellen des Images wird mit \emph{sudo cluster set-restore
 <HOSTNAME>} wieder der entsprechende Boot-Modus gesetzt und der Node
-neugestartet. Dort wird nun ein anderes Script vom Headnode geholt (siehe \emph{
+neu gestartet Dort wird nun ein anderes Script vom Head-Node geholt (siehe \emph{
 aufgabe4.4/restore.sh}) und die beiden Partitionen wiederhergestellt.
 Anschließend werden noch die Swap-Partition und die Daten-Partition für das
 verteilte Dateisystem neu formatiert und die alten UUIDs gesetzt.

bericht/prov/prov.tex

@@ -1,5 +1,4 @@
-\section{Compiler, Modules, Backup und Klonen
+\section{Compiler, Modules, Backup und Klonen des Compute-Node}
-des Compute Nodes}
 
 \input{prov/prov-compiler}
 

bericht/sv/sv-dhcp_dns.tex

@@ -5,10 +5,10 @@
 \begin{sloppypar}
 Wir haben uns für den \emph{ISC-Dhcpd} als DHCP-Server entschieden. Zur
 Konfiguration haben wir in \emph{/etc/dhcpd.conf} (siehe \emph{aufgabe3.2}) die
-interne Top-Level-Domain \emph{zotac} eintragen und den Headnode als DNS-Server eingestellt.
+interne Top-Level-Domain \emph{zotac} eintragen und den Head-Node als DNS-Server eingestellt.
 \end{sloppypar}
 
-Des Weiteren haben wir das Subnet \emph{10.20.0.0/24} deklariert und wiederum den Headnode als verantwortlichen Router eingetragen.
+Des Weiteren haben wir das Subnet \emph{10.20.0.0/24} deklariert und wiederum den Head-Node als verantwortlichen Router eingetragen.
 
 Die Pro-Host-Konfiguration sieht bei uns wie folgt aus:
 

bericht/sv/sv-filesystems.tex

@@ -25,8 +25,8 @@ Elastic-Hashing nennt. Dieser verteilte Ansatz verbessert die Verfügbar- und
 Skalierbarkeit, da bei Dateisystemen wie Lustre, der Metadatenserver häufig zum
 Flaschenhals wird. Das Dateisystem lässt sich im laufenden Betrieb um weitere
 Nodes erweitern. GlusterFS kann auf beliebige Dateisysteme aufgesetzt werden,
-was die Wiederherstellung im Falle eines Absturzes vereinfacht. Der einzigste
+was die Wiederherstellung im Falle eines Absturzes vereinfacht. Der einzige
-Nachteil, der uns aufgefallen ist, ist das GlusterFS auf Basis von Fuse im
+Nachteil, der uns aufgefallen ist, ist das GlusterFS auf Basis von FUSE im
 User-Space implementiert ist, was potentiell langsamer als eine entsprechende
 Kernel-Implementierung ist.
 
@@ -36,7 +36,7 @@ Partition angelegt, diese mit Befehl:
 \shellcmd{mkfs.xfs -i size=512 /dev/sda5}
 
 formatiert und nach \emph{/mnt/glusterfs} gemountet (siehe aufgabe3.3/fstab).
-Nach dem Starten des GlusterFS-Dienstes, sowohl auf Head- und Computenode:
+Nach dem Starten des GlusterFS-Dienstes, sowohl auf Head- und Compute-Node:
 
 \shellcmd{systemctl enable glusterfs.service}
 
@@ -60,8 +60,8 @@ Um die Schreibdurchsatz zu ermitteln, verwendeten wir den Befehl \emph{dd}:
 
 um einen 512MB Block auf die Festplatte. Die Option \emph{conv=fdatasync} sorgt
 für einen Dateisystem-Sync nach dem Schreiben um die korrekte Schreibrate zu
-ermitteln. Für die Leserate haben wir folgenden Befehl benutzt um dieselbige
+ermitteln. Für die Leserate haben wir folgenden Befehl benutzt um erstellte
-erstellte Datei zu lesen:
+Datei zu lesen:
 
 \shellcmd{dd bs=1M count=512 if=/path/to/file of=/dev/null conv=fdatasync}
 

bericht/sv/sv-ldap.tex

@@ -34,7 +34,7 @@ Um auf den Verzeichnisdienst zugreifen zu können, haben wir eine Datei
 angelegt, die nur durch \emph{root}-Benutzer zugreifbar ist
 (Verzeichnisberechtigung $600_8$).
 
-\subsubsection{Client-Konfiguration (Headnode und Computenode)}
+\subsubsection{Client-Konfiguration (Head-Node und Compute-Node)}
 
 \begin{sloppypar}
 Hierfür haben wir die Variablen \emph{BASE, URI, TIMEOUT, NETWORK\_TIMEOUT} in