Update
[plateforme-wifi:dev-guide.git] / wifi-developer-guide.tex
1 \documentclass{article}
2
3 \usepackage[utf8]{inputenc}
4 \usepackage[french]{babel}
5 \usepackage{dingbat}
6 \usepackage{hyperref} % Pour les liens hypertexte
7 \usepackage{graphicx} % Pour les images
8 \usepackage{fourier-orns} % \danger
9 \usepackage{amssymb} % \varnothing
10 \usepackage{multirow}
11
12 % Une petite commande pour signaler dans le texte les petits soucis
13 % à éclaircir, ...
14 \newcommand\avoir[1]{\vspace{1ex}\fbox{     %
15 \begin{minipage}[]{0.9\textwidth}    %
16    {\bf À voir. }\small #1    %
17 \end{minipage}}%
18 \marginpar{\mbox{\eye}} %
19 \vspace{1ex}
20 }
21
22 % Commande « Attention »
23 \newcommand\warning[1]{\vspace{1ex}\fbox{     %
24 \begin{minipage}[]{0.9\textwidth}    %
25    {\bf Attention. }\small #1    %
26 \end{minipage}}%
27 \marginpar{\mbox{\danger}} %
28 \vspace{1ex}
29 }
30
31 % Cadre pour une note quelconque
32 \newcommand\note[2]{
33         \vspace{1ex}
34         \fbox{
35                 \begin{minipage}[]{0.9\textwidth}
36                         {\bf #1.}
37                         #2
38                 \end{minipage}
39         }
40         \vspace{1ex}
41 }
42
43 % Images
44 \graphicspath{{img/}}
45 \addtolength{\hoffset}{-1cm}
46 \addtolength{\textwidth}{2cm}
47 \newcommand\image[1]{
48 %  \begin{figure}[h]
49     \includegraphics[width=\textwidth]{img/#1}
50 %\end{figure}
51 }
52
53
54
55
56 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
57
58 \title{Plateforme Wifi\\---\\Guide du développeur}
59 \author{E. \bsc{Chaput}\\---\\E. \bsc{Bouttier}}
60
61 \begin{document}
62
63 \maketitle
64
65 \begin{abstract}
66    Ce document est une introduction au développement sur la plateforme wifi,
67    en particulier les drivers wifi, afin d'avoir une prise en main rapide du
68    code. Il fait suite au document sur l'utilisation de la plateforme wifi.
69 \end{abstract}
70
71 \tableofcontents
72
73 \newpage
74
75 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
76
77 \section{Introduction}
78
79 Ce document est composé de quatres parties que l’on pourrait associer
80 deux-à-deux.
81
82 Les deux premières parties s’intéressent à la génération du système fournit dans
83 le guide l’utilisateur. La première partie s’appuie pour cela sur une suite de
84 scripts automatisés alors que la deuxième partie détail pas-à-pas chaque étape.
85 Ainsi, la deuxième partie peut être survolé si on opte pour une génération
86 automatique du système. Cependant, elle contient des informations pouvant
87 s’avérer utiles pour personnaliser son système.
88
89 Les deux dernières parties essayent de donner quelques informations sur
90 l'architecture des drivers wifi {\sc ath5k} et {\sc ath9k} afin de faciliter
91 leur modification à des fins expérimentales. Ils y est étudier l’effet du
92 carrier-sens, physique et virtuel, ainsi que du backoff sur les performances des
93 connexions en {\sc TCP} et {\sc UDP}.
94
95 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
96
97 \section{Utilisation des scripts de génération automatisé}
98
99 Afin de pouvoir régénéré le système le plus rapidement possible, des scripts
100 automatisants cette étape ont été écrit. Vous pouvez les récupérer depuis le
101 dépot {\sc git} accessible sur {\sc gitorious}. Pour cloner le dépot avec git,
102 on utilisera la commande suivante :
103 \begin{verbatim}
104     $ git clone git://gitorious.org/plateforme-wifi/autogen.git
105 \end{verbatim}
106 Sinon, on pourra télécharger directement une archive tar.gz de la dernière
107 version des fichiers du dépots à l'adresse suivante : \\
108 \url{https://gitorious.org/plateforme-wifi/autogen/archive-tarball/master}
109
110 Pour lancer la génération, on executera simplement :
111 \begin{verbatim}
112         $ make
113 \end{verbatim}
114
115 La génération du système se fait en 7 étapes, effectué par les scripts S01 à
116 S07. Les scripts S41 et S99 ne sont pas des scripts de génération du sytème,
117 mais des scripts qui y seront intégré. Le Makefile crée des fichiers
118 {\tt .stamp\_*} pour marqué chaque étape comme effectué. Il peut être nécessaire
119 d'en supprimer pour relancer une étape (ou alors exécuter directement le script
120 associé).
121
122 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
123
124 \section{Génération du système avec Buildroot}
125
126 \subsection{Description de buildroot}
127
128 Buildroot est une suite de scripts sous forme de Makefile qui permet
129 facilement de générer son propre système Linux. Il se charge de la compilation
130 d'une chaîne de compilation croisée afin de compiler le noyau, ainsi que tous
131 les programmes nécessaires pour avoir un système utilisable.
132 Il permet aussi la génération du fichier d'amorçage en {\sc pxe}.
133
134 \subsection{Obtenir buildroot}
135
136 La dernière version de buildroot peut être trouvé sur la page
137 \url{http://buildroot.uclibc.org/download.html}. Ce didactitiel a été réalisé
138 avec la version 2012.05 de buildroot.
139
140 \subsection{Configuration de buildroot}
141
142 Buildroot possède une interface de configuration en curses accessible avec la
143 commande suivante (à executer à la racine de l'archive décompressé) :
144
145 \begin{verbatim}
146    $ make menuconfig
147 \end{verbatim}
148
149 \image{buildroot.png}
150
151 \subsubsection{Utiliser la configuration proposé}
152
153 Il est possible de charger un fichier de configuration depuis le menu {\tt Load
154 an Alternate Configuration File}. Vous pouvez utiliser le fichier de
155 configuration {\tt buildroot-2012.05.config} fournit dans le dépot {\tt autogen}
156 (cf partie 1).
157
158 \subsubsection{Utiliser une configuration personnalisé}
159
160 Nous détaillerons dans cette partie les principales options qui ont permit de
161 réaliser le système fournit en annexe.
162
163 On gardera l'architecture {\tt i386} proposé, ainsi que la variante {\tt i586}.
164
165 Dans le menu {\tt Toolchain}, on pourra activer l'{\sc IPv6}. Si vous souhaitez
166 utiliser le {\tt syslog} évolué et non celui inclue dans {\tt busybox}, vous
167 devez choisir {\tt Enable large file (files > 2 GB) support}.
168
169 Dans le menu {\tt System configuration}, on veillera à bien spécifier un
170 baudrate de 19200 pour le port série. On pourra également personnaliser le nom
171 d'hôte. Nous verrons ultérieurement comment définir un nom d'hôte auto-déterminé
172 suivant la machine.
173
174 Dans le menu {\tt Bootloader}, on choisira {\tt syslinux} et on décochera
175 {\tt isolinux} pour ne garder que {\tt pxelinux}. Cette étape est facultative si
176 vous utilisez le fichier d'amorçage fournit en annexe. \\
177 \note{Attention}{Il se peut que la compilation échoue avec la version 4.04 de
178 syslinux. On pourra essayer de passer à la version 4.05 en appliquand un patch
179 disponible dans le dépot {\tt autogen} puis en relançant la compilation : \\
180 {\tt \$ patch -p1 < syslinux-4.05.patch}}
181  
182 On activera la compilation du noyau dans le menu {\tt Kernel}. Ceci est
183 également facultatif si vous souhaité seulement généré la chaine de compilation
184 croisé et utiliser le noyau fournit. Pour la configuration du noyau, on
185 pourra utiliser le fichier de configuration {\tt kernel.config} fournit en
186 annexe. Il est également possible de commencer une nouvelle configuration en se
187 basant sur un defconfig. On spécifira dans se cas {\tt i386} pour son nom.
188 Dans les deux cas, nous verrons par la suite comment modifier cette
189 configuration.
190
191 Après l'activation de la compilation du noyau, on choisira {\tt initramfs for
192 initial ramdisk of linux kernel} dans le menu {\tt Filesystem images}. On pourra
193 également décocher {\tt tar the root filesystem}, peut utile dans notre cas.
194
195 Dans le menu {\tt Package Selection for the target}, on pourra sélectionner
196 énormément de programme à compiler pour notre platforme. Busybox est un
197 programme essentiel qui propose toutes les commandes de base
198 ({\tt cp, mv, udhcpc, ...}).
199 L'option ``Show packages that are also provided by busybox'' permet par
200 exemple de sélectionner le client/serveur {\sc dhcp} de l'{\sc isc}.
201 Nous sélectionnerons par exemple {\tt bridge-utils}, {\tt hostapd},
202 {\tt iproute2}, {\tt iptables}, {\tt iw}, {\tt openssh}, {\tt tcpdump},
203 {\tt wireless tools} et {\tt wpa\_supplicant}, toutes disponibles dans le
204 menu {\tt Networking applications}, ainsi que {\tt vim} dans {\tt Text editors
205 and viewers} et {\tt syslogd \& klogd} dans {\tt System tools}. {\tt iperf}
206 nécessite une chaîne de compilation croisée avec support du {\tt C++} (plus
207 lent).
208
209 \subsection{Configuration du noyau Linux}
210
211 Il est possible de personnaliser la configuration du noyau en se basant sur le
212 defconfig précédemment sélectionné ou sur le fichier de configuration fournit.
213 Le noyau possède également une interface de configuration en curses accessible
214 par la commande :
215
216 \begin{verbatim}
217    $ make linux-menuconfig
218 \end{verbatim}
219
220 On supposera dans la suite que nous sommes partie du defconfig i386.
221 Nous allons pouvoir optimiser notre noyau en ne gardant que les drivers
222 nécessaire à notre matériel.
223
224 On pourra jeter un coup d'oeuil dans le menu {\tt Networking support}.
225 Si vous comptez utiliser bridge-utils, pensez à activer le support du bridge
226 dans le noyau ({\tt Networkins support > Networking options > 802.1d
227 Ethernet Bridging}).
228
229 Le menu {\tt Device drivers} est sans doute celui où il y a le plus à faire.
230 \begin{itemize}
231   \item Dans le menu {\tt Network device support > Ethernet driver support}, on
232   pourra tous désactiver pour ne garder que le driver {\tt DP8381x series PCI
233   Ethernet support} disponible en cochant {\tt National Semi-conductor devices}.
234   \item De même, on pourra tous désactiver dans le menu {\tt Network device
235   support > Wireless LAN} pour ne garder que les drivers {\sc Atheros} disponible dans
236   le menu {\tt Atheros Wireless Cards}.
237   \item On vérifira que {\tt netconsole} est bien supporté ({\tt Network device
238   support > Network core driver support > Network console logging support}).
239   Cette option permet de reçevoir les messages du noyau au démarrage en UDP.
240 \end{itemize}
241
242 \note{Remarque}{Il est préférable de compiler les drivers en dure dans le noyau
243 pour gagner le temps de chargement ({\tt [*]}). Cependant, pour travailler sur
244 les drivers wifi, il est préférable de les compiler comme module ({\tt [M]})
245 afin de pouvoir les décharger pour en charger d'autres.}
246
247 Dans le menu {\tt File systems}, nous pouvons décocher tous ce que nous pouvons.
248 On pourra éventuellement laisser le {\sc nfs} dans {\tt Network File System}
249 si besoin est.
250
251 On pourra décocher la {\tt virtualisation}.
252
253 \subsection{Personnalisation du système}
254
255 \subsubsection{Skeleton}
256
257 Buildroot se base pour générer notre système sur un skeleton. Il s'agit d'une
258 image du système de base avant installation des programmes compilés. Il est donc
259 possible de personnaliser son système en modifiant le contenue du skeleton.
260
261 Pour cela, nous allons commencer par copier le skeleton fournit par buildroot
262 disponible dans le dossier {\tt fs/skeleton}. Nous spécifirons l'emplacement de
263 notre copie dans le menu {\tt System configuration} en choisissant {\tt custom
264 target skeleton} pour l'option {\tt Root FS skeleton}. \\
265 \note{Remarque}{Après une première compilation, le skeleton n'est plus utilisé.
266 Vous pouvez tous de même faire des modifications en vue d'une autre compilation
267 directement dans le dossier {\tt output/target}.}
268
269 Les scripts d'init se trouvent dans le dossier {\tt /etc/init.d}, et sont lancé
270 par ordre numérique. Vous pouvez donc ajouter vos propres scripts de démarrage.
271
272 Il est possible que vous souhaitiez rajouter vos propres applications dans votre
273 système. La voie la plus simple est sans doute l'ajout d'un paquage dans
274 buildroot. On pourra se renseigner sur la méthode à suivre depuis la
275 documentation officielle :
276 \url{http://buildroot.uclibc.org/downloads/manual/manual.html#\_adding\_new\_packages\_to\_buildroot}.
277
278 \subsubsection{Réseau}
279
280 La configuration du réseau se fait classiquement par le fichier
281 {\tt /etc/network/interfaces}. Cependant, il est possible de spécifier la
282 configuration directement dans la ligne de commande du noyau, ce qui permet de
283 la modifier sans devoir régénérer votre noyau.
284
285 Pour obtenir une adresse {\sc ip} par {\sc dhcp}, il suffit de rajouter l'option
286 suivante :
287 \begin{verbatim}
288                 ip=dhcp
289 \end{verbatim}
290
291 Pour configurer une {\sc ip} statique, on pourra utiliser l'option suivante :
292 \begin{verbatim}
293                 ip=192.168.1.1::192.168.1.254:255.255.255.0:net4826:eth0:off
294 \end{verbatim}
295 où {\tt 192.168.1.1} est l'{\sc ip} de la machine, {\tt 192.168.1.254}
296 l'{\sc ip} du routeur et {\tt net4826} le nom d'hôte de la machine.
297
298 \subsubsection{SSH}
299
300 Si vous utilisez un serveur ssh, celui-ci génère au démarrage des clefs privées
301 ce qui est très lent sur ces petites machines, et fera également apparaître des
302 problèmes d'identification d'hôte entre deux démarrage. Il est donc préférable
303 de les ajouter au skeleton. Vous pouvez utiliser les clefs fournit avec le guide
304 de l'utilisateur :
305 \begin{verbatim}
306         $ cp /path/to/annexes/ssh_host_* fs/skeleton/etc/
307 \end{verbatim}
308
309 Vous pouvez également télécharger les clefs par {\sc tftp} au démarrage comme c'est le
310 cas dans le système fournit. Pour cela, vous pouvez utiliser le scripts {\tt
311 S41gettftpaddr} qui permet d'obtenir l'{\sc ip} du serveur tftp (voir le guide
312 de l'utilisateur), et patcher le script d'init
313 {\tt S50sshd} avec le patch {\tt S50sshd.patch} pour qu'il ne génère les clefs
314 que s'il n'a pas pu les télécharger :
315 \begin{verbatim}
316         $ patch -p1 < /path/to/annexes/S50sshd.patch
317 \end{verbatim}
318 \note{Remarque}{Le patch modifie le fichier {\tt package/openssh/S50sshd}. Si
319 vous avez déjà lancé une première compilation de buildroot, copier le
320 directement dans votre filesystem avant de relancer {\tt make} : \\
321 {\tt \$ cp package/openssh/S50sshd output/target/etc/init.d/}
322 }\\
323
324 Par defaut, le serveur ssh est configurer pour refuser les connexions sans mot
325 de passe, entre autre celle de l'utilisateur {\tt root}. Il est donc nécessaire
326 de modifier cette option dans le fichier {\tt output/target/etc/sshd\_config} 
327 \emph{après une première génération de notre système} (sans quoi le fichier
328 n'existerai pas encore). Il faut donc rajouter la ligne :
329 \begin{verbatim}
330         PermitEmptyPasswords yes
331 \end{verbatim}
332 Le patch {\tt sshd\_config.patch} s'occupe de cette modification :
333 \begin{verbatim}
334         $ patch -p1 < /path/to/annexes/sshd_config.patch
335 \end{verbatim}
336
337 Si vous souhaitez utiliser l'authentification par clef, aujouter votre clef
338 public dans le fichier {\tt /root/.ssh/authorized\_keys} :
339 \begin{verbatim}
340         $ mkdir -p fs/skeleton/root/.ssh/authorized_keys
341         $ cat ~/id_rsa.pub >> fs/skeleton/root/.ssh/authorized_keys
342 \end{verbatim}
343 Vous pouvez utiliser la clef id\_soekris contenue dans le dépot {\tt autogen}
344 pour vous connecter au système fournit. Cependant, celle-ci étant publiquement
345 disponible, elle peut introduire de grave problème de sécurité.
346
347 \subsection{Génération du système}
348
349 Pour lancer la génération de votre système précédement compilé, lancé tous
350 simplement :
351 \begin{verbatim}
352         $ make
353 \end{verbatim}
354
355 À la fin de la compilation, vous pourrez récupérer votre système dans le dossier
356 {\tt output/images}. Il contient généralement les fichiers {\tt pxelinux.bin} et
357 {\tt bzImage} ainsi qu'un fichier {\tt root.tar} si vous aviez demandé une
358 archive tar du système de fichier.
359
360 Vous pouvez par la suite modifier des options dans le menuconfig et/ou modifier
361 le système de fichier présent dans le dossier {\tt output/target}. Relancez
362 alors la commande {\tt make} pour régénérer votre images. Dans le cas de la
363 modification d'un paquage, pour que votre modification soit prise en compte,
364 vous devrez préalablement le nettoyer :
365 \begin{verbatim}
366         $ make <package>-clean
367 \end{verbatim}
368 Pour en savoir plus sur le fonctionnement de buildroot, on se reportera à la
369 documentation officielle :
370 \url{http://buildroot.uclibc.org/downloads/manual/manual.html#\_how\_buildroot\_works}
371
372 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
373
374 \section{Drivers wifi}
375
376 Les douze Soekris de la plateforme wifi sont équipés de cartes {\tt WLM200MX} munient
377 du chipset {\sc Atheros} {\tt AR9220} et requérant le driver {\tt ATH9K} pour
378 fonctionner. Deux autres cartes {\tt WLM54AG} utilisant le chipset {\tt AR5414} et
379 requirant le driver {\tt ATH5K} sont également disponibles.
380
381 Anciennement, les cartes wifi {\sc Atheros} étaient utilisées avec les drivers
382 {\sc Madwifi}. Ceux-ci étaient composés d'une couche {\tt HAL}, fournit par {\tt
383 Atheros} et non open source, ainsi que d'une couche libre, utilisant les
384 fonctions de la couche {\tt HAL}. Leurs modifications étaient très limité dû à
385 l'impossibilité d'accéder à la couche matérielle.
386
387 Depuis le noyau 2.6.25 environ, de nouveaux drivers entièrement open source,
388 {\tt ATH5K} et {\tt ATH9K} sont présent directement dans les sources du noyau.
389 Ils s'agit de ces drivers que nous étudirons, les drivers {\sc Madwifi} étant
390 dépréciés.
391
392 \subsection{Récupération des sources}
393
394 Les sources des drivers wifi {\sc Atheros} sont disponible directement avec les
395 sources du noyau linux, que vous pouvez récupérer sur \url{http://kernel.org}.
396 Vous trouverez les drivers dans le dossier : {\tt linux/drivers/net/wireless/ath}.
397 Si vous avez utilisé buildroot, celui-ci a déjà récupéré les sources du noyau.
398 Vous pouvez les récupérer dans le dossier \\
399 {\tt buildroot/output/build/linux-x.y.z/}.
400
401 \subsection{Compilation des drivers}
402
403 La compilation des drivers sous Linux est basé sur le Kernel Build System
404 utilisant des Makefile un peu particulier. Le Makefile pour les drivers
405 {\sc Atheros} est présent dans le dossier {\tt ath}. Pour lancer la compilation,
406 exécutez la commande suivante :
407 \begin{verbatim}
408         $ make -C /path/to/linux/source/dir SUBDIRS=/path/to/module/source/dir modules
409 \end{verbatim}
410 À partir du dossier {\tt ath} dans buildroot, vous pouvez simplement lancer la
411 commande :
412 \begin{verbatim}
413         $ make -C ../../../.. SUBDIRS="$(PWD)" modules
414 \end{verbatim}
415
416 Vous pouvez également rajouter dans le Makefile présent dans le dossier {\tt
417 ath} les lignes suivantes (en fin de fichier) :
418 \begin{verbatim}
419 default:
420         $(MAKE) -C /linux/source/dir SUBDIRS=/module/source/dir modules
421 \end{verbatim}
422 Vous pouvez ainsi simplement lancer la commande {\tt make} depuis le dossier
423 {\tt ath}, qui exécutera alors la cible {\tt default}.
424
425 \subsection{Modules et dépendances}
426
427 Les drivers Madwifi étaient basé sur l’interface Wireless-Extention ({\sc WEXT})
428 du noyau. Cependant, une nouvelle interface basé non plus sur {\tt ioctl} mais
429 sur des structures de callback, lib/mac/cfg80211, a vue le jour. Les nouveaux
430 drivers s’appuient sur cette interface.
431
432 Les drivers {\sc Atheros} {\tt ATH5K} et {\tt ATH9K} sont composé de cinq
433 modules :
434 \begin{itemize}
435         \item {\tt ath} : La partie commune aux modules {\tt ath5k} et {\tt ath9k} ;
436         \item {\tt ath5k} : le driver {\tt ath5k} ;
437         \item {\tt ath9k} : le driver {\tt ath9k} ;
438         \item {\tt ath9k\_hw} : la partie hardware du driver {\tt ath9k} ;
439         \item {\tt ath9k\_common} : partie commune au driver {\tt ath9k} et au
440         driver {\tt ath9k\_htc} (le driver {\tt htc} est utilisé pour deux chipset
441         spécifique).
442 \end{itemize}
443
444 Après compilation des modules, il faut encore les charger en mémoire avec la
445 commande {\tt insmod <module.ko>}. Cependant, un ordre précis est à respecter
446 afin de satisfaire les dépendances de chaque module. Celles-ci peuvent être
447 obtenu à l’aide de la commande {\tt modinfo <module.ko>}. Voici la liste des
448 dépendances pour les modules qui nous intéressent :
449
450 \begin{itemize}
451         \item {\tt lib80211} : $\varnothing$
452         \item {\tt cfg80211} : $\varnothing$
453         \item {\tt mac80211} : cfg80211
454         \item {\tt ath} : cfg80211
455         \item {\tt ath5k} : ath, mac80211, cfg80211
456         \item {\tt ath9k\_hw} : ath
457         \item {\tt ath9k\_common} : ath9k\_hw, ath
458         \item {\tt ath9k} : ath9k\_common, ath9k\_hw, ath, mac80211, cfg80211
459 \end{itemize}
460
461 \subsection{Architectures}
462
463 \includegraphics[angle=90,height=18cm]{architecture.pdf}
464
465 Lorsqu’un fichier est modifié, il est utile de savoir après compilation quel
466 module doit être rechargé. Ce diagramme renseigne pour chaque fichier avec quel
467 module il est linké (obtenue à partir du Makefile).
468
469 \subsection{Debuggage}
470
471 Des informations de débuggage sont disponible en compilant les drivers
472 {\sc Atheros} avec respectivement les options {\tt CONFIG\_ATH5K\_DEBUG} et
473 {\tt CONFIG\_ATH9K\_DEBUGFS}.
474
475 Les informations de débuggage pour le driver {\tt ath9k} sont disponible sous la
476 forme d’entrées dans le debugfs. Pour y accéder, celui-ci doit d’abord être
477 monté :
478 \begin{verbatim}
479         # mount -t debugfs none /sys/kernel/debug
480 \end{verbatim}
481
482 Vous trouverez les entrées liées au driver {\tt ath9k} dans le dossier \\
483 {\tt /sys/kernel/debug/ieee80211/phyX/ath9k/}. Les informations pour chaque
484 entrée est disponible sur la page officielle de documentation à l’adresse :
485 \url{http://linuxwireless.org/en/users/Drivers/ath9k/debug}.
486
487 L’entrée la plus importante est sans doute {\tt debug}. En effet, celle-ci
488 permet de modifier le filtre des messages envoyé vers syslog. Par exemple, on
489 pourra afficher les messages de type {\tt FATAL}, {\tt BEACON} et {\tt QUEUE}
490 avec la commande {\tt echo "0x502" > debug} ({\tt cf} documentation pour les
491 détails du masque).
492
493 \subsubsection{Queues}
494
495 Les trames, data, beacon ou autre, sont placées dans des queues. Celles-ci
496 possèdent plusieurs paramètres, stoqué dans une structure
497 {\tt ath9k\_tx\_queue\_info} (définie dans {\tt mac.h}). Les fonctions
498 {\tt ath\_txq\_setup} et {\tt ath\_txq\_update} (présentent dans {\tt xmit.c})
499 permettent de les modifier. Afin de connaître les paramètres actuels des
500 différentes queues, il est possible de rajouter une entrée
501 {\tt tx\_queue\_info} dans le système de fichiers debugfs à
502 l’aide du patch {\tt debugfs\_tx\_queue\_info.patch} :
503 \begin{verbatim}
504         ath/ath9k$ patch -p1 < debugfs_tx_queue_info.patch
505 \end{verbatim}
506
507 \subsection{Tests avec débit}
508
509 Afin d’étudier l’influence des modifications effectuées, il est intéressant de
510 faire des tests de débit à l’aide d’{\tt iperf}. Celui-ci fonctionne en mode
511 client/serveur et effectue un test de bande passante du client vers le serveur.
512
513 Pour lancer le serveur sur un soekris, lancez simplement {\tt iperf -s}.
514 Pour connecter un client au serveur, lancez {\tt iperf -c A.B.C.D}. Vous pouvez
515 spécifier la durée d’un test avec l’option {\tt -t} (par défaut, 10 secondes).
516
517 Par défaut, les tests sont effectué en TCP. Utilisez l’option {\tt -u} pour
518 effectuer un test en UDP (le serveur également doit être lancé avec cette
519 option). Vous pouvez spécifier le débit de la transmission avec l’option
520 {\tt -b}, par exemple : {\tt iperf -c A.B.C.D -u -b 100M}.
521
522 Il est intéressant de coupler l’utilisation d’{\tt iperf} avec l’observation du
523 fichier \\ {\tt /sys/kernel/debug/ieee80211/phyX/ath9k/xmit} (ainsi que {\tt recv}).
524
525 \subsection{Paramètres de module}
526
527 Il est possible de passer des paramètres à un module à son chargement. Pour
528 cela, il suffit de les passer en argument à la commande {\tt insermod} :
529 \begin{verbatim}
530         # insmod module.ko param=value
531 \end{verbatim}
532
533 On trouve facilement de nombreuse information à ce sujet sur internet, par
534 exemple \url{http://www.makelinux.net/books/lkd2/ch16lev1sec6}.
535
536 Voici tous de même un exemple pour se faire une idée : rajoutez les lignes
537 suivantes dans les premières lignes du fichier {\tt ath/ath9k/init.c}.
538 \begin{verbatim}
539 char * modparam_name = "unnamed";
540 module_param_named(name, modparam_name, charp, 0644);
541 MODULE_PARM_DESC(name, "Test parameter");
542 \end{verbatim}
543 Ceci a pour effet de déclarer une variable {\tt modparam\_name} donc la valeur
544 pourra être spécifiée en utilisant la commande {\tt insmod ath9k.ko
545 name=monkey}.
546
547 Il est également possible de contrôler la valeur de cette variable, et de la
548 modifier, et ce alors que le module est chargé, grâce au système de fichier
549 {\tt /sys}. En effet, les paramètres des modules apparaissent dans le dossiers
550 {\tt /sys/modules/MODULE\_NAME/parameters/}. Les permissions spécifiées dans la
551 macro {\tt module\_param\_named} s’appliquent au fichier présent dans ce
552 dossier. Ceci constitue un moyen simple et rapide de mettre en place une entrée
553 de débuggage dans le système de fichier au moyen de peu de ligne de code.
554
555 \subsection{Envoyer des messages dans les log}
556 Il est intéressant de pouvoir afficher des messages de débuggage dans notre
557 driver (par exemple la valeur des paramètres reçu en argument). Pour cela, on
558 se tournera vers la fonction {\tt printk}. Elle s’utilise simplement :
559 \begin{verbatim}
560         printk(KERN_INFO "Value of my int : %d\n", my_int);
561 \end{verbatim}
562 Les autres niveaux de priorité sont disponible dans la documentation de
563 {\tt printk}.
564
565 Si vous avez activé l’option {\tt CONFIG\_ATH\_DEBUG} à la compilation, il est
566 possible d’utiliser la macro {\tt ath\_dbg} dans le code source. Celle-ci a
567 l’avantage de permettre de filtrer les messages de debug suivant leur catégorie.
568 On la préfèrera donc à {\tt printk}. Elle s’utiles de la manière suivante :
569 \begin{verbatim}
570         ath_dbg(common, QUEUE, "Format printf avec des %s\n", "variable");
571 \end{verbatim}
572 Le deuxième argument renseigne la catégorie du message. La liste des
573 options disponible peut être consultée ici :\\
574 \url{http://linuxwireless.org/en/users/Drivers/ath9k/debug}.
575
576 Il est possible de modifier cette macro pour afficher également le nom du
577 fichier, la ligne et la fonction d’où l’appelle à {\tt ath\_dbg} a été effectué.
578 On pourra pour cela appliquer le patch {\tt ath\_dbg.patch} dans le dossier
579 {\tt ath} :
580 \begin{verbatim}
581         $ patch -p1 < /path/to/ath_dbg.patch
582 \end{verbatim}
583 On fera bien attention après recompilation à recharger \emph{tous} les modules.
584 En effet, certains pourraient continuer d’utiliser l’ancien prototype et créer
585 ainsi des {\tt kernel panic}.
586
587 \subsection{Détails des fichiers}
588
589 \begin{itemize}
590         \item {\tt init.c}: Fonctions d’initialisations. On y trouve les points
591         d’entrée et de sortie du module (déclaré par les macros {\tt module\_init}
592         et {\tt module\_exit}). L’initialisation du module consiste en la déclaration
593         auprès du système de la gestion de périphérique sur des bus {\sc ahb}
594         et {\sc pci}. La suite de l’initialisation n’a lieu qu’après un callback du
595         système, informant le module de la présence d’un périphérique qu’il a
596         déclaré gérer. Le hardware du périphérique est alors initialisé
597         (enregistrement de différentes valeurs dans les registres) et le
598         périphérique réseau est déclaré auprès du système. Cette déclaration se
599         fait au travers de la surcouche {\tt lib/mac/cfg80211} spécifique au drivers
600         wifi.
601         \item {\tt pci.c}: Gére l’enregistrement auprès du système comme driver
602         {\sc pci}. Ceci consiste à indiquer au système les périphériques géré par le
603         driver en fournissant leur vendor-id et product-id. Si le système détecte
604         la présence d’un périphérique concerné, le driver est prévenu par une
605         fonction de callback.
606         \item {\tt ahb.c}: Équivalent de la partie {\sc pci} mais pour le bus
607         {\sc ahb}. Il s’agit d’un bus minimaliste, de type DMA (Direct Memory
608         Access), que l’on trouve généralement dans les systèmes de type SoC (System
609         On a Chip). Les démarches sont très semblables à la partie {\sc pci}
610         (enregistrement comme gestionnaire d’une liste de périphériques, callback
611         du système lors de la présence d’un de ceux-ci).
612         \item {\tt ani.h}: On y parle de CCK (Complementary Code Keying), d’OFDM
613         (Orthogonal Frequency Division Multiplexing) et de MRC (Maximal Ratio
614         Combining) (Système d’optimisation des performances par usage de deux
615         antennes distinctes).
616         \item {\tt arXXXX}: Les fichiers préfixés par {\tt ar} sont spécifique à
617         certain chipset. Dans notre cas, nous nous intéresserons aux fichiers
618         préfixé par {\tt ar9002}, en charge de notre chipset {\tt ar9220}.
619         \item {\tt btcoex.c}: Utile seulement pour les cartes wifi qui sont
620         également des cartes bluetooth. On y gère alors la coexistance avec le
621         bluetooth. Ceci ne nous intéresse pas dans le cadre de notre firmware.
622         \item {\tt beacon.c}: Gère l’envoit des trames balises. Ce fichier est
623         intéressant car il modifie les paramètres de la queue d’envoit (nottament
624         contention window).
625         \item {\tt mci.c}: Gestion de l’état du lien, sleeping mode, puissance du
626         signal, …
627         \item {\tt phy.h}: Quelques {\tt define} lié à la couche physique
628         (puissance, gain, …)
629         \item {\tt rc.c}: Rate Control
630         \item {\tt reg.h}: Longue liste de {\tt define} d’adresse de registre.
631         Difficilement exploitable … Cependant, on peut arrivé à deviner certaine
632         définition comme étant l’adresse d’un registre, suivit de la définition des
633         bits de ce registre (par exemple, la définition du registre
634         {\tt AR\_D\_BGL\_IFS\_MISC} suivit du bit
635         {\tt AR\_D\_GBL\_IFS\_MISC\_IGNORE\_BACKOFF}.
636         Ces information peuvent par la suite être utilisées avec les macros
637         {\tt REG\_SET\_BITS} et {\tt REG\_CLR\_BIT}. Celles-ci prennent en argument
638         un pointeur sur une structure {\tt ath\_hw} (habituellement {\tt ah}, ou
639         {\tt sc->sc\_ah} où {\tt sc} est un pointeur sur une structure
640         {\tt ath\_softc}), un registre et un bit.
641         \item {\tt recv.c}: Fonctions de reception des trames wifi.
642         \item {\tt xmit.c}: Fonctions d’envoit des trames wifi.
643         \item {\tt ath9k.h}: Header for the ath9k.ko driver core *only* -- hw code
644         nor any other driver should rely on this file or its contents.
645         \item {\tt calib.c}: Calibration : Ajuste le NF (Noise Floor) en fonction du
646         bruit.
647         \item {\tt common.c}: Quelques fonctions, peut utiles, commune à {\tt ath9k}
648         et {\tt ath9k\_htc}. Ce fichier constitue à lui seul le module
649         {\tt ath9k\_common}. Cependant, ses points d’entrée et de sortie sont vide,
650         ses fonctions sont simplement exportées.
651         \item {\tt dfs.c}: Compilé et linké au module {\tt ath9k.ko} ssi
652         {\tt CONFIG\_ATH9K\_DFS\_CERTIFIED} est définie. L’acronyme de ce module
653         signifie Dynamic Frequency Change. L’objectif est de ne pas brouiller les
654         radars en changant dynamiquement de fréquence lorsqu’un pulse radar est
655         détecté sur la fréquence actuelle.
656         \item {\tt debug.c}: Les fonctions de débuggage sont activé ssi la variable
657         {\tt CONFIG\_ATH9K\_DEBUGFS} est définie. Les possibilités énoncé dans la
658         partie sur le débuggage sont fournit par ce fichier.
659         \item {\tt dfs\_debug.c}: Les fonctions de débuggage liées à la partie DFS,
660         linké ssi la variable {\tt CONFIG\_ATH9K\_DFS\_DEBUGFS} est définie.
661         \item {\tt eeprom}: Gestion de l’eeprom. Celle-ci contient plusieurs
662         information telles que le code du pays (utile au régulateur qui interdit
663         certain channel suivant la réglementation en vigueur) ou l’adresse MAC.
664         \item {\tt gpio.c}: Gère :
665         \begin{itemize}
666                 \item Les LED ;
667                 \item Les boutons rfkill (radio frequence kill - désactivation matériel
668                 du wifi) ;
669                 \item La coexistance avec le bluetooth (btoex).
670         \end{itemize}
671         \item {\tt htc}: ath9k\_htc provides hardware support for Atheros AR9001 and
672         AR9002 family hardware.
673         \item {\tt hif\_usb.c}: En lien avec le module {\tt htc}.
674         \item {\tt hw.c}: Fonction hardware. Le fichier est divisé en plusieurs
675         section :
676         \begin{itemize}
677                 \item Helper Functions
678                 \item Chip Revisions
679                 \item HW Attach, Detach, Init Routines
680                 \item INI
681                 \item Reset and Channel Switching Routines
682                 \item Power Management (Chipset)
683                 \item Beacon Handling
684                 \item HW Capabilities
685                 \item GPIO / RFKILL / Antenne
686                 \item General Operation
687                 \item HTC
688         \end{itemize}
689         \item {\tt hw-ops.h}: Courtes fonctions {\tt inline} de paramétrage.
690         \item {\tt wmi.c}: Wireless Module Interface
691 \end{itemize}
692
693 \subsection{Séquence de démarrage}
694
695 Le fichier {\tt ath9k\_init.c} contient un résumé des principales fonctions
696 appelées lors du chargement du module.
697
698 \subsection{Structures de données courtantes}
699
700 La structure la plus courament véhiculé est la structure {\tt ath\_softc},
701 appelé couramment {\tt sc}. Elle est définie dans le fichier {\tt ath9k.h}.
702 Beaucoup d’autre structure utilisé sont stoqué dans la structure
703 {\tt ath\_softc}. Par exemple, la structure {\tt ath\_hw}, courament appelé
704 {\tt ah}, s’obtient par {\tt sc->sc\_ah}.
705
706 Une structure très intéressante est la structure {\tt ieee80211\_ops}. Le
707 driver {\tt ath9k} en définie une dans le fichier {\tt main.c} à la ligne 2433.
708 Celle-ci contient toutes les fonctions de callback qu’il est enregistré auprès
709 de la sous-couche {\tt lib/cfg/mac80211}. Par exemple, le champ {\tt .tx}
710 pointe sur la fonction {\tt ath\_tx}, qui est la fonction du driver qui est
711 appelé lorsqu’une trame est à transmettre. Vous pouvez obtenir les informations
712 sur chaque champ de cette structure dans la documentation de la sous-couche
713 {\tt 802.11} consultable en ligne : \url{linuxwireless.org/80211books/}.
714
715 Cette structure est utilisé en argument de la fonction
716 {\tt ieee80211\_alloc\_hw} dans la fonction {\tt ath\_pci\_probe}, appelé
717 lorsqu’un périphérique pci est géré par le driver :
718 \begin{verbatim}
719         ieee80211_alloc_hw(sizeof(struct ath_softc), &ath9k_ops);
720 \end{verbatim}
721
722
723 %\subsection{Envoit de trames}
724 %
725 %Il y a deux fonctions principales utilisées lors de l’envoit d’une trame :
726 %{\tt ath\_tx\_txqaddbuf} et {\tt ath\_tx\_complete} (présente dans xmit.c).
727
728 \section{Désactivation du backoff et carrier-sens}
729
730 \subsection{Macros}
731
732 Vous avez 3 macros à votre disposition pour désactiver le backoff et le
733 carrier-sens :
734 \begin{verbatim}
735         REG_SET_BIT(ah, AR_DIAG_SW, AR_DIAG_FORCE_CH_IDLE_HIGH); // phy carrier-sens
736         REG_SET_BIT(ah, AR_DIAG_SW, AR_DIAG_IGNORE_VIRT_CS); // virtual carrier-sens
737         REG_SET_BIT(ah, AR_D_GBL_IFS_MISC, AR_D_GBL_IFS_MISC_IGNORE_BACKOFF);
738 \end{verbatim}
739 Il peut être intéressant de consulter dans le fichier {\tt ath9k/reg.h} les
740 autres bits des registres {\tt AR\_D\_GBL\_IFS\_MISC} et {\tt AR\_DIAG\_SW} pour
741 en étudier l’influence
742 (par exemple, \\ {\tt AR\_D\_GBL\_IFS\_MISC\_TURBO\_MODE}).
743
744 \subsection{Tests}
745
746 Ces tests ont été effectués en mode ad-hoc à l’aide de trois stations : l’une
747 exécutant {\tt iperf} en mode serveur et les deux autres exécutants {\tt iperf}
748 en mode client (iperf test la bande passante du client vers le serveur). Le
749 premier client était munie du drivers wifi {\tt ath9k} non modifié tandis que le
750 deuxième était munie premièrement du driver non modifié puis par la suite de
751 plusieurs versions du driver modifié. Pour chaque version du driver, le débit
752 a était testé en {\sc TCP} et {\sc UDP}, tout d’abord seul, puis avec le client
753 au driver non modifié en concurrence. Les tests ont été fait sur une durée de
754 une minute. Pour les tests en {\sc TCP}, il est donné le débit moyen tandis que
755 pour les tests en {\sc UDP}, il est donné le débit d’émission (maximal de la
756 carte réseau, avec les paramètres du driver wifi utilisé), le débit de réception
757 et le pourcentage de paquets perdus. Pour les tests en concurrences, il est
758 indiqué sur la première ligne les résultats pour le driver non modifié.
759
760 \subsubsection{Test 1}
761
762 Les deux clients sont munies du driver non modifié.
763
764 \vspace{0.2cm}
765 \begin{tabular}{|l|c|c|}
766         \hline
767         \multicolumn{3}{|c|}{Client seul} \\
768         \hline
769         TCP & \multicolumn{2}{|c|}{11.2 Mb/s} \\
770         UDP & \multicolumn{2}{|c|}{12.1 Mb/s 12.1 Mb/s 0\%} \\
771         \hline\hline
772         \multicolumn{3}{|c|}{Clients en concurrence} \\
773         \hline
774         & TCP & UDP \\
775         \hline
776         \multirow{2}{*}{TCP} & 5.77 Mb/s & 3.82Mb/s \\
777                 & 5.67 Mb/s & 12.5 Mb/s 12.3Mb/s 1.7\% \\
778         \hline
779         \multirow{2}{*}{UDP} & 12.5 Mb/s 12.3Mb/s 1.7\% & 11.2 Mb/s 8.45 Mb/s 24\% \\
780                 & 3.82Mb/s & 11.8 Mb/s 8.64 Mb/s 26\% \\
781         \hline
782 \end{tabular}
783
784 \subsubsection{Test 2}
785
786 Le deuxième driver a été modifié par l’ajout des trois lignes suivantes dans la
787 fonction {\tt ath\_txq\_schedule} (présente dans {\tt xmit.c}).
788 \begin{verbatim}
789 REG_SET_BIT(ah, AR_DIAG_SW, AR_DIAG_FORCE_CH_IDLE_HIGH);
790 REG_SET_BIT(ah, AR_DIAG_SW, AR_DIAG_IGNORE_VIRT_CS);
791 REG_SET_BIT(ah, AR_D_GBL_IFS_MISC, AR_D_GBL_IFS_MISC_IGNORE_BACKOFF);
792 \end{verbatim}
793
794 \vspace{0.2cm}
795 \begin{tabular}{|l|c|c|}
796         \hline
797         \multicolumn{3}{|c|}{Client seul} \\
798         \hline
799         TCP & \multicolumn{2}{|c|}{3.81 Mb/s} \\
800         UDP & \multicolumn{2}{|c|}{11.9 Mb/s 11.9 Mb/s 0\%} \\
801         \hline\hline
802         \multicolumn{3}{|c|}{Clients en concurrence} \\
803         \hline
804         & TCP & UDP \\
805         \hline
806         \multirow{2}{*}{TCP} & 7.22 Mb/s & 452 Kb/s \\
807                 & 3.82 Mb/s & 12.8 Mb/s 12.8Mb/s 0.11\% \\
808         \hline
809         \multirow{2}{*}{UDP} & 9.46 Mb/s 3.30 Mb/s 65\% & 1.62 Mb/s 531 Kb/s 67\% \\
810                 & 960 Kb/s & 12.4 Mb/s 12.4 Mb/s 0.03\% \\
811         \hline
812 \end{tabular}
813
814 \subsubsection{Test 3}
815
816 Il s’agit du même test que le test 2, mais cette fois-ci les deux clients
817 possèdent un driver modifié.
818
819 \vspace{0.2cm}
820 \begin{tabular}{|l|c|c|}
821         \hline
822         \multicolumn{3}{|c|}{Clients en concurrence} \\
823         \hline
824         & TCP & UDP \\
825         \hline
826         \multirow{2}{*}{TCP} & 1.02 Mb/s & 34.3 Kb/s \\
827                 & 1.52 Mb/s & 10.2 Mb/s 9.57Mb/s 5.5\% \\
828         \hline
829         \multirow{2}{*}{UDP} & 10.2 Mb/s 9.57 Mb/s 5.5\% & 1.80 Mb/s 1.25 Mb/s 25\% \\
830                 & 34.3 Kb/s & 6.92 Mb/s  49.2 Kb/s 99\% \\
831         \hline
832 \end{tabular}
833
834 \subsubsection{Test 4}
835
836 Le driver du premier client n’est pas modifié alors que le driver du deuxième
837 client a été modifié par l’ajout des lignes suivantes dans la fonction
838 {\tt ath\_txq\_schedule} (présente dans {\tt xmit.c}):
839 \begin{verbatim}
840 //REG_SET_BIT(ah, AR_DIAG_SW, AR_DIAG_FORCE_CH_IDLE_HIGH);
841 //REG_SET_BIT(ah, AR_DIAG_SW, AR_DIAG_IGNORE_VIRT_CS);
842 REG_SET_BIT(ah, AR_D_GBL_IFS_MISC, AR_D_GBL_IFS_MISC_IGNORE_BACKOFF);
843 \end{verbatim}
844
845 \vspace{0.2cm}
846 \begin{tabular}{|l|c|c|}
847         \hline
848         \multicolumn{3}{|c|}{Client seul} \\
849         \hline
850         TCP & \multicolumn{2}{|c|}{955 Kb/s} \\
851         UDP & \multicolumn{2}{|c|}{11.9 Mb/s 11.9 Mb/s 0\%} \\
852         \hline\hline
853         \multicolumn{3}{|c|}{Clients en concurrence} \\
854         \hline
855         & TCP & UDP \\
856         \hline
857         \multirow{2}{*}{TCP} & 5.80 Mb/s & 3.22 Mb/s \\
858                 & 1.24 Mb/s & 11.9 Mb/s 11.9 Mb/s 0.28\% \\
859         \hline
860         \multirow{2}{*}{UDP} & 11.8 Mb/s 10.8 Mb/s 7.4\% & 4.49 Mb/s 4.45 Mb/s 0.62\% \\
861                 & 1.02 Mb/s & 12.1 Mb/s 12.0 Mb/s 0.16\% \\
862         \hline
863 \end{tabular}
864
865 \subsubsection{Test 5}
866
867 Le driver du premier client n’est pas modifié alors que le driver du deuxième
868 client a été modifié par l’ajout des lignes suivantes dans la fonction
869 {\tt ath\_txq\_schedule} (présente dans {\tt xmit.c}):
870 \begin{verbatim}
871 //REG_SET_BIT(ah, AR_DIAG_SW, AR_DIAG_FORCE_CH_IDLE_HIGH);
872 REG_SET_BIT(ah, AR_DIAG_SW, AR_DIAG_IGNORE_VIRT_CS);
873 //REG_SET_BIT(ah, AR_D_GBL_IFS_MISC, AR_D_GBL_IFS_MISC_IGNORE_BACKOFF);
874 \end{verbatim}
875
876 \vspace{0.2cm}
877 \begin{tabular}{|l|c|c|}
878         \hline
879         \multicolumn{3}{|c|}{Client seul} \\
880         \hline
881         TCP & \multicolumn{2}{|c|}{10.8 Mb/s} \\
882         UDP & \multicolumn{2}{|c|}{11.6 Mb/s 11.6 Mb/s 0\%} \\
883         \hline\hline
884         \multicolumn{3}{|c|}{Clients en concurrence} \\
885         \hline
886         & TCP & UDP \\
887         \hline
888         \multirow{2}{*}{TCP} & 5.52 Mb/s & 3.72Mb/s \\
889                 & 5.43 Mb/s & 12.0 Mb/s 11.9 Mb/s 1.1\% \\
890         \hline
891         \multirow{2}{*}{UDP} & 11.8 Mb/s 11.1 5.2Mb/s \% & 11.8 Mb/s 6.60 Mb/s 44\% \\
892                 & 3.95 Mb/s & 11.8 Mb/s 6.24 Mb/s 47\% \\
893         \hline
894 \end{tabular}
895
896 \subsubsection{Test 6}
897
898 Le driver du premier client n’est pas modifié alors que le driver du deuxième
899 client a été modifié par l’ajout des lignes suivantes dans la fonction
900 {\tt ath\_txq\_schedule} (présente dans {\tt xmit.c}):
901 \begin{verbatim}
902 REG_SET_BIT(ah, AR_DIAG_SW, AR_DIAG_FORCE_CH_IDLE_HIGH);
903 //REG_SET_BIT(ah, AR_DIAG_SW, AR_DIAG_IGNORE_VIRT_CS);
904 //REG_SET_BIT(ah, AR_D_GBL_IFS_MISC, AR_D_GBL_IFS_MISC_IGNORE_BACKOFF);
905 \end{verbatim}
906
907 \vspace{0.2cm}
908 \begin{tabular}{|l|c|c|}
909         \hline
910         \multicolumn{3}{|c|}{Client seul} \\
911         \hline
912         TCP & \multicolumn{2}{|c|}{5.51 Mb/s} \\
913         UDP & \multicolumn{2}{|c|}{Mb/s Mb/s \%} \\
914         \hline\hline
915         \multicolumn{3}{|c|}{Clients en concurrence} \\
916         \hline
917         & TCP & UDP \\
918         \hline
919         \multirow{2}{*}{TCP} & Mb/s & Mb/s \\
920                 & Mb/s & Mb/s Mb/s \% \\
921         \hline
922         \multirow{2}{*}{UDP} & Mb/s Mb/s \% & Mb/s Mb/s \% \\
923                 & Mb/s & Mb/s Mb/s \% \\
924         \hline
925 \end{tabular}
926
927 \subsubsection{Test 7}
928
929 Le driver du premier client n’est pas modifié alors que le driver du deuxième
930 client a été modifié par l’ajout des lignes suivantes dans la fonction
931 {\tt ath\_txq\_schedule} (présente dans {\tt xmit.c}):
932 \begin{verbatim}
933 REG_SET_BIT(ah, AR_DIAG_SW, AR_DIAG_FORCE_CH_IDLE_HIGH);
934 //REG_SET_BIT(ah, AR_DIAG_SW, AR_DIAG_IGNORE_VIRT_CS);
935 //REG_SET_BIT(ah, AR_D_GBL_IFS_MISC, AR_D_GBL_IFS_MISC_IGNORE_BACKOFF);
936 \end{verbatim}
937
938 \vspace{0.2cm}
939 \begin{tabular}{|l|c|c|}
940         \hline
941         \multicolumn{3}{|c|}{Client seul} \\
942         \hline
943         TCP & \multicolumn{2}{|c|}{5.51 Mb/s} \\
944         UDP & \multicolumn{2}{|c|}{11.8 Mb/s 11.8 Mb/s 0\%} \\
945         \hline\hline
946         \multicolumn{3}{|c|}{Clients en concurrence} \\
947         \hline
948         & TCP & UDP \\
949         \hline
950         \multirow{2}{*}{TCP} & 6.79 Mb/s & 1.43 Mb/s \\
951                 & 3.67 Mb/s & 12.1 Mb/s 12.0 Mb/s 0.5\% \\
952         \hline
953         \multirow{2}{*}{UDP} & 8.39 Mb/s 3.03 Mb/s 63\% & 1.92 Mb/s 1.90 Mb/s 1.1\% \\
954                 & 2.13 Mb/s & 9.94 Mb/s 9.91 Mb/s 0.2\% \\
955         \hline
956 \end{tabular}
957
958 \subsection{Remarques divers}
959 \begin{itemize}
960         \item Si les résultats sont incohérants, même avec seulement certains
961         clients, tester de redémarrer le serveur {\tt iperf} …
962 \end{itemize}
963
964
965 \end{document}