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

Sn@ke · « **le:** 29 mars 2019 à 17:27:00 »

Bonjour,

Nous avons ajouté le packet loss (taux de retransmissions TCP pendant le download) sur nPerf.com, pour le moment c'est encore en rodage.

Seuls les serveurs suivants sont compatibles à 100% :

DE OVH 10G - Limburg
ES Stackscale 10G - Madrid
FR Rezopole 1G - Lyon
FR SFR 10G - Courbevoie

N'hésitez pas à tester et me faire des retours

underground78 · « **Réponse #1 le:** 30 mars 2019 à 10:55:21 »

Bonjour,

Je ne sais pas si c'est lié à cette modification mais j'ai des débits mesurés qui dépassent ponctuellement les 1 Gbps. J'ai testé sur le serveur SFR Courbevoie (compatible) et le serveur anycast ByTel (non compatible), le même comportement est visible dans les deux cas.

alain_p · « **Réponse #2 le:** 30 mars 2019 à 11:23:23 »

Je suis dans le même cas, j'avais fait un speedtest hier soir, et je ne vois pas affiché le packet loss.

underground78 · « **Réponse #3 le:** 30 mars 2019 à 11:26:00 »

Citation de: alain_p le 30 mars 2019 à 11:23:23

je ne vois pas affiché le packet loss.

Je ne suis pas sûr de comprendre, on le voit pourtant sur ta capture.

alain_p · « **Réponse #4 le:** 30 mars 2019 à 11:29:07 »

Exact, je n'avais pas vu ! Je m'attendais à ce qu'il soit affiché à part, il l'est donc seulement pour le download. Mais il est bien là

vivien · « **Réponse #5 le:** 30 mars 2019 à 12:17:41 »

Il est bien là et c'est bien les pertes de paquets uniquement dans le sens descendant.

J'ai injecté 40% de pertes de paquets avec Tutoriel pour générer des pertes de paquets / latence / gigue sur un équipement avec NetEm dans le sens montant et cela n'affecte pas les pertes de paquets descendant :

BadMax · « **Réponse #6 le:** 30 mars 2019 à 12:34:59 »

5% de perte de paquets sur Free ADSL, z'êtes des petits joueurs avec vos fibres les gars.

alain_p · « **Réponse #7 le:** 30 mars 2019 à 12:39:53 »

Ah bah, la fibre est insensible aux interférences électromagnétiques.

BadMax · « **Réponse #8 le:** 30 mars 2019 à 16:02:34 »

Intéressant, sur mon autre ligne ADSL OVH, seulement 0,5% de pertes. En synchronisant un poil plus bas (environ 4Mb/s contre 6Mb/s chez Free), serait-ce une explication sur l'écart ?

alain_p · « **Réponse #9 le:** 30 mars 2019 à 16:23:58 »

Oui, c'est tout à fait possible. En synchronisant plus bas, tu as une marge de bruit plus haut, dons moins de sensibilité aux perturbations électromagnétiques. Comparativement, mon 1.43% en FTTH (P2P) me parait élevé.

vivien · « **Réponse #10 le:** 30 mars 2019 à 16:31:55 »

Pour avoir travaillé sur le sujet, je peut donner une explication et des pistes de réflexions sur les pertes présentes, qui dans 99,9% des cas ne sont pas liés à des paquets perdu sur le chemin, mais à un dépassement de buffer.

TCP ne connais pas le débit de votre connexion Internet. Il s'adapte tout seul en fonction des pertes de paquets et de la latence.

On va prendre trois exemples de ligne (xDSL / FTTH c'est la même chose) :

- Ligne avec un gros buffer (plusieurs Mo) : Quand la connexion sature, les paquets supplèmentaires sont mis dans le buffer. La latence va augmenter. L'èmetteur va ralentir le débit où il envoi les paquets car la Rwin le limite, mais comme tous les piles TCP/IP modernes ont un Rwin adaptative, la Rwin voyant que tout se passe bien va augmenter. Problématique : La latence "chargé" visible sur https://fast.com/fr/ sera de plusieurs secondes (j'ai déjà vu des latence chargée de 10 secondes). La conséquence si vous surfez en même temps qu'un gros téléchargement le surf sera impossible ou très lent. Une ligne qui as un ping de 10 secondes c'est vraiment lent le surf, ce sera le cas car chaque demande devra passer par le buffer qui, comme il est de grande taille garde les paquets 10 secondes. Ce phénomène de buffer sur-dimensionné est appelé bufferbloat

- Ligne avec un buffer ridiculement petit (moins de 10 Ko en xDSL, moins de 100 Ko en FTTH) : Quand la connexion sature, les paquets sont mis dans le buffers qui déborde aussitôt : TCP va limiter le débit en émission. Si c'est un transfert multi-thread, les différentes connexions TCP vont se compenser entre-elles pour remplir le tuyau mais en mono-thread, TCP ne détectant pas la petite variation de latence qui lui indique que la connexion sature avant les pertes de paquets, le débit sera assez aléatoire et ne repliera pas la ligne au maximum. La latence étant toujours très faible, le surf qui est fait pendant le téléchargement sera très rapide.https://fast.com/fr/ indiquera une latence chargée proche de la latence non chargée.

-Ligne avec un buffer équilibré, adapté au débit de la ligne : La bonne taille du buffer, c'est la plus petite taille qui permet à TCP de comprendre où est la limite du débit. Je ne donnerais pas de taille précise cela dépend du débit (plus le débit est élevé, plus il faut un grand buffer exprimé en octets ou en nombre de paquets). En fait de façon idéale, il faudrait exprimer le buffer que l'on met dans les équipements en millisecondes : une ligne ADSL qui synchronise à 5 Mb/s doit avoir un buffer 10 fois plus petit que celle qui synchronise à 50 Mb/s.

Le rapport avec le test nPerf ?
Il faut considérer que les pertes de paquets comme une bonne chose : une ligne avec un buffer équilibré doit avoir des pertes de paquets. En XDSL, des opérateurs comme Bouygues Telecom, Free ou SFR ont des buffers équilibrés. Orange avait des buffers trop important qui réduisent la possibilité de faire plusieurs usages simultanés sur une ligne ADSL.

Voici un bon exemple de ce qu'il ne faut pas faire avec ma ligne SFR câble et le buffer est clairement surdimensionné (1,2 secondes de ping chargé).
Concrètement, quand je fais des sauvegardes, il m'est complètement impossible de surfer (j'ai depuis introduit une limitation de débit dans mes sauvegardes pour ne pas avoir le ping qui augmente).

Comme vous pouvez le voir dans mon test nPerf j'ai 0% de perte (ci-dessous, celui où j'ai généré 40% de perte de paquets en montant, mais c'est aussi le même résultat sans générer de perte de paquets en montant : les pertes de paquets sur le débit montant impactent le débit montant)

vivien · « **Réponse #11 le:** 30 mars 2019 à 17:36:05 »

En résumé pour savoir dans quelle situation vous êtes :

- Ligne avec un buffer trop important : Latence chargée - latence non chargée supérieur à 50ms (pour le test nPerf si vous n'avez pas de perte de paquets, vous savez que c'est le cas où qu'il y a une limitation du débit à cause d'un CPU pas assez puissant)

- Ligne avec un buffer trop petit : Le test simple : il faut faire un test avec une "connexion unique" et "connexion multiple" comme c'est le cas par défaut. Si le débit mono connexion est nettement inférieur au débit multi-connexion c'est qu'il y a un problème sur votre ligne. Une des causes peut être un buffer trop petit, mais il y a d'autres causes possibles.. https://www.speedtest.net/fr propose depuis peu ce type de test. Pour nPerf, il me semble que c'est accessible uniquement pour ceux qui ont l'appli android / iOS payante (ce n'est pas disponible dans le mode gratuit)

Si vous avez le débit maximum avec un test connexion et que la latence chargée - latence non chargée est inférieur à 50ms alors tout est bon. Votre ligne permet de télécharger rapidement avec une seule connexion et permet de faire de multiples usages en parallèle.

Si Sn@ke me lit voici les 6 innovations que j’aimerais bien voir dans nPerf :
- Tester la latence chargée / non chargée comme le test "Fast" de Netflix
- Tester le débit en "connexion multiple" et "connexion unique" comme SpeedTest d'Ookla
- Tester le débit en IPv4. Si une connexion IPv6 est disponible, proposer à la fin du test de faire un test IPv6 et afficher les deux résultats dans une même image, comme http://ipv6-test.com/speedtest/
- Proposer en option de tester le débit sur le port 8443 (pour les serveurs sur le port 443)
- Proposer de tester le débit avec un serveur non listé dans la liste
- Évaluer via un script la puissance du CPU afin de déterminer si c'est lui qui a bridé le débit. Beaucoup de tests à 1 Gb/s sont limités par le CPU. Pour le 10 Gb/s, je pense que c'est tous les tests qui sont limités par le CPU. L'indiquer au client qui fait le test serait un grand plus. Par exemple savez-vous qu'avec un Celeron N2840 @2.16GHz, le débit est limité à moins de 100 Mb/s à cause des faibles performances de processeur ?