Si tu veux un speedtest estampillé par ta société :
http://www.speedtest.net/fr/mini.php
ça vaut ce que ça vaut, ça évolue souvent, et c'est donc embêtant à
maintenir, mais c'est plus simple qu'un iperf côté client (un navigateur
web + flash fait l'affaire côté client), et côté serveur, tu as le choix
PHP, ASP ou JSP.
Pour des tests plus poussés, iperf en faisant jouer les tailles de
fenêtres TCP sera plus précis, et en UDP pour avoir la capacité maximale
(je me force à utiliser les bons termes, sinon un troll de la liste va
me tomber dessus).
Le 21/09/2014 16:57, Kavé Salamatian a écrit :
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/
---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce
que la protection avast! Antivirus est active.
http://www.avast.com
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
