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

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

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é.

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)

Code: [Sélectionner]

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

Ballast · « **Réponse #13 le:** 30 mars 2019 à 20:28:48 »

Citation de: Sn@ke le 29 mars 2019 à 17:27:00

FR SFR 10G - Courbevoie
N'hésitez pas à tester et me faire des retours

Bonjour,

alain_p · « **Réponse #14 le:** 30 mars 2019 à 22:09:07 »

Citation de: vivien le 30 mars 2019 à 17:36:05

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.

vivien · « **Réponse #15 le:** 30 mars 2019 à 22:44:46 »

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.

lechercheur123 · « **Réponse #16 le:** 31 mars 2019 à 03:42:36 »

Citation de: vivien le 30 mars 2019 à 16:31:55

- 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

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

vivien · « **Réponse #17 le:** 31 mars 2019 à 07:24:41 »

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é)

Phil · « **Réponse #18 le:** 31 mars 2019 à 10:20:13 »

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é

vivien · « **Réponse #19 le:** 31 mars 2019 à 10:40:33 »

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".

Phil · « **Réponse #20 le:** 31 mars 2019 à 10:52:31 »

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.

Sn@ke · « **Réponse #21 le:** 31 mars 2019 à 18:27:26 »

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...

alain_p · « **Réponse #22 le:** 31 mars 2019 à 18:37:50 »

Citation de: vivien le 30 mars 2019 à 19:41:26

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.

kgersen · « **Réponse #23 le:** 31 mars 2019 à 18:43:48 »

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 )