Auteur Sujet: Ajout du Packet Loss sur nPerf.com (Lu 14991 fois)

Sn@ke · « **Réponse #48 le:** 11 avril 2019 à 15:44:07 »

Pour info, selon la version du kernel qui tourne sur le serveur, le packet loss n'est pas forcèment disponible.
Pour avoir le packet loss, il faut un kernel >= 4.2 (Debian9, Ubuntu 16 & 18)
Pour la latence et la gigue chargée ça fonctionne avec un 3.16 (Debian 8 ), pas encore testé avec un 3.10 (CentOS 7/RHEL7)
CentOS6/RHEL6 on oublie c'est du 2.6, incompatible avec les dernières versions de libc. On a donc stoppé le support.

vivien · « **Réponse #49 le:** 11 avril 2019 à 20:49:59 »

Pour Ubuntu il est possible d'avoir un Kernel plus récent en ne modifiant rien d'autre

=> Linux 4.18 : gain de performance sur certains serveurs

Le Kernel qui sera mis en place automatiquement sur les serveurs Bouygues en août sera Linux 5.0, le kernel utilisé par Ubuntu 19.04 qui sort jeudi prochain.

underground78 · « **Réponse #50 le:** 13 avril 2019 à 14:33:10 »

Citation de: Sn@ke le 11 avril 2019 à 11:04:50

Aujourd'hui, ajout de la latence et de la gigue chargées pendant le download ET l'upload.
Utilisez le bouton "..."

Je vois un truc curieux au niveau de la gigue, le test détecte une gigue bien moins importante quand la connexion est chargée que quand elle ne l'est pas. C'est logique ça ?

Sinon je vois toujours des pics bizarres au dessus des 1 Gbps.

Edit : Correction, cf. ci-dessous.

alain_p · « **Réponse #51 le:** 13 avril 2019 à 20:21:30 »

Tu ne voulais pas dire l'inverse, c'est à dire bien moins importante pour la gigue chargée que pour le ping ?

J'ai la même chose ici, et j'observe aussi régulièrement, des pointes au-delà de 1000 Mb/s, jusqu'à 1200 Mb/s ou plus.

underground78 · « **Réponse #52 le:** 13 avril 2019 à 20:23:20 »

Citation de: alain_p le 13 avril 2019 à 20:21:30

Tu ne voulais pas dire l'inverse, c'est à dire bien moins importante pour la gigue chargée que pour le ping ?

Oups, c'est corrigé.

vivien · « **Réponse #53 le:** 13 avril 2019 à 20:41:19 »

La gigue (en charge comme à vide) est peu fiable, car c'est l'écart entre la latence minimum et la latence maximum et les systèmes d’exploitation n'étant pas temps réel, la latence maximum est souvent faussé par le logiciel.

Ce qui est important pour TCP, c'est si la gigue fait que les paquets arrivent dans le désordre. Pour moi c'est cette information qu'il faudrait avoir.

Sn@ke · « **Réponse #54 le:** 17 avril 2019 à 10:44:06 »

La gigue durant le speed test est mesurée par le noyau linux du serveur tandis que celle de la latence est mesurée par le client via le browser, donc forcèment plus sujette à variations d'origine logicielle.

hwti · « **Réponse #55 le:** 18 avril 2019 à 00:46:47 »

Citation de: Sn@ke le 17 avril 2019 à 10:44:06

La gigue durant le speed test est mesurée par le noyau linux du serveur tandis que celle de la latence est mesurée par le client via le browser, donc forcèment plus sujette à variations d'origine logicielle.

Je suppose que la précision de la mesure côté serveur doit dépendre du kernel utilisé (les kernels serveurs sont en général optimisés pour le débit et pas la latence), et de la carte réseau : si c'est matériel (https://networkengineering.stackexchange.com/questions/23369/how-to-check-if-a-nic-supports-hardware-timestamps), ou logiciel (et donc soumis à la modération des interruptions, qui va retarder la lecture des paquets, et aux éventuelles latences liées aux fréquences processeur réduites à faible charge).

Mais dans tous les cas, c'est bien mieux que ce que peut faire un browser.
Est-ce qu'on ne pourrait pas avoir une meilleure mesure de la latence en remontant le RTT de la connexion TCP (ou en analysant les timestamps) sur le serveur ?

Sn@ke · « **Réponse #56 le:** 01 juillet 2019 à 17:54:55 »

Citation de: hwti le 18 avril 2019 à 00:46:47

Est-ce qu'on ne pourrait pas avoir une meilleure mesure de la latence en remontant le RTT de la connexion TCP (ou en analysant les timestamps) sur le serveur ?

C'est justement le RTT qui est remonté pour la "latence chargée". Comme on établi plusieurs connexions c'est la moyenne des RTT de l'ensemble des connexions.

hwti · « **Réponse #57 le:** 01 juillet 2019 à 18:31:44 »

Citation de: Sn@ke le 01 juillet 2019 à 17:54:55

C'est justement le RTT qui est remonté pour la "latence chargée". Comme on établi plusieurs connexions c'est la moyenne des RTT de l'ensemble des connexions.

Du coup je ne comprends pas le "tandis que celle de la latence est mesurée par le client via le browser".

vivien · « **Réponse #58 le:** 01 juillet 2019 à 18:39:10 »

Une hypothèse :
- Latence (non chargée) => Mesurée par le navigateur
- Latence (chargée) => Mesurée coté serveur

Cela serait bien de mettre touts ces informations un peu geek dans un code de conduite, accessible via un lien depuis la page de test.

Exemples :
- DébitTest 60 indique met un lien sous le bouton "Je test ma connexion" qui est DébiTest 60 respecte le code de conduite 2018 de l’Arcep (voir les critères du protocole).

Il y a quelques imprécisions dans le tableau, c'est plus l'idée de mettre un lien depuis la page de test pour rendre ces informations plus accessibles.

- IPv6-test met sous le menu de sélection du serveur "ARCEP Code of Conduct : EN | FR"

Sn@ke · « **Réponse #59 le:** 02 juillet 2019 à 10:23:59 »

Citation de: vivien le 01 juillet 2019 à 18:39:10

Une hypothèse :
- Latence (non chargée) => Mesurée par le navigateur
- Latence (chargée) => Mesurée coté serveur