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

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

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

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

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.
tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

Introduction: Quest quun problme de performance?

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
tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

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

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

Introduction: Quest quun problme de performance?: Les rseaux

pouvant tre impliqus

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

Introduction: Quest quun problme de performance?

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

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

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

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

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
tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

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
tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

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

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

1.

Collecte des informations de bases

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

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

1.

Collecte des informations de bases

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

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

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

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

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

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

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

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

[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

Vrification des informations du systme:

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
tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

Vrification des informations du systme:

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.

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

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 :

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

MSS = Maximum Segment Size

RTT = Round Trip Time
P = Packet Loss probability
From Matt Mathis document

2. Les tapes dans le dbogage

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
Ok : passer au point suivant

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
Ok : passer au point suivant

En TCP :
Pb : si le test UDP est correct cela provient de la configuration TCP dun des htes.

Test applicatif ??: Si possible

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

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
tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

2. Les tapes dans le dbogage

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).
tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

2. Les tapes dans le dbogage

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.

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

2. Les tapes dans le dbogage

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
tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

2. Les tapes dans le dbogage

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.

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

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
stddev rtt = 0.008588, stddev b = 0.000009
Partial queueing: avg = 0.000143 ms (864 bytes)
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
stddev rtt = 0.015285, stddev b = 0.000017
Partial queueing: avg = 0.000155 ms (864 bytes)
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
stddev rtt = 0.001030, stddev b = 0.000001
Partial queueing: avg = 0.000033 ms (864 bytes)
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

2. Les tapes dans le dbogage

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

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

2. Les tapes dans le dbogage

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

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

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

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

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

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

Quelques exemples de problmes de

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

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

Quelques exemples de problmes de

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

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

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
tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie

Questions??

tutoJRES Mtrologie 3 octobre 2008 GT Mtrologie