Comme nous parlons de mesure soyons précis :-) Que veut on mesurer ? Le débit sur un lien ? quel débit ? physique ? couche 2 ? couche 3? (exemple classique débit ATM sur ADSL \neq débit IP sur lien ATM) Pour le débit sur un lien seul utiliser SNMP, voir Netflow sans échantillonnage (sinon évaluer l’erreur d’échantillonnage)
Le débit de bout en bout ? mais quel débit ? le débit disponible au goulot d’étranglement? (utiliser pathload http://www.measurementlab.net/tools/pathload2) le débit atteint par UDP? ( utiliser iperf) le débit atteint par TCP (utiliser iperf et fait varier vos tailles de fenêtre de réception, à la rigueur installer un web100 ou un web10G dans le noyau linux de la destination (http://www.web100.org/). Par ailleurs le ping ne donne pas toujours de RTT fiable, car les paquets ICMP peuvent être mis en file non prioritaire et peuvent être envoyé sur des chemins différents par les équilibreur de charge. Utiliser OWAMP pour de l'UDP, mais si vous avez du TCP sur votre lien c’est même mieux d’utiliser le RTT mesuré par les connexions TCP qu’on peut l’avoir de plusieurs façons par exemple en utilisant l’utilitaire ss (socket statistics) sous linux. BTW, IPPM est largement dépassé pour la mesure de débit car l’hypothèse de base d’échantillonnage sans biais (PASTA pour les intimes) n’est pas valable pour les flots TCP ou les flots ne générant pas de paquet à des instants aléatoires, lire le papier "The Role of PASTA in Network Measurement » http://conferences.sigcomm.org/sigcomm/2006/discussion/getpaper.php?paper_id=23. IPPM est bon pour monitorer les statistiques moyennes à grande échelles (moyenne des statistiques au moins sur 5 mins) . Croire les RFC quand on parle de technique et d’architecture. Ne jamais les croire quand on parle de stats ou de méthodologie analytique :-). Je ne fais pas référence à mon cours sur les mesures sur Internet mieux vaut indiquer les réfs à la source :-). Mais dans le cours je passe bien 2 à 3 séances de cours + 2 TP à expliquer les subtilités de la mesure de débit, donc la réponse précise nécessite d’avoir plus de détails sur le scénario. A+ Kv Le 21 sept. 2014 à 16:21, Stephane Bortzmeyer <bortzme...@nic.fr> a écrit : > On Sun, Sep 21, 2014 at 03:12:37PM +0200, > Matt <matta...@gmail.com> wrote > a message of 75 lines which said: > >> A priori il faut se méfier du ping pour récupérer le RTT > > Se méfier, oui, mais, en pratique, ça marche en général bien. > > Sinon, il y a OWAMP : > > http://www.bortzmeyer.org/4656.html > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
