Debogage v1

Rsolution des problmes de
performances de bout en bout

muyal@renater.fr
andreu@renater.fr
tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie
Contributions
FX Andreu, Renater
S. Muyal, Renater
B. Tuy
C. Grenet
Agenda
Introduction: Quest-ce quun problme de performance?
Collecte des informations de base
Linvestigation pas pas (Mthodologie)
Travaux et projets sur le sujet et quelques exemples
Introduction: Quest quun problme de performance?

Dfinition
Les pannes sont facilement repres par les NOCs ou ASRs:
tat binaire: marche/ne marche pas
Il existe un ensemble doutils de supervision qui dtectent et signalent
automatiquement les pannes.
Il est souvent simple de connatre la cause de la panne: coupure lectrique,
coupure dun lien, etc
Problme de performance: Dgradation sans quil y ait coupure du

service
ex: multimdia: voix saccade
ex: Temps de rponse dun serveur plus lev que dhabitude
Les problmes de performances sont beaucoup plus difficile rsoudre

quune panne:
Difficile dceler par les outils basiques de supervision
Difficile de faire le lien entre les indicateurs applicatifs et les indicateurs rseau
Configuration pralable de seuils dans les outils de supervision en fonction des
applications: long et pas vident.

Dfinition
Les problmes de performances applicatives sont donc souvent dcels par

lutilisateur final:
Les dgradations sont perues au niveau applicatif, donc par lutilisateur final.
Cest lutilisateur qui signale dans la plupart des cas son administrateur
systme et rseau (ASR) les problmes de performances.
Une fois le problme de performance signal, difficile de savoir

o se trouve le problme
la cause/lment qui provoque cette dgradation: On se renvoie la balle
souvent!!
une investigation est souvent ncessaire

Objectifs pour les ASR:
tre proactif
Dceler les problmes de performances avant lutilisateur final (probablement
une investigation sera tout de mme ncessaire pour rsoudre le problme)
Pendant la rsolution du problme de performance, les utilisateurs pourront tre
informs que le service est dgrad
Introduction:
Dans un problme de performance, un ensemble dlments peut tre
concern
Les extrmits
Utilisateurs
Applications
Systmes dexploitation
Matriel: carte rseau, autres (disques durs, carte mre, etc)
Le rseau local
LAN, VLANs, WLANs
Les rseaux
de campus
de collecte
Nationaux, expl : RENATER et autres rseaux de la recherche
Internationaux : GEANT2, OpenTransit, points dchanges
autres oprateurs
Introduction: Quest quun problme de performance?: Les rseaux

pouvant tre impliqus

Perception de lutilisateur
Les performances perues par lutilisateur sont diffrentes des performances rseau:
Application multimdia: + sensible au temps de rponse

Application transfert: + sensible au dbit
Combinaison de ces critres
Temps de rponse applicatif

Le temps de rponse applicatif temps de rponse rseau
Disponibilit/Fiabilit dun service Disponibilit rseau

Applications multimdia: Le MOS (Mean Opinion Score): permet de qualifier le flux audio:
Mean Opinion Score (MOS)
MOS
Qualit
Dgradation
Excellente
Imperceptible
Bonne
Perceptible mais pas gnante
Moyenne
Lgrement gnante
Mauvaise
Gnante
Trs Mauvaise
Trs gnante
Introduction: Quest-ce quun problme de performance?
Dmarche pour rsoudre un problme de performance par un

ASR:
Collecte dinformation
Auprs de lutilisateur final
Sur son propre rseau (celui de lASR)
Information mise disposition par les autres rseaux
Vrifier quil sagit dun vrai problme rseau

Problme autre quapplicatif (Base de donnes, CPU/mmoire de la
machine, etc)
Investigation/tests :
Faire des tests de bout en bout avec les machines impliques

Faire des tests partir de systmes ddis
Suivre le protocole de test dcrit dans cette prsentation
tablir un diagnostic
Agenda
Mthodologie :
1 - Collecte des informations de base
Description du problme: collecte au prs de lutilisateur
Connatre les sources dinformation disponibles
Comprendre/Identifier le problme : une description pas pas
2 Tests effectuer (dmarche +

Prsentation doutils)
Travaux et projets sur le sujet et tudes de

cas
1.
Collecte des informations de base

Description du problme par lutilisateur final
LASR est contact par lutilisateur final gnralement

LASR doit collecter un maximum dinformations:
Fonctionnement de lapplication sans dgradation (fonctionnement normal)
Valeurs de rfrence pour les applications du SI
Fonctionnement observ avec dgradation
LASR doit sassurer que les donnes collectes sont correctes:

Lutilisateur nest pas forcement un expert
Perceptions en fonction des utilisateurs
Attention aux units
Canevas/Template de collecte dinformations:

Connatre le contexte (utilisateur, appli, systmes, chemin)
Permet de relayer facilement le problme dautres rseaux
1.
Collecte des informations de bases
Les sources dinformation 1/2
Avant de commencer les tests, beaucoup

dinformations sont dj disponibles au
niveau des rseaux traverss:
Weathermap (carte du rseau avec le taux
dutilisation des liens)
Diffusion des tickets dincident et de
maintenance
Looking glass : Permet dexcuter certaines
commandes sur les quipements rseau
1.
Les sources dinformation 2/2
Les rseaux rgionaux, de campus, MANs de la

communaut :
le site gt-mtro :
http://gt-metro.grenet.fr/index.php/Liste_des_r%C3%A9seaux_de_collecte
Les rseaux nationaux/internationaux :

http://www.renater.fr
Liste des pages de diffusion dinformation des NRENs :
http://monstera.man.poznan.pl/wiki/index.php/Network_Weathermaps
Autres rseaux (oprateurs privs, ISPs, GIXs) via :

http://stream.free.fr/index.html
1.
Comprendre le problme : une description pas pas
Avec ces informations collectes, lASR essaie de dceler do

peut provenir le problme:
Vrification quil sagit dun problme rseau et non pas dun
problme applicatif (vrification des logs applicatif et systme, restart
de lapplication, reboot du systme si ncessaire, tests du rseau local,
tests du chemin complet).
Le plus souvent les informations collectes permettent dcarter
certaines pistes mais ne permettent pas de trouver lorigine du
problme.
Des tests additionnels sont ncessaires
2. Les tapes dans lanalyse dun

problme complexe de performance
La premire tude du problme na pas suffit, il faut faire une
tude plus pousse. Il est indispensable dans cette partie
davoir au pralable install et tudi les outils standards de
supervision et monitoring.
La mthode :
Vrification approfondie :
Sur le(s) systme(s)
Sur le(s) rseau(x)
Tester :
Utiliser le(s) poste(s) impact(s) ou au plus proche
Utiliser des systmes correctement paramtrs : CPU et rseau disponible
Utiliser les bons outils et dans le bon ordre
1.
Vrification des informations aux

extrmits
Le type d'application/logiciel et son mode de fonctionnement

Les piles protocolaires employes (RTP, TCP, UDP, IPv4,
IPv6, etc)
Les systmes d'exploitation (version, noyau, etc.)
Les adresses IP et les ports de niveau 4 des extrmits
Le type de cartes rseau, processeur, mmoire vive
Vrification des informations du systme:

Linux
Vrification des paramtres de la pile TCP dans le cas de problmes de transfert
longue distance et/ou trs haut dbit :
Rappel TCP tuning background : http://dsd.lbl.gov/TCP-tuning/background.html
Paramtres principaux :
Dans /proc/sys/ :
net.core.rmem_max = 16777216
Possibilit de tuner le code de lapplication :
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
http://dsd.lbl.gov/TCP-tuning/setsockopt.html
net.ipv4.tcp_wmem = 4096 65536 16777216
Vrification du mode de communication de la carte rseau :

Utilisation du logiciel ethtool, exemple :
Vrification de la MTU :
exemple de decouverte de la MTU sur le chemin avec
tracepath (ou autre)
tracepath 193.51.184.89
1?: [LOCALHOST] pmtu 1500
1: nri-a-gi1-0-0-140.cssi.renater.fr.183.51.193.in-addr.arpa (193.51.183.186) 0.447ms
2: nri-b-g14-0-0-101.cssi.renater.fr (193.51.187.18) asymm 9 7.893ms
3: reims-pos2-0.cssi.renater.fr (193.51.179.150)
asymm 8 8.094ms
4: nancy-pos1-0.cssi.renater.fr (193.51.179.138)
asymm 7 7.898ms
5: strasbourg-pos2-0.cssi.renater.fr (193.51.180.42)
7.903ms
6: sonde-gip-strasbourg.cssi.renater.fr (193.51.184.89) 8.222ms reached
Resume: pmtu 1500 hops 6 back 6
[root@ORSAY root]# ethtool eth0

Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 1000baseT/Full
Advertised auto-negotiation: No
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: puag
Wake-on: g
Current message level: 0x00000002 (2)
Link detected: yes

Windows XP/2000
Windows XP/2000:
Support de la RFC1323: Large window (rcv_window cod sur 30bits ~
1Go au lieu de 64K dans Windows NT)
Modification des valeurs de:
"Tcp Receive Window" =BDP (ex: 4 000 000 en octets)

"Window Scaling" activ
"Selective Acks" activ
"Time Stamping" activ
Le plus simple est dutiliser des programmes vous permettant de modifier
les valeurs prdfinies par Windows: DrTCP, SG TCP Optimizer ou
Cablenut
# turn on window scale and timestamp option

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323Opts=3
# set default TCP receive window size
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpWindowSize=256000
# set max TCP send/receive window sizes (max you can set using setsockopt call)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\GlobalMaxTcpWindowSize=16777216

Windows Vista
Support de lauto-tuning:
Rgulation automatique des fentres TCP
Jusqu 16 MB maximum pour la fentre de rception (receive window)
Possibilit dactiver lauto-tuning via linterface netsh
netsh interface tcp set global autotunninglevel=disabled
netsh interface tcp set global autotunninglevel=normal
Pas de moyen dajuster le default TCP buffer (64 KB).

Lalgorithme dautotuning nest pas utilis si le RTT est infrieur 1 ms
Il peut donc y avoir un impact sur le LANso single streamTCP will be throttled on a
LAN by this small default TCP buffer.
2. Les tapes dans le dbogage
Rappel sur les paramtres systmes (1/2)
Mme si la plupart du temps les systmes dexploitation (OS) sont correctement paramtrs par dfaut, il
est parfois ncessaire de tuner son OS pour obtenir de meilleures performances.
Rappel : Sur un rseau haut dbit et sur de longues distances, mme la perte dun seul paquet peut
gravement affecter les performances. Pour TCP, le dbit maximum est :
1
Rate<
* p
RTT
MSS
Exemple de dbit obtenu

en fonction de
limplmentation de TCP et
du RTT :
MSS = Maximum Segment Size

RTT = Round Trip Time
P = Packet Loss probability
From Matt Mathis document
Les Tests
Lors dun problme de performance rseau, le protocole de tests suivre
est le suivant :
Test de connectivit :
Pb : sassurer que le poste distant est bien connect au rseau et correctement
configur (adresse IP, masque, filtre ICMP, mode duplex)
Ok : passer au point suivant
Test du chemin :
Pb : gnralement un problme sur le chemin peut tre une route asymtrique ou un
problme de MTU
Test de la bande passante disponible (avec recherche de pertes) :

En UDP :
Pb : par exemple, un dbit plus faible que celui attendu, cest un problme de congestion
En TCP :
Pb : si le test UDP est correct cela provient de la configuration TCP dun des htes.
Test applicatif ??: Si possible

Vrification de la connectivit et du chemin :

Ping :
Utilis pour tester la disponibilit dun hte
Algorithme : utilisation du protocole ICMP
Envoi dun paquet echo request avec:
Un identifiant par processus ping
Un numro de squence par echo request
Lhte cible rpond avec un ICMP echo reply

Le rsultat : RTT, TTL, et numro de squence.
Traceroute :
Utilis pour dcouvrir le chemin jusqu la destination.
Algorithme : utilisation de ICMP ou UDP et le champ TTL de len-tte IP
Envoi dun paquet avec TTL=1

Le premier routeur renvoi un ICMP time exceeded.
Envoi dun paquet avec le TTL 2 vers la cible, le deuxime routeur rpond.
On continue jusqu la destination en incrmentant le TTL ou jusquau TTL max.
Inconvnient des deux mthodes lorsque :

Les chemins aller et retour sont asymtriques
lICMP est filtr
Les paquets ICMP ne sont pas traits par les routeurs comme les autres paquets
Vrification de la bande passante

Plusieurs mthodes de mesure de la bande passante
Outils qui estiment la bande passante thorique (taille des liens)
pchar ou pathchar
Ils permettent dobtenir la taille du lien entre deux quipements de routage et
donnent ainsi une estimation de la bande passante thorique saut par saut. Ils
sont trs peu intrusifs mais ne sont pas toujours suffisants pour rsoudre des
problmes de performances haut dbit (mode solo).
Ces outils sont parfois peu fiables mais fournissent un indice de confiance.
Outils qui mesurent la bande passante disponible entre deux htes au

niveau UDP ou TCP en gnrant du trafic jusqu saturation du plus petit
des liens traverss.
Iperf
Ces outils sont trs intrusifs mais ils permettent dobtenir une meilleure mesure
de la bande passante disponible pour une application entre deux htes (mode
client-serveur).
Vrification de la bande passante disponible

exemple
La dmarche suivie
Aprs vrification des systmes dexploitation (avec tuning des paramtres

TCP si besoin), de la connectivit et du chemin emprunt, nous allons
dterminer le dbit maximum que nous allons atteindre en UDP et en TCP
(avec un flux).
La premire phase consiste en un test Iperf UDP avec le paramtre -b en
indiquant le dbit souhait, par exemple pour un dbit de 90Mb/s mettez sur la
ligne de commande : -b90M . Cest lors de cette phase que le serveur Iperf
indiquera sil y a du dsquencement et/ou des pertes de paquets pouvant tre
dus une congestion. Si le dbit est atteint sans aucune alerte, la partie rseau
emprunte est capable de fournir un tel dbit lors dun test en TCP si les
systmes sont correctement paramtrs.
Lors de la deuxime phase, nous vrifions que nous atteignons le mme dbit
en TCP. Si le dbit nest pas atteint et que le test UDP est valide, il est
fortement conseill de vrifier les paramtres systmes des htes (charges,
tuning TCP). Cest cette deuxime phase que les traces suivantes
correspondent.
Vrification de la bande passante disponible

Traces (serveur puis client):
[root@LYON netwarrior]# ./iperf -s -i 5
-----------------------------------------------------------Server listening on TCP port 5001
TCP window size: 64.0 KByte (default)
-----------------------------------------------------------[ 6] local 193.51.184.113 port 5001 connected with 193.51.183.225 port 39518
[ ID] Interval
Transfer Bandwidth
[ 6] 0.0- 5.0 sec 52.1 MBytes 87.4 Mbits/sec
[ 6] 5.0-10.0 sec 52.7 MBytes 88.4 Mbits/sec
[ 6] 0.0-10.0 sec 105 MBytes 87.9 Mbits/sec
netflow1:/home/maintenance# ./iperf -c 193.51.184.113 -i 5
-----------------------------------------------------------Client connecting to 193.51.184.113, TCP port 5001
TCP window size: 16.0 KByte (default)
-----------------------------------------------------------[ 3] local 193.51.183.225 port 39518 connected with 193.51.184.113 port 5001
[ ID] Interval
Transfer Bandwidth
[ 3] 0.0- 5.0 sec 52.3 MBytes 87.8 Mbits/sec
[ 3] 5.0-10.0 sec 52.6 MBytes 88.2 Mbits/sec
[ 3] 0.0-10.0 sec 105 MBytes 87.8 Mbits/sec
Vrification de la
bande passante
Lorsquon ne dispose pas de
serveur lautre extrmit, on
peut utiliser des outils qui ne
fonctionnent pas en mode
Client/Serveur :
Ex Pchar :
Burst successifs saut par saut en
faisant varier la taille des
paquets: On dduit en rcuprant
le RTT le dbit du lien.
Tests assez long car logiciel peut
intrusif
Se base sur des messages ICMP:
Problme si filtrage
r2 = 0.991958 indice de
confiance par lien.
pchar to 193.51.184.89 (193.51.184.89) using UDP/IPv4

Using raw socket input
Packet size increments from 32 to 1500 by 32
46 test(s) per repetition
32 repetition(s) per hop
0: 193.51.183.185 (netflow-nri-a.cssi.renater.fr)
Partial loss:
0 / 1472 (0%)
Partial char:
rtt = 0.134549 ms, (b = 0.000090 ms/B), r2 = 0.991958
stddev rtt = 0.000992, stddev b = 0.000001
Partial queueing: avg = 0.000078 ms (864 bytes)
Hop char:
rtt = 0.134549 ms, bw = 88449.851910 Kbps
Hop queueing:
avg = 0.000078 ms (864 bytes)
1: 193.51.183.186 (nri-a-gi1-0-0-140.cssi.renater.fr.183.51.193.in-addr.arpa)
Partial loss:
0 / 1472 (0%)
Partial char:
rtt = 7.637975 ms, (b = 0.000085 ms/B), r2 = 0.654697
Hop char:
rtt = 7.503426 ms, bw = --.--- Kbps
Hop queueing:
avg = 0.000064 ms (0 bytes)
2: 193.51.187.18 (nri-b-g14-0-0-101.cssi.renater.fr)
Partial loss:
0 / 1472 (0%)
Partial char:
rtt = 7.643269 ms, (b = 0.000068 ms/B), r2 = 0.273070
Hop char:
rtt = 0.005294 ms, bw = --.--- Kbps
Hop queueing:
avg = 0.000012 ms (0 bytes)
.
5: 193.51.180.42 (strasbourg-pos2-0.cssi.renater.fr)
Partial loss:
292 / 1472 (19%)
Partial char:
rtt = 7.625242 ms, (b = 0.000227 ms/B), r2 = 0.999402
Hop char:
rtt = 0.038397 ms, bw = 80400.838878 Kbps
Hop queueing:
avg = -0.000016 ms (0 bytes)
6: 193.51.184.89 (sonde-gip-strasbourg.cssi.renater.fr)
Path length:
6 hops
Path char:
rtt = 7.625242 ms r2 = 0.999402
Path bottleneck: 40644.270594 Kbps
Path pipe:
38740 bytes
Path queueing: average = 0.000033 ms (864 bytes)
Start time:
Fri Aug 10 10:48:41 2007
End time:
Fri Aug 10 11:38:53 2007
Analyse des paquets

Analyse de flux TCP avec tcpdump/wireshark
Avantage de pouvoir faire des captures au niveau des deux extrmits
(identification des pertes, de boitiers intermediaires qui remarquent
certaines options, etc)
Graphiques avec les pertes, retransmission, numro de squences, etc
Description des problmes possibles

Problmes de performances dus des pertes de paquets
(dtection possible avec Iperf sur des flux UDP):
Vrifier sur le poste (ifconfig, ethtool)
Vrifier sur le rseau local (weathermap, connection sur les
equipements)
Alerter le rseau de collecte (si les pertes ne sont pas identifies aux
endroits prcdents ou si la perte est dtecte par les pchar-like sur un
rseau tiers) aprs vrification des tickets dincidents et de
maintenances dudit rseau sils sont publics.
Problmes de performance sans perte de paquets, sans

dsquencement, avec un dbit UDP acceptable il y a de
trs forte chance que ce soit un problme de configuration du
systme
Que faire :
Un problme de performance de bout en bout a t
dtect mais nest pas rsolu : que faire ?
Alerter le rseau de collecte qui analysera le problme et
pourra ventuellement le faire remonter
Quelques exemples de problmes de

performances: LAN
Half/Full duplex et Auto-ngociation
Mismatch entre deux quipements
Recommandation
Pour un parc homogne et rcent: Activer lauto-ngociation
Pour un parc htrogne ou vtuste: Configuration manuelle
Collisions:
Utilisation de Hubs
Recommandation:
Dans la mesure du possible faire voluer son parc vers un rseau
commut

performances: WLAN
Performance avec du WIFI bien moindre et sensible
beaucoup plus de paramtres alatoires:
CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance)
permet dviter les collisions.
Mais le mdia est tout de mme partag par lensemble des utilisateurs

performances: LAN/Campus
Problme de performance au niveau du LAN: Botiers
intermdiaires
Pare-feux
Boitiers de performances: Lisseur de trafic, etc
Botiers NAT
Proxies/mandataires
VPNs
Ces botiers ajoutent un temps de traitement qui peut entraner

des ralentissements, surtout sils ne sont pas traits par le
matriel
3. Les Travaux et projets sur le sujet

Gt-metro
http://gt-metro.grenet.fr/
PERT: Performance Enhancement Response Team

Structure au niveau europen pour traiter les problmes de performance
Pert-KB (base de connaissance du Performance Enhencement Response
Team PERT): http://kb.pert.geant2.net/PERTKB/
Perfsonar
Mesures de performance interdomaine: http://www.perfsonar.net/
Liens spcifiques sur comment faire des transferts haut-dbit et/ou longue
distance :
http://dsd.lbl.gov/TCP-tuning/links.html
http://dsd.lbl.gov/TCP-tuning/TCP-Tuning-Tutorial.pdf
http://2007.jres.org/planning/slides/63.pdf
Questions??

Debogage v1

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Debogage v1

Transféré par

Droits d'auteur :

Formats disponibles

Rsolution des problmes de

performances de bout en bout

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

Introduction: Quest quun problme de performance?

Problme de performance: Dgradation sans quil y ait coupure du

Les problmes de performances sont beaucoup plus difficile rsoudre

Introduction: Quest quun problme de performance?

Les problmes de performances applicatives sont donc souvent dcels par

Une fois le problme de performance signal, difficile de savoir

une investigation est souvent ncessaire

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

Introduction: Quest quun problme de performance?: Les rseaux

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

Introduction: Quest quun problme de performance?

Application multimdia: + sensible au temps de rponse

Temps de rponse applicatif

Disponibilit/Fiabilit dun service Disponibilit rseau

Perceptible mais pas gnante

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

Introduction: Quest-ce quun problme de performance?

Dmarche pour rsoudre un problme de performance par un

Vrifier quil sagit dun vrai problme rseau

Faire des tests de bout en bout avec les machines impliques

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

2 Tests effectuer (dmarche +

Travaux et projets sur le sujet et tudes de

Collecte des informations de base

LASR est contact par lutilisateur final gnralement

Fonctionnement observ avec dgradation

LASR doit sassurer que les donnes collectes sont correctes:

Canevas/Template de collecte dinformations:

Collecte des informations de bases

Les sources dinformation 1/2

Avant de commencer les tests, beaucoup

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

Collecte des informations de bases

Les sources dinformation 2/2

Les rseaux rgionaux, de campus, MANs de la

Les rseaux nationaux/internationaux :

Autres rseaux (oprateurs privs, ISPs, GIXs) via :

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

Collecte des informations de bases

Comprendre le problme : une description pas pas

Avec ces informations collectes, lASR essaie de dceler do

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

2. Les tapes dans lanalyse dun

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

Vrification des informations aux

Le type d'application/logiciel et son mode de fonctionnement

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

Vrification des informations du systme:

Vrification du mode de communication de la carte rseau :

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

[root@ORSAY root]# ethtool eth0

Vrification des informations du systme:

"Tcp Receive Window" =BDP (ex: 4 000 000 en octets)

# turn on window scale and timestamp option

Vrification des informations du systme:

Pas de moyen dajuster le default TCP buffer (64 KB).

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

2. Les tapes dans le dbogage