La Fibre
Télécom => Réseau => 
Comment tester son débit ? => Discussion démarrée par: vivien le 14 août 2014 à 19:19:38
-
Impact de la publicité sur les tests de débit
Je me suis toujours demandé quel était l’impact des publicités affichées a coté des tests SpeedTest et DegroupTest.
Pour ceux qui ont un PC suffisamment puissant il est faible.
Par contre avec un Pentium dual core à 2,4 Ghz sous Windows 8.1 l'impact est impressionnant en FTTH.
Ce qui l'est plus encore, c'est que la publicité a un impact plus fort sur les performances de Chome.
Firefox permet d'avoir un meilleur débit.
J'ai réalisé des copie d'écran avec l'utilisation des 2 cœurs de mon processeur (la partie de droite des 2 graphes en bas de chaque copie d'écran représentant l’utilisation du processeur au moment du test de débit)
Tests de débit avec Firefox 31 sous Windows 8.1 avec update août 2014
TestDebit.info (sans publicité) : 396 Mb/s presque le débit max de la ligne FTTH Bouygues Telecom (400 Mb/s). Le CPU n'est pas chargé au maximum
(https://lafibre.info/testdebit/windows8/201408_win81_firefox_testdebit.png)
SpeedTest.net : 240 Mb/s. Le cpu au maximum est la cause de la limitation de débit
(https://lafibre.info/testdebit/windows8/201408_win81_firefox_speedtest.png)
DegroupTest nouvelle version : 250 Mb/s. Le cpu au maximum est la cause de la limitation de débit
(https://lafibre.info/testdebit/windows8/201408_win81_firefox_degrouptest.png)
-
Tests de débit avec Google Chrome sous Windows 8.1 avec update août 2014
Chrome + TestDebit.info (sans publicité) : 226 Mb/s Le cpu au maximum est la cause de la limitation de débit.
(https://lafibre.info/testdebit/windows8/201408_win81_chrome_testdebit.png)
Chrome + SpeedTest.net : 174 Mb/s. Le cpu au maximum est la cause de la limitation de débit
(https://lafibre.info/testdebit/windows8/201408_win81_chrome_speedtest.png)
Chrome + DegroupTest nouvelle version : 91 Mb/s. Le cpu au maximum est la cause de la limitation de débit
(https://lafibre.info/testdebit/windows8/201408_win81_chrome_degrouptest.png)
-
installes les extensions Flash Block (https://chrome.google.com/webstore/detail/flashblock/gofhjkjmkpinhpoiabjplobcaignabnl) et AdBlock (https://chrome.google.com/webstore/detail/adblock/gighmmpiobklfepjocnamgkkbiglidom) ou Ad-Block+ (https://chrome.google.com/webstore/detail/adblock-plus/cfhdojbkjhnklbpkdaibdccddilifddb) dans Chrome pour voir de combien les pubs influent sur le résultat.
-
Pourquoi les pubs prennent autant de ressource pross? étrange je trouve quand même!!
-
Pourquoi les pubs prennent autant de ressource pross? étrange je trouve quand même!!
Avec les grosses animations Flash multicolores qui s'agitent de partout, conçues sans la moindre idée d'optimisation en tête, et les divers blocs de JavaScript volumineux des régies chargés dans tous les sens, il ne faut pas s'étonner. D'autant plus que la tendance actuelle est de surcharger les sites web avec.
Sur les vieilles machines, il y a aussi la RAM que les publicités peuvent consommer massivement : si le PC passe en swap, il n'y a plus grand chose à espérer pour les performances du test.
Bref, une raison de plus d'utiliser Adblock Plus.
-
Mon PC portable est tellement pourri qu'il drop 1/3 des images d'une vidéo YouTube en 720p (gels, macro-blocs, pixellisations, même des sabliers à cause de l'ordi !), pour que vous ayez une idée du niveau de non-performances. Donc pour les tests de vitesses je n'espère pas grand-chose avec la fibre. Pour que le PC ne plante pas ou ne s'arrête pas pour surcharge ou surchauffe processeur le minimum sera de mettre AdBlock+ ;D
-
Chrome a une implèmentation assez peu performante de Flash, même sans pub il grève pas mal les débits sur une machine "pas trop puissante", le meilleur couple pour moi et FF 31 + Flash 14.0.x..
Par contre, je ne sais pas si on doit prendre en compte le test de Dégrouptest, car je n'ai jamais réussi sur aucun serveur en France à avoir des débits cohérents et surtout viable quand on a la chance d'avoir 1Gbits/s
DégroupTest :
(http://reho.st/thumb/self/34600bff460ac3eb062f6dca3acdf712d172d9c3.png) (http://reho.st/view/self/34600bff460ac3eb062f6dca3acdf712d172d9c3.png)
SpeedTest (le premier à avoir les vraies perfs !) :
(http://reho.st/thumb/self/c2e44a0c5ab82e47649a852901851e881dbe0b2c.png) (http://reho.st/view/self/c2e44a0c5ab82e47649a852901851e881dbe0b2c.png)
Et TestDebit.info sur DC3 (ma référence depuis que j'ai la fibre) :
(http://reho.st/thumb/self/3c57973572c5e2547754ea5a76fe2dc22cb124ae.png) (http://reho.st/view/self/3c57973572c5e2547754ea5a76fe2dc22cb124ae.png)
Comme l'on en avait déjà discuté, il doit manquer de thread chez DegroupTest pour paralléliser assez et vraiment saturer la fibre 1Gbits/s, et aussi le temps assez court du test... Cependant avant j'avais quand même l'upload de correct, je ne l'ai plus maintenant...
En terme de CPU, j'ai :
_ Chrome et son Pepper Flash : 20% de CPU User et 10% de CPU kernel
_ Firefox + Flash : 17% de CPU User + 3 à 4 % de CPU Kernel
durant les tests qui sont à 920Mbits/s sur SpeedTest au minimum avec dans les deux cas les pubs bloquées !
Conclusion, Chrome n'est pas ce qu'il y a de mieux pour tester les perfs, il va plus vite engorger une machine "limitée" en terme de CPU.
-
Une autre hypothèse est que Chrome a une implèmentation qui rend les animations flash plus fluides et donc qui consomme plus de CPU au dépend du reste (test de débit).
-
Heu plus fluide ? Je viens de le refaire sur TestDebit.info, qui est quand même bien limité en "effets graphiques" et c'est la même chose : surconsommation en CPU User et surtout Kernel pour lui 'un seul Tab ouvert !!) tandis que mon Firefox (23 tabs ouverts à coté) est à nettement moins gourmand en Kernel (donc I/O).. D'ailleurs c'est même du simple au double durant le test en upload (12-13% versus 6-7%) alors que dans ce cas, les deux ont un CPU Kernel faible...
Pour moi l'implèmentation de Google n'est pas aussi performante que celle d'Adobe, tout simplement... Google ne fait pas toujours mieux que les autres, même techniquement.
-
Chrome a une implèmentation assez peu performante de Flash, même sans pub il grève pas mal les débits sur une machine "pas trop puissante", le meilleur couple pour moi et FF 31 + Flash 14.0.x..
Par contre, je ne sais pas si on doit prendre en compte le test de Dégrouptest, car je n'ai jamais réussi sur aucun serveur en France à avoir des débits cohérents et surtout viable quand on a la chance d'avoir 1Gbits/s
DégroupTest :
(http://reho.st/thumb/self/34600bff460ac3eb062f6dca3acdf712d172d9c3.png) (http://reho.st/view/self/34600bff460ac3eb062f6dca3acdf712d172d9c3.png)
SpeedTest (le premier à avoir les vraies perfs !) :
(http://reho.st/thumb/self/c2e44a0c5ab82e47649a852901851e881dbe0b2c.png) (http://reho.st/view/self/c2e44a0c5ab82e47649a852901851e881dbe0b2c.png)
Et TestDebit.info sur DC3 (ma référence depuis que j'ai la fibre) :
(http://reho.st/thumb/self/3c57973572c5e2547754ea5a76fe2dc22cb124ae.png) (http://reho.st/view/self/3c57973572c5e2547754ea5a76fe2dc22cb124ae.png)
Comme l'on en avait déjà discuté, il doit manquer de thread chez DegroupTest pour paralléliser assez et vraiment saturer la fibre 1Gbits/s, et aussi le temps assez court du test... Cependant avant j'avais quand même l'upload de correct, je ne l'ai plus maintenant...
En terme de CPU, j'ai :
_ Chrome et son Pepper Flash : 20% de CPU User et 10% de CPU kernel
_ Firefox + Flash : 17% de CPU User + 3 à 4 % de CPU Kernel
durant les tests qui sont à 920Mbits/s sur SpeedTest au minimum avec dans les deux cas les pubs bloquées !
Conclusion, Chrome n'est pas ce qu'il y a de mieux pour tester les perfs, il va plus vite engorger une machine "limitée" en terme de CPU.
Sur DegroupTest t'es en mode HTTP, c'est normal. Normalement tu ne redescend en mode HTTP que si le test sur port 8080 ne passe pas. Tu as bloqué le port 8080 ?
-
Pour ajouter un élèment à la discussion, on a aussi constaté que Flash pouvait être perturbé par d'autres instances flash... donc pour un test optimal, fermez toutes les autres fenêtres du navigateur. ;)
-
Chez moi Degrouptest a été plus rapide après désactivation de Adblock ;D
-
Pour moi l'implèmentation de Google n'est pas aussi performante que celle d'Adobe, tout simplement... Google ne fait pas toujours mieux que les autres, même techniquement.
Le Flash intégré dans Chrome (Pepper Flash interface PPAPI) est aussi fourni par Adobe, c'est quasi le même code sauf son interfaçage avec le navigateur. Ca n'est pas Google qui le développe, c'est juste Google qui le distribue.
Comme c'est du PPAPI, c'est plus isolé (sandboxing) et plus sécurisé ce qui explique les différences de performance quand on est au limite de la machine.
Mais ce pas Chrome en soi le coupable. On peut très bien utiliser la version systeme de Flash dans Chrome , la meme que FF utilise, il suffit d'aller dans chrome://plugins/ et désactivé la version PPAPI et s'assurer que la version NPAPI est activée. A ce moment la, on peut vraiment comparer FF et Chrome. Chez moi Chrome va plus vite que FF avec le Flash NPAPI.
C'est l'éternel balance entre performance et sécurité, un choix vite fait dans 99% des cas ( d'autant plus que le Flash PPAPI se met a jour tous seul avec Chrome contrairement a la version system qui ne se met a jour que si on redémarre l'OS).
-
Pepper Flash Player is maintained by Google, and is newer than Adobe Flash Player. Adobe currently still provides security fixes for Adobe Flash Player. Google provides newer features in Pepper Flash Player. Pepper Flash Player can currently only be used with Chromium (and with Chrome).
https://wiki.debian.org/PepperFlashPlayer (https://wiki.debian.org/PepperFlashPlayer)
Le sandboxing existe aussi pour Firefox : http://blogs.adobe.com/security/2012/06/inside-flash-player-protected-mode-for-firefox.html (http://blogs.adobe.com/security/2012/06/inside-flash-player-protected-mode-for-firefox.html)
Bref, Ok pour le PPAPI versus NAPI mais pour ce qui est des perfs, ça n'explique pas vraiment tout, surtout du Kernel CPU...
-
https://wiki.debian.org/PepperFlashPlayer (https://wiki.debian.org/PepperFlashPlayer)
La situation pour Linux n'est pas la situation pour les autres OS, il ne faut pas la généraliser. Voir http://www.adobe.com/software/flash/about/ (http://www.adobe.com/software/flash/about/)
L'accord entre Google et Adobe est un accès au code source du Flash Player, avec d'autres d'ailleurs dont Microsoft pour IE, et à partir de ce source commun, sous le contrôle d'Adobe, Google 'build' et diffuse sa version Pepper et par la même propose donc une version a jour pour Linux alors que celle d'Adobe pour Linux est resté figé a la version 11.
"Google provides newer features in Pepper Flash Player" est donc une généralisation un peu hâtive et une vue réductrice de tout ca. Ce n'est pas Google qui ajoute de nouvelles fonctionnalités dans Pepper Flash, cela n'est que la conséquence de l'utilisation de ce source partagé et a jour. Le Flash est le même partout et sous le contrôle d'Adobe qui fournit (et fait payer) les outils de développement pour faire du Flash. Sinon ca serait vite la zone si chacun ajoute ses propres 'features' dans Flash.
Bref, Ok pour le PPAPI versus NAPI mais pour ce qui est des perfs, ça n'explique pas vraiment tout, surtout du Kernel CPU...
Pour les perfs et le 'kernel CPU usage' il faut comparer a version et type de Flash identiques sinon ça n'a pas vraiment de sens. Qu'est qui n'est pas expliqué la ?
Pour bien analyser, il faudrait aussi le code source en Flash du speedtest...
Le but c'est de mesurer et comparer la vitesse réseau du poste et éventuellement les navigateurs entre eux. Mais faire ca tout en faisant des animations visuelles en Flash c'est bien tant qu'on a que de l'ADSL ou des machines surpuissantes... Il manque vraiment un mode 'sans visuel' dans leur speedtest.
-
Pour les perfs et le 'kernel CPU usage' il faut comparer a version et type de Flash identiques sinon ça n'a pas vraiment de sens. Qu'est qui n'est pas expliqué la ?
Pour bien analyser, il faudrait aussi le code source en Flash du speedtest...
"Pepper" : 14.0.0.177 versus "Adobe" : 14.0.0.145 ... Même version majeure... Mécanisme de sandboxing (peut être bien différent mais existant) aussi avec FF depuis la version 11.3 sous Windows.
Maintenant, avoir les sources en Flash du Speedtest changerai quoi ? C'est du bytecode tout comme pour Java, c'est la FVM qui exécute le même code, et si pour toi Pepper en PPAPI contre Flash en NAPI est à la rue, le problème viendrait donc de PPAPI versus NPAPI... C'est bien joli que Google ait chié sur NPAPI pour proposer un truc moins bien, que personne n'utilise sauf eux, en concurrence avec nACL fait par ... Google et dont la encore tout le monde se fout... un peu comme leur format d'image à la con, par contre pas vraiment le passage limite en force de SPDY (qui n'est pas si joli que ça) dans l'HTTP 2.0.
Si mes trois machines testées, Chrome me claque un overhead de CPU Kernel, et c'est encore plus craint sur une machine peu puissante... Constat final : Chrome bride le test sur DC3 sur mon vieux Core2, pas Firefox. Et c'est de la faute de Google, et que de la sienne...
-
"Pepper" : 14.0.0.177 versus "Adobe" : 14.0.0.145 ... Même version majeure... Mécanisme de sandboxing (peut être bien différent mais existant) aussi avec FF depuis la version 11.3 sous Windows.
Maintenant, avoir les sources en Flash du Speedtest changerai quoi ? C'est du bytecode tout comme pour Java, c'est la FVM qui exécute le même code, et si pour toi Pepper en PPAPI contre Flash en NAPI est à la rue, le problème viendrait donc de PPAPI versus NPAPI... C'est bien joli que Google ait chié sur NPAPI pour proposer un truc moins bien, que personne n'utilise sauf eux, en concurrence avec nACL fait par ... Google et dont la encore tout le monde se fout... un peu comme leur format d'image à la con, par contre pas vraiment le passage limite en force de SPDY (qui n'est pas si joli que ça) dans l'HTTP 2.0.
Si mes trois machines testées, Chrome me claque un overhead de CPU Kernel, et c'est encore plus craint sur une machine peu puissante... Constat final : Chrome bride le test sur DC3 sur mon vieux Core2, pas Firefox. Et c'est de la faute de Google, et que de la sienne...
Comme dit avant c'est comparer des trucs incomparables.
Tu as clairement une dent contre Google donc ca ne sert pas a grand chose d'insister. On est sur lafibre.info ici pas sur universfreebox ou autre site de fanboys. Arguments posés et solides et objectivité sont de mise plutôt que sortir des inepties partisanes.
Si tu veux comparer il faut comparer le comparable: il te suffit de basculer le Flash en mode NPAPI dans Chrome pour faire ca (ca prend 10 secondes et sans redémarrer quoique ce soit). Tu verras que Chrome ne bride rien de plus.
Si tu veux comparer le sandboxing de Pepper et la solution de FF: https://media.blackhat.com/bh-us-12/Briefings/Sabanal/BH_US_12_Sabanal_Digging_Deep_WP.pdf
Oui c'est long (50+ pages) et très technique mais très instructif a lire. C'est écrit par des chercheurs d'IBM et pas de Google ou Adobe et ca ne vient pas d'un wiki lambda et c'est hébergé sur Blackhat.
Encore une fois, oui PPAPI est mois performant que NPAPI pour ce cas (speedtest) mais ca n'est pas un probleme car dans 99% des autres cas car l'écart de performance n'est pas visible vu les utilisations qui sont faites de Flash.
Pour NPAPI vs PPAPI il suffit de se renseigner un peu plus. Aller dire que c'est 'moins bien' juste parce que dans les cas extrêmes c'est plus consommateur de CPU c'est juste complètement partial et partisan. nACL utilise PPAPI et n'est donc pas en concurrence.
Idem pour le format d'image et SPDY, il faut pas sortir ce genre de chose ici sans des arguments fondés et solides , encore un fois on est pas sur universfreebox ou que sais-je.
-
Je pense comparer ce qui est comparable : soit 100% des utilisateurs de Firefox qui vont utiliser le NPAPI et 99.95% des utilisateurs de Chrome qui vont utiliser PPAPI pour tester .... les perfs de sa liaison fibre.
Pour le reste tu as mon MP ce qui est mieux pour toi je pense, fin du HS pour moi.
-
L'important a savoir serait en dessous de quelles specs matérielles le Speedtest est faussé parce que la machine ne suit pas:
A - la machine ne suit pas dans tous les cas (speedtest en dessous du nominal que ce soit avec Chrome ou FF)
B - la machine ne suit pas uniquement avec PPAPI (speedtest nominal sous FF ou Chrome NPAPI mais pas sous Chrome PPAPI)
C - la machine suit toujours (speedtest nominal avec les 2 navigateurs).
En gros il y a 3 paliers de specs matérielles.
Si l'écart en A et B représente un % ridicule de machines, on parle pour rien depuis le début.
A ce jour j'en ai pas encore croisé de machine dans la tranche B, c'est en général soit A ou soit C.
Donc pour une machine A, que FF affiche 450Mbps au lieu de 950Mbps ou que Chrome affiche 400Mbps au lieu de 950Mbps ca n'apporte pas grand chose a l'utilisateur au final (ni même que Chrome avec NPAPI affiche 500Mbps d'ailleurs).
On ne va pas aller faire installer FF a un néophyte qui a l'habitude de Chrome juste pour ca. Ou lui faire basculer le mode de Flash dans Chrome.
Et pour recoller au sujet de départ de combien les paliers bougent quand on désactive les pubs ?
-
Je penserais à faire des tests avec Adblock pour comparer avec et sans pub.
-
Quelque chose a fait fortement changer les performances flash sur ma machine sous OpenSUSE 13.2...
Auparavant, il m'était impossible de mesurer un débit supérieur à 30-50 Mb/s sur speedtest.net et surtout sur testdebit.info. Aucun problème en revanche pour atteindre les 100 Mb/s (ou devrais-je dire les 93.43 Mb/s) en ligne de commande ou avec un téléchargement normal.
Mais désormais, ce n'est plus le cas, et ces deux sites affichent 93.43 Mb/s. Difficile de dire exactement depuis quand, comme je ne fais pas un test tous les quatre matins.
Serait-ce une nouvelle version de flash qui se montrerait beaucoup plus véloce ?
Ca me semble surprenant, car je pensais qu'Adobe ne faisait désormais que le strict nécessaire pour le plugin NPAPI (uniquement les corrections de sécurité...)
Pareil du côté de Firefox...
Quelqu'un aurait-il une idée pour expliquer cela ?
cochonou@linux-opensuse-27:~> cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 Duo CPU T7100 @ 1.80GHz
stepping : 13
microcode : 0xa4
cpu MHz : 800.000
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fdiv_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
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 nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm ida dtherm tpr_shadow vnmi flexpriority
bogomips : 3590.94
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
cochonou@linux-opensuse-27:~> zypper info flash-player
Loading repository data...
Reading installed packages...
Information for package flash-player:
-------------------------------------
Repository: openSUSE-13.2-Update-Non-Oss
Name: flash-player
Version: 11.2.202.440-2.29.1
Arch: i586
Vendor: openSUSE
Installed: Yes
Status: up-to-date
Installed Size: 19,2 MiB
Summary: Adobe Flash Plugin and Standalone Player
Description:
This package contains Adobe's Flash Plugin for the supported Web
browsers in addition to a standalone flash player application.
cochonou@linux-opensuse-27:~> zypper info MozillaFirefox
Loading repository data...
Reading installed packages...
Information for package MozillaFirefox:
---------------------------------------
Repository: openSUSE-13.2 Update-Oss
Name: MozillaFirefox
Version: 35.0-9.1
Arch: i586
Vendor: openSUSE
Installed: Yes
Status: up-to-date
Installed Size: 92,3 MiB
Summary: Le navigateur web Mozilla Firefox
Description:
Mozilla Firefox is a standalone web browser, designed for standards
compliance and performance. Its functionality can be enhanced via a
plethora of extensions.
-
Je pense qu'il faut chercher les causses ailleurs, car j'ai un processeur proche sur mon portable et je n'ai pas eu de souci avec SpeedTest en flash sous Linux.
Ce qui pouvais poser problème c'est l'affichage de la carte qui peut bugger mais sinon le test de débit down et up est fiable (le ping moins)
-
Rien que l'affichage du compteur "kilométrique" saccadait beaucoup à l'époque, ce qui n'est plus le cas.
J'avais également contrôlé qu'il n'y avait pas un autre process/daemon qui me consommait des cycles CPU.
Bon, en tout cas je retiens de ta réponse que ça devait donc être un problème spécifique à ma configuration. Et que tout a du retomber "en marche" au cours d'une mise à jour...