La Fibre
Télécom => Réseau => 
Comment tester son débit ? => Discussion démarrée par: 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 :)
-
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.
-
Je suis dans le même cas, j'avais fait un speedtest hier soir, et je ne vois pas affiché le packet loss.
-
je ne vois pas affiché le packet loss.
Je ne suis pas sûr de comprendre, on le voit pourtant sur ta capture.
-
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à
-
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 (https://lafibre.info/tutoriels-linux/generer-des-pertes-de-paquets/) dans le sens montant et cela n'affecte pas les pertes de paquets descendant :
(https://lafibre.info/testdebit/ubuntu/201903_nperf_perte_paquet.png)
-
5% de perte de paquets sur Free ADSL, z'êtes des petits joueurs avec vos fibres les gars.
-
Ah bah, la fibre est insensible aux interférences électromagnétiques.
-
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 ?
-
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é.
-
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 (https://lafibre.info/serveur-linux/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).
(https://lafibre.info/testdebit/ubuntu/201903_fast_test_debit_netflix.png)
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)
(https://lafibre.info/testdebit/ubuntu/201903_nperf_perte_paquet.png)
-
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 ?
-
Pourquoi demander un test du CPU pour savoir si c'est lui qui limite le débit ?
En 2016 mon voisin à acheté un superbe PC Lenovo G50-30 à 300€.
Quand vous voyez ses caractéristiques, cela semble pas mal si vous ne connaissez pas le Celeron N2840...
- Dalle : 15.6’’ WXGA HD LED (1366x768, brillante)
- Processeur : Intel Celeron Dual Core N2840 Bay Trail-M (2.16 GHz, 2 cœurs, TDP 7.5W)
- Mémoire vive installée : 4 Go DDR3L 1600 MHz
- Espace de stockage : 1 To à 5400 tr/min
- Carte graphique : Intel HD intégrée au processeur
- Lecteur optique : Graveur DVD
- Système audio : 2 haut-parleurs, Dolby Advanced Audio
- Webcam : Oui, HD 720p avec micro
Son processeur brident complètement la machine, pour Windows 10 il faut oublier, cela rame trop pour que cela soit utilisable.
Ses performances avec nPerf ? A 100 Mb/s le CPU est saturé.
(https://lafibre.info/testdebit/ubuntu/201903_nperf_cpu_intel_celeron_n2840.png)
Le détail du CPU Celeron N2840, un processeur d'une lenteur incroyable (en même temps un TDP de 7,5watts, il consomme pas beaucoup pour une gravure en 22 nm)
Il lui manque par exemple les 7 instructions dédiées au chiffrement matériel AES (AES-NI)
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Thread(s) per core: 1
Core(s) per socket: 2
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 55
Model name: Intel(R) Celeron(R) CPU N2840 @ 2.16GHz
Stepping: 8
CPU MHz: 2582.293
CPU max MHz: 2582.3000
CPU min MHz: 499.8000
BogoMIPS: 4326.40
Virtualization: VT-x
L1d cache: 24K
L1i cache: 32K
L2 cache: 1024K
NUMA node0 CPU(s): 0,1
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer rdrand lahf_lm 3dnowprefetch epb tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms dtherm ida arat
-
FR SFR 10G - Courbevoie
N'hésitez pas à tester et me faire des retours :)
Bonjour,
-
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.
Merci pour les explications, Vivien. Effectivement, Free doit avoir un buffer équilibré car la latence chargée reste très modeste.
-
Free a annoncé avoir officiellement travailler sur le Bufferbloat.
Comment faire pour voir si votre ligne perd des paquets (hors débordement de buffer ?)
Il faut faire un test avec un logiciel qui permet d'envoyer les paquets à un débit limité et limiter le débit à moitié du débit maximum.
iperf3 permet de le faire avec l'argument "-b"
A ce débit on ne devrait perdre aucun paquet pour débordement de buffer.
-
- 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 (https://lafibre.info/serveur-linux/bufferbloat/)
Merci, je comprends maintenant pourquoi chez mon père avec son ADSL 6Mbps chez RED il devient impossible de naviguer sur le web dès qu'un téléchargement sature la connexion (ce qui arrive souvent avec 6 Mbps). Du coup, c'est au niveau de la Neufbox que le buffer est mal configuré si j'ai bien compris ? C'est quand même embêtant, même le téléphone fixe ne marche plus dans ces cas-là (pas d'appels entrants ni sortants). Je vais essayer de faire un test sur fast.com pour voir
-
Les buffers qui sont importants sont uniquement ceux où le débit se réduit le plus.
Concrètement :
- Débit montant : c'est la box
- Débit descendant, les buffers sont sur le DSLAM ou l'OLT pour le lignes avec un débit FTTH < 1 Gb/s. Pour les lignes FTTH Gpon avec un débit de 1 Gb/s, ce qui va brider le débit, c'est le câble Ethernet derrière l'ONT: ce sont donc les buffers de l'ONT qui vont se remplir.
Dans ton cas c'est donc ton DSLAM. Le problème de SFR c'est qu'ils ont différentes génération de DSLAM et que si certaines sont excellentes (même niveau que Free niveau débit et buffers), d'autres sont médiocres (et il y a 4 ans, ils commercialisaient encore des lignes sur des dDSLAM ADSL qui ne gèrent pas d'ADSL2+). Sur un même NRA il ont de nombreux type de DSLAM et j'ai déjà du jouer au jeu de résilier pour re-souscrire pour être placé sur le bon DSLAM (c'est un jeu risqué, mais à la seconde souscription j'ai été sur le DSLAM souhaité)
-
interessant ce post, cela correspond à ce que j'observe avec mon accès ovh, sur nperf j'ai 0,01% de perte en passant par overthebox, sur fast j'ai ping 44ms et chargé 233ms
uniquement sur la freebox près de 17% de perte donc cohérent, mais pas les ping qui sont à 21ms et 219ms chargé ...
je comparerai une fois fibré :)
-
17% de perte ?
Il y a un souci : TCP fait perdre des paquets, mais pas au point d'avoir 17% de paquets perdus.
Là tu as peut -être un problème autre.
Tu ne ferai pas ton test en Wi-Fi ?
Le Wi-Fi perd beaucoup de paquets, même quand la connexion est bonne.
Pour comparer ce qui est comparable, il faut faire un test en Ethernet et éviter impérativement le CPL / Wi-Fi.
Plus je réfléchi, plus je me dis que l'indicateur de pertes de paquet est compliqué à analyser et qu'il est préférable de faire les analyses à partir de la latence chargée / non chargée + débit en "connexion multiple" et "connexion unique".
-
Filaire uniquement, un test en wifi ne sert à rien ou juste à donner une idée.
Ça ne m’étonne pas plus que ça, notre ligne adsl est vraiment catastrophique, bcp d’erreurs (dont 1 mois de coupure) le cuivre est totalement à l’abandon, 6mbps a seulement 2.3km, pas étonnant que notre village soit le premier fibré du secteur.
Overthebox fait du bon boulot finalement, très stable et efficace, il faut dire que la 4g marche bien ici.
-
Pour la Overthebox, je suppose que le packet loss est mesuré uniquement entre le serveur nPerf et le point de sortie (d'entrée dans le cas du DL) chez OVH car les acquittements des paquets se font ici (avant d'être retransmis à l'utilisateur) non ? Vivien pourra probablement confirmer.
C'est le même pb avec les NAT opérateurs sur les réseaux cellulaires à priori...
-
Pourquoi demander un test du CPU pour savoir si c'est lui qui limite le débit ?
Effectivement, ce serait bien d'inclure un test du processeur (ou du matériel en général) car la plupart des PCs achetés 300/400 € sont incapables (s'ils ont un port gigabit), de soutenir un débit d'1 Gb/s, et ce n'est pas la faute du FAI. Avec la généralisation des connexions FTTH, et l'accroissement des débits offerts, le Gb/s est devenu la norme en FTTH, ce genre de cas va se multiplier.
-
Les cyphers utilisés par nperf tuent carrement le cpu sur certains appareils.
Quand on fait un speedtest web il faut faire en sorte d'utiliser le 1er cypher que le client supporte et pas imposer celui du serveur (cf https://www.ssllabs.com/ssltest/viewMyClient.html, section Cipher Suites )
-
Pour la Overthebox, je suppose que le packet loss est mesuré uniquement entre le serveur nPerf et le point de sortie (d'entrée dans le cas du DL) chez OVH car les acquittements des paquets se font ici (avant d'être retransmis à l'utilisateur) non ? Vivien pourra probablement confirmer.
Cela dépend du type du VPN : les VPN basés sur TCP font que les pertes de paquet accès seront ré-émis alors que les VPN UDP vont perdre les paquets, ce qui n'est pas grave car il y a du TCP à l'intérieur.
OpenVPN propose les deux modes (TCP/UDP). La recommandation est de passer en UDP, j'imagine que c'est ce que fait Overthebox, sans avoir de certitude
C'est le même pb avec les NAT opérateurs sur les réseaux cellulaires à priori...
La majorité des opérateurs mobiles coupent la connexion pour améliorer les performances donc le serveur nPerf ne vois pas les pertes sur le réseau mobile.
Par contre chez certains opérateurs, seul le port 80 et le port 443 sont coupés, donc en réalisant un test sur le port 8443 on devrait voir les pertes bout en bout.
Les cyphers utilisés par nperf tuent carrement le cpu sur certains appareils.
Je viens de faire un comparatif sur un PC où c'est le CPU qui limite.
Je vais ouvrir un autre sujet pour ne pas polluer celui-ci sur les Packet Loss.
Edit: réalisé => SpeedTest / nPerf: L'impact du CPU sur les débits (https://lafibre.info/tester-son-debit/impact-cpu-testdebit/)
-
On en a profité pour mettre à jour les ciphers et ajouter le support TLS 1.3
C'est déployé sur les 4 serveurs concernés par le PacketLoss ;)
-
Il me semble que nPerf est le premier test de débit à utiliser TLS 1.3
-
On en a profité pour mettre à jour les ciphers et ajouter le support TLS 1.3
speedtest.net: massy.testdebit.info port 8080 (avec nmap --script ssl-enum-ciphers ...)
8080/tcp open http-proxy
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
...
| TLSv1.1:
| ciphers:
...
| TLSv1.2:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 1024) - A
...
| compressors:
| NULL
| cipher preference: client
| warnings:
| Key exchange (dh 1024) of lower strength than certificate key
|_ least strength: A
NPerf: fr-sfr-courbevoie-01-10g.nperf.net:
443/tcp open https
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
| compressors:
| NULL
| cipher preference: server
|_ least strength: A
-
On en a profité pour mettre à jour les ciphers et ajouter le support TLS 1.3
C'est déployé sur les 4 serveurs concernés par le PacketLoss ;)
Vous privilégiez Chacha20-Poly1305 même pour les clients qui supportent AES-NI, c'est un choix ?
-
La préférence est corrigée, merci :)
-
Je capte pas pourquoi nperf est toujours faiblard en download:
depuis un chromebook en wifi (>500 Mbps vérifié en local) sur une connexion fibre 1G/250M Bytel:
SFR - packet loss affiché: 0.01%
(https://pic.nperf.com/r/3183153889719141-Dg3rhayb.png)
Bytel:
(https://pic.nperf.com/r/3183154523008077-SLtNzpWz.png)
avec speedtest:
(https://www.speedtest.net/result/8160047880.png)
j'ai fait plusieurs fois les tests pour évacuer tout souci de wifi. c'est constant a 20Mbps pres.
-
kgersen quel est ton processeur ?
Pourrais-tu tester avec le serveur SpeedTest de Massy pour comparer avec le serveur nPerf Bouygues ?
Les deux serveurs ont une configuration hardware et software identique est sont dans la même baie.
(Attention: SpeedTest refusant l'Anycast, il faut regarder sur https://bouygues.testdebit.info/ que les le serveur Anycast utilisé pour prendre le serveur SpeedTest correspondant)
La première phrase de https://bouygues.testdebit.info/ indique la localisation du serveur qui répond :
- Paris => SpeedTest TestDebit.info à Massy
- Lyon => SpeedTest LaFibre.info à Lyon
- Lille => SpeedTest LaFibre.info à Douai
- Bordeaux => SpeedTest LaFibre.info à Bordeaux
- Aix-Marseille => SpeedTest TestDebit.info à Marseille
-
c'est un i5-7Y57
j'obtient 500+ avec Massy (toujours en wifi):
(https://www.speedtest.net/result/8160293470.png)
ce chromebook atteint 940 en filaire avec un adapteur ethernet_usb-c.
J'ai aucun souci avec speedtest ou iperf, curl, wget, etc, y'a que nperf qui se traine en download avec un cpu pas a fond (60% au max sur un des cores).
-
Le fait que nPerf ne reconnaisse pas ton navigateur web entrainerait l’exécution d'un code à large compatibilité et qui ne permet pas une montée correcte en débit ?
C'est une hypothèse, par exemple sur http://ipv6-test.com/speedtest/ il y a du code qui diminue sensiblement la durée du test avec Internet Explorer, pour éviter un plantage du navigateur.
-
je ne pense pas, j'ai une autre machine pas trop puissante sous Win10 qui a le meme souci avec nperf.
j'ai testé avec un 'user-agent' switcher , nperf voit bien ce que lui dit le switcher (chrome win10), le résultat est le meme.
Je pense que leur code est juste un peu trop gourmant en cpu. je ne vois que ca comme explication.
-
Moi ce qui me gêne dans nPerf, c'est l'impossibilité de choisir un autre serveur que celui par défaut avec Firefox et Chromium sous Linux.
On reste avec une fenêtre "Connexion au serveur" avec en légère transparence la liste déroulante des serveurs...
La liste est adaptée en fonction de la capacité du client à se connecter sur un serveur sur le port 8443 (le serveur Ikoula - Reims est par exemple uniquement disponible sur le port 8443) et la disponibilité d'IPv6 (les serveurs IPv6 ne sont visibles que par ceux qui ont une connectivité IPv6).
Note : Ça serait un plus de marquer le port qui sera utilisé dans la liste déroulante
(https://lafibre.info/testdebit/ubuntu/201904_nperf_chromium_firefox.png)
-
Je n'ai pas de problème pour choisir un serveur autre que celui par défaut sur nPerf avec Firefox.
-
Ce bug ne se produit que sous Linux.
(Je me demande bien pourquoi)
-
Ce bug ne se produit que sous Linux.
(Je me demande bien pourquoi)
C'est un souci avec WebGL. On a prévu de mettre à jour la lib qu'on utilise (THREE.js) mais c'est pas garanti que ça corrige le pb...
-
Je n'ai pas ce souci sous Chrome 73 et Ubuntu 18.10 pour ma part.
-
Je suis sur ma machine de travail et je peux changer les serveurs.
J'utilise debian 9 et firefox esr 60.6.1
la cg c'est quadro k2000 et utilise les drivers propriétaires de nvidia
-
Pour info, la nouvelle version de l'applicatif serveur est disponible (v2.2.0).
La mise à jour des serveurs nPerf est en cours.
Le packet loss devrait être disponible sur la majorité des serveurs dans les jours/semaines qui viennent.
-
C'est mis en place sur les différents serveurs Anycast de Bouygues Telecom et sur le serveur Ikoula Reims.
-
Aujourd'hui, ajout de la latence et de la gigue chargées pendant le download ET l'upload.
Utilisez le bouton "..." ;)
-
a force vous allez refaire http://www.dslreports.com/speedtest ... ;D pourquoi ne pas faire un deal avec eux des le départ plutot que réinventer la roue ?
-
a force vous allez refaire http://www.dslreports.com/speedtest ... ;D pourquoi ne pas faire un deal avec eux des le départ plutot que réinventer la roue ?
Et que les USA soient les seuls à mesurer la qualité de l'Internet dans le monde ? :o Je crois que c'est bien d'avoir plusieurs acteurs :)
-
Et que les USA soient les seuls à mesurer la qualité de l'Internet dans le monde ? :o Je crois que c'est bien d'avoir plusieurs acteurs :)
deal pour avoir/partager leur code ....
-
Parfait cet ajout, c'était attendu (au moins par moi)
Il ne serait possible de rajouter un petit code qui tenterait rapidement de voir les performances du processeur, après avoir réalisé le test de débit ?
L'idée est de pouvoir donner un avertissement quand on suspecte que le CPU a pu être l'élèment limitant du test de débit.
On trouve de nombreux test de perf web (ex: https://silver.urih.com/ ) il faudrait un test court (3 secondes) et si possible pas trop éloigné de ce qui est utilisé comme instructions pour réaliser le test de débit.
-
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.
-
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 (https://lafibre.info/serveur-linux/linux-4-18/)
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.
(https://lafibre.info/testdebit/ubuntu/201804_ubuntu_kernel_support.svg)
-
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.
-
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.
-
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é. ::)
-
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.
-
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.
-
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 ?
-
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.
-
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".
-
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 (https://www.4gmark.com/ccarcep?m=netgmark&p=inc)).
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 (https://ipv6-test.com/speedtest/cc-details-fr.php)"
-
Une hypothèse :
- Latence (non chargée) => Mesurée par le navigateur
- Latence (chargée) => Mesurée coté serveur
8)
-
Bonjour à tous,
j'ai à tout heure 17-18% de packet loss, est-ce fiable ? Que faire ?
(https://pic.nperf.com/r/3511335309863181-ugU9V3YT.png)
-
C'est lié à BBR, l'algorithme de congestion qui permet d'avoir de bons débits, au prix de nombreuses pertes de paquets.