La Fibre
Télécom => Réseau => 
Comment tester son débit ? => Discussion démarrée par: vivien le 08 février 2020 à 12:41:15
-
Je vais aussi développer un outil pour remplacer IPerf3 si vous avez des idées & demandes c'est le moment.
Je me demande si il est pertinent de se lancer sur un nouvel outil coté serveur.
Je verrais plus un outil de test de débit en ligne de commande qui utilise un serveur web classique (Apache2 / Nginx) pour tester les débits.
Un serveur web classique à de nombreux avantages sur un outil dédié :
- Robustesse (vs plantage régulier quand l'usage est un peu exotique avec iPerf3)
- Nombreux flux et clients en parallèle (vs 1 client max par port avec iPerf3)
- Chiffrent représentatif (vs pas de chiffrement avec iPerf3)
- Prise en charge de http/2 et les nouvelles technologies...
Le test de débit se fait en téléchargeant de gros fichiers comme le propose https://bouygues.testdebit.info/ et en upload en recevant le flux envoyé par le client (comme cela fonctionne bien avec curl)
Le gros manque pour exploiter pleinement un serveur web pour faire des tests de débit, c'est le coté client.
Il y a bien curl qui permet de faire un test sur une durée fixe (Réaliser un test de débit descendant ou montant avec CURL sous Linux (https://lafibre.info/tester-son-debit/curl-linux/)) mais les débits sont affichés en Mio/s, pas de possibilité d’exclure le slow start, pas de possibilité de multithread et le test upload est peu performant et nécessite d'avoir un gros fichier sur le client. Il serait bien aussi de pouvoir changer de port TCP pour faire des tests de neutralité.
Bref, je pense qu'il serait plus intéressant de faire un client efficace que de faire un nouvel outil coté serveur.
-
Je me demande si il est pertinent de se lancer sur un nouvel outil coté serveur.
Bref, je pense qu'il serait plus intéressant de faire un client efficace que de faire un nouvel outil coté serveur.
Oui je n'avais pas l'intention de réinventer la roue ou un protocole comme celui Iperf mais d'utiliser http, https, http/2 et http/3/quic.
Le code client pourra télécharger / uploaded vers n'importe quel serveur web. Ca permettra de réaliser des tests avec plusieurs serveurs différents en meme temps ce qui est impératif pour tester du 10G sur Internet.
Le code coté serveur sera donc un serveur web mais je ne crois pas que apache/nginx/caddy ou autre soient des bons candidats pour faire des serveurs de tests de débits dédiés.
L'idée est donc d'utiliser le code de serveur web existants (en Go ou en Rust) et de bâtir dessus un serveur web plus dédié a des tests de débit.
Par exemple on ne servira pas des fichiers 'réels' stockés sur disque (ou un ramdisk) comme tu fais actuellement avec testdebit.info mais des fichiers généré a la volée comme fait httpbin (https://httpbin.org/#/Dynamic_data/get_stream_bytes__n_). Au lieu d'avoir un ensemble fixé de fichiers de tests (100M, 1G, 5G, etc) et d'extensions le client pourra demandé ce qu'il veut a l'octet pres et pourra 'post' ce qu'il veut. On pourra aussi mettre des limites coté serveurs voir une file d'attente.
L'avantage d'utiliser ce code serveur est d'avoir aussi le crosstalk, la charge cpu et plusieurs autres info non dispo quand on utilise apache/nginx/caddy/etc.
Il va de soit que le code client est plus important et sera le premier truc à faire puisqu'il peut fonctionner seul sans le code serveur.
Le code serveur est en plus et viendra après, pour faire des mesures plus précises (ou des tests lan ce qui est mon intérêt 1er) et générer des statistiques pour faire des graphes.
-
Remonter la charge réseau est intéressante. La charge CPU ou Ram est peu intéressante dans mon cas car l'utilisation est faible, même dans le cas de trafic https en 10 Gb/s, que ce soit sur une ou plusieurs connexion TCP. Pour un test monothread en https, il faut qu'un seul cœur soit capable de traiter le trafic, mais c'était déjà le cas sur la génération précédente de serveur que j'avais.
Peut-être créer un sujet dédié... le jour où on souhaite retrouver l'info au milieu de ce sujet, ce sera pas simple (je peut aussi séparer les messages pour en faire un nouveau sujet)
-
kgersen tu comptes faire ce projet en opensource ?
Je cherchais justement une idée de projet concret pour mettre en pratique du rust (ça fait quelques mois que j'avance progressivement sur la doc), du-coup je souhaiterai contribuer au projet.
Pour le code client je suppose qu'il faudra développer un programme multiplateforme ? On peut aussi envisager tenter quelque chose en webassembly, il y a surement moyen de faire des tests de débit moins gourmand dans le navigateur avec cette techno.
-
kgersen tu comptes faire ce projet en opensource ?
Je cherchais justement une idée de projet concret pour mettre en pratique du rust (ça fait quelques mois que j'avance progressivement sur la doc), du-coup je souhaiterai contribuer au projet.
Pour le code client je suppose qu'il faudra développer un programme multiplateforme ? On peut aussi envisager tenter quelque chose en webassembly, il y a surement moyen de faire des tests de débit moins gourmand dans le navigateur avec cette techno.
oui surement open-source , c'est trop tot pour le langage toutefois et j’avoue que ma préférence va a Go plutôt qu'a Rust (je ne suis pas convaincu par Rust en l'état, y'a trop 'd'effet de mode' autour et un manque de recul. Les packages tiers manquent de maturité et de mise a l'épreuve).
J'ai fais des benchmarks et je continue a en faire avant de décider du langage.
L'important c'est surtout de trouver une bonne lib client http car le but n'est pas d'aller se taper l'écriture d'un client http (surtout avec http/2 et quic...). Go a une bon client HTTP de base (net/http) et une variante rapide (valyala/fasthttp), et Go a servit pour développer HTTP/2. Rust a reqwest et Hyper.rs et au pire y'a libcurl pour quasi tout les langages...c'est peut-être le mieux mais la portabilité est plus compliqué.
Webassembly n'apportera pas grand chose en terme de performance , js ou wasm c'est pareil pour ce cas d'usage. Le bottleneck c'est les limites du sandbox des navigateurs et comment ils implémentent les websockets (ou l'api fetch) car wasm n'a pas d'accès plus bas niveau que js. Franchement et ca fait un moment que je suis sur ce sujet je ne pense pas qu'on puisse fait mieux que ce que font les 'speedtest' web actuels donc ca ne sert pas a grand chose de vouloir utiliser un navigateur.
Du moins pour le code du test lui meme (aka le client http), par contre j'ai bien l'intention de faire une interface 'web' pour l'utilisateur non expert (c'est le défaut #1 des tests avec IPerf et curl). L'idée est de faire comme avec 'Electron' mais sans la lourdeur Electron: le programme n'a pas d'interface native mais expose une interface web accessible sur localhost (ou meme en réseau). Je n'ai toutefois pas encore décider quel framework web utilisé (d'autant que je déteste JS donc ca doit être du TS ou peut-être gopherjs). L'idéal sera un seul langage pour toute la stack...a ce niveau wasm peut peut-être jouer un role...
Je vais procéder par étape:
1. Client sans interface web, ligne de commande, multiplate-forme. L'équivalent de "curl" mais vers /dev/null par défaut (et optimiser pour ca) avec parallélisme et génération d'une résultat exportable (image ou graphe). Le client pourra mesurer le crosstalk, savoir quel type d'interface et type/debit (filiaire,wifi, 4g,) est utilisée , la charge cpu, etc bien plus qu'un navigateur donc. On peut meme embarquer libupnp (http://miniupnp.free.fr/index_fr.html)pour connaitre le crosstalk a la box du FAI...(vu que l'API des box c'est un sujet mort ou pas utilisable).
2. Interface web sur ce client pour les utilisateurs moins avertis. Ils téléchargent un 'exe' et le lance et ca ouvre leur navigateur sur 'localhost:1234' par exemple et une interface facon speedtest va controler le .exe pour faire des tests. L'interface doit permettre de proposer une liste de tests: download d'un fichier depuis testdebit.info par exemple, de plusieurs fichiers fichiers meme temps, etc. on peut meme envisager de concevoir des "groupes d'url" a proposer.
3. Le serveur dédié qui apportera des fonctionnalités supplémentaires (j'ai pas mal d'idées a ce sujet) notamment ce qu'on fait coté client (interface, crosstalk, cpu,etc). on peut envisager de mettre le client et le serveur dans le meme .exe par la suite pour faire des tests lan ou P2P entre 2 abonnés (moyennant l'ouverture des ports/IP qui va bien).
-
oui surement open-source , c'est trop tot pour le langage toutefois et j’avoue que ma préférence va a Go plutôt qu'a Rust (je ne suis pas convaincu par Rust en l'état, y'a trop 'd'effet de mode' autour et un manque de recul. Les packages tiers manquent de maturité et de mise a l'épreuve).
J'ai fais des benchmarks et je continue a en faire avant de décider du langage.
L'important c'est surtout de trouver une bonne lib client http car le but n'est pas d'aller se taper l'écriture d'un client http (surtout avec http/2 et quic...). Go a une bon client HTTP de base (net/http) et une variante rapide (valyala/fasthttp), et Go a servit pour développer HTTP/2. Rust a reqwest et Hyper.rs et au pire y'a libcurl pour quasi tout les langages...c'est peut-être le mieux mais la portabilité est plus compliqué.
Effectivement il y a beaucoup de hype autour du Rust, à voir si c'est juste passager où si cela restera. Après effectivement il faut bencher un maximum comme on cherche le plus de perf. À voir en fonction du niveau d'optimisation des libs existantes et du possible impact du garbage collector de Go (mais j'ai entendu dire qu'il a été beaucoup optimisé dans les dernières versions, son impact est vraiment minime depuis).
Webassembly n'apportera pas grand chose en terme de performance , js ou wasm c'est pareil pour ce cas d'usage. Le bottleneck c'est les limites du sandbox des navigateurs et comment ils implémentent les websockets (ou l'api fetch) car wasm n'a pas d'accès plus bas niveau que js. Franchement et ca fait un moment que je suis sur ce sujet je ne pense pas qu'on puisse fait mieux que ce que font les 'speedtest' web actuels donc ca ne sert pas a grand chose de vouloir utiliser un navigateur.
Ok donc effectivement si c'est la sandbox / l'implémentation websocket il y a effectivement rien à explorer dans les autres langages.
Du moins pour le code du test lui meme (aka le client http), par contre j'ai bien l'intention de faire une interface 'web' pour l'utilisateur non expert (c'est le défaut #1 des tests avec IPerf et curl). L'idée est de faire comme avec 'Electron' mais sans la lourdeur Electron: le programme n'a pas d'interface native mais expose une interface web accessible sur localhost (ou meme en réseau). Je n'ai toutefois pas encore décider quel framework web utilisé (d'autant que je déteste JS donc ca doit être du TS ou peut-être gopherjs). L'idéal sera un seul langage pour toute la stack...a ce niveau wasm peut peut-être jouer un role...
Alors pour un electron en plus léger, il y a webview : https://github.com/zserge/webview (avec des binding pour Go inclus et pour Rust sur ce projet : https://github.com/Boscop/web-view ) Je l'ai déjà utilisé pour quelques tests et pour un petit programme de remonté de log via une ligne série au boulot, ça permet d'avoir un exécutable beaucoup plus léger comme il passe par le navigateur du système au lieu d'embarquer un chromium. Et pour la partie backend tu codes en natif au lieu du JS.
Pour le front, tu peux mettre ce que tu veux, mais vaut mieux quelque chose qui gère du polyfill ou à minima qui compile vers du JS ancien, car sous Windows ça tourne par dessous IE11 (il est aussi possible de targer edge). J'approuve Typescript, j'en fais depuis bientôt 2 an maintenant, le retour au JS est compliqué une fois habitué.
-
C'est vraiment un projet intéressant, surtout avec l'arrivée des connexion à 10 Gb/s, débit qui nécessite de très grosses ressources CPU pour être testé dans un navigateur web (quel que soit la navigateur et quel que soit l'outil de test).
Je pense intéressant d'en faire une version clé USB Bootable, afin de pouvoir aider une personne à vérifier un logiciel ou driver de Windows 10 bride le débit.
-
Bon courage !
Faites signe lorsqu’il y aura de quoi tester.
-
Effectivement il y a beaucoup de hype autour du Rust, à voir si c'est juste passager où si cela restera. Après effectivement il faut bencher un maximum comme on cherche le plus de perf. À voir en fonction du niveau d'optimisation des libs existantes et du possible impact du garbage collector de Go (mais j'ai entendu dire qu'il a été beaucoup optimisé dans les dernières versions, son impact est vraiment minime depuis).
Ok donc effectivement si c'est la sandbox / l'implémentation websocket il y a effectivement rien à explorer dans les autres langages.
Alors pour un electron en plus léger, il y a webview : https://github.com/zserge/webview (avec des binding pour Go inclus et pour Rust sur ce projet : https://github.com/Boscop/web-view ) Je l'ai déjà utilisé pour quelques tests et pour un petit programme de remonté de log via une ligne série au boulot, ça permet d'avoir un exécutable beaucoup plus léger comme il passe par le navigateur du système au lieu d'embarquer un chromium. Et pour la partie backend tu codes en natif au lieu du JS.
Pour le front, tu peux mettre ce que tu veux, mais vaut mieux quelque chose qui gère du polyfill ou à minima qui compile vers du JS ancien, car sous Windows ça tourne par dessous IE11 (il est aussi possible de targer edge). J'approuve Typescript, j'en fais depuis bientôt 2 an maintenant, le retour au JS est compliqué une fois habitué.
Si on fait bien la 'boucle' en Go ou autre langage avec GC, y'a pas d'allocation mémoire donc pas de GC nécessaire. J'ai tester goben (https://github.com/udhos/goben)ou un go-httpbin (https://github.com/kgersen/go-httpbin) modifié par mes soins sur 10Gbits ca passe sans souci , la mémoire et le cpu s'ennuient.
Du coup niveau perf je ne pense pas que le langage fera la différence. La maillon lent est dans la stack IP de l'OS. C'est vraiment la "lib client http" qui va importer (notamment sa gestion de la boucle d'envoi/reception et ce qu'on peut modifier ou pas dedans). Et si elle est au point, si elle permet HTTP/2 et QUIC (ideal pour tester UDP).
J'avais croisé webview mais mais ce n'est pas vraiment ce que je cherche. Tout les PC desktop ont un navigateur autant en profiter plutôt que d'embarquer nous meme du 'code de rendu html' (en plus EdgeHTML est abandonné non?).
De toute facon l'interface web est a l'étape 2, ca laisse du temps pour réfléchir et faire du design.
-
J'avais croisé webview mais mais ce n'est pas vraiment ce que je cherche. Tout les PC desktop ont un navigateur autant en profiter plutôt que d'embarquer nous meme du 'code de rendu html' (en plus EdgeHTML est abandonné non?).
Justement webview passe par le navigateur du système, il n'embarque rien du tout ;)
Et oui EdgeHTML est en maintenance, il va être abandonnée une fois que tous les edge seront migré sur la version basée sur chromium.
-
J'avais plus dans l'idée de développer un testeur de débit en peer-to-peer pour ne plus être dépendant d'un seul serveur par test.
-
Justement webview passe par le navigateur du système, il n'embarque rien du tout ;)
oui mais du coup ce n'est pas vraiment multi-plateforme (Windows/Linux/Mac ce n'est pas suffisant en terme de 'multi-plateforme'. Il faut aussi Android, iOS, Freebsd, voir n'importe quel OS futur).
De toute façon c'est mieux que l'exe soit indépendant du 'webview' cela permet de l'utiliser a distance sur des machines sans interface graphique. On met le client dans un routeur ou un serveur et on a l'interface sur une autre machine. C'est plus simple niveau dev et 'build' aussi.
Je ne pense pas que l'utilisateur soit gêné de voir http://localhost:1234 d'autant qu'on peut faire une PWA pour masquer l'url (a vérifier toutefois vu les contraintes de validation pour faire une PWA). On peut aussi faire juste une API REST sur http://localhost:1234 servie par le .exe et le code html/js est ailleurs sur un serveur public et appel l'API localement via XHR. Voir un mélange des 2.
un truc du genre, 3 solutions possibles:
(https://i.imgur.com/bfB03CT.png)
Mon projet s’appelle 'NSpeed' , car c'est la suite de mon vieux test HTML5 ( http://nspeed.info/ - ce domaine s'auto détruira prochainement...) qui n'a jamais abouti vraiment vu les résultats obtenus (et y'a https://github.com/librespeed/speedtest pour ceux qui veulent un test HTML5 open source & complet).
L'url sera https://nspeed.app/ et le projet sur github (projet privé pour le moment). Mais apres chacun peut hoster son build (testdebit.info notamment).
(pour ceux qui auront deviné j'ai un projet derriere plus important de service en ligne pour récolter et presenter des graphes historisés de mesures a ceux qui veulent faire tourner le client en permanence chez eux mais ca c'est l'étape 4).
-
J'avais plus dans l'idée de développer un testeur de débit en peer-to-peer pour ne plus être dépendant d'un seul serveur par test.
c'est le but a la base: pouvoir faire un test avec plusieurs serveurs en meme temps. Apres que ces serveurs soit dédiés a ca, pas dédiés a ca ou chez un particulier ou pas c'est un détail.
l'idée: tu fais une liste d'url a télécharger. par exemple:
A: https://bouygues.testdebit.info/1G/1G.iso
B: http://ubuntu.mirrors.ovh.net/ubuntu-releases/19.10/ubuntu-19.10-live-server-amd64.iso
C: https://dl.google.com/android/studio/maven-google-com/stable/offline-gmaven-stable.zip
puis pour chaque url tu peux choisir combien d'exemplaires a télécharger en meme temps voir enchainer des flux: 4 fois A en meme temps que B 4 fois a la suite en meme temps que 2 C a la suite.
ca fait donc dans le temps:
A.................
A.................
A.................
A.................
B...B...B...B...
C.......C........
soit 6 flux en meme temps (qui finissent pas forcement en meme temps) vers 3 serveurs différents.
Pour chaque flux on aura le débit instantané et moyen avec un graphe de l'ensemble et le max et la moyenne total ainsi que la latence de chaque flux.
On peut optionnellement mettre un temps maxi par flux, un temps maxi total et un volume maxi par flux et maxi total.
Avec ce type de schéma on couvre pas mal de tests possibles d'autant qu'un peut faire des GET et des POST en meme temps. Donc on peut aussi tester l'envoi en meme temps que la réception.
Ceci permet de comparer les FAI sur le peering aussi et pas que sur le débit final.
En ligne de commande on peut donc passer des url :
nspeed.exe --get https://bouygues.testdebit.info/1G/1G.iso,4 --get http://ubuntu.mirrors.ovh.net/ubuntu-releases/19.10/ubuntu-19.10-live-server-amd64.iso,4x --get http://ubuntu.mirrors.ovh.net/ubuntu-releases/19.10/ubuntu-19.10-live-server-amd64.iso,2
Mais l'idée ensuite est proposer des tests préparés a l'avance pour simplifier les choses pour les utilisateurs novices:
nspeed.exe --test https://nspeed.app/nspeed/test1.ns(vous pouvez ouvrir test1.ns sans risque c'est un fichier texte).
Pour le P2P quand on sera a l'étape 3: les serveurs nspeed peuvent tres bien s'annoncer quelque part pour "s'offrir" en serveurs de test (avec une limite de BP et temps par exemple). du coup on pourra avoir un "url centrale" qui fera un sorte de "reverse proxy load balancer" vers tout les participants, a l'instar d'un tracker torrent.
voici c'est l'idée 'sur le papier' pour le moment , ca peut changer quand la réalité va frapper ;)
-
Très intéressant comme projet mais je me demande si c'est pas un peut le principe d'un accélérateur de téléchargement avec affichage des statistiques du traffic généré et agrégé une fois que tout les téléchargements sont effectués ce que tu veux faire....
En effet, Internet Download Manager (IDM pour les intimes) permet de télécharger en mono/multi flux, avec des limites de vitesse (pour faire une QOS éventuelle pour les petits débits) et de créer des listes de téléchargements qui lancent les téléchargements l'un après l'autre (dès que fini, le suivant se lance), avec Schudele ou alors à l'envie si je veux que le PDF de 2Mo soit téléchargé immédiatement.
(https://appspourpc.com/wp-content/uploads/2018/08/Internet-Download-Manager-img.jpg)
À noter que ADM, son pendant sous Android fait pratiquement la même chose :
(https://imag.malavida.com/mvimgbig/download-fs/advanced-download-manager-23136-5.jpg)
Et en appuyant sur le petit graphique dans le menu ADM on a même des stats de traffic 🤣
-
Avec un accélérateur de téléchargement il est impossible d'envoyer les flux vers /dev/null et on est donc limité par la vitesse du SSD.
Maintenant le débit monothread me semble aussi intéressant car un bon réseau qui proposer 1 Gb/s doit proposer un débit monothread à 1 Gb/s quand tout se passe bien.
En 10 Gb/s, c'est plus compliqué pour plusieurs raisons (quand il y a un LAG de n liens 10 Gb/s, les connexions TCP sont réparties entre les différents liens et une seule connexion ne peut utiliser qu'un seul lien 10 Gb/s. L'utilisateur n'étant pas seul sur le lag, il va voir son débit monothread limité)
Pour les tests en multithread, on voit que l'utilisation de l'algorithme BBR peut faire chuter le débit.
(https://lafibre.info/images/free_debit/202001_comparatif_bubic_bbr_1.png)
BBR est par contre bon en monothread :
(https://lafibre.info/images/free_debit/202001_comparatif_bubic_bbr_2.png)
-
oui les accélérateurs de téléchargement ca existe déja notamment aria2 (https://github.com/aria2/aria2) en ligne de commande.
Comme souligne Vivien le souci c'est qu'ils ne peuvent sauvegarder vers /dev/null.
aria2 était un bon candidat de départ pour ce projet d'ailleurs mais il faut se plonger dans le code d'un autre et il est assez complexe.
L'idée de base est aussi de faire un outil simple d'utilisation pour les novices (interface 'un bouton' pas plus) mais avec des options avancées pour les experts.
-
petit update: j'avance sur le concept et l'archi générale du projet (étapes, composants a trouver, code a développer). J'étais en vacances pendant 2 semaines donc pas de code produit ;D
Je m'y remet des lundi.
J’essaierai de faire un point hebdo tout les lundis par exemple.
En attendant si quelqu'un pouvait compiler une liste d'url interresants a utiliser par nspeed, par exemple:
https://bouygues.testdebit.info/1G/1G.iso (plus toute ces variantes)
http://ubuntu.mirrors.ovh.net/ubuntu-releases/19.10/ubuntu-19.10-live-server-amd64.iso
https://dl.google.com/android/studio/maven-google-com/stable/offline-gmaven-stable.zip
Il y a sans doute les miroirs des distros, des gros binaires sur github, peut-etre des données open data , etc
Pour chacun il serait bien d'avoir la taille , le type de protocole supporter par le serveur (http 1.1, 2, quic, 3) et chiffrement ou pas.
On manque surtout d'url pour faire des 'POST' (test upload).
Le projet est la : https://github.com/kgersen/nspeed . Vous pouvez vous abonnez ('watch') pour suivre les évolutions ('releases only' pour être notifié des nouveaux binaires quand dispo.).
Vous pouvez ouvrir des 'issues' pour faire des suggestions/demandes.
-
My 2 cents sur le sujet sur github ;)
Attention aussi aux liens de type GOOGLE qui sont souvent en CDN...
-
La liste des miroirs Ubuntu es disponible sur :
- CD : https://launchpad.net/ubuntu/+cdmirrors
- Archive : https://launchpad.net/ubuntu/+archivemirrors
Il y a en effet des fichiers de plus de 1 Go sur le miroir :
$ find /home/ubuntu-archive/ -size +1G
/home/ubuntu-archive/ubuntu/pool/universe/t/texlive-extra/texlive-extra_2019.20190710.orig.tar.xz
/home/ubuntu-archive/ubuntu/pool/universe/t/texlive-extra/texlive-extra_2017.20180305.orig.tar.xz
/home/ubuntu-archive/ubuntu/pool/universe/t/texlive-extra/texlive-extra_2019.202000218.orig.tar.xz
/home/ubuntu-archive/ubuntu/pool/universe/t/texlive-extra/texlive-extra_2018.20190227.orig.tar.xz
/home/ubuntu-archive/ubuntu/pool/universe/f/flightgear-data/flightgear-data_3.4.0+dfsg.orig.tar.bz2
/home/ubuntu-archive/ubuntu/pool/universe/f/flightgear-data/flightgear-data_2018.1.1+dfsg.orig.tar.bz2
/home/ubuntu-archive/ubuntu/pool/universe/f/flightgear-data/flightgear-data-base_2019.1.1+dfsg-1_all.deb
/home/ubuntu-archive/ubuntu/pool/universe/f/flightgear-data/flightgear-data_2019.1.1+dfsg.orig.tar.bz2
/home/ubuntu-archive/ubuntu/pool/universe/f/flightgear-data/flightgear-data-base_2018.3.2+dfsg-1_all.deb
/home/ubuntu-archive/ubuntu/pool/universe/f/flightgear-data/flightgear-data_3.0.0.orig.tar.bz2
/home/ubuntu-archive/ubuntu/pool/universe/f/flightgear-data/flightgear-data_2018.3.2+dfsg.orig.tar.bz2
/home/ubuntu-archive/ubuntu/pool/universe/c/ceph/ceph-test-dbg_10.2.11-0ubuntu0.16.04.2_i386.deb
/home/ubuntu-archive/ubuntu/pool/universe/c/ceph/ceph-test-dbg_10.1.2-0ubuntu1_amd64.deb
/home/ubuntu-archive/ubuntu/pool/universe/c/ceph/ceph-test-dbg_10.1.2-0ubuntu1_i386.deb
/home/ubuntu-archive/ubuntu/pool/universe/c/ceph/ceph-test-dbg_10.2.11-0ubuntu0.16.04.2_amd64.deb
/home/ubuntu-archive/ubuntu/pool/multiverse/n/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.1.243.orig-ppc64el.tar.xz
/home/ubuntu-archive/ubuntu/pool/multiverse/n/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.1.243.orig-amd64.tar.xz
/home/ubuntu-archive/ubuntu/pool/multiverse/n/nvidia-cuda-toolkit/nvidia-cuda-toolkit_9.1.85.orig.tar.gz
/home/ubuntu-archive/ubuntu/pool/multiverse/n/nvidia-cuda-toolkit/nvidia-cuda-toolkit_5.5.22.orig.tar.gz
/home/ubuntu-archive/ubuntu/pool/multiverse/n/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.1.168.orig-ppc64el.tar.xz
/home/ubuntu-archive/ubuntu/pool/multiverse/n/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.1.105.orig-ppc64el.tar.xz
/home/ubuntu-archive/ubuntu/pool/multiverse/n/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.1.105.orig-amd64.tar.xz
/home/ubuntu-archive/ubuntu/pool/multiverse/n/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.1.168.orig-amd64.tar.xz
Maintenant ce n'est pas trop fait pour tester les débits ces serveurs.
-
le niveau de compression doit être de 100% en plus ;)
-
My 2 cents sur le sujet sur github ;)
Attention aussi aux liens de type GOOGLE qui sont souvent en CDN...
Les 'issues' github c'est plus pour ouvrir des bugs & demandes d'amélioration 'précises' (une fonctionnalité bien précise par exemple). Pour commentaires plus général ou liste de serveurs utilisons ce sujet ici.
Je ne vois pas trop le rapport entre www.willemijns.com/faqspeed.htm et le sujet des urls ou j'ai loupé un truc.
-
willemijns a développé en 2006 un script de test de débit qui utilise pleins de serveurs distincts en parallèle (vivilproject). Il va télécharger sur pleins de serveurs FTP des fichiers en parallèle, pour saturer la connexion.
-
ah ok oui je ne voyais pas la liste des url , il faut scroller bien bas pour les voir. Le début n'est qu'une liste de speedtest et je m'étais arrêté la.
-
vivien, ce truc est désactivé depuis 2 mois ;) les MAJ interne de listes foiraient et j'avais developpé depuis 1 an des scripts linux privés donc j'ai sabordé le tout.
il y a 15 ans j'utilisais les serveurs FTP des mirrors de distro linux mais ce temps là est dépassé...
se baser sur dl.google.fr qui est un mega-CDN c'est pas logique.
oui la liste que j'ai donné contient plus dans le bas des dizaines et des dizaines de site de tests comme test-debit.free.fr il y a dedans par exemple https://speed.hetzner.de/10GB.bin qui est l'un des 4 ou 5 webhosters allemand les plus connus.
Je conseille toujours et encore des fichiers incompressibles (et vivien m'appuiera sur cela on en a déjà parlé sur ce forum) pas des fichiers remplis de 0. j'ai AUCUN serveur de test de ce type dans mes scripts internes.
Idem quand ca pue le CDN à plein nez.
-
Je ne vois pas le souci avec les '0' et les CDN dans le cadre de ce projet. Ca concerne plus les outils plus haut niveau comme un navigateur par exemple.
-
Je ne vois pas le souci avec les '0' et les CDN dans le cadre de ce projet. Ca concerne plus les outils plus haut niveau comme un navigateur par exemple.
pour les 0 ils peuvent être compréssés à un moment ou à un autre... surtout si ca passe dans des tunnels type VPN
pour les CDN c'est parce que on ne connait pas facilement le lieu ou est le serveur exactement.
et pour finir dans mes remarques que j'avais faites dans github, ne pas diffuser un outil qui puisse être
trop puissant et être utilisable 24/7 ;)
-
J'ai mis une v0.1 en ligne: https://nspeed.app/nspeed-client/v0.1/ si vous voulez tester rapidement.
C'est un version minimaliste qui prend en paramètre des urls et les téléchargent en parallele.
par exemple (sous Linux):
./nspeed-client https://ipv4.bouygues.testdebit.info/1G/1G.iso https://ipv4.bouygues.testdebit.info/1G/1G.iso https://ipv4.scaleway.testdebit.info/1G/1G.iso
va télécharger en meme temps les 3 url (dont 2 fois le meme).
Il n'y a pour le moment qu'une option " -quiet" ou "--quiet" qui supprime l'affichage de la progression:
par exemple (sous Windows):
.\nspeed-client.exe --quiet https://ipv4.bouygues.testdebit.info/1G/1G.iso
Spawning download of https://ipv4.bouygues.testdebit.info/1G/1G.iso index 1
time = 8.4945774s size = 1000000000 for https://ipv4.bouygues.testdebit.info/1G/1G.iso index 1 bps: 941777280
Download Finished
Je n'ai pas de Mac pour tester mais comme c'est écrit en Go j'ai généré un binaire pour Mac.
J'ai un travail de rédaction et de documentation à faire avant de mettre le code source et la 'todo' list en ligne sur github. J’espère d'ici demain soir.
-
Petit test.
Chrome qui pleure :)
(https://pix.milkywan.fr/8VXec7L4.png)
D:\Users\admin\Downloads>nspeed-client.exe --quiet https://ipv4.bouygues.testdebit.info/1G/1G.iso
Spawning download of https://ipv4.bouygues.testdebit.info/1G/1G.iso index 1
time = 13.7498069s size = 1000000000 for https://ipv4.bouygues.testdebit.info/1G/1G.iso index 1 bps: 581826352
Download Finished
-
oui et c'est un binaire non signé pour le moment.
-
un "chmod +x nspeed-client" sous linux n'est pas de trop ;)
ca va où les fichiers temp ? si on arrete par CTRL+C tu les vires ?
-
Cela va vers /dev/null sinon on serait limité par les accès disques, qui sont souvent moins performant que la connexion internet.
Avec mon accès 100 Mb/s câble SFR :
C'est étonnant, en testant Bouygues (serveur Cubic) et Scaleway (serveur BBR), c'est Bouygues qui termine en premier :
$ ./nspeed-client https://bouygues.testdebit.info/100M.iso https://scaleway.testdebit.info/100M.iso
Spawning download of https://bouygues.testdebit.info/100M.iso index 1
Spawning download of https://scaleway.testdebit.info/100M.iso index 2
2 ; 1 ; 11 MB ; 100 MB ; 8192 ; https://scaleway.testdebit.info/100M.iso
1 ; 1 ; 2.4 MB ; 100 MB ; 8192 ; https://bouygues.testdebit.info/100M.iso
1 ; 2 ; 8.5 MB ; 100 MB ; 8192 ; https://bouygues.testdebit.info/100M.iso
2 ; 2 ; 17 MB ; 100 MB ; 8192 ; https://scaleway.testdebit.info/100M.iso
1 ; 3 ; 20 MB ; 100 MB ; 8192 ; https://bouygues.testdebit.info/100M.iso
2 ; 3 ; 18 MB ; 100 MB ; 8192 ; https://scaleway.testdebit.info/100M.iso
1 ; 4 ; 31 MB ; 100 MB ; 8192 ; https://bouygues.testdebit.info/100M.iso
2 ; 4 ; 18 MB ; 100 MB ; 8192 ; https://scaleway.testdebit.info/100M.iso
1 ; 5 ; 43 MB ; 100 MB ; 8192 ; https://bouygues.testdebit.info/100M.iso
2 ; 5 ; 18 MB ; 100 MB ; 8192 ; https://scaleway.testdebit.info/100M.iso
1 ; 6 ; 55 MB ; 100 MB ; 8192 ; https://bouygues.testdebit.info/100M.iso
2 ; 6 ; 18 MB ; 100 MB ; 8192 ; https://scaleway.testdebit.info/100M.iso
1 ; 7 ; 66 MB ; 100 MB ; 8192 ; https://bouygues.testdebit.info/100M.iso
2 ; 7 ; 18 MB ; 100 MB ; 8192 ; https://scaleway.testdebit.info/100M.iso
1 ; 8 ; 78 MB ; 100 MB ; 8192 ; https://bouygues.testdebit.info/100M.iso
2 ; 8 ; 18 MB ; 100 MB ; 8192 ; https://scaleway.testdebit.info/100M.iso
1 ; 9 ; 90 MB ; 100 MB ; 8192 ; https://bouygues.testdebit.info/100M.iso
2 ; 9 ; 18 MB ; 100 MB ; 8192 ; https://scaleway.testdebit.info/100M.iso
time = 9.823932294s size = 100000000 for https://bouygues.testdebit.info/100M.iso index 1 bps: 81433785
2 ; 10 ; 18 MB ; 100 MB ; 8192 ; https://scaleway.testdebit.info/100M.iso
2 ; 11 ; 26 MB ; 100 MB ; 8192 ; https://scaleway.testdebit.info/100M.iso
2 ; 12 ; 38 MB ; 100 MB ; 8192 ; https://scaleway.testdebit.info/100M.iso
2 ; 13 ; 50 MB ; 100 MB ; 8192 ; https://scaleway.testdebit.info/100M.iso
2 ; 14 ; 62 MB ; 100 MB ; 8192 ; https://scaleway.testdebit.info/100M.iso
2 ; 15 ; 74 MB ; 100 MB ; 8192 ; https://scaleway.testdebit.info/100M.iso
2 ; 16 ; 86 MB ; 100 MB ; 8192 ; https://scaleway.testdebit.info/100M.iso
2 ; 17 ; 98 MB ; 100 MB ; 8192 ; https://scaleway.testdebit.info/100M.iso
time = 17.187530831s size = 100000000 for https://scaleway.testdebit.info/100M.iso index 2 bps: 46545371
Download Finished
Idem avec K-Net (BBR) et Bouygues (Cubic) :
$ ./nspeed-client https://k-net.testdebit.info/100M.iso https://bouygues.testdebit.info/100M.iso
Spawning download of https://k-net.testdebit.info/100M.iso index 1
Spawning download of https://bouygues.testdebit.info/100M.iso index 2
1 ; 1 ; 11 MB ; 100 MB ; 8192 ; https://k-net.testdebit.info/100M.iso
2 ; 1 ; 2.3 MB ; 100 MB ; 8192 ; https://bouygues.testdebit.info/100M.iso
2 ; 2 ; 9.4 MB ; 100 MB ; 8192 ; https://bouygues.testdebit.info/100M.iso
1 ; 2 ; 16 MB ; 100 MB ; 8192 ; https://k-net.testdebit.info/100M.iso
2 ; 3 ; 20 MB ; 100 MB ; 8192 ; https://bouygues.testdebit.info/100M.iso
1 ; 3 ; 17 MB ; 100 MB ; 8192 ; https://k-net.testdebit.info/100M.iso
2 ; 4 ; 32 MB ; 100 MB ; 8192 ; https://bouygues.testdebit.info/100M.iso
1 ; 4 ; 17 MB ; 100 MB ; 8192 ; https://k-net.testdebit.info/100M.iso
2 ; 5 ; 44 MB ; 100 MB ; 8192 ; https://bouygues.testdebit.info/100M.iso
1 ; 5 ; 17 MB ; 100 MB ; 8192 ; https://k-net.testdebit.info/100M.iso
2 ; 6 ; 56 MB ; 100 MB ; 8192 ; https://bouygues.testdebit.info/100M.iso
1 ; 6 ; 17 MB ; 100 MB ; 8192 ; https://k-net.testdebit.info/100M.iso
2 ; 7 ; 68 MB ; 100 MB ; 8192 ; https://bouygues.testdebit.info/100M.iso
1 ; 7 ; 17 MB ; 100 MB ; 8192 ; https://k-net.testdebit.info/100M.iso
2 ; 8 ; 80 MB ; 100 MB ; 8192 ; https://bouygues.testdebit.info/100M.iso
1 ; 8 ; 17 MB ; 100 MB ; 8192 ; https://k-net.testdebit.info/100M.iso
2 ; 9 ; 91 MB ; 100 MB ; 8192 ; https://bouygues.testdebit.info/100M.iso
1 ; 9 ; 17 MB ; 100 MB ; 8192 ; https://k-net.testdebit.info/100M.iso
time = 9.729989222s size = 100000000 for https://bouygues.testdebit.info/100M.iso index 2 bps: 82220029
1 ; 10 ; 18 MB ; 100 MB ; 8192 ; https://k-net.testdebit.info/100M.iso
1 ; 11 ; 30 MB ; 100 MB ; 8192 ; https://k-net.testdebit.info/100M.iso
1 ; 12 ; 42 MB ; 100 MB ; 8192 ; https://k-net.testdebit.info/100M.iso
1 ; 13 ; 54 MB ; 100 MB ; 8192 ; https://k-net.testdebit.info/100M.iso
1 ; 14 ; 66 MB ; 100 MB ; 8192 ; https://k-net.testdebit.info/100M.iso
1 ; 15 ; 78 MB ; 100 MB ; 8192 ; https://k-net.testdebit.info/100M.iso
1 ; 16 ; 89 MB ; 100 MB ; 8192 ; https://k-net.testdebit.info/100M.iso
time = 16.890127996s size = 100000000 for https://k-net.testdebit.info/100M.iso index 1 bps: 47364945
Download Finished
-
Bonjour, petit essai rapide juste pour tester. A savoir qu'il y a le décodeur qui fonctionne, un Netflix dans une chambre et une PS4 en jeu online dan sune autre qui tournent en même temps.
stylou@lynx:~/bin$ ./nspeed-client https://ipv4.bouygues.testdebit.info/1G/1G.iso https://ipv4.scaleway.testdebit.info/1G/1G.iso
Spawning download of https://ipv4.bouygues.testdebit.info/1G/1G.iso index 1
Spawning download of https://ipv4.scaleway.testdebit.info/1G/1G.iso index 2
1 ; 1 ; 72 MB ; 1.0 GB ; 8192 ; https://ipv4.bouygues.testdebit.info/1G/1G.iso
2 ; 1 ; 36 MB ; 1.0 GB ; 8192 ; https://ipv4.scaleway.testdebit.info/1G/1G.iso
1 ; 2 ; 130 MB ; 1.0 GB ; 8192 ; https://ipv4.bouygues.testdebit.info/1G/1G.iso
2 ; 2 ; 73 MB ; 1.0 GB ; 8192 ; https://ipv4.scaleway.testdebit.info/1G/1G.iso
1 ; 3 ; 196 MB ; 1.0 GB ; 8192 ; https://ipv4.bouygues.testdebit.info/1G/1G.iso
2 ; 3 ; 112 MB ; 1.0 GB ; 8192 ; https://ipv4.scaleway.testdebit.info/1G/1G.iso
1 ; 4 ; 269 MB ; 1.0 GB ; 8192 ; https://ipv4.bouygues.testdebit.info/1G/1G.iso
2 ; 4 ; 151 MB ; 1.0 GB ; 8192 ; https://ipv4.scaleway.testdebit.info/1G/1G.iso
1 ; 5 ; 346 MB ; 1.0 GB ; 8192 ; https://ipv4.bouygues.testdebit.info/1G/1G.iso
2 ; 5 ; 191 MB ; 1.0 GB ; 8192 ; https://ipv4.scaleway.testdebit.info/1G/1G.iso
1 ; 6 ; 422 MB ; 1.0 GB ; 8192 ; https://ipv4.bouygues.testdebit.info/1G/1G.iso
2 ; 6 ; 231 MB ; 1.0 GB ; 8192 ; https://ipv4.scaleway.testdebit.info/1G/1G.iso
1 ; 7 ; 502 MB ; 1.0 GB ; 8192 ; https://ipv4.bouygues.testdebit.info/1G/1G.iso
2 ; 7 ; 268 MB ; 1.0 GB ; 8192 ; https://ipv4.scaleway.testdebit.info/1G/1G.iso
1 ; 8 ; 579 MB ; 1.0 GB ; 8192 ; https://ipv4.bouygues.testdebit.info/1G/1G.iso
2 ; 8 ; 306 MB ; 1.0 GB ; 8192 ; https://ipv4.scaleway.testdebit.info/1G/1G.iso
1 ; 9 ; 633 MB ; 1.0 GB ; 8192 ; https://ipv4.bouygues.testdebit.info/1G/1G.iso
2 ; 9 ; 347 MB ; 1.0 GB ; 8192 ; https://ipv4.scaleway.testdebit.info/1G/1G.iso
1 ; 10 ; 696 MB ; 1.0 GB ; 8192 ; https://ipv4.bouygues.testdebit.info/1G/1G.iso
2 ; 10 ; 386 MB ; 1.0 GB ; 8192 ; https://ipv4.scaleway.testdebit.info/1G/1G.iso
1 ; 11 ; 766 MB ; 1.0 GB ; 8192 ; https://ipv4.bouygues.testdebit.info/1G/1G.iso
2 ; 11 ; 423 MB ; 1.0 GB ; 8192 ; https://ipv4.scaleway.testdebit.info/1G/1G.iso
1 ; 12 ; 842 MB ; 1.0 GB ; 8192 ; https://ipv4.bouygues.testdebit.info/1G/1G.iso
2 ; 12 ; 460 MB ; 1.0 GB ; 8192 ; https://ipv4.scaleway.testdebit.info/1G/1G.iso
1 ; 13 ; 920 MB ; 1.0 GB ; 8192 ; https://ipv4.bouygues.testdebit.info/1G/1G.iso
2 ; 13 ; 499 MB ; 1.0 GB ; 8192 ; https://ipv4.scaleway.testdebit.info/1G/1G.iso
1 ; 14 ; 981 MB ; 1.0 GB ; 8192 ; https://ipv4.bouygues.testdebit.info/1G/1G.iso
2 ; 14 ; 536 MB ; 1.0 GB ; 8192 ; https://ipv4.scaleway.testdebit.info/1G/1G.iso
time = 14.389557312s size = 1000000000 for https://ipv4.bouygues.testdebit.info/1G/1G.iso index 1 bps: 555958729
2 ; 15 ; 573 MB ; 1.0 GB ; 8192 ; https://ipv4.scaleway.testdebit.info/1G/1G.iso
2 ; 16 ; 610 MB ; 1.0 GB ; 8192 ; https://ipv4.scaleway.testdebit.info/1G/1G.iso
2 ; 17 ; 649 MB ; 1.0 GB ; 8192 ; https://ipv4.scaleway.testdebit.info/1G/1G.iso
2 ; 18 ; 687 MB ; 1.0 GB ; 8192 ; https://ipv4.scaleway.testdebit.info/1G/1G.iso
2 ; 19 ; 724 MB ; 1.0 GB ; 8192 ; https://ipv4.scaleway.testdebit.info/1G/1G.iso
2 ; 20 ; 762 MB ; 1.0 GB ; 8192 ; https://ipv4.scaleway.testdebit.info/1G/1G.iso
2 ; 21 ; 798 MB ; 1.0 GB ; 8192 ; https://ipv4.scaleway.testdebit.info/1G/1G.iso
2 ; 22 ; 835 MB ; 1.0 GB ; 8192 ; https://ipv4.scaleway.testdebit.info/1G/1G.iso
2 ; 23 ; 874 MB ; 1.0 GB ; 8192 ; https://ipv4.scaleway.testdebit.info/1G/1G.iso
2 ; 24 ; 914 MB ; 1.0 GB ; 8192 ; https://ipv4.scaleway.testdebit.info/1G/1G.iso
2 ; 25 ; 955 MB ; 1.0 GB ; 8192 ; https://ipv4.scaleway.testdebit.info/1G/1G.iso
2 ; 26 ; 994 MB ; 1.0 GB ; 8192 ; https://ipv4.scaleway.testdebit.info/1G/1G.iso
time = 26.141402571s size = 1000000000 for https://ipv4.scaleway.testdebit.info/1G/1G.iso index 2 bps: 306027956
Download Finished
-
ca va où les fichiers temp ? si on arrete par CTRL+C tu les vires ?
y'a pas de fichiers temporaires ni même d'écriture sur '/dev/null' car écrire sur /dev/null c'est des appels systèmes coûteux en cpu. Tout ce passe en mémoire avec en principe un minimum de consommation mémoire.
Cela va vers /dev/null sinon on serait limité par les accès disques, qui sont souvent moins performant que la connexion internet.
Avec mon accès 100 Mb/s câble SFR :
C'est étonnant, en testant Bouygues (serveur Cubic) et Scaleway (serveur BBR), c'est Bouygues qui termine en premier :[/size]
oui j'ai remarqué que scaleway.testdebit.info fait pas mal de yoyo ... même en solo connexion on n'a pas toujours 940+ Mbps sur une connection 1 Gbps. Mais c'est pareil avec curl.
-
petit update:
- mon temps dispo est très réduit en ce moment, a peine quelques heures par semaine. Mais d'ici la fin du mois/début mai je devrais pouvoir consacrer 100% de mon temps a ce projet et ce jusqu'en septembre voir plus.
- le langage retenu est donc Go. principalement pour sa maturité et la facilité de son aspect multi-plateforme .
- j'ai mis sur github dans la partie 'projet' ce sur quoi je me focalise en ce moment('in progress') et ce qu'il reste à faire pour la phase 1 ('todo'): https://github.com/kgersen/nspeed/projects/1
La section 'todo' n'est pas figée et pourra évoluer en fonction des remarques faites ici.
- le dossier 'research' ( https://github.com/kgersen/nspeed/tree/master/research ) contient des bouts de code, des notes, etc pour certains aspects du projet. ceci évoluera au fur et a mesure.
Il y a 2 sous parties importantes a finaliser en terme d'étude pour la P1:
- comment obtenir l'interface réseau utilisée (ou les interfaces dans des cas plus rares), son type et ses caractéristiques (ethernet, wifi, débit max, etc) et comment mesurer le crosstalk sur cette interface
- comment obtenir la charge cpu pendant le test, par cpu, par coeur, pour le process nspeed, pour tout l'OS ? idéalement obtenir aussi les specs de la machine (type cpu, mémoire, etc).
Ces 2 parties sont par nature différentes d'un OS a l'autre. Il faut donc soit trouver du code existant multiplate-forme qui fait déjà cela soit développer du nouveau code soit combiner avec du code existant spécifique a une plateforme.
Par exemple pour le CPU il y a peut-etre https://github.com/shirou/gopsutil mais je n'ai pas encore évalué cette lib. Si quelqu'un connait ou veut faire des tests avec c'est le moment.
Pour l'interface et le crosstalk je vois comment faire en théorie, notamment avec Windows et Linux (Mac aucune idée). J'ai mis un script shell qui permet d'avoir le crosstalk d'un curl sous Linux: https://github.com/kgersen/nspeed/blob/master/research/p1/crosstalk_linux.sh
par exemple:
sh crosstalk_linux.sh <url>va télécharger avec curl l'url et afficher le crosstalk (en principe...).
Le script utilise 'ip route get' pour trouver l'interface mais appeler la commande Linux 'ip' depuis un programme en Go n'est pas recommandé car cette commande n'est pas forcement dispo sur tous les variantes de Linux par défaut. Du coup une meilleur approche est de comprendre comment 'ip route' fonctionne et le refaire en Go ou trouver une lib qui fait deja cela.
Pour le crosstalk c'est de la lecture dans sysfs , un système de fichier virtuel exposant des éléments du kernel et a priori dispo sur tous les variantes de Linux/Unix (a vérifier).
par exemple:
cat /sys/class/net/eth0/statistics/rx_bytesAffiche le compteur instantané d'octets reçus de l'interface eth0. C'est facile a lire une fois qu'on a le nom de l'interface (eth0 ou autre).
Pour Windows c'est plus complexe car il faut passer par WMI a priori ou trouver les appels systèmes direct s'il y en a. Il y a un programme en Go que j'utilise, https://github.com/martinlindhe/wmi_exporter, qui permet de collecter les stats de Windows (cpu, disque, réseau,etc) pour Prometheus. Ce code peut servir d'inspiration pour cette partie (et pour le cpu aussi).
Pour la P2, j'ai plein d'idées mais rien de concret encore. Idem pour la P3 et P4 mais bien qu'on a le temps pour ca, n’hésitez a soumettre des idées car elles peuvent influer sur la façon donc la P1 est architecturée.
rappel:
P1: client nspeed en ligne de commande
P2: interface web 'locale' exposée par le client nspeed
P3: serveur nspeed
P4: backend nspeed. collecte, automation et présentation (=proposer des sondes nspeed, automatiser la collection des résultats, faire des graphes, etc).
Si vous n'est pas programmeur et souhaiter contribuer vous pouvez:
- trouver des idées/concepts d'interface pour P2 (ie ce qu'on appelle l’expérience utilisateur = UX. https://wireframe.cc/ permet de faire des esquisses rapidement ou https://moqups.com pour des choses plus poussées)
- trouver des URL a télécharger et les caractériser (en partant de la liste de willemijns par exemple). caractériser = localisation du DC ou situé le serveur , ip4/ipv6 , quel(s) version(s) d'http sont supportés, quel débit max peut-on obtenir au mieux, etc et faire des listes de tests
Pour les interactions plus instantanées j'ai crée un canal 'nspeed' sur le Discord non officiel de LaFibre: https://discord.gg/hWu2e4 mais c'est plus pour discuter des détails. Privilégier ce sujet pour les discussions de 'fond'.
-
J'updaterais mon fichier vers juin avec une version plus récente mais il y a déjà pas mal d'URLs pour se faire la main.
sinon Je réitère le souhait d'éjecter toute URL qui puisse être compressible. 10 milliards de caractères "X" pour faire un fichier de 10GB non merci !
-
A noter que les BBox permettent d’accéder a leur cross-talk directement, sans authentification aucune:
https://mabbox.bytel.fr/api/v1/wan/ip/stats
Ainsi que d'obtenir des infos détaillés sur la partie WAN (ip public, dns, type de connexion, sfp ou ont, adresse mac) ou la partie LAN (notamment les IP, le crosstalk et comment on est connecté a la box (wifi ou filaire)).
mais vu que c'est spécifique a un seul FAI ce ne sera pas utilisé par NSpeed de suite. Plus tard éventuellement sous forme de module optionnel.
-
v 0.2. dispo (changelog non dispo pour le moment principalement l'affichage d'info et le cpu via l'option --verbose)
Si des gens sous Windows peuvent tester ceci:
télécharger nspeed-client.exe. Sous powershell :
cd ~
iwr https://nspeed.app/nspeed-client/v0.2/Windows-x64/nspeed-client.exe -useb -outfile nspeed-client.exe(pour ouvrir powershell il suffit de clicker la loupe en bas a gauche (rechercher) et taper powershell)
ensuite (toujours dans la fenetre powershell):
test 1:
.\nspeed-client.exe --verbose https://bouygues.testdebit.info/1G/1G.iso
test 2:
.\nspeed-client.exe --verbose https://scaleway.testdebit.info/1G/1G.iso
Pendant ces tests, ayez le gestionnaire des taches ouvert, onglet performance et comparer les graphes par core avec les nombres affichés en début des lignes.
c'est juste pour savoir si la charge cpu est correctement remontée sous Windows.
exemple sur un NUC quad core:
max cores = 4
1 https://bouygues.testdebit.info/1G/1G.iso
1 size 1000000000 procolol HTTP/1.1 local IP:port 192.168.1.3:54900 remote IP:port 89.84.1.222:443
16 07 10 22 1 ; 1 ; 110.5 MB ; 953.7 MB ; 8192 ; https://ipv4.bouygues.testdebit.info/1G/1G.iso
07 06 01 06 1 ; 2 ; 222.6 MB ; 953.7 MB ; 8192 ; https://ipv4.bouygues.testdebit.info/1G/1G.iso
11 09 09 14 1 ; 3 ; 334.4 MB ; 953.7 MB ; 8192 ; https://ipv4.bouygues.testdebit.info/1G/1G.iso
07 05 05 05 1 ; 4 ; 446.4 MB ; 953.7 MB ; 8192 ; https://ipv4.bouygues.testdebit.info/1G/1G.iso
06 00 06 06 1 ; 5 ; 558.5 MB ; 953.7 MB ; 8192 ; https://ipv4.bouygues.testdebit.info/1G/1G.iso
02 02 11 05 1 ; 6 ; 670.6 MB ; 953.7 MB ; 8192 ; https://ipv4.bouygues.testdebit.info/1G/1G.iso
04 03 06 10 1 ; 7 ; 782.2 MB ; 953.7 MB ; 8192 ; https://ipv4.bouygues.testdebit.info/1G/1G.iso
18 09 16 27 1 ; 8 ; 894.1 MB ; 953.7 MB ; 8192 ; https://ipv4.bouygues.testdebit.info/1G/1G.iso
1 937.6 Mbps time = 8.532104149s size = 1000000000 url https://ipv4.bouygues.testdebit.info/1G/1G.iso
Download Finished
ps: ces nombres sont les pourcentages de charge pour chaque coeur (virtuel). ils vont entre 00 et 100 donc.
-
Ça semble OK.
Reste que les graphes côté Windows ne sont pas super précis.
nspeed m'indiquait au plus bas pour un CPU à 63% là où sur le graphe, il me semblait être aux environs de 80%.
-
max cores = 12
1 https://bouygues.testdebit.info/1G/1G.iso
1 size 1000000000 procolol HTTP/1.1 local IP:port 192.168.1.89:53179 remote IP:port 89.84.1.222:443
69 01 80 00 10 01 04 16 12 01 03 00 1 ; 1 ; 90.6 MB ; 953.7 MB ; 8192 ; https://bouygues.testdebit.info/1G/1G.iso
59 05 81 00 02 00 06 12 05 02 00 00 1 ; 2 ; 180.0 MB ; 953.7 MB ; 8192 ; https://bouygues.testdebit.info/1G/1G.iso
69 00 94 00 02 00 00 17 02 00 00 02 1 ; 3 ; 282.9 MB ; 953.7 MB ; 8192 ; https://bouygues.testdebit.info/1G/1G.iso
70 03 73 00 02 02 06 11 03 02 02 00 1 ; 4 ; 381.2 MB ; 953.7 MB ; 8192 ; https://bouygues.testdebit.info/1G/1G.iso
53 00 77 00 02 05 03 09 02 02 03 00 1 ; 5 ; 472.6 MB ; 953.7 MB ; 8192 ; https://bouygues.testdebit.info/1G/1G.iso
74 02 91 00 02 02 00 19 02 00 00 00 1 ; 6 ; 577.1 MB ; 953.7 MB ; 8192 ; https://bouygues.testdebit.info/1G/1G.iso
54 00 74 00 00 02 02 18 00 02 00 00 1 ; 7 ; 654.8 MB ; 953.7 MB ; 8192 ; https://bouygues.testdebit.info/1G/1G.iso
52 00 54 02 03 03 00 17 00 00 02 00 1 ; 8 ; 717.3 MB ; 953.7 MB ; 8192 ; https://bouygues.testdebit.info/1G/1G.iso
57 17 58 03 06 00 05 17 06 03 03 02 1 ; 9 ; 791.6 MB ; 953.7 MB ; 8192 ; https://bouygues.testdebit.info/1G/1G.iso
68 25 83 05 20 02 11 17 08 05 09 03 1 ; 10 ; 879.7 MB ; 953.7 MB ; 8192 ; https://bouygues.testdebit.info/1G/1G.iso
1 745.2 Mbps time = 10.7359135s size = 1000000000 url https://bouygues.testdebit.info/1G/1G.iso
Download Finished
Il voit bien le problème qu'il semble y avoir dans Windows sur ma machine (c'est du CPU consommé côté kernel) : le coeur 0 est toujours chargé à peu près de la même manière, mais parfois le coeur 2 est à 30% maximum, parfois il sature (et ça arrive aussi bien avec curl que nspeed).
Du coup ça pourrait être intéressant de mesurer séparément userspace et kernel.
-
Et sinon "procolol" ;D
-
ok merci pour ces retours.
Et sinon "procolol" ;D
;D
-
Dans mon cas, avec une Intel 82579V
Le reglage Interrupt Moderation Rate (Adaptive, Extreme, High, Low, Medium, Minimal, Off, présenté dans cet ordre) est par défaut en Adaptive, et ça fait n'importe quoi.
En Off, ça ne dépasse pas 60000 interruptions/s.
En Extreme, c'est 10000 interruptions par seconde (en plus du bruit de fond d'environ 6000 à 8000).
En Adaptive, ça peut être 30000, comme 150000 :o
Je vois ça avec "Interrupts delta" de Process Hacker.
Cette valeur semble pouvoir être récupérée même sans être admin, donc on pourrait la tracer pour donner des indices pour l'analyse des cas où la consommation CPU côté kernel est importante.
-
ouh le temps passe trop vite et j'ai slacké un peu ;D
@hwti merci pour les infos et désolé du délai
un petit point:
- J'ai eu des soucis avec mon serveur chez OVH, plusieurs attaques DDoS récurrentes et des tentatives de brute force ssh... du coup j'ai viré ce serveur et suis passé chez Github Pages pour l'hébergement du site avec en frontal Cloudflare pour la protection (et pour IPv6 car Github Pages ne fonctionne pas en IPv6!!).
- J'ai crée une organisation sur Github pour le projet de façon a ce qu'il ne dépende plus de mon pseudo et pour pouvoir inviter plus facilement des collaborateurs a l'avenir. Il y a pour le moment 3 dépôts: le projet nspeed lui-même, le contenu du site nspeed.app (pour Github Pages) et le source (Hugo (https://gohugo.io/)) de ce site web. L'organisation est : https://github.com/nspeed-app
- il y a aussi maintenant un email info@nspeed.app
- je dois mettre en place un CD/CI avant de republier les binaires. Cela me simplifiera grandement la tache plus tard. Cela va me prendre quelques jours. Ensuite je pourrai ensuite publier des itérations de façon plus fréquente.
- quand je serais proche de la v1.0 je publierai le code source.
Prochain point dans une semaine environ donc sauf événement d'ici la.
-
Bonjour kgersen,
Où en est le projet NSpeed et la v1.0 ?
-
C'est toujours en cours mais lent.
Pas mal de contretemps cet été et a l'autonome a cause d'autres projets.
Pas mal d'expérimentations avec Rust et C++ notamment et une tentative de faire un système a base de plugin qui s'est avéré peu convaincant.
Du coup retour a une version plus simple et saine. Go reste le bon choix pour le moment.
Janvier et février seront consacrés a NSpeed avec un nouveau hiatus en mars puis une reprise en juin.
Je donne peu d'info j'avoue après j'ai peu de demande aussi. sans doute un phénomène poule/œuf :)
Et si quelqu'un veut faire un logo je suis preneur.
-
Et si quelqu'un veut faire un logo je suis preneur.
Il faut surfer sur la vague de Need For Speed. Mais sans voiture par contre :)
(https://images.techhive.com/images/article/2016/01/super-fast-gigabit-internet-speed-100638058-primary.idge.jpg)
-
Pas mal d'expérimentations avec Rust et C++ notamment.
Des soucis avec Rust ? Ça me tenterais bien d’apprendre Rust avec un projet comme ça.
-
J'ai repris le dev hier mais pas de promesses donc j'annonce rien :)
Des soucis avec Rust ? Ça me tenterais bien d’apprendre Rust avec un projet comme ça.
Rust = trop complexe, pas mature et trop peu de fonctionnalités dans la 'standard library' ou trop peu de crates 'incontournables'.
Par exemple pour faire un truc comme NSpeed il faut utiliser le crate tokio et un crate http comme hyper.
Aucun de ses trucs n'est 'battle tested' comme la standard lib de Go qui offre serveur et client http utilisés a grand échelle dans des très gros projets qui tournent 7/24 depuis longtemps.
L'impression c'est que Rust c'est comme le noyau Linux, y'a un base minimal que tout le monde utilise et après c'est la foire au crates comme c'est la foire aux distro Linux. En plus la plupart des crates sont en version 0.X donc pas finies, sans parler de celles qui sont abandonnées passé l'effet de mode. Et faire dépendre son code d'une crate faite par un étudiant en IT qui est passé a autre chose après ses études ce n'est pas très pérenne quand même...
-
Je partage l'analyse sur Rust et je ne peux pas faire de comparaison avec Go car jamais codé dessus.
Mais sa complexité est relative comme tout nouveaux outils, pour la maturité, j'ai déjà eu des soucis avec hyper ou tokio qui faisaient crasher le programme suite a un 'too many open files' il y a quelques années mais qui sont résolu depuis.
Comme dis je ne peux pas comparer avec Go, mais j'aurais privilégié Rust.
-
Donc c'est plutôt crate tokio et un crate http qui posent problème et non Rust ?
-
Ce qu'il dit, c'est que Go offre les fonctionnalités dans sa librairie standard, alors que pour Rust il faut dépendre de code tiers.
Donc c'est une comparaison des écosystèmes, pas des languages.
-
la v0.4 est en ligne: https://dl.nspeed.app/nspeed-client/v0.4/
il y a beaucoup de changement et nouveautés: https://github.com/nspeed-app/nspeed#readme
principalement:
- ajout du 'put' (http post) pour tester l'upload
- options pour plusieurs flux en meme temps plutot que répéter le meme url plusieurs fois
- premiere version du serveur
Je n'ai pas trop testé sur Windows et pas du tout sur Mac.
Il y aura un build par semaine sauf besoin urgent de publier un fix.
-
Cet exemple marche pas...
./nspeed get https://bouygues.testdebit.info/10G/10G.iso https://scaleway.testdebit.info/10G/10G.iso
FATA[0000] unknown command https://scaleway.testdebit.info/10G/10G.iso
;)
-
Cet exemple marche pas...
./nspeed get https://bouygues.testdebit.info/10G/10G.iso https://scaleway.testdebit.info/10G/10G.iso
FATA[0000] unknown command https://scaleway.testdebit.info/10G/10G.iso
;)
c'est normal il manque un get ;) c'est corrigé
./nspeed get https://bouygues.testdebit.info/10G/10G.iso get https://scaleway.testdebit.info/10G/10G.iso
-
Pas mal ce soft, c'est que je cherchais pour générer des fichier à la volée.
On aura le choix de l'IPV4/6 dans les prochaines versions ?
Une version docker de prévue ?
-
Il est dit sur https://nspeed.app/about-nspeed/ :
NSpeed is high performance multi-threaded network bandwidth measurement tool.
It’s an open-source, free, for non profit, collaborative application.
Pourtant je ne trouve pas où sont les sources ?
-
Il est dit sur https://nspeed.app/about-nspeed/ :Pourtant je ne trouve pas où sont les sources ?
Les sources seront publiées au plus tard avec la 1.0.
Pour l'instant c'est un peu le fouillis dans le code et pas mal de refactoring est nécessaire pour avoir un truc présentable.
-
Pas mal ce soft, c'est que je cherchais pour générer des fichier à la volée.
On aura le choix de l'IPV4/6 dans les prochaines versions ?
Une version docker de prévue ?
oui pour ipv4/ipv6.
Pour docker vu que nspeed est un binaire unique il n'est pas prévu de publier une image Docker officielle de suite mais si y'a de la demande c'est simple à faire (et a terme on va utiliser https://goreleaser.com/ donc il sera simple d'ajouter Docker et il y aura également un Dockerfile pour build & run).
Apres le but étant de mesurer des débits il faut savoir qu'un conteneur peut impacter les performances cpu car par défaut il y a du NAT en IPv4 entre l’hôte et le conteneur donc si on cherche la perf, il vaut mieux "docker run --network host ...".
-
Sous Windows, les perfs en localhost avec le serveur sont limitées sur un thread, avec une forte consommation CPU côté kernel :
- 5,8Gbps en IPv6
- 4,4Gbps en IPv4
Un curl en client se débrouille mieux, même si bizarrement il commence à 6xxMo/s avant de monter à 1-1,2Go/s (suivant ce que Windows fait avec les différents cœurs on dirait).
WSL2 fait mieux aussi (serveur et client dedans), avec 8,9Gbps en IPv6 et 9,4Gbps en IPv4.
Au passage, quand on spécifie une IP, comme "nspeed get http://127.0.0.1:7333/g/10g", le log DNS est invalide :
DNSInfoTime = -2562047h47m16.854775808s
-
Sous Windows, les perfs en localhost avec le serveur sont limitées sur un thread, avec une forte consommation CPU côté kernel :
- 5,8Gbps en IPv6
- 4,4Gbps en IPv4
Un curl en client se débrouille mieux, même si bizarrement il commence à 6xxMo/s avant de monter à 1-1,2Go/s (suivant ce que Windows fait avec les différents cœurs on dirait).
WSL2 fait mieux aussi (serveur et client dedans), avec 8,9Gbps en IPv6 et 9,4Gbps en IPv4.
Au passage, quand on spécifie une IP, comme "nspeed get http://127.0.0.1:7333/g/10g", le log DNS est invalide :
merci du retour. Je vais faire des tests plus poussé sur Windows et rajouter des infos de diags.
pour le log DNS c'est normal pour le moment.
-
Sous Windows, les perfs en localhost avec le serveur sont limitées sur un thread, avec une forte consommation CPU côté kernel :
le serveur n'est pas trop opti pour le moment, mais y'a un paramètre pour passer la taille du buffering haut level: c'est 'chunk_size'.
donc par exemple:
nspeed get http://localhost:7333/g/10g?chunk_size=100k
par défaut chunk_size 10kiB (10 x 1024 bytes). Cela peut jouer surement sur les performances surtout avec la loopback.
pour l'upload il n'y a pas d'équivalent.
-
v0.5 disponible - https://dl.nspeed.app/nspeed-client/v0.5/ ou https://github.com/nspeed-app/nspeed/releases/tag/v0.5
il y a maintenant un changelog pour suivre l'évolution: https://github.com/nspeed-app/nspeed/blob/master/CHANGELOG.md
v0.5
general
- better usage help text
- better formatting in verbose mode (-verbose)
- parsed units allow now decimal precision ("2.2g")
server
- "-h" host option changed to "-a" (since "-h" is standard for help)
- default host is now "localhost"
- "-4" and "-6" options to use IPv4 or IPv6 only (must be consistent with "-a")
- the "-s" option can now parse units of bytes like the client (for instance: "-s 1g" for 1GB, "-s 1G" for 1GiB)
- the "-t" now parse seconds only instead of requiring a unit (consistent with client)
- route '/p' is also accepted instead of redirecting to '/p/'
- added name & version in a http response header
get & put
- "-4" and "-6" options are now working
- "-k" option to ignore certificate validation
- "-a host|interface|ip" option
known issues / caveats
- server: the default host is now 'localhost' which leads to bind only to IPv4 (Go bug: https://github.com/golang/go/issues/9334). A temporary workaround is to launch a second server instance with the -6 flag: `nspeed server server -6` will listen to localhost on IPv4 and IPv6. A fix will be implemented soon. Some OS can fail to resolve 'localhost' to ::1 even if they have IPv6 configured. In that case use "-a ::1" explicitly (`nspeed server server -a ::1`)
- put: redirect(s) happen after the upload which normal behavior for a HTTP POST.
- performance inconsistencies on Windows
- '-a "" ' doesn't parse on Windows, workaround: use '-a ::'
- server: '-a interface_name' bind to the first candidate address (ipv6/ipv4/link-local) found for that interface. It's not the same behavior as a bind with SO_BINDTODEVICE (which is platform specific).
- client: '-a interface_name' use the first candidate address (ipv6/ipv4/link-local) found for that interface. It doesn't perfom a source address selection depending on the destination.
on peut maintenant spécifier l'ip/interface source d'un get ou d'un put (option -a) ce qui permet sur une machine avec plusieurs cartes réseau de forcer un chemin réseau autre que la route par défaut.
Si quelqu'un derrière une livebox 5 avec 2 connexions lan ou plus sur la meme machine pouvait tester (avec 2 ports ethernet ou 1 port ethernet et le wifi par exemple):
nspeed get -a "interface 1" https://bouygues.testdebit.info/10G/10G.iso get -a "interface 2" https://bouygues.testdebit.info/10G/10G.iso
(sous Windows utiliser "get-netadapter" pour voir les noms des interfaces réseau).
ou derrière une Freebox Delta sur les ports 1G... ;)
prévisions pour la v0.6: API
- client: ajout d'une option: délais d'attente avant de lancer les transferts.
- server: ajout d' options: durée de vie du server et nombre de requetes max (généralisation du "-1" d'iperf3)
- api: gros morceau, il faut refactorer (https://fr.wikipedia.org/wiki/R%C3%A9usinage_de_code) le code, définir une API propre. Cet étape permettra ensuite d'avoir le mode 'agent' et l'UI web.
prévisions pour la v0.7: utilisation de l'API
- mode agent : lancer nspeed en mode agent permet a un nspeed maitre de le contrôler a distance. Ceci permettra d’effectuer des tests synchronisés et centralisés depuis plusieurs machines en même temps.
- UI web version basique: version simpliste sans chichi dans l'interface web
prévisions pour la v0.8: metrics & graphes
Le but de cette version est de produire des metrics dans un format standardisé. Pour le moment le candidat est https://openmetrics.io/ mais le sujet reste ouvert.
prévision pour la v0.10: hardware & crosstalk
- déterminer le hardware & OS de la machine (cartes réseaux, bus pci, autres logiciels tournant dans la machine, etc) et les caractéristiques en fonctionnement.
- relever les compteurs hardware avant, pendant et après un test
- éventuellement obtenir des infos de la passerelle et de son crosstalk ( a ce jour que les BBox de Bouygues permettent cela (https://api.bbox.fr/doc/apirouter/index.html#api-WAN-GetWANIPStats) ,l'API standardisé des box étant un désastre de la bureaucratie a la française...)
prévision pour la v0.11: ouverture du code en open-source
prévision pour la v0.12: HTTP/3 & WebRTC
prévision pour la v0.13: WebUI 2.0
-
- better usage help text
Le "--help" est bien, je pense qu'il faudrait avoir la même sortie quand on lance la commande sans arguments.
0 GET {URL: "http://bouygues.testdebit.info/10G.iso", IPversion: 0, Host: , Instance: 0, timeout: 8s}Peut-être "Address" à la place de Host, parce que c'est l'option "-a", et que Host pourrait faire penser au champ HTTP.
Le "-a interface" sous Windows semble choisir l'IPv4, est-ce normal ?
On peut forcer avec "-6", mais c'est bizarre que l'IPv6 ne soit pas en premier.
Sans l'option "-a", il préfère l'IPv6, probablement dans l'ordre des réponses DNS.
Pour l'argument vide pour l'option "-a", ça dépend du shell :
- cmd.exe :
nspeed_windows_amd64.exe server -a "" - PowerShell :
.\nspeed_windows_amd64.exe server -a '""'Sinon effectivement, "-a ::" fonctionne avec les deux.
-
Le "--help" est bien, je pense qu'il faudrait avoir la même sortie quand on lance la commande sans arguments.
oui c'est prévu avec l'arrivé de UI web qui conditionnera le comportement sans arguments.
0 GET {URL: "http://bouygues.testdebit.info/10G.iso", IPversion: 0, Host: , Instance: 0, timeout: 8s}Peut-être "Address" à la place de Host, parce que c'est l'option "-a", et que Host pourrait faire penser au champ HTTP.
C'est corrigé.
D'autant qu'ajouter des headers HTTP comme Host est prévu pour la suite.
Apres cet affichage est temporaire et sera revu entièrement avec les metrics.
Le "-a interface" sous Windows semble choisir l'IPv4, est-ce normal ?
On peut forcer avec "-6", mais c'est bizarre que l'IPv6 ne soit pas en premier.
Sans l'option "-a", il préfère l'IPv6, probablement dans l'ordre des réponses DNS.
Je n'ai pas testé sous Windows cette partie. Pour le moment on ne trie pas par version d'IP , on se contente de l'ordre retourné par l'OS mais c'est noté qu'il faut trier par version.
Apres "-a interface" a l'origine c'était pour ne bind que sur un interface comme fait SO_BINDTODEVICE sous Linux mais ceci étant spécifique a Linux et pas dans la stdlib de Go pour le moment je me content de retourner une des IP de l'interface ce qui ne fonctionne pas toujours bien. Plus tard une implémentation avec SO_BINDTODEVICE devrait venir.
Pour l'argument vide pour l'option "-a", ça dépend du shell :
- cmd.exe :
nspeed_windows_amd64.exe server -a "" - PowerShell :
.\nspeed_windows_amd64.exe server -a '""'Sinon effectivement, "-a ::" fonctionne avec les deux.
ah bien vu je n'utilise plus que powershell du coup j'ai pas penser a tester sous cmd.
"-a ::" plante avec -4 ce qui est normal. Du coup le bon équivalent serait '-a=""' (les options "ligne de commande" en Go acceptent "-a valeur" et "-a=valeur"). J'ai corrigé la doc en conséquence.
merci des retours.
-
Y'a un souci sous Windows, ca ne distribue pas sur tous les coeurs du cpu.
En attendant la v.06 il y a une 0.5interim: sur https://dl.nspeed.app/nspeed-client/v0.5interim/
qui permet de tester avec un meilleur affichage du cpu (option -verbose):
.\nspeed_windows_amd64.exe -verbose get -n 4 http://scaleway.testdebit.info/10G/10G.iso
on peut aussi tester le client et serveur ensemble (débit 'loopback' donc "pur cpu") grace a des nouvelles options:
.\nspeed_windows_amd64.exe -server -n 1 get -w 1 http://localhost:7333/g/10g
y'a clairement un souci mais si d'autres pouvaient confirmer cela sur Windows pour savoir si c'est général ou pas. merci.
-
Ca reste effectivement chargé en CPU, particulièrement en kernel.
Voici sur un i7 3930K à 4,1Ghz :
>nspeed_windows_amd64.exe -verbose server -n 1 get -w 1 http://localhost:7333/g/10g
Jobs:
0 server {Address: "localhost", port: 7333, IPversion: 0, max_size: 40.0 GB, max_request duration: 10000000000, UseTLS: false, maxruns: 1, max life: 0s}
1 {Command: GET, URL: "http://localhost:7333/g/10g", IPversion: 0, Address: , Instance: 0, timeout: 8s}
12:43AM INF nspeed listening on http://[::1]:7333 job=0
12:43AM INF waking up job=1
12:43AM INF | 3| 3| 4| 1| 0| 0| 0| 0| 0| 3| 0| 0|, active jobs: 2 / active goroutines: 6
12:43AM INF LocalAddr=[::1]:59672 RemoteAddr=[::1]:7333 job=1 protocol=HTTP/1.1
12:43AM INF | 2| 0| 0| 95| 5| 0| 5| 24| 0| 46| 3| 0|, active jobs: 2 / active goroutines: 10
12:43AM INF | 3| 3| 2| 36| 11| 0| 0| 0| 0| 92| 39| 2|, active jobs: 2 / active goroutines: 10
12:43AM INF | 3| 5| 5| 58| 14| 2| 2| 2| 2| 34| 69| 0|, active jobs: 2 / active goroutines: 10
12:43AM INF | 5| 6| 0| 80| 6| 0| 2| 14| 2| 0| 80| 2|, active jobs: 2 / active goroutines: 10
12:43AM INF | 0| 3| 3| 65| 6| 0| 0| 50| 0| 61| 2| 0|, active jobs: 2 / active goroutines: 10
12:43AM INF | 3| 13| 3| 47| 3| 0| 2| 72| 0| 0| 50| 0|, active jobs: 2 / active goroutines: 10
12:43AM INF | 3| 2| 5| 2| 5| 0| 0| 71| 0| 63| 44| 0|, active jobs: 2 / active goroutines: 10
12:43AM INF | 6| 5| 3| 11| 6| 3| 0| 64| 5| 0|100| 2|, active jobs: 2 / active goroutines: 10
12:43AM INF ReadBPS=5778172813 TotalRead=5776998400 TotalWrite=0 WriteBPS=0 duration=7.998374 job=0 url="download 10g to [::1]:59672"
12:43AM INF processed read:5776945152 / write: 0 bytes job=1
12:43AM INF 1 max total requests reached, shutting down server job=0
12:43AM INF shutdown finished job=0
job 0 %!s(<nil>) Job| Read| Write| Time|target
Job 1| 5.8 Gbps| 0 bps| 8.00|get http://localhost:7333/g/10g
Total| 5.8 Gbps| 0 bps| 8.00|
Rien que sous WSL2, ça reste limité par un coeur, mais c'est bien mieux :
loic@i7:~$ ./nspeed_linux_amd64 -verbose server -n 1 get -w 1 http://localhost:7333/g/10g
Jobs:
0 server {Address: "localhost", port: 7333, IPversion: 0, max_size: 40.0 GB, max_request duration: 10000000000, UseTLS: false, maxruns: 1, max life: 0s}
1 {Command: GET, URL: "http://localhost:7333/g/10g", IPversion: 0, Address: , Instance: 0, timeout: 8s}
1:02AM INF nspeed listening on http://127.0.0.1:7333 job=0
1:02AM INF waking up job=1
1:02AM INF | 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0|, active jobs: 2 / active goroutines: 7
1:02AM INF LocalAddr=127.0.0.1:53322 RemoteAddr=127.0.0.1:7333 job=1 protocol=HTTP/1.1
1:02AM INF | 10| 0| 24| 1| 0| 64| 0| 0| 0| 96| 0| 0|, active jobs: 2 / active goroutines: 10
1:02AM INF | 14| 0| 73| 0| 0| 0| 0| 0| 0| 98| 0| 1|, active jobs: 2 / active goroutines: 10
1:02AM INF | 75| 0| 83| 1| 0| 26| 0| 0| 0| 0| 0| 0|, active jobs: 2 / active goroutines: 10
1:02AM INF |100| 0| 29| 0| 0| 52| 0| 0| 0| 0| 0| 0|, active jobs: 2 / active goroutines: 10
1:02AM INF ReadBPS=16108688729 TotalRead=9999994880 TotalWrite=5120 WriteBPS=8247 duration=4.9662614000000005 job=0 url="download 10g to 127.0.0.1:53322"
1:02AM INF 1 max total requests reached, shutting down server job=0
1:02AM INF shutdown finished job=0
1:02AM INF processed read:10000000000 / write: 0 bytes job=1
job 0 %!s(<nil>) Job| Read| Write| Time|target
Job 1| 16.1 Gbps| 0 bps| 4.97|get http://localhost:7333/g/10g
Total| 16.1 Gbps| 0 bps| 4.97|
Sur un Ryzen 5 3500X (plus récent, mais aussi sans les pénalités liées aux failles Meltdown et autres sur les syscalls), j'ai entre 9,5Gbps et 11,5Gps (plus de variation), avec en gros (Windows semble migrer un peu les threads) un cœur saturé et un autre très chargé.
WSL2 fait 2 fois mieux (moins de gain que sur l'autre machine).
Sinon, avec l'option "-verbose", les traces colorées devraient dépendre des capacités du terminal.
Avec Windows Terminal, ça fonctionne.
Dans un cmd.exe simple, ce n'est pas géré donc il affiche les séquences d'échappement.
Sous Linux, il garde la couleur quand on redirige dans un fichier, donc même là ce n'est pas testé (certes on peut utiliser "less -R" pour voir les logs en couleur).
-
ok merci.
Sinon, avec l'option "-verbose", les traces colorées devraient dépendre des capacités du terminal.
Avec Windows Terminal, ça fonctionne.
Dans un cmd.exe simple, ce n'est pas géré donc il affiche les séquences d'échappement.
Sous Linux, il garde la couleur quand on redirige dans un fichier, donc même là ce n'est pas testé (certes on peut utiliser "less -R" pour voir les logs en couleur).
Les couleurs ont été ajoutées en urgence pour cette version, ce n'est pas définitif et disparaitra quand y'aura l'interface web. c'est juste pour faciliter la lecture quand il y a beaucoup de cores.
pourrais tu essayer avec -n 4 ou plus (dans les 2 sens) et un serveur distant (meme lan ou pas) ?
sur un Ryzen 9 3950x (16c/32t) en download sur Windows j'ai 100% d'un cpu sur un lien 10Gbps lan avec un serveur Linux en face:
./nspeed.exe -verbose get -n 8 http://xxxxx.local:7333/g/10g
ca ne donne que 4 Gbps pour les 8 flux
et
(https://i.imgur.com/OqmtP1h.png)
alors que dans l'autre sens:
./nspeed.exe -verbose put -n 8 http://xxxxx.local:7333/p 10g
ca donne bien le max du lien: 9.3 Gbps
et
(https://i.imgur.com/69TcaR6.png)
y'a un souci avec "get" sur Windows et que sur Windows mais je ne vois pas ou. Quand j'inverse les rôles (serveur Windows et client Linux) le problème apparait sur le Windows aussi quand on fait des 'put' depuis le client Linux: y'a un souci en réception coté Windows donc, que ce soit avec le code http client (get) ou avec le code http serveur (post). A moins que ce soit ma machine (drivers ou autre) qui a un souci.
-
Donc il y aurait deux soucis :
- le fait que sur N flux, Windows ne répartisse pas entre les coeurs
- le fait que sur 1 flux, la consommation CPU soit supérieure à d'autres outils, et donc le débit maximum possible soit plus faible
Sur un vrai trafic entre deux machines, la répartition des traitements (au moins kernel) va dépendre des paramètres de files RSS de la carte réseau.
La consommation CPU est aussi liée au nombre d'interruptions réseau (réglage dans les paramètres de la carte, et comportement dynamique).
-
Donc il y aurait deux soucis :
- le fait que sur N flux, Windows ne répartisse pas entre les coeurs
- le fait que sur 1 flux, la consommation CPU soit supérieure à d'autres outils, et donc le débit maximum possible soit plus faible
Sur un vrai trafic entre deux machines, la répartition des traitements (au moins kernel) va dépendre des paramètres de files RSS de la carte réseau.
La consommation CPU est aussi liée au nombre d'interruptions réseau (réglage dans les paramètres de la carte, et comportement dynamique).
avec curl 1 flux j'ai le même débit.
mais t'a une bonne piste, en loopback (localhost) j'ai bien plusieurs cœurs utilisés en reception.
j'ai désactivé puis réactivé le RSS de ma carte réseau et du coup le problème a disparu... curieux (et pas trop cool si c'est pas stable).
mais en réception je n'ai toujours pas le max sur un 1 flux alors que je l'ai en émission.. donc y'a un autre problème en réception.
Mais bon a priori le problème est spécifique a cette carte et pas a Windows ce qui me rassure.
-
la v0.6 est dispo: https://dl.nspeed.app/nspeed-client/v0.6/
modifs: https://github.com/nspeed-app/nspeed/blob/main/CHANGELOG.md
L'API est commencé mais pas encore fonctionnel donc pas dans cette version.
Si des gens peuvent testé leur débit 'cpu pur' (localhost a localhost) en indiquant leur marque/modele de cpu.
pour tester on part d'un flux dans chaque sens puis le nombre de coeur physiques, puis logiques puis le double:
sur cpu 4c/8t:
#1 flux
nspeed server -n 2 get -w 1 -n 1 http://localhost:7333/g/40g put -w 1 -n 1 http://localhost:7333/p 40g
# 4 flux
nspeed server -n 8 get -w 1 -n 4 http://localhost:7333/g/40g put -w 1 -n 4 http://localhost:7333/p 40g
# 8 flux
nspeed server -n 16 get -w 1 -n 8 http://localhost:7333/g/40g put -w 1 -n 8 http://localhost:7333/p 40g
# 16 flux
nspeed server -n 32 get -w 1 -n 16 http://localhost:7333/g/1g put -w 1 -n 16 http://localhost:7333/p 40g
sur un Intel NUC 7 (Intel(R) Core(TM) i7-8559U CPU @ 2.70GHz) sous Linux (kernel 5.4.0) j'obtient:
1 flux: 18 Gbps - 19 Gbps
16 flux: 34 Gbps - 35 Gbps Gbps
Je serais curieux de voir si y'a des OS non symétriques.
-
la v0.6 est dispo: https://dl.nspeed.app/nspeed-client/v0.6/
modifs: https://github.com/nspeed-app/nspeed/blob/main/CHANGELOG.md
L'API est commencé mais pas encore fonctionnel donc pas dans cette version.
Si des gens peuvent testé leur débit 'cpu pur' (localhost a localhost) en indiquant leur marque/modele de cpu.
pour tester on part d'un flux dans chaque sens puis le nombre de coeur physiques, puis logiques puis le double:
sur cpu 4c/8t:
#1 flux
nspeed server -n 2 get -w 1 -n 1 http://localhost:7333/g/40g put -w 1 -n 1 http://localhost:7333/p 40g
# 4 flux
nspeed server -n 8 get -w 1 -n 4 http://localhost:7333/g/40g put -w 1 -n 4 http://localhost:7333/p 40g
# 8 flux
nspeed server -n 16 get -w 1 -n 8 http://localhost:7333/g/40g put -w 1 -n 8 http://localhost:7333/p 40g
# 16 flux
nspeed server -n 32 get -w 1 -n 16 http://localhost:7333/g/1g put -w 1 -n 16 http://localhost:7333/p 40g
sur un Intel NUC 7 (Intel(R) Core(TM) i7-8559U CPU @ 2.70GHz) sous Linux (kernel 5.4.0) j'obtient:
1 flux: 18 Gbps - 19 Gbps
16 flux: 34 Gbps - 35 Gbps Gbps
Je serais curieux de voir si y'a des OS non symétriques.
Bonjour,
Sur un Windows 10 20H2 avec un Intel I5-8250U, ça donne :
(https://i.imgur.com/USj9IYC.png)
-
ok merci. faut vraiment que je corrige l'affichage des couleurs ;D
ca ne monte pas haut mais le cpu c'est max 70% par core, c'est curieux... Windows et ses bizarreries...
-
ok merci. faut vraiment que je corrige l'affichage des couleurs ;D
ca ne monte pas haut mais le cpu c'est max 70% par core, c'est curieux... Windows et ses bizarreries...
Si tu veux que je face d'autres tests, n'hésite pas.
-
Si tu veux que je face d'autres tests, n'hésite pas.
Oui merci, quand y'aura l'interface graphique ca sera plus facile pour tout le monde d'échanger des résultats de tests.
-
Ryzen 3600 - linux 5.11
./nspeed_linux_amd64 server -n 2 get -w 1 -n 1 http://localhost:7333/g/40g put -w 1 -n 1 http://localhost:7333/p 40g
Jobs:
0 server {Address: "localhost", port: 7333, IPversion: 0, max_size: 40.0 GB, max_request duration: 10000000000, UseTLS: false, maxruns: 2, max life: 0s}
1 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 0, timeout: 8s}
2 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 0, timeout: 8s,size: 40000000000 (40.0 GB)}
| 0| 3| 0| 0| 0| 1| 0| 0| 1| 0| 0| 0|, active jobs: 3 / active goroutines: 9
| 18| 44| 22| 46| 55| 25| 18| 18| 39| 24| 23| 49|, active jobs: 3 / active goroutines: 14
| 28| 25| 32| 23| 28| 43| 46| 46| 31| 34| 30| 19|, active jobs: 3 / active goroutines: 14
| 60| 28| 17| 36| 21| 36| 21| 21| 17| 42| 53| 37|, active jobs: 3 / active goroutines: 14
| 23| 29| 51| 58| 25| 43| 40| 32| 10| 12| 3| 50|, active jobs: 3 / active goroutines: 14
| 13| 48| 0| 38| 46| 53| 68| 17| 0| 32| 32| 29|, active jobs: 3 / active goroutines: 14
| 43| 34| 51| 34| 27| 73| 41| 8| 1| 36| 37| 3|, active jobs: 3 / active goroutines: 14
| 38| 31| 17| 56| 56| 37| 30| 31| 50| 20| 16| 17|, active jobs: 3 / active goroutines: 14
| 52| 29| 32| 46| 55| 17| 31| 44| 17| 36| 0| 32|, active jobs: 3 / active goroutines: 14
Job| Read| Write| Time|target
Job 1| 15.7 Gbps| 0 bps| 8.00|get http://localhost:7333/g/40g
Job 2| 0 bps| 16.9 Gbps| 8.00|put http://localhost:7333/p 40.0 GB
Total| 15.7 Gbps| 16.9 Gbps| 8.00|
Intel i7-3770K - linux 5.11
./nspeed_linux_amd64 server -n 2 get -w 1 -n 1 http://localhost:7333/g/40g put -w 1 -n 1 http://localhost:7333/p 40g
Jobs:
0 server {Address: "localhost", port: 7333, IPversion: 0, max_size: 40.0 GB, max_request duration: 10000000000, UseTLS: false, maxruns: 2, max life: 0s}
1 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 0, timeout: 8s}
2 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 0, timeout: 8s,size: 40000000000 (40.0 GB)}
| 2| 0| 0| 0| 2| 1| 0| 1|, active jobs: 3 / active goroutines: 7
| 49| 43| 49| 32| 39| 54| 48| 31|, active jobs: 3 / active goroutines: 14
| 33| 29| 45| 50| 61| 51| 28| 41|, active jobs: 3 / active goroutines: 14
| 41| 28| 68| 35| 39| 31| 71| 39|, active jobs: 3 / active goroutines: 14
| 42| 40| 37| 38| 57| 53| 46| 29|, active jobs: 3 / active goroutines: 14
| 23| 45| 46| 54| 35| 47| 48| 45|, active jobs: 3 / active goroutines: 14
| 37| 38| 39| 57| 48| 49| 18| 62|, active jobs: 3 / active goroutines: 14
| 33| 37| 38| 62| 47| 54| 37| 52|, active jobs: 3 / active goroutines: 14
| 52| 33| 45| 66| 53| 34| 26| 52|, active jobs: 3 / active goroutines: 14
Job| Read| Write| Time|target
Job 1| 8.3 Gbps| 0 bps| 8.00|get http://localhost:7333/g/40g
Job 2| 0 bps| 8.8 Gbps| 8.00|put http://localhost:7333/p 40.0 GB
Total| 8.3 Gbps| 8.8 Gbps| 8.00|
-
merci. x2 entre un Ryzen 3600 et Intel i7-3770K, nice ;D
-
Sur linux j'ai cette erreur
nspeed_linux_amd64 get -4 -n 4 http://scaleway.testdebit.info/10G/10G.dat
Jobs:
0 {Command: GET, URL: "http://scaleway.testdebit.info/10G/10G.dat", IPversion: 4, Address: , Instance: 0, timeout: 8s}
1 {Command: GET, URL: "http://scaleway.testdebit.info/10G/10G.dat", IPversion: 4, Address: , Instance: 1, timeout: 8s}
2 {Command: GET, URL: "http://scaleway.testdebit.info/10G/10G.dat", IPversion: 4, Address: , Instance: 2, timeout: 8s}
3 {Command: GET, URL: "http://scaleway.testdebit.info/10G/10G.dat", IPversion: 4, Address: , Instance: 3, timeout: 8s}
6:34PM FTL error="Get \"http://scaleway.testdebit.info/10G/10G.dat\": dial tcp: i/o timeout" job=2
-
Sur linux j'ai cette erreur
nspeed_linux_amd64 get -4 -n 4 http://scaleway.testdebit.info/10G/10G.dat
Jobs:
0 {Command: GET, URL: "http://scaleway.testdebit.info/10G/10G.dat", IPversion: 4, Address: , Instance: 0, timeout: 8s}
1 {Command: GET, URL: "http://scaleway.testdebit.info/10G/10G.dat", IPversion: 4, Address: , Instance: 1, timeout: 8s}
2 {Command: GET, URL: "http://scaleway.testdebit.info/10G/10G.dat", IPversion: 4, Address: , Instance: 2, timeout: 8s}
3 {Command: GET, URL: "http://scaleway.testdebit.info/10G/10G.dat", IPversion: 4, Address: , Instance: 3, timeout: 8s}
6:34PM FTL error="Get \"http://scaleway.testdebit.info/10G/10G.dat\": dial tcp: i/o timeout" job=2
tu 'ping -4 scaleway.testdebit.info' correctement ?
sinon ajoute l'option -verbose avant le get
-
ping -4 scaleway.testdebit.info
PING (62.210.156.7) 56(84) bytes of data.
64 bytes from hopus.jesuisfrancobelge.eu (62.210.156.7): icmp_seq=1 ttl=58 time=36.0 ms
64 bytes from hopus.jesuisfrancobelge.eu (62.210.156.7): icmp_seq=2 ttl=58 time=36.6 ms
64 bytes from hopus.jesuisfrancobelge.eu (62.210.156.7): icmp_seq=3 ttl=58 time=36.2 ms
64 bytes from hopus.jesuisfrancobelge.eu (62.210.156.7): icmp_seq=4 ttl=58 time=36.6 ms
^C64 bytes from 62.210.156.7: icmp_seq=5 ttl=58 time=36.8 ms
--- ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 12707ms
rtt min/avg/max/mdev = 35.987/36.436/36.811/0.307 ms ping -6 scaleway.testdebit.info
PING scaleway.testdebit.info(hopus.ipv6.jesuisfrancobelge.eu (2001:bc8:3::7)) 56 data bytes
64 bytes from hopus.ipv6.jesuisfrancobelge.eu (2001:bc8:3::7): icmp_seq=1 ttl=57 time=36.8 ms
64 bytes from hopus.ipv6.jesuisfrancobelge.eu (2001:bc8:3::7): icmp_seq=2 ttl=57 time=36.0 ms
64 bytes from hopus.ipv6.jesuisfrancobelge.eu (2001:bc8:3::7): icmp_seq=3 ttl=57 time=37.1 ms
64 bytes from hopus.ipv6.jesuisfrancobelge.eu (2001:bc8:3::7): icmp_seq=4 ttl=57 time=36.6 ms
^C64 bytes from 2001:bc8:3::7: icmp_seq=5 ttl=57 time=36.4 ms
--- scaleway.testdebit.info ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 12528ms
rtt min/avg/max/mdev = 36.006/36.557/37.055/0.350 ms
nspeed_linux_amd64 -verbose get -4 -n 4 http://scaleway.testdebit.info/10G/10G.dat
Jobs:
0 {Command: GET, URL: "http://scaleway.testdebit.info/10G/10G.dat", IPversion: 4, Address: , Instance: 0, timeout: 8s}
1 {Command: GET, URL: "http://scaleway.testdebit.info/10G/10G.dat", IPversion: 4, Address: , Instance: 1, timeout: 8s}
2 {Command: GET, URL: "http://scaleway.testdebit.info/10G/10G.dat", IPversion: 4, Address: , Instance: 2, timeout: 8s}
3 {Command: GET, URL: "http://scaleway.testdebit.info/10G/10G.dat", IPversion: 4, Address: , Instance: 3, timeout: 8s}
| 13| 3| 4| 5| 6| 3| 10| 3| 4| 0| 5| 2| 1| 6| 2| 1|, active jobs: 4 / active goroutines: 13
| 8| 4| 3| 1| 1| 2| 0| 1| 0| 3| 1| 1| 0| 0| 0| 0|, active jobs: 4 / active goroutines: 13
| 10| 6| 4| 2| 2| 7| 1| 1| 1| 1| 3| 6| 2| 3| 3| 2|, active jobs: 4 / active goroutines: 13
| 10| 2| 6| 3| 1| 1| 2| 0| 2| 3| 3| 1| 0| 0| 1| 0|, active jobs: 4 / active goroutines: 13
| 10| 3| 0| 5| 0| 1| 0| 2| 1| 3| 3| 1| 2| 1| 0| 0|, active jobs: 4 / active goroutines: 13
7:05PM FTL error="Get \"http://scaleway.testdebit.info/10G/10G.dat\": dial tcp: i/o timeout" job=3
-
c'est marrant comme bug ... ;D t'as bien la v0.6 de nspeed_linux_amd64 (visible avec "nspeed_linux_amd64 -version")
avec -n 1 ca passe pas non plus ?
nspeed_linux_amd64 -verbose get -4 -n 1 http://scaleway.testdebit.info/10G/10G.dat
sinon avec curl ca passe ?
curl -o /dev/null http://scaleway.testdebit.info/10G/10G.dat
-
Oui j'ai bien la V0.6, la 0.5 même problème.
Curl fonctionne bien
En -n 1 même erreur
Pas de problème sur Windows, bizarre :P
-
windows 10 20H2 i5-10400
.\nspeed_windows_amd64.exe server -n 2 get -w 1 -n 1 http://localhost:7333/g/40g put -w 1 -n 1 http://localhost:7333/p 40g
Jobs:
0 server {Address: "localhost", port: 7333, IPversion: 0, max_size: 40.0 GB, max_request duration: 10000000000, UseTLS: false, maxruns: 2, max life: 0s}
1 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 0, timeout: 8s}
2 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 0, timeout: 8s,size: 40000000000 (40.0 GB)}
|←[32m 0←[0m|←[32m 0←[0m|←[32m 2←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 3←[0m|←[32m 0←[0m|, active jobs: 3 / active goroutines: 9
|←[31m 94←[0m|←[32m 5←[0m|←[31m 82←[0m|←[32m 0←[0m|←[33m 58←[0m|←[32m 0←[0m|←[32m 0←[0m|←[33m 52←[0m|←[32m 5←[0m|←[32m 0←[0m|←[33m 58←[0m|←[32m 5←[0m|, active jobs: 3 / active goroutines: 14
|←[33m 80←[0m|←[32m 13←[0m|←[31m 89←[0m|←[32m 0←[0m|←[32m 38←[0m|←[32m 0←[0m|←[32m 0←[0m|←[33m 73←[0m|←[32m 3←[0m|←[32m 0←[0m|←[33m 59←[0m|←[32m 0←[0m|, active jobs: 3 / active goroutines: 14
|←[33m 70←[0m|←[32m 17←[0m|←[33m 75←[0m|←[32m 3←[0m|←[33m 60←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 3←[0m|←[32m 3←[0m|←[33m 67←[0m|←[33m 63←[0m|←[32m 0←[0m|, active jobs: 3 / active goroutines: 14
|←[33m 77←[0m|←[32m 14←[0m|←[32m 42←[0m|←[32m 0←[0m|←[32m 33←[0m|←[32m 0←[0m|←[32m 5←[0m|←[33m 61←[0m|←[32m 6←[0m|←[33m 61←[0m|←[33m 63←[0m|←[32m 0←[0m|, active jobs: 3 / active goroutines: 14
|←[33m 63←[0m|←[32m 17←[0m|←[33m 63←[0m|←[32m 0←[0m|←[33m 65←[0m|←[32m 2←[0m|←[32m 8←[0m|←[32m 48←[0m|←[32m 18←[0m|←[32m 31←[0m|←[33m 51←[0m|←[32m 0←[0m|, active jobs: 3 / active goroutines: 14
|←[31m 98←[0m|←[32m 0←[0m|←[33m 53←[0m|←[32m 2←[0m|←[33m 78←[0m|←[32m 0←[0m|←[32m 3←[0m|←[33m 80←[0m|←[32m 3←[0m|←[32m 0←[0m|←[33m 53←[0m|←[32m 0←[0m|, active jobs: 3 / active goroutines: 14
|←[31m 92←[0m|←[32m 0←[0m|←[33m 78←[0m|←[32m 0←[0m|←[32m 37←[0m|←[32m 13←[0m|←[32m 0←[0m|←[33m 75←[0m|←[32m 0←[0m|←[32m 0←[0m|←[33m 65←[0m|←[32m 0←[0m|, active jobs: 3 / active goroutines: 14
|←[31m 85←[0m|←[32m 0←[0m|←[31m 85←[0m|←[32m 0←[0m|←[33m 71←[0m|←[32m 0←[0m|←[32m 2←[0m|←[33m 74←[0m|←[32m 2←[0m|←[32m 42←[0m|←[32m 6←[0m|←[32m 0←[0m|, active jobs: 3 / active goroutines: 8
Job| Read| Write| Time|target
Job 1| 13.0 Gbps| 0 bps| 8.00|get http://localhost:7333/g/40g
Job 2| 0 bps| 13.1 Gbps| 8.00|put http://localhost:7333/p 40.0 GB
Total| 13.0 Gbps| 13.1 Gbps| 8.00|
.\nspeed_windows_amd64.exe server -n 8 get -w 1 -n 4 http://localhost:7333/g/40g put -w 1 -n 4 http://localhost:7333/p 40g
Jobs:
0 server {Address: "localhost", port: 7333, IPversion: 0, max_size: 40.0 GB, max_request duration: 10000000000, UseTLS: false, maxruns: 8, max life: 0s}
1 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 0, timeout: 8s}
2 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 1, timeout: 8s}
3 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 2, timeout: 8s}
4 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 3, timeout: 8s}
5 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 0, timeout: 8s,size: 40000000000 (40.0 GB)}
6 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 1, timeout: 8s,size: 40000000000 (40.0 GB)}
7 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 2, timeout: 8s,size: 40000000000 (40.0 GB)}
8 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 3, timeout: 8s,size: 40000000000 (40.0 GB)}
|←[32m 3←[0m|←[32m 0←[0m|←[32m 3←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 3←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 0←[0m|, active jobs: 9 / active goroutines: 23
|←[31m 95←[0m|←[31m 90←[0m|←[31m 90←[0m|←[31m 89←[0m|←[31m 86←[0m|←[33m 71←[0m|←[31m 92←[0m|←[33m 80←[0m|←[31m 84←[0m|←[31m 83←[0m|←[31m 83←[0m|←[31m 84←[0m|, active jobs: 9 / active goroutines: 41
|←[31m 86←[0m|←[31m 89←[0m|←[31m 81←[0m|←[33m 77←[0m|←[31m 82←[0m|←[31m 86←[0m|←[31m 92←[0m|←[31m 83←[0m|←[31m 92←[0m|←[33m 74←[0m|←[31m 82←[0m|←[33m 78←[0m|, active jobs: 9 / active goroutines: 41
|←[31m 89←[0m|←[31m 88←[0m|←[31m 87←[0m|←[31m 91←[0m|←[31m 94←[0m|←[31m 88←[0m|←[31m 81←[0m|←[31m 92←[0m|←[31m 88←[0m|←[33m 78←[0m|←[31m 88←[0m|←[31m 89←[0m|, active jobs: 9 / active goroutines: 41
|←[31m 92←[0m|←[31m 83←[0m|←[31m 83←[0m|←[31m 86←[0m|←[31m 91←[0m|←[31m 94←[0m|←[31m 81←[0m|←[31m 84←[0m|←[31m 88←[0m|←[33m 77←[0m|←[31m 88←[0m|←[31m 83←[0m|, active jobs: 9 / active goroutines: 41
|←[31m 89←[0m|←[31m 89←[0m|←[31m 95←[0m|←[31m 84←[0m|←[31m 91←[0m|←[31m 94←[0m|←[31m 92←[0m|←[31m 81←[0m|←[31m 89←[0m|←[31m 92←[0m|←[31m 91←[0m|←[31m 89←[0m|, active jobs: 9 / active goroutines: 41
|←[31m 92←[0m|←[31m 81←[0m|←[31m 92←[0m|←[31m 81←[0m|←[33m 73←[0m|←[31m 83←[0m|←[31m 83←[0m|←[31m 84←[0m|←[31m 81←[0m|←[31m 81←[0m|←[31m 83←[0m|←[33m 78←[0m|, active jobs: 9 / active goroutines: 41
|←[31m 86←[0m|←[31m 83←[0m|←[31m 91←[0m|←[31m 83←[0m|←[31m 94←[0m|←[31m 81←[0m|←[31m 91←[0m|←[31m 83←[0m|←[31m 88←[0m|←[31m 81←[0m|←[31m 94←[0m|←[31m 86←[0m|, active jobs: 9 / active goroutines: 41
|←[31m 83←[0m|←[31m 81←[0m|←[31m 88←[0m|←[31m 83←[0m|←[31m 94←[0m|←[33m 70←[0m|←[31m 91←[0m|←[31m 89←[0m|←[31m 92←[0m|←[31m 83←[0m|←[31m 84←[0m|←[31m 88←[0m|, active jobs: 9 / active goroutines: 41
Job| Read| Write| Time|target
Job 1| 2.0 Gbps| 0 bps| 8.01|get http://localhost:7333/g/40g
Job 2| 2.8 Gbps| 0 bps| 8.00|get http://localhost:7333/g/40g
Job 3| 2.0 Gbps| 0 bps| 8.00|get http://localhost:7333/g/40g
Job 4| 3.0 Gbps| 0 bps| 8.00|get http://localhost:7333/g/40g
Job 5| 0 bps| 2.8 Gbps| 8.01|put http://localhost:7333/p 40.0 GB
Job 6| 0 bps| 5.5 Gbps| 8.01|put http://localhost:7333/p 40.0 GB
Job 7| 0 bps| 5.2 Gbps| 8.01|put http://localhost:7333/p 40.0 GB
Job 8| 0 bps| 5.5 Gbps| 8.01|put http://localhost:7333/p 40.0 GB
Total| 9.9 Gbps| 19.0 Gbps| 8.01|
.\nspeed_windows_amd64.exe server -n 16 get -w 1 -n 8 http://localhost:7333/g/40g put -w 1 -n 8 http://localhost:7333/p 40g
Jobs:
0 server {Address: "localhost", port: 7333, IPversion: 0, max_size: 40.0 GB, max_request duration: 10000000000, UseTLS: false, maxruns: 16, max life: 0s}
1 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 0, timeout: 8s}
2 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 1, timeout: 8s}
3 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 2, timeout: 8s}
4 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 3, timeout: 8s}
5 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 4, timeout: 8s}
6 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 5, timeout: 8s}
7 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 6, timeout: 8s}
8 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 7, timeout: 8s}
9 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 0, timeout: 8s,size: 40000000000 (40.0 GB)}
10 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 1, timeout: 8s,size: 40000000000 (40.0 GB)}
11 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 2, timeout: 8s,size: 40000000000 (40.0 GB)}
12 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 3, timeout: 8s,size: 40000000000 (40.0 GB)}
13 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 4, timeout: 8s,size: 40000000000 (40.0 GB)}
14 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 5, timeout: 8s,size: 40000000000 (40.0 GB)}
15 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 6, timeout: 8s,size: 40000000000 (40.0 GB)}
16 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 7, timeout: 8s,size: 40000000000 (40.0 GB)}
|←[32m 0←[0m|←[32m 0←[0m|←[32m 3←[0m|←[32m 0←[0m|←[32m 2←[0m|←[32m 2←[0m|←[32m 2←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 2←[0m|←[32m 2←[0m|, active jobs: 17 / active goroutines: 39
|←[31m 83←[0m|←[32m 50←[0m|←[33m 72←[0m|←[33m 59←[0m|←[33m 75←[0m|←[33m 57←[0m|←[31m 82←[0m|←[32m 48←[0m|←[31m 86←[0m|←[33m 51←[0m|←[33m 72←[0m|←[32m 42←[0m|, active jobs: 17 / active goroutines: 77
|←[31m 83←[0m|←[33m 63←[0m|←[33m 75←[0m|←[32m 50←[0m|←[33m 72←[0m|←[32m 38←[0m|←[33m 73←[0m|←[33m 56←[0m|←[33m 72←[0m|←[33m 64←[0m|←[31m 86←[0m|←[33m 52←[0m|, active jobs: 17 / active goroutines: 77
|←[33m 69←[0m|←[31m 82←[0m|←[33m 80←[0m|←[33m 67←[0m|←[33m 72←[0m|←[32m 49←[0m|←[33m 67←[0m|←[33m 55←[0m|←[33m 69←[0m|←[33m 52←[0m|←[33m 78←[0m|←[33m 53←[0m|, active jobs: 17 / active goroutines: 77
|←[33m 67←[0m|←[33m 75←[0m|←[31m 91←[0m|←[33m 67←[0m|←[31m 81←[0m|←[32m 49←[0m|←[31m 86←[0m|←[33m 61←[0m|←[33m 78←[0m|←[33m 60←[0m|←[31m 89←[0m|←[33m 60←[0m|, active jobs: 17 / active goroutines: 77
|←[31m 81←[0m|←[33m 73←[0m|←[33m 73←[0m|←[33m 73←[0m|←[33m 75←[0m|←[33m 52←[0m|←[33m 77←[0m|←[33m 56←[0m|←[31m 86←[0m|←[33m 69←[0m|←[31m 92←[0m|←[33m 52←[0m|, active jobs: 17 / active goroutines: 77
|←[31m 82←[0m|←[33m 75←[0m|←[33m 77←[0m|←[33m 70←[0m|←[31m 84←[0m|←[33m 63←[0m|←[31m 81←[0m|←[33m 55←[0m|←[33m 77←[0m|←[33m 56←[0m|←[31m 88←[0m|←[33m 55←[0m|, active jobs: 17 / active goroutines: 77
|←[33m 72←[0m|←[33m 75←[0m|←[31m 86←[0m|←[33m 72←[0m|←[33m 65←[0m|←[33m 67←[0m|←[33m 77←[0m|←[33m 62←[0m|←[33m 77←[0m|←[33m 66←[0m|←[31m 83←[0m|←[33m 54←[0m|, active jobs: 17 / active goroutines: 77
|←[31m 84←[0m|←[33m 73←[0m|←[31m 86←[0m|←[33m 67←[0m|←[33m 78←[0m|←[33m 69←[0m|←[31m 89←[0m|←[33m 78←[0m|←[31m 81←[0m|←[33m 62←[0m|←[31m 82←[0m|←[32m 47←[0m|, active jobs: 17 / active goroutines: 77
Job| Read| Write| Time|target
Job 1| 479.1 Mbps| 0 bps| 7.98|get http://localhost:7333/g/40g
Job 2| 886.5 Mbps| 0 bps| 8.00|get http://localhost:7333/g/40g
Job 3| 2.1 Gbps| 0 bps| 8.00|get http://localhost:7333/g/40g
Job 4| 5.4 Gbps| 0 bps| 8.00|get http://localhost:7333/g/40g
Job 5| 885.4 Mbps| 0 bps| 8.00|get http://localhost:7333/g/40g
Job 6| 968.9 Mbps| 0 bps| 8.00|get http://localhost:7333/g/40g
Job 7| 5.5 Gbps| 0 bps| 8.00|get http://localhost:7333/g/40g
Job 8| 872.9 Mbps| 0 bps| 8.00|get http://localhost:7333/g/40g
Job 9| 0 bps| 860.4 Mbps| 8.00|put http://localhost:7333/p 40.0 GB
Job 10| 0 bps| 975.8 Mbps| 8.00|put http://localhost:7333/p 40.0 GB
Job 11| 0 bps| 488.6 Mbps| 8.00|put http://localhost:7333/p 40.0 GB
Job 12| 0 bps| 494.0 Mbps| 8.00|put http://localhost:7333/p 40.0 GB
Job 13| 0 bps| 899.7 Mbps| 8.00|put http://localhost:7333/p 40.0 GB
Job 14| 0 bps| 9.0 Gbps| 8.00|put http://localhost:7333/p 40.0 GB
Job 15| 0 bps| 5.5 Gbps| 8.00|put http://localhost:7333/p 40.0 GB
Job 16| 0 bps| 976.4 Mbps| 8.00|put http://localhost:7333/p 40.0 GB
Total| 17.1 Gbps| 19.2 Gbps| 8.00|
.\nspeed_windows_amd64.exe server -n 32 get -w 1 -n 16 http://localhost:7333/g/1g put -w 1 -n 16 http://localhost:7333/p 40g
Jobs:
0 server {Address: "localhost", port: 7333, IPversion: 0, max_size: 40.0 GB, max_request duration: 10000000000, UseTLS: false, maxruns: 32, max life: 0s}
1 {Command: GET, URL: "http://localhost:7333/g/1g", IPversion: 0, Address: , Instance: 0, timeout: 8s}
2 {Command: GET, URL: "http://localhost:7333/g/1g", IPversion: 0, Address: , Instance: 1, timeout: 8s}
3 {Command: GET, URL: "http://localhost:7333/g/1g", IPversion: 0, Address: , Instance: 2, timeout: 8s}
4 {Command: GET, URL: "http://localhost:7333/g/1g", IPversion: 0, Address: , Instance: 3, timeout: 8s}
5 {Command: GET, URL: "http://localhost:7333/g/1g", IPversion: 0, Address: , Instance: 4, timeout: 8s}
6 {Command: GET, URL: "http://localhost:7333/g/1g", IPversion: 0, Address: , Instance: 5, timeout: 8s}
7 {Command: GET, URL: "http://localhost:7333/g/1g", IPversion: 0, Address: , Instance: 6, timeout: 8s}
8 {Command: GET, URL: "http://localhost:7333/g/1g", IPversion: 0, Address: , Instance: 7, timeout: 8s}
9 {Command: GET, URL: "http://localhost:7333/g/1g", IPversion: 0, Address: , Instance: 8, timeout: 8s}
10 {Command: GET, URL: "http://localhost:7333/g/1g", IPversion: 0, Address: , Instance: 9, timeout: 8s}
11 {Command: GET, URL: "http://localhost:7333/g/1g", IPversion: 0, Address: , Instance: 10, timeout: 8s}
12 {Command: GET, URL: "http://localhost:7333/g/1g", IPversion: 0, Address: , Instance: 11, timeout: 8s}
13 {Command: GET, URL: "http://localhost:7333/g/1g", IPversion: 0, Address: , Instance: 12, timeout: 8s}
14 {Command: GET, URL: "http://localhost:7333/g/1g", IPversion: 0, Address: , Instance: 13, timeout: 8s}
15 {Command: GET, URL: "http://localhost:7333/g/1g", IPversion: 0, Address: , Instance: 14, timeout: 8s}
16 {Command: GET, URL: "http://localhost:7333/g/1g", IPversion: 0, Address: , Instance: 15, timeout: 8s}
17 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 0, timeout: 8s,size: 40000000000 (40.0 GB)}
18 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 1, timeout: 8s,size: 40000000000 (40.0 GB)}
19 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 2, timeout: 8s,size: 40000000000 (40.0 GB)}
20 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 3, timeout: 8s,size: 40000000000 (40.0 GB)}
21 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 4, timeout: 8s,size: 40000000000 (40.0 GB)}
22 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 5, timeout: 8s,size: 40000000000 (40.0 GB)}
23 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 6, timeout: 8s,size: 40000000000 (40.0 GB)}
24 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 7, timeout: 8s,size: 40000000000 (40.0 GB)}
25 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 8, timeout: 8s,size: 40000000000 (40.0 GB)}
26 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 9, timeout: 8s,size: 40000000000 (40.0 GB)}
27 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 10, timeout: 8s,size: 40000000000 (40.0 GB)}
28 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 11, timeout: 8s,size: 40000000000 (40.0 GB)}
29 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 12, timeout: 8s,size: 40000000000 (40.0 GB)}
30 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 13, timeout: 8s,size: 40000000000 (40.0 GB)}
31 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 14, timeout: 8s,size: 40000000000 (40.0 GB)}
32 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 15, timeout: 8s,size: 40000000000 (40.0 GB)}
|←[32m 2←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 1←[0m|←[32m 0←[0m|←[32m 1←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 0←[0m|, active jobs: 33 / active goroutines: 52
|←[31m 98←[0m|←[33m 78←[0m|←[31m 83←[0m|←[33m 73←[0m|←[31m 88←[0m|←[33m 67←[0m|←[31m 83←[0m|←[31m 88←[0m|←[31m 89←[0m|←[33m 69←[0m|←[33m 73←[0m|←[33m 78←[0m|, active jobs: 33 / active goroutines: 149
|←[33m 75←[0m|←[33m 64←[0m|←[33m 77←[0m|←[33m 72←[0m|←[31m 89←[0m|←[33m 64←[0m|←[33m 78←[0m|←[33m 64←[0m|←[31m 95←[0m|←[33m 66←[0m|←[33m 77←[0m|←[33m 72←[0m|, active jobs: 32 / active goroutines: 142
|←[31m 83←[0m|←[33m 64←[0m|←[33m 80←[0m|←[33m 59←[0m|←[33m 71←[0m|←[32m 48←[0m|←[33m 67←[0m|←[33m 59←[0m|←[31m 83←[0m|←[33m 55←[0m|←[31m 81←[0m|←[33m 59←[0m|, active jobs: 31 / active goroutines: 137
|←[31m 91←[0m|←[33m 72←[0m|←[31m 86←[0m|←[31m 81←[0m|←[31m 89←[0m|←[33m 75←[0m|←[33m 78←[0m|←[31m 91←[0m|←[33m 80←[0m|←[33m 69←[0m|←[31m 86←[0m|←[33m 72←[0m|, active jobs: 30 / active goroutines: 132
|←[33m 78←[0m|←[33m 72←[0m|←[31m 83←[0m|←[33m 72←[0m|←[33m 73←[0m|←[33m 80←[0m|←[33m 66←[0m|←[33m 64←[0m|←[33m 69←[0m|←[33m 75←[0m|←[33m 80←[0m|←[33m 63←[0m|, active jobs: 30 / active goroutines: 132
|←[33m 67←[0m|←[33m 58←[0m|←[33m 75←[0m|←[33m 55←[0m|←[33m 64←[0m|←[33m 57←[0m|←[33m 64←[0m|←[33m 58←[0m|←[31m 94←[0m|←[32m 42←[0m|←[31m 92←[0m|←[32m 50←[0m|, active jobs: 26 / active goroutines: 112
|←[33m 64←[0m|←[33m 55←[0m|←[33m 63←[0m|←[33m 78←[0m|←[33m 75←[0m|←[33m 66←[0m|←[33m 78←[0m|←[33m 55←[0m|←[33m 67←[0m|←[32m 45←[0m|←[31m 88←[0m|←[32m 48←[0m|, active jobs: 26 / active goroutines: 112
|←[33m 63←[0m|←[33m 58←[0m|←[31m 86←[0m|←[32m 50←[0m|←[33m 80←[0m|←[33m 52←[0m|←[33m 61←[0m|←[33m 70←[0m|←[33m 77←[0m|←[33m 58←[0m|←[33m 73←[0m|←[32m 45←[0m|, active jobs: 26 / active goroutines: 112
Job| Read| Write| Time|target
Job 1| 597.5 Mbps| 0 bps| 8.00|get http://localhost:7333/g/1g
Job 2| 823.9 Mbps| 0 bps| 8.00|get http://localhost:7333/g/1g
Job 3| 592.0 Mbps| 0 bps| 8.00|get http://localhost:7333/g/1g
Job 4| 1.5 Gbps| 0 bps| 5.18|get http://localhost:7333/g/1g
Job 5| 823.4 Mbps| 0 bps| 8.00|get http://localhost:7333/g/1g
Job 6| 3.1 Gbps| 0 bps| 2.56|get http://localhost:7333/g/1g
Job 7| 5.2 Gbps| 0 bps| 1.52|get http://localhost:7333/g/1g
Job 8| 410.0 Mbps| 0 bps| 8.00|get http://localhost:7333/g/1g
Job 9| 2.6 Gbps| 0 bps| 3.14|get http://localhost:7333/g/1g
Job 10| 816.9 Mbps| 0 bps| 7.99|get http://localhost:7333/g/1g
Job 11| 1.5 Gbps| 0 bps| 5.22|get http://localhost:7333/g/1g
Job 12| 418.9 Mbps| 0 bps| 7.99|get http://localhost:7333/g/1g
Job 13| 599.6 Mbps| 0 bps| 8.00|get http://localhost:7333/g/1g
Job 14| 1.5 Gbps| 0 bps| 5.21|get http://localhost:7333/g/1g
Job 15| 1.5 Gbps| 0 bps| 5.22|get http://localhost:7333/g/1g
Job 16| 594.5 Mbps| 0 bps| 8.00|get http://localhost:7333/g/1g
Job 17| 0 bps| 1.1 Gbps| 8.00|put http://localhost:7333/p 40.0 GB
Job 18| 0 bps| 3.6 Gbps| 8.00|put http://localhost:7333/p 40.0 GB
Job 19| 0 bps| 1.1 Gbps| 8.00|put http://localhost:7333/p 40.0 GB
Job 20| 0 bps| 824.6 Mbps| 8.00|put http://localhost:7333/p 40.0 GB
Job 21| 0 bps| 824.3 Mbps| 8.00|put http://localhost:7333/p 40.0 GB
Job 22| 0 bps| 2.1 Gbps| 8.00|put http://localhost:7333/p 40.0 GB
Job 23| 0 bps| 603.0 Mbps| 8.00|put http://localhost:7333/p 40.0 GB
Job 24| 0 bps| 431.1 Mbps| 8.00|put http://localhost:7333/p 40.0 GB
Job 25| 0 bps| 423.0 Mbps| 8.00|put http://localhost:7333/p 40.0 GB
Job 26| 0 bps| 596.3 Mbps| 8.00|put http://localhost:7333/p 40.0 GB
Job 27| 0 bps| 590.8 Mbps| 8.00|put http://localhost:7333/p 40.0 GB
Job 28| 0 bps| 3.7 Gbps| 8.00|put http://localhost:7333/p 40.0 GB
Job 29| 0 bps| 6.6 Gbps| 8.00|put http://localhost:7333/p 40.0 GB
Job 30| 0 bps| 601.8 Mbps| 8.00|put http://localhost:7333/p 40.0 GB
Job 31| 0 bps| 828.4 Mbps| 8.00|put http://localhost:7333/p 40.0 GB
Job 32| 0 bps| 835.1 Mbps| 8.00|put http://localhost:7333/p 40.0 GB
Total| 12.7 Gbps| 24.7 Gbps| 8.00|
-
5 fois d'affilé avec 16 flux c'est pas vraiment constant :
Total| 25.6 Gbps| 5.3 Gbps| 8.00|
Total| 20.0 Gbps| 14.9 Gbps| 8.00|
Total| 25.6 Gbps| 13.9 Gbps| 8.00|
Total| 17.2 Gbps| 14.6 Gbps| 8.01|
Total| 28.1 Gbps| 10.8 Gbps| 8.00|
-
Windows 10 5950x :
.\nspeed_windows_amd64.exe server -n 2 get -w 1 -n 1 http://localhost:7333/g/40g put -w 1 -n 1 http://localhost:7333/p 40g
Jobs:
0 server {Address: "localhost", port: 7333, IPversion: 0, max_size: 40.0 GB, max_request duration: 10000000000, UseTLS: false, maxruns: 2, max life: 0s}
1 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 0, timeout: 8s}
2 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 0, timeout: 8s,size: 40000000000 (40.0 GB)}
|←[32m 2←[0m|←[32m 5←[0m|←[32m 21←[0m|←[32m 2←[0m|←[32m 0←[0m|←[32m 3←[0m|←[32m 6←[0m|←[32m 3←[0m|←[32m 2←[0m|←[32m 6←[0m|←[32m 3←[0m|←[32m 6←[0m|←[32m 2←[0m|←[32m 3←[0m|←[32m 6←[0m|←[32m 17←[0m|←[32m 2←[0m|←[32m 3←[0m|←[32m 5←[0m|←[32m 5←[0m|←[32m 16←[0m|←[32m 30←[0m|←[32m 0←[0m|←[32m 5←[0m|←[32m 0←[0m|←[32m 5←[0m|←[32m 0←[0m|←[32m 3←[0m|←[32m 2←[0m|←[32m 5←[0m|←[32m 3←[0m|←[32m 5←[0m|, active jobs: 3 / active goroutines: 11
|←[32m 2←[0m|←[32m 5←[0m|←[32m 5←[0m|←[32m 43←[0m|←[32m 2←[0m|←[32m 49←[0m|←[32m 0←[0m|←[32m 43←[0m|←[32m 0←[0m|←[32m 9←[0m|←[32m 37←[0m|←[32m 9←[0m|←[32m 5←[0m|←[32m 2←[0m|←[33m 76←[0m|←[32m 5←[0m|←[32m 3←[0m|←[32m 3←[0m|←[32m 6←[0m|←[32m 0←[0m|←[32m 25←[0m|←[33m 65←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 2←[0m|←[32m 8←[0m|←[32m 2←[0m|←[32m 2←[0m|←[32m 0←[0m|←[32m 2←[0m|←[32m 2←[0m|, active jobs: 3 / active goroutines: 14
|←[32m 2←[0m|←[32m 2←[0m|←[32m 6←[0m|←[32m 38←[0m|←[32m 2←[0m|←[32m 36←[0m|←[32m 0←[0m|←[32m 29←[0m|←[32m 5←[0m|←[32m 5←[0m|←[32m 38←[0m|←[32m 6←[0m|←[32m 0←[0m|←[32m 8←[0m|←[31m100←[0m|←[32m 0←[0m|←[32m 2←[0m|←[32m 5←[0m|←[32m 6←[0m|←[32m 0←[0m|←[32m 45←[0m|←[33m 55←[0m|←[32m 3←[0m|←[32m 0←[0m|←[32m 2←[0m|←[32m 0←[0m|←[32m 2←[0m|←[32m 2←[0m|←[32m 2←[0m|←[32m 0←[0m|←[32m 2←[0m|←[32m 5←[0m|, active jobs: 3 / active goroutines: 14
|←[32m 3←[0m|←[32m 3←[0m|←[32m 13←[0m|←[32m 36←[0m|←[32m 2←[0m|←[32m 28←[0m|←[32m 5←[0m|←[32m 25←[0m|←[32m 5←[0m|←[32m 8←[0m|←[32m 22←[0m|←[32m 25←[0m|←[32m 16←[0m|←[32m 3←[0m|←[31m 92←[0m|←[32m 2←[0m|←[32m 2←[0m|←[32m 2←[0m|←[32m 15←[0m|←[32m 5←[0m|←[32m 34←[0m|←[33m 59←[0m|←[32m 3←[0m|←[32m 6←[0m|←[32m 2←[0m|←[32m 2←[0m|←[32m 2←[0m|←[32m 2←[0m|←[32m 2←[0m|←[32m 2←[0m|←[32m 3←[0m|←[32m 11←[0m|, active jobs: 3 / active goroutines: 14
|←[32m 3←[0m|←[32m 3←[0m|←[32m 47←[0m|←[32m 28←[0m|←[32m 3←[0m|←[32m 30←[0m|←[32m 6←[0m|←[32m 3←[0m|←[32m 2←[0m|←[32m 8←[0m|←[32m 8←[0m|←[32m 28←[0m|←[32m 45←[0m|←[32m 5←[0m|←[33m 75←[0m|←[32m 20←[0m|←[32m 2←[0m|←[32m 5←[0m|←[32m 6←[0m|←[32m 3←[0m|←[32m 44←[0m|←[32m 50←[0m|←[32m 2←[0m|←[32m 2←[0m|←[32m 8←[0m|←[32m 2←[0m|←[32m 2←[0m|←[32m 2←[0m|←[32m 2←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 6←[0m|, active jobs: 3 / active goroutines: 14
|←[32m 6←[0m|←[32m 2←[0m|←[32m 50←[0m|←[32m 36←[0m|←[32m 11←[0m|←[32m 42←[0m|←[32m 2←[0m|←[32m 6←[0m|←[32m 6←[0m|←[32m 14←[0m|←[32m 2←[0m|←[32m 0←[0m|←[32m 19←[0m|←[32m 3←[0m|←[33m 59←[0m|←[32m 16←[0m|←[32m 2←[0m|←[32m 0←[0m|←[32m 13←[0m|←[32m 0←[0m|←[33m 55←[0m|←[32m 45←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 3←[0m|←[32m 6←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 2←[0m|←[32m 0←[0m|, active jobs: 3 / active goroutines: 14
|←[32m 2←[0m|←[32m 3←[0m|←[32m 34←[0m|←[32m 36←[0m|←[32m 6←[0m|←[32m 38←[0m|←[32m 8←[0m|←[32m 3←[0m|←[32m 2←[0m|←[32m 9←[0m|←[32m 13←[0m|←[32m 5←[0m|←[32m 28←[0m|←[32m 0←[0m|←[31m 86←[0m|←[32m 2←[0m|←[32m 0←[0m|←[32m 2←[0m|←[32m 5←[0m|←[32m 0←[0m|←[32m 48←[0m|←[32m 41←[0m|←[32m 0←[0m|←[32m 3←[0m|←[32m 5←[0m|←[32m 0←[0m|←[32m 8←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 6←[0m|←[32m 3←[0m|, active jobs: 3 / active goroutines: 14
|←[32m 2←[0m|←[32m 5←[0m|←[32m 39←[0m|←[32m 28←[0m|←[32m 9←[0m|←[32m 47←[0m|←[32m 8←[0m|←[32m 2←[0m|←[32m 3←[0m|←[32m 6←[0m|←[32m 5←[0m|←[32m 30←[0m|←[32m 2←[0m|←[32m 2←[0m|←[33m 78←[0m|←[32m 5←[0m|←[32m 0←[0m|←[32m 5←[0m|←[32m 17←[0m|←[32m 11←[0m|←[32m 22←[0m|←[33m 67←[0m|←[32m 0←[0m|←[32m 3←[0m|←[32m 0←[0m|←[32m 8←[0m|←[32m 8←[0m|←[32m 2←[0m|←[32m 0←[0m|←[32m 3←[0m|←[32m 2←[0m|←[32m 5←[0m|, active jobs: 3 / active goroutines: 14
|←[32m 27←[0m|←[32m 3←[0m|←[32m 22←[0m|←[32m 14←[0m|←[32m 3←[0m|←[32m 34←[0m|←[32m 5←[0m|←[32m 11←[0m|←[32m 0←[0m|←[32m 35←[0m|←[32m 5←[0m|←[32m 5←[0m|←[32m 0←[0m|←[32m 28←[0m|←[31m 86←[0m|←[32m 2←[0m|←[32m 0←[0m|←[32m 2←[0m|←[32m 6←[0m|←[32m 0←[0m|←[32m 18←[0m|←[33m 77←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 2←[0m|←[32m 5←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 5←[0m|, active jobs: 3 / active goroutines: 14
Job| Read| Write| Time|target
Job 1| 16.0 Gbps| 0 bps| 8.00|get http://localhost:7333/g/40g
Job 2| 0 bps| 16.0 Gbps| 8.00|put http://localhost:7333/p 40.0 GB
Total| 16.0 Gbps| 16.0 Gbps| 8.00|
.\nspeed_windows_amd64.exe server -n 16 get -w 1 -n 8 http://localhost:7333/g/40g put -w 1 -n 8 http://localhost:7333/p 40g
Jobs:
0 server {Address: "localhost", port: 7333, IPversion: 0, max_size: 40.0 GB, max_request duration: 10000000000, UseTLS: false, maxruns: 16, max life: 0s}
1 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 0, timeout: 8s}
2 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 1, timeout: 8s}
3 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 2, timeout: 8s}
4 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 3, timeout: 8s}
5 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 4, timeout: 8s}
6 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 5, timeout: 8s}
7 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 6, timeout: 8s}
8 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 7, timeout: 8s}
9 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 0, timeout: 8s,size: 40000000000 (40.0 GB)}
10 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 1, timeout: 8s,size: 40000000000 (40.0 GB)}
11 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 2, timeout: 8s,size: 40000000000 (40.0 GB)}
12 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 3, timeout: 8s,size: 40000000000 (40.0 GB)}
13 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 4, timeout: 8s,size: 40000000000 (40.0 GB)}
14 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 5, timeout: 8s,size: 40000000000 (40.0 GB)}
15 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 6, timeout: 8s,size: 40000000000 (40.0 GB)}
16 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 7, timeout: 8s,size: 40000000000 (40.0 GB)}
|←[32m 5←[0m|←[32m 2←[0m|←[32m 8←[0m|←[32m 3←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 1←[0m|←[32m 0←[0m|←[32m 4←[0m|←[32m 2←[0m|←[32m 1←[0m|←[32m 1←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 6←[0m|←[32m 0←[0m|←[32m 13←[0m|←[32m 11←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 1←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 0←[0m|←[32m 5←[0m|, active jobs: 17 / active goroutines: 38
|←[32m 30←[0m|←[32m 34←[0m|←[31m100←[0m|←[32m 0←[0m|←[32m 21←[0m|←[32m 22←[0m|←[32m 40←[0m|←[32m 32←[0m|←[32m 19←[0m|←[32m 29←[0m|←[33m 67←[0m|←[32m 12←[0m|←[32m 38←[0m|←[32m 38←[0m|←[31m100←[0m|←[32m 2←[0m|←[32m 17←[0m|←[32m 19←[0m|←[32m 27←[0m|←[32m 13←[0m|←[33m 52←[0m|←[32m 38←[0m|←[32m 20←[0m|←[32m 14←[0m|←[32m 19←[0m|←[32m 8←[0m|←[32m 27←[0m|←[32m 14←[0m|←[32m 16←[0m|←[32m 16←[0m|←[32m 27←[0m|←[32m 17←[0m|, active jobs: 17 / active goroutines: 77
|←[32m 31←[0m|←[32m 34←[0m|←[31m100←[0m|←[32m 8←[0m|←[32m 13←[0m|←[32m 48←[0m|←[32m 31←[0m|←[32m 44←[0m|←[32m 31←[0m|←[32m 22←[0m|←[33m 53←[0m|←[32m 25←[0m|←[33m 58←[0m|←[32m 8←[0m|←[31m100←[0m|←[32m 0←[0m|←[32m 27←[0m|←[32m 8←[0m|←[32m 23←[0m|←[32m 17←[0m|←[33m 57←[0m|←[32m 38←[0m|←[32m 17←[0m|←[32m 17←[0m|←[32m 25←[0m|←[32m 13←[0m|←[32m 31←[0m|←[32m 11←[0m|←[32m 23←[0m|←[32m 16←[0m|←[32m 25←[0m|←[32m 22←[0m|, active jobs: 17 / active goroutines: 77
|←[32m 19←[0m|←[32m 36←[0m|←[31m100←[0m|←[32m 2←[0m|←[32m 17←[0m|←[32m 44←[0m|←[32m 48←[0m|←[32m 28←[0m|←[32m 36←[0m|←[32m 9←[0m|←[33m 54←[0m|←[32m 29←[0m|←[32m 28←[0m|←[32m 31←[0m|←[31m100←[0m|←[32m 0←[0m|←[32m 25←[0m|←[32m 13←[0m|←[32m 30←[0m|←[32m 16←[0m|←[33m 56←[0m|←[32m 32←[0m|←[32m 20←[0m|←[32m 11←[0m|←[32m 25←[0m|←[32m 11←[0m|←[32m 30←[0m|←[32m 13←[0m|←[32m 28←[0m|←[32m 6←[0m|←[32m 17←[0m|←[32m 14←[0m|, active jobs: 17 / active goroutines: 77
|←[32m 39←[0m|←[32m 28←[0m|←[31m100←[0m|←[32m 2←[0m|←[32m 30←[0m|←[32m 25←[0m|←[32m 42←[0m|←[32m 28←[0m|←[32m 42←[0m|←[32m 8←[0m|←[32m 42←[0m|←[32m 38←[0m|←[32m 14←[0m|←[32m 30←[0m|←[31m100←[0m|←[32m 0←[0m|←[32m 16←[0m|←[32m 17←[0m|←[32m 23←[0m|←[32m 9←[0m|←[33m 52←[0m|←[32m 42←[0m|←[32m 20←[0m|←[32m 11←[0m|←[32m 19←[0m|←[32m 14←[0m|←[32m 30←[0m|←[32m 11←[0m|←[32m 22←[0m|←[32m 11←[0m|←[32m 14←[0m|←[32m 8←[0m|, active jobs: 17 / active goroutines: 77
|←[32m 47←[0m|←[32m 19←[0m|←[31m 81←[0m|←[32m 20←[0m|←[32m 34←[0m|←[32m 36←[0m|←[32m 39←[0m|←[32m 30←[0m|←[32m 45←[0m|←[32m 11←[0m|←[33m 52←[0m|←[32m 17←[0m|←[32m 27←[0m|←[32m 20←[0m|←[31m100←[0m|←[32m 0←[0m|←[32m 28←[0m|←[32m 11←[0m|←[32m 23←[0m|←[32m 27←[0m|←[33m 59←[0m|←[32m 25←[0m|←[32m 17←[0m|←[32m 18←[0m|←[32m 20←[0m|←[32m 13←[0m|←[32m 31←[0m|←[32m 3←[0m|←[32m 17←[0m|←[32m 13←[0m|←[32m 11←[0m|←[32m 8←[0m|, active jobs: 17 / active goroutines: 77
|←[32m 9←[0m|←[32m 45←[0m|←[32m 10←[0m|←[31m100←[0m|←[32m 25←[0m|←[32m 41←[0m|←[32m 34←[0m|←[32m 31←[0m|←[32m 30←[0m|←[32m 16←[0m|←[33m 63←[0m|←[32m 19←[0m|←[32m 33←[0m|←[32m 25←[0m|←[31m 98←[0m|←[32m 2←[0m|←[32m 20←[0m|←[32m 22←[0m|←[32m 28←[0m|←[32m 3←[0m|←[33m 63←[0m|←[32m 33←[0m|←[32m 16←[0m|←[32m 11←[0m|←[32m 23←[0m|←[32m 16←[0m|←[32m 25←[0m|←[32m 3←[0m|←[32m 27←[0m|←[32m 5←[0m|←[32m 22←[0m|←[32m 11←[0m|, active jobs: 17 / active goroutines: 77
|←[32m 9←[0m|←[32m 33←[0m|←[32m 0←[0m|←[31m100←[0m|←[32m 39←[0m|←[32m 33←[0m|←[32m 48←[0m|←[32m 20←[0m|←[33m 52←[0m|←[32m 16←[0m|←[33m 63←[0m|←[32m 17←[0m|←[32m 17←[0m|←[32m 45←[0m|←[31m100←[0m|←[32m 0←[0m|←[32m 25←[0m|←[32m 20←[0m|←[32m 28←[0m|←[32m 9←[0m|←[33m 56←[0m|←[32m 39←[0m|←[32m 23←[0m|←[32m 11←[0m|←[32m 34←[0m|←[32m 3←[0m|←[32m 27←[0m|←[32m 9←[0m|←[32m 31←[0m|←[32m 8←[0m|←[32m 17←[0m|←[32m 9←[0m|, active jobs: 17 / active goroutines: 77
|←[32m 11←[0m|←[32m 19←[0m|←[32m 3←[0m|←[31m100←[0m|←[32m 50←[0m|←[32m 28←[0m|←[32m 31←[0m|←[32m 31←[0m|←[32m 34←[0m|←[32m 42←[0m|←[32m 34←[0m|←[32m 35←[0m|←[32m 17←[0m|←[32m 47←[0m|←[31m 97←[0m|←[32m 6←[0m|←[32m 25←[0m|←[32m 16←[0m|←[32m 28←[0m|←[32m 17←[0m|←[33m 52←[0m|←[32m 39←[0m|←[32m 19←[0m|←[32m 23←[0m|←[32m 13←[0m|←[32m 19←[0m|←[32m 22←[0m|←[32m 14←[0m|←[32m 17←[0m|←[32m 14←[0m|←[32m 9←[0m|←[32m 22←[0m|, active jobs: 17 / active goroutines: 77
Job| Read| Write| Time|target
Job 1| 4.1 Gbps| 0 bps| 8.00|get http://localhost:7333/g/40g
Job 2| 2.2 Gbps| 0 bps| 8.00|get http://localhost:7333/g/40g
Job 3| 2.1 Gbps| 0 bps| 8.00|get http://localhost:7333/g/40g
Job 4| 4.1 Gbps| 0 bps| 8.00|get http://localhost:7333/g/40g
Job 5| 1.1 Gbps| 0 bps| 8.00|get http://localhost:7333/g/40g
Job 6| 1.4 Gbps| 0 bps| 8.00|get http://localhost:7333/g/40g
Job 7| 1.4 Gbps| 0 bps| 8.00|get http://localhost:7333/g/40g
Job 8| 4.1 Gbps| 0 bps| 8.00|get http://localhost:7333/g/40g
Job 9| 0 bps| 2.1 Gbps| 8.00|put http://localhost:7333/p 40.0 GB
Job 10| 0 bps| 2.1 Gbps| 8.00|put http://localhost:7333/p 40.0 GB
Job 11| 0 bps| 2.1 Gbps| 8.00|put http://localhost:7333/p 40.0 GB
Job 12| 0 bps| 2.1 Gbps| 8.00|put http://localhost:7333/p 40.0 GB
Job 13| 0 bps| 2.1 Gbps| 8.00|put http://localhost:7333/p 40.0 GB
Job 14| 0 bps| 2.1 Gbps| 8.00|put http://localhost:7333/p 40.0 GB
Job 15| 0 bps| 4.0 Gbps| 8.00|put http://localhost:7333/p 40.0 GB
Job 16| 0 bps| 4.0 Gbps| 8.00|put http://localhost:7333/p 40.0 GB
Total| 20.5 Gbps| 20.7 Gbps| 8.00|
-
Oui j'ai bien la V0.6, la 0.5 même problème.
Curl fonctionne bien
En -n 1 même erreur
Pas de problème sur Windows, bizarre :P
ca doit être la résolution DNS, Go utilise par défaut un résolveur interne sur Linux. J'ai pas forcé a autre chose.
J'ai enlevé l'affichage des résolutions DNS depuis la v.05 je vais les remettre.
sinon tu peux lancer nspeed avec une variable d'env GODEBUG=netdns=cgo avant pour changer le comportement du résolveur. (pour les curieux voir https://golang.org/pkg/net/#hdr-Name_Resolution )
GODEBUG=netdns=cgo nspeed_linux_amd64 -verbose get -4 -n 1 http://scaleway.testdebit.info/10G/10G.dat
si ce n'est pas le problème je sèche :)
-
5 fois d'affilé avec 16 flux c'est pas vraiment constant :
Total| 25.6 Gbps| 5.3 Gbps| 8.00|
Total| 20.0 Gbps| 14.9 Gbps| 8.00|
Total| 25.6 Gbps| 13.9 Gbps| 8.00|
Total| 17.2 Gbps| 14.6 Gbps| 8.01|
Total| 28.1 Gbps| 10.8 Gbps| 8.00|
oui curieux. t'as un antivirus réseau ou autre ?
-
oui curieux. t'as un antivirus réseau ou autre ?
juste windows defender. par contre j'ai vu apres mon cpu c'est 12 coeurs, ca doit jouer ?
-
juste windows defender. par contre j'ai vu apres mon cpu c'est 12 coeurs, ca doit jouer ?
peut-être je n'ai pas trop testé cette partie la. essai avec 12 ou 24 pour voir.
-
ca doit être la résolution DNS, Go utilise par défaut un résolveur interne sur Linux. J'ai pas forcé a autre chose.
J'ai enlevé l'affichage des résolutions DNS depuis la v.05 je vais les remettre.
sinon tu peux lancer nspeed avec une variable d'env GODEBUG=netdns=cgo avant pour changer le comportement du résolveur. (pour les curieux voir https://golang.org/pkg/net/#hdr-Name_Resolution )
GODEBUG=netdns=cgo nspeed_linux_amd64 -verbose get -4 -n 1 http://scaleway.testdebit.info/10G/10G.dat
si ce n'est pas le problème je sèche :)
GODEBUG=netdns=cgo nspeed_linux_amd64 -verbose get -4 -n 1 http://scaleway.testdebit.info/10G/10G.dat
Jobs:
0 {Command: GET, URL: "http://scaleway.testdebit.info/10G/10G.dat", IPversion: 4, Address: , Instance: 0, timeout: 8s}
| 10| 1| 2| 3| 2| 3| 1| 0| 4| 2| 0| 0| 0| 0| 2| 0|, active jobs: 1 / active goroutines: 7
| 9| 1| 0| 3| 1| 3| 2| 1| 0| 0| 2| 1| 4| 2| 5| 1|, active jobs: 1 / active goroutines: 7
| 8| 0| 1| 1| 4| 5| 2| 0| 2| 1| 0| 0| 1| 1| 3| 1|, active jobs: 1 / active goroutines: 7
| 10| 2| 4| 0| 2| 1| 1| 2| 1| 1| 0| 1| 3| 1| 0| 1|, active jobs: 1 / active goroutines: 7
| 9| 0| 1| 4| 1| 0| 1| 0| 5| 2| 0| 0| 4| 2| 1| 0|, active jobs: 1 / active goroutines: 7
9:08PM FTL error="Get \"http://scaleway.testdebit.info/10G/10G.dat\": dial tcp: i/o timeout" job=0
-
:o :o ;D
et avec google.com aussi?
GODEBUG=netdns=1 nspeed_linux_amd64 -verbose get -4 -n 1 https://google.com
GODEBUG=netdns=cgo+1 nspeed_linux_amd64 -verbose get -4 -n 1 https://google.com
sinon:
curl -o nspeed4 https://dl.nspeed.app/nspeed-client/v0.4/nspeed_linux_amd64
chmod +x nspeed4
./nspeed4 -verbose get https://google.com get http://scaleway.testdebit.info
rm ./nspeed4
qu'y a t'il apres les "LookupIp for ..." ?
-
Même résultat avec Google
Nspeed 0.4
DEBU[0000] max cores = 16
Jobs:
0 GET {URL: "https://google.com", IPversion: 0, Instance: 0, timeout: 8s}
1 GET {URL: "http://scaleway.testdebit.info", IPversion: 0, Instance: 0, timeout: 8s}
DEBU[0000] spawning workload 0 https://google.com false
DEBU[0000] spawning workload 1 http://scaleway.testdebit.info false
DEBU[0001] cpu 0 8 core#0=9.090909085564034 core#1=0 core#10=0.9999999980209395 core#11=0 core#12=4.999999997962732 core#13=1.0000000004656613 core#14=0 core#15=2.02020201963782 core#2=1.0000000013969839 core#3=2.0000000004074536 core#4=2.02020201963782 core#5=1.9801980197306543 core#6=1.0101010093437939 core#7=2.0000000004074536 core#8=2.9702970302450473 core#9=0
INFO[0001] #0;0;0 B;0 B;0;https://google.com
INFO[0001] #1;0;0 B;0 B;0;http://scaleway.testdebit.info
DEBU[0002] cpu 0 8 core#0=8.163265307940682 core#1=0 core#10=4.000000000814907 core#11=3.0303030295012716 core#12=1.0000000013969839 core#13=0 core#14=2.020202020157478 core#15=0 core#2=0.9999999975552781 core#3=0 core#4=3.9603960394613087 core#5=0 core#6=1.0000000009313226 core#7=0 core#8=0 core#9=1.0204081627501405
INFO[0002] #0;0;0 B;0 B;0;https://google.com
INFO[0002] #1;0;0 B;0 B;0;http://scaleway.testdebit.info
DEBU[0003] cpu 0 8 core#0=9.090909091443597 core#1=1.0000000009313226 core#10=0 core#11=5.050505053504221 core#12=0.9999999975552781 core#13=1.9607843126624898 core#14=1.980198020643626 core#15=5.00000000174623 core#2=4.000000000814907 core#3=0.999999999476131 core#4=0.999999999476131 core#5=0.999999999476131 core#6=0 core#7=0.9900990096014213 core#8=0.9900990105857189 core#9=2.0000000004074536
INFO[0003] #0;0;0 B;0 B;0;https://google.com
INFO[0003] #1;0;0 B;0 B;0;http://scaleway.testdebit.info
DEBU[0003] LookupIp for google.com
DEBU[0003] 2a00:1450:4007:80f::200e
DEBU[0003] 216.58.206.238
DEBU[0003] LookupIp for scaleway.testdebit.info
DEBU[0003] 2001:bc8:3::7
DEBU[0003] 62.210.156.7
DEBU[0004] cpu 0 10 core#0=10.10101010112888 core#1=3.999999997904524 core#10=0 core#11=5.999999999767169 core#12=0 core#13=0 core#14=1.01010100981891 core#15=0.9999999975552781 core#2=0 core#3=1.0000000009313226 core#4=4.040404040314956 core#5=0 core#6=1.999999998952262 core#7=0 core#8=3.03030303092662 core#9=1.0000000009313226
INFO[0004] #0;0;0 B;0 B;0;https://google.com
INFO[0004] #1;0;0 B;0 B;0;http://scaleway.testdebit.info
DEBU[0005] cpu 0 10 core#0=10.10101010225728 core#1=2.0202020216273686 core#10=0.9900990105857189 core#11=1.999999998952262 core#12=2.9999999998835847 core#13=1.0101010112888003 core#14=3.9999999993597157 core#15=0 core#2=3.960396041287252 core#3=1.9801980192028426 core#4=1.01010100981891 core#5=1.0000000009313226 core#6=1.0101010112888003 core#7=0.999999999476131 core#8=0 core#9=0
INFO[0005] #0;0;0 B;0 B;0;https://google.com
INFO[0005] #1;0;0 B;0 B;0;http://scaleway.testdebit.info
DEBU[0006] cpu 0 10 core#0=9.09090908984008 core#1=1.01010100981891 core#10=0 core#11=0 core#12=1.9801980220844098 core#13=0.999999999476131 core#14=4.000000000814907 core#15=0 core#2=3.03030302945673 core#3=0 core#4=0.999999999476131 core#5=1.999999998952262 core#6=2.999999998486601 core#7=2.0000000004074536 core#8=1.0101010108136843 core#9=2.020202020157478
INFO[0006] #0;0;0 B;0 B;0;https://google.com
INFO[0006] #1;0;0 B;0 B;0;http://scaleway.testdebit.info
INFO[0006] #1 size = 94.6 kB (92.4 KiB) procotol = HTTP/1.1 local IP:port = [2a05:6xxxxxxxxxxxxxxxxxxx]:44774 remote IP:port = [2001:bc8:3::7]:80 DNSInfoTime = 3.077444274s ConnInfoTime = 3.114009968s FirstResponseByte = 3.150250834s
INFO[0006] job 0 got redirect
INFO[0006] #1 transfered 94642 bytes
DEBU[0007] cpu 1 9 core#0=9.090909091443597 core#1=0.999999999476131 core#10=0 core#11=0 core#12=1.0101010093437939 core#13=0.999999999476131 core#14=2.0000000004074536 core#15=0.9900990110422049 core#2=1.0101010112888003 core#3=5.00000000174623 core#4=4.000000000814907 core#5=2.0202020225776005 core#6=0.9999999999417925 core#7=3.9999999993597157 core#8=0 core#9=1.999999998952262
INFO[0007] #0;0;0 B;0 B;0;https://google.com
INFO[0007] #1;3.265513027;92.4 KiB;92.4 KiB;634;http://scaleway.testdebit.info
DEBU[0008] cpu 1 9 core#0=9.18367347217571 core#1=0 core#10=0 core#11=0 core#12=0 core#13=0 core#14=2.0202020186875878 core#15=1.0000000004656613 core#2=1.9801980197306543 core#3=6.060606059002543 core#4=0 core#5=3.99999999749707 core#6=1.0101010108136843 core#7=0 core#8=3.9999999993597157 core#9=0
INFO[0008] #0;0;0 B;0 B;0;https://google.com
INFO[0008] #1;3.265513027;92.4 KiB;92.4 KiB;634;http://scaleway.testdebit.info
DEBU[0009] cpu 1 7 core#0=9.183673466236153 core#1=1.0000000013969839 core#10=0.999999999476131 core#11=0.9900990110422049 core#12=0 core#13=1.0000000009313226 core#14=1.0101010112888003 core#15=3.999999997904524 core#2=1.0101010093437939 core#3=3.03030303092662 core#4=2.999999998428393 core#5=0.9999999999417925 core#6=2.9999999998835847 core#7=1.0101010108136843 core#8=5.999999999767169 core#9=0.999999999476131
INFO[0009] #0;0;0 B;0 B;0;https://google.com
INFO[0009] #1;3.265513027;92.4 KiB;92.4 KiB;634;http://scaleway.testdebit.info
INFO[0009] #0 size = -1 B (-1 B) procotol = HTTP/2.0 local IP:port = [2a05:6xxxxxxxxxxxxxxxxxxx]:50170 remote IP:port = [2a00:1450:4007:813::2004]:443 DNSInfoTime = 6.428978872s ConnInfoTime = 6.51283548s FirstResponseByte = 6.587627558s
INFO[0009] #0 crypto = TLS13 cipher = TLS_AES_128_GCM_SHA256 TLSDone in = 6.512777021s
INFO[0009] #0 transfered 13057 bytes
DEBU[0009] wait group ended
DEBU[0009] all workers done (3 remaining active goroutines)
DEBU[0009] main loop endedrc = 2
INFO[0009] #0 speed = 31.4 kbps time = 3331 ms (3.3311338360000002 s) size = 13.1 kB (12.8 KiB) url = https://google.com
INFO[0009] #1 speed = 231.9 kbps time = 3265 ms (3.265513027 s) size = 94.6 kB (92.4 KiB) url = http://scaleway.testdebit.info
total: speed = 258.6 kbps time = 3.331133836s size = 107699 Bytes ( 107.7 kB )
-
nspeed 0.6 sur i7 3930K à 4,1Ghz
Même avec un flux ça semble mieux se répartir qu'avant, les performances sont meilleures.
Windows 10 natif :
- 12.0 Gbps| 8.2 Gbps avec 1 flux
- 18.0 Gbps| 18.0 Gbps avec 12 flux
WSL2 :
- 10.8 Gbps| 10.1 Gbps avec 1 flux
- 25.4 Gbps| 27.4 Gbps avec 12 flux
Linux 5.11.12 (Fedora 34) :
- 11.2 Gbps| 11.3 Gbps avec 1 flux
- 33.9 Gbps| 35.0 Gbps avec 12 flux
Windows 10 :
>nspeed_windows_amd64.exe server -n 2 get -w 1 -n 1 http://localhost:7333/g/40g put -w 1 -n 1 http://localhost:7333/p 40g
Jobs:
0 server {Address: "localhost", port: 7333, IPversion: 0, max_size: 40.0 GB, max_request duration: 10000000000, UseTLS: false, maxruns: 2, max life: 0s}
1 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 0, timeout: 8s}
2 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 0, timeout: 8s,size: 40000000000 (40.0 GB)}
| 3| 1| 4| 0| 4| 1| 3| 0| 0| 0| 1| 0|, active jobs: 3 / active goroutines: 7
| 69| 3| 52| 25| 38| 11| 17| 8| 5| 75| 61| 27|, active jobs: 3 / active goroutines: 14
| 80| 3| 8| 66| 30| 2| 14| 9| 11| 73| 45| 42|, active jobs: 3 / active goroutines: 14
| 59| 9| 36| 45| 28| 3| 28| 3| 3| 84| 48| 47|, active jobs: 3 / active goroutines: 14
| 57| 22| 3| 75| 14| 3| 25| 3| 6| 88| 83| 8|, active jobs: 3 / active goroutines: 14
| 38| 50| 25| 50| 56| 9| 39| 5| 14| 64| 17| 27|, active jobs: 3 / active goroutines: 14
| 17| 67| 48| 44| 59| 5| 47| 5| 19| 16| 11| 69|, active jobs: 3 / active goroutines: 14
| 53| 31| 22| 75| 42| 0| 56| 6| 25| 13| 8| 64|, active jobs: 3 / active goroutines: 14
| 41| 48| 42| 34| 61| 3| 41| 2| 25| 30| 20| 38|, active jobs: 3 / active goroutines: 14
Job| Read| Write| Time|target
Job 1| 12.0 Gbps| 0 bps| 8.00|get http://localhost:7333/g/40g
Job 2| 0 bps| 8.2 Gbps| 8.00|put http://localhost:7333/p 40.0 GB
Total| 12.0 Gbps| 8.2 Gbps| 8.00|
WSL2 :
$ ./nspeed_linux_amd64 server -n 2 get -w 1 -n 1 http://localhost:7333/g/40g put -w 1 -n 1 http://localhost:7333/p 40g
Jobs:
0 server {Address: "localhost", port: 7333, IPversion: 0, max_size: 40.0 GB, max_request duration: 10000000000, UseTLS: false, maxruns: 2, max life: 0s}
1 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 0, timeout: 8s}
2 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 0, timeout: 8s,size: 40000000000 (40.0 GB)}
| 0| 1| 0| 0| 0| 1| 1| 0| 0| 0| 0| 0|, active jobs: 3 / active goroutines: 9
| 3| 0| 0| 50| 46| 61| 59| 0| 71| 0| 3| 56|, active jobs: 3 / active goroutines: 14
| 26| 2| 0| 75| 24| 36| 47| 0| 47| 0| 73| 0|, active jobs: 3 / active goroutines: 14
| 70| 1| 17| 45| 72| 0| 34| 0| 63| 26| 14| 0|, active jobs: 3 / active goroutines: 14
| 79| 0| 1| 12| 43| 36| 35| 0| 73| 34| 14| 0|, active jobs: 3 / active goroutines: 14
| 51| 0| 76| 17| 44| 0| 55| 0| 21| 0| 59| 0|, active jobs: 3 / active goroutines: 14
| 59| 1| 0| 25| 57| 1| 82| 0| 49| 0| 55| 0|, active jobs: 3 / active goroutines: 14
| 45| 6| 60| 11| 16| 48| 67| 0| 58| 3| 37| 0|, active jobs: 3 / active goroutines: 14
| 58| 6| 60| 0| 0| 66| 19| 0| 42| 0| 88| 0|, active jobs: 3 / active goroutines: 14
Job| Read| Write| Time|target
Job 1| 10.8 Gbps| 0 bps| 8.00|get http://localhost:7333/g/40g
Job 2| 0 bps| 10.1 Gbps| 8.00|put http://localhost:7333/p 40.0 GB
Total| 10.8 Gbps| 10.1 Gbps| 8.00|
Linux :
$ ./nspeed_linux_amd64 server -n 2 get -w 1 -n 1 http://localhost:7333/g/40g put -w 1 -n 1 http://localhost:7333/p 40g
Jobs:
0 server {Address: "localhost", port: 7333, IPversion: 0, max_size: 40.0 GB, max_request duration: 10000000000, UseTLS: false, maxruns: 2, max life: 0s}
1 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 0, timeout: 8s}
2 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 0, timeout: 8s,size: 40000000000 (40.0 GB)}
| 2| 0| 1| 0| 0| 0| 1| 2| 1| 1| 1| 1|, active jobs: 3 / active goroutines: 9
| 18| 4| 15| 27| 0| 15| 43| 83| 11| 34| 41| 65|, active jobs: 3 / active goroutines: 14
| 81| 1| 1| 4| 0| 0| 0| 77| 47| 33| 61| 45|, active jobs: 3 / active goroutines: 14
| 15| 25| 23| 7| 15| 12| 15| 62| 16| 61| 54| 61|, active jobs: 3 / active goroutines: 14
| 75| 31| 22| 9| 50| 45| 1| 24| 38| 24| 23| 31|, active jobs: 3 / active goroutines: 14
| 2| 76| 48| 6| 63| 20| 52| 16| 8| 54| 2| 28|, active jobs: 3 / active goroutines: 14
| 0| 46| 27| 0| 22| 67| 75| 1| 40| 54| 18| 8|, active jobs: 3 / active goroutines: 14
| 29| 63| 18| 0| 0| 50| 41| 0| 37| 39| 88| 13|, active jobs: 3 / active goroutines: 14
| 23| 27| 41| 26| 25| 5| 28| 25| 42| 17| 81| 34|, active jobs: 3 / active goroutines: 14
Job| Read| Write| Time|target
Job 1| 11.2 Gbps| 0 bps| 8.00|get http://localhost:7333/g/40g
Job 2| 0 bps| 11.3 Gbps| 8.00|put http://localhost:7333/p 40.0 GB
Total| 11.2 Gbps| 11.3 Gbps| 8.00|
Je n'ai mis les logs que sur 1 flux, sinon le message était trop long.
Sur 12 flux, sans surprise tous les coeurs logiques sont saturés.
-
nspeed 0.6 sur Ryzen 5 3500X
Windows a un comportement bizarre :
- sur une build insider : 4 flux (donc 8 transferts, puisque les deux sens sont testés en même temps) sont suffisants sous Windows pour saturer les 6 cœurs.
Le résultat est que parfois ça s'équilibre, mais souvent l'envoi semble avoir la priorité.
- sur une 20H2 : les performances sont moins bonnes, un cœur est à 100% et les autres non (et ajouter des flux ne change rien), mais du coup ça reste équilibré
Bizarrement comparé à l'autre machine, Windows 10 n'a pas l'air de super bien fonctionner, comparé à WSL2.
C'est différent de ce que j'avais vu avant, je suis un peu perplexe.
Et WSL2 bat un Linux natif, surtout sur 1 flux ???
Windows 10 (insider, build 21364) :
- 10.7 Gbps| 11.1 Gbps avec 1 flux
- 7.7 Gbps| 23.0 Gbps, ou 13.8 Gbps| 14.1 Gbps avec 4 flux
Windows 10 (20H2) :
- 10.4 Gbps| 10.4 Gbps avec 1 flux
- 11.3 Gbps| 11.4 Gbps avec 4 flux
WSL2 (build 21364/kernel 5.10, ou 20H2/kernel 5.4) :
- 23.7 Gbps| 28.9 Gbps avec 1 flux
- 32.8 Gbps| 36.4 Gbps avec 3 flux ou plus
Linux 5.11.12 (Fedora 34) :
- 16.3 Gbps| 17.2 Gbps avec 1 flux (avec le CPU governor "performance", légèrement meilleur que "schedutil")
- 30.7 Gbps| 34.0 Gbps avec 3 flux ou plus
Windows 10 21364 :
>nspeed_windows_amd64.exe server -n 2 get -w 1 -n 1 http://localhost:7333/g/40g put -w 1 -n 1 http://localhost:7333/p 40g
Jobs:
0 server {Address: "localhost", port: 7333, IPversion: 0, max_size: 40.0 GB, max_request duration: 10000000000, UseTLS: false, maxruns: 2, max life: 0s}
1 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 0, timeout: 8s}
2 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 0, timeout: 8s,size: 40000000000 (40.0 GB)}
| 4| 0| 3| 1| 1| 6|, active jobs: 3 / active goroutines: 7
| 13| 34| 44| 92| 36| 97|, active jobs: 3 / active goroutines: 14
| 8| 39| 50|100| 22| 95|, active jobs: 3 / active goroutines: 14
| 9| 31| 31| 97| 57| 97|, active jobs: 3 / active goroutines: 14
| 17| 40| 42| 97| 17| 97|, active jobs: 3 / active goroutines: 14
| 23| 33| 43| 91| 39| 91|, active jobs: 3 / active goroutines: 14
| 11| 44| 23| 97| 45| 92|, active jobs: 3 / active goroutines: 14
| 5| 41| 28| 92| 42| 98|, active jobs: 3 / active goroutines: 14
| 3| 27| 25| 95| 58|100|, active jobs: 3 / active goroutines: 14
Job| Read| Write| Time|target
Job 1| 10.7 Gbps| 0 bps| 8.00|get http://localhost:7333/g/40g
Job 2| 0 bps| 11.1 Gbps| 8.00|put http://localhost:7333/p 40.0 GB
Total| 10.7 Gbps| 11.1 Gbps| 8.00|
Windows 10 20H2 4 flux, pas de répartition sur les coeurs :
>nspeed_windows_amd64.exe server -n 8 get -w 1 -n 4 http://localhost:7333/g/40g put -w 1 -n 4 http://localhost:7333/p 40g
Jobs:
0 server {Address: "localhost", port: 7333, IPversion: 0, max_size: 40.0 GB, max_request duration: 10000000000, UseTLS: false, maxruns: 8, max life: 0s}
1 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 0, timeout: 8s}
2 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 1, timeout: 8s}
3 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 2, timeout: 8s}
4 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 3, timeout: 8s}
5 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 0, timeout: 8s,size: 40000000000 (40.0 GB)}
6 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 1, timeout: 8s,size: 40000000000 (40.0 GB)}
7 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 2, timeout: 8s,size: 40000000000 (40.0 GB)}
8 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 3, timeout: 8s,size: 40000000000 (40.0 GB)}
| 2| 0| 2| 3| 2| 0|, active jobs: 9 / active goroutines: 23
| 44| 81| 59| 30| 30|100|, active jobs: 9 / active goroutines: 41
| 55| 88| 72| 31| 33|100|, active jobs: 9 / active goroutines: 41
| 47| 86| 67| 45| 42|100|, active jobs: 9 / active goroutines: 41
| 36| 83| 63| 44| 32|100|, active jobs: 9 / active goroutines: 41
| 36| 77| 51| 50| 35|100|, active jobs: 9 / active goroutines: 41
| 42| 88| 58| 44| 44|100|, active jobs: 9 / active goroutines: 41
| 32| 75| 63| 46| 23|100|, active jobs: 9 / active goroutines: 41
| 56| 86| 51| 48| 41|100|, active jobs: 9 / active goroutines: 41
Job| Read| Write| Time|target
Job 1| 2.8 Gbps| 0 bps| 8.00|get http://localhost:7333/g/40g
Job 2| 2.8 Gbps| 0 bps| 8.00|get http://localhost:7333/g/40g
Job 3| 2.8 Gbps| 0 bps| 8.01|get http://localhost:7333/g/40g
Job 4| 2.8 Gbps| 0 bps| 8.01|get http://localhost:7333/g/40g
Job 5| 0 bps| 2.8 Gbps| 8.01|put http://localhost:7333/p 40.0 GB
Job 6| 0 bps| 2.8 Gbps| 8.01|put http://localhost:7333/p 40.0 GB
Job 7| 0 bps| 2.8 Gbps| 8.01|put http://localhost:7333/p 40.0 GB
Job 8| 0 bps| 2.8 Gbps| 8.01|put http://localhost:7333/p 40.0 GB
Total| 11.3 Gbps| 11.4 Gbps| 8.01|
WSL2 :
$ ./nspeed_linux_amd64 server -n 2 get -w 1 -n 1 http://localhost:7333/g/40g put -w 1 -n 1 http://localhost:7333/p 40g
Jobs:
0 server {Address: "localhost", port: 7333, IPversion: 0, max_size: 40.0 GB, max_request duration: 10000000000, UseTLS: false, maxruns: 2, max life: 0s}
1 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 0, timeout: 8s}
2 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 0, timeout: 8s,size: 40000000000 (40.0 GB)}
| 0| 0| 0| 0| 0| 0|, active jobs: 3 / active goroutines: 7
| 83| 82| 73| 60| 68| 41|, active jobs: 3 / active goroutines: 14
| 80| 23| 76| 79| 77| 78|, active jobs: 3 / active goroutines: 14
| 77| 75| 66| 26| 82| 83|, active jobs: 3 / active goroutines: 14
| 46| 84| 83| 37| 83| 82|, active jobs: 3 / active goroutines: 14
| 42| 35| 74| 79| 90| 87|, active jobs: 3 / active goroutines: 14
| 25| 63| 68| 75| 89| 82|, active jobs: 3 / active goroutines: 14
| 84| 37| 50| 71| 73| 88|, active jobs: 3 / active goroutines: 14
| 82| 53| 65| 77| 84| 47|, active jobs: 3 / active goroutines: 15
Job| Read| Write| Time|target
Job 1| 23.7 Gbps| 0 bps| 8.01|get http://localhost:7333/g/40g
Job 2| 0 bps| 28.9 Gbps| 8.01|put http://localhost:7333/p 40.0 GB
Total| 23.7 Gbps| 28.9 Gbps| 8.01|
Linux 5.11.12 :
$ ./nspeed_linux_amd64 server -n 2 get -w 1 -n 1 http://localhost:7333/g/40g put -w 1 -n 1 http://localhost:7333/p 40g
Jobs:
0 server {Address: "localhost", port: 7333, IPversion: 0, max_size: 40.0 GB, max_request duration: 10000000000, UseTLS: false, maxruns: 2, max life: 0s}
1 {Command: GET, URL: "http://localhost:7333/g/40g", IPversion: 0, Address: , Instance: 0, timeout: 8s}
2 {Command: POST, URL: "http://localhost:7333/p", IPversion: 0, Address: , Instance: 0, timeout: 8s,size: 40000000000 (40.0 GB)}
| 1| 0| 2| 2| 3| 3|, active jobs: 3 / active goroutines: 10
| 56| 53| 66| 49| 62| 63|, active jobs: 3 / active goroutines: 14
| 44| 72| 22| 69| 55| 80|, active jobs: 3 / active goroutines: 14
| 79| 40| 58| 59| 49| 63|, active jobs: 3 / active goroutines: 14
| 47| 85| 49| 50| 37| 86|, active jobs: 3 / active goroutines: 14
| 54| 68| 49| 63| 38| 76|, active jobs: 3 / active goroutines: 14
| 56| 65| 55| 56| 66| 53|, active jobs: 3 / active goroutines: 14
| 58| 44| 67| 73| 63| 44|, active jobs: 3 / active goroutines: 14
| 62| 48| 72| 47| 54| 69|, active jobs: 3 / active goroutines: 14
Job| Read| Write| Time|target
Job 1| 16.3 Gbps| 0 bps| 8.00|get http://localhost:7333/g/40g
Job 2| 0 bps| 17.2 Gbps| 8.00|put http://localhost:7333/p 40.0 GB
Total| 16.3 Gbps| 17.2 Gbps| 8.00|
-
Merci pour tout ces tests. Je vais rajouter des métrics supplémentaires dans la prochaine version. J'ai l'impression que sur Windows, en réception, il y a bien plus d'échange entre le code et l'OS (plus d'appels systèmes).Sans doute une histoire de taille de buffer ou autre mais je ne trouve pas trop ou d'autant que ne c'est pas spécifique a nspeed. iperf3 et curl ont le même souci aussi mais les 2 viennent du monde Linux aussi (peut-être la couche POSIX de Windows n'est pas performante a ce niveau?). Ce n'est pas étonnant donc que WSL soit plus performant.
Mais ca n'explique pas l'écart Intel / Ryzen. J'ai pas de Windows sur Intel et j'ai des bizarrerie de perf en réception sur Windows/Ryzen. Sur un LAN 10Gbps, curl, iperf3 plafonnent a 6Gbps en réception mono session tcp avec un cœur a 100% la ou l'envoi sature le lien 10Gbps avec a peine 40% d'un cœur. J'ai testé avec une carte Intel 82599 et une Aquantia,pareil.
Il faudrait trouver un outil de de transfert (style curl) ou de débit (style iperf) fait pour Windows (pas un port depuis Linux donc), avec code source, qu'on trace les différences au niveau appels systèmes.
-
iperf3 passe par Cygwin, mais curl utilise directement winsock.
De mémoire ils étaient plus performants, mais là avec le dernier test on a l'émission et la réception en même temps.
Pour WSL, je parle de WSL2, qui tant qu'on est en localhost est une VM Linux comme une autre (mais il arrive à être plus rapide qu'un Linux natif sur un flux sur le Ryzen, c'est étrange).
WSL1, qui implémente les syscalls dans le kernel Windows, est catastrophique en comparaison : seulement 2Gbps.
La réception sur une vraie interface dépend du contrôle de la modération d'interruptions, qui fait parfois des choses bizarres, et du RSS pour répartir sur les coeurs quand il y a plusieurs flux.
En émission c'est plus simple, car ce sont directement de plus gros blocs de données qui sont envoyés, et découpés par la carte.
-
Pour WSL, je parle de WSL2, qui tant qu'on est en localhost est une VM Linux comme une autre (mais il arrive à être plus rapide qu'un Linux natif sur un flux sur le Ryzen, c'est étrange).
WSL1, qui implémente les syscalls dans le kernel Windows, est catastrophique en comparaison : seulement 2Gbps.
oui on parle bien de WSL= WSL2 pour moi (WSL1 n'existe quasi plus dans mon esprit :) et je n'ai même pas testé avec)
La réception sur une vraie interface dépend du contrôle de la modération d'interruptions, qui fait parfois des choses bizarres, et du RSS pour répartir sur les coeurs quand il y a plusieurs flux.
En émission c'est plus simple, car ce sont directement de plus gros blocs de données qui sont envoyés, et découpés par la carte.
completement d'accord. c'est juste que sur la même machine, Windows fait moins bien que Linux en réception mono-flux et surtout n'arrive pas au max du réseau avec un CPU très performant (Ryzen 9).
Apres c'est peut-être un souci avec les Ryzen et Windows ? Mais le test localhost justement démontre déjà moins de performance en réception entre Windows et Linux a ce niveau.
bref si j'élimine le RSS/cores car un seul flux et si j'élimine aussi carrément la carté réseau (localhost) , en réception et qu'en réception Windows est moins performant. Est-ce propre a Windows ou est-ce le portage sur Windows via Cygwin (iperf) ou MinGW (curl, Go) qui n'est pas optimum ? c'est la ou je m’interroge.
-
oui on parle bien de WSL= WSL2 pour moi (WSL1 n'existe quasi plus dans mon esprit :) et je n'ai même pas testé avec)
C'est important de ne pas l'oublier, parce que si certaines personnes veulent tester avec WSL, elles risquent de se retrouver avec WSL1 : ma MSI X570 Tomahawk avait la virtualisation désactivée par défault !
bref si j'élimine le RSS/cores car un seul flux et si j'élimine aussi carrément la carté réseau (localhost) , en réception et qu'en réception Windows est moins performant. Est-ce propre a Windows ou est-ce le portage sur Windows via Cygwin (iperf) ou MinGW (curl, Go) qui n'est pas optimum ? c'est la ou je m’interroge.
Le test avec 1 flux semble plus compliqué que 1 thread get + 1 thread put + 1 ou 2 threads server (ou alors les OS déplacent les threads d'un coeur à l'autre).
Curl n'utilise pas nécessairement MinGW, il est possible de compiler avec Visual C++.
L'API est WinSock, mais peut-être qu'il existe des extensions qui seraient utiles pour un test de débit (par exemple TransmitFile en émission) et qui ne sont pas exploitées, ou un paramétrage non optimal.
-
Curl n'utilise pas nécessairement MinGW, il est possible de compiler avec Visual C++.
L'API est WinSock, mais peut-être qu'il existe des extensions qui seraient utiles pour un test de débit (par exemple TransmitFile en émission) et qui ne sont pas exploitées, ou un paramétrage non optimal.
oui possible. la distrib que tout le monde utilise ( https://curl.se/windows/ ) est compilée avec mingw.
Apres toutes ces 'couches" intermédiaires appellent WinSock de toute façon. cf en Go: https://golang.org/src/net/fd_windows.go (c'est bien WSARecv qui est utilisé).
Mais je ne vais pas traîner plus la dessus: tant que nspeed est au meme niveau que curl et iperf3, ca me suffit pour le moment.
-
Mais je ne vais pas traîner plus la dessus: tant que nspeed est au meme niveau que curl et iperf3, ca me suffit pour le moment.
J'ai un léger écart, mais ce que je vois c'est surtout que Windows semble très incohérent.
Sur le 3500X avec un serveur nspeed local :
- un client nspeed (dans le même processus, ou séparé) donne entre 9,2Gbps et 11,2Gbps
- le curl 7.55.1 intégré à Windows donne 1110Mo/s, donc à priori un peu moins (à voir, en fonction de ce qui est compté par npeed et curl)
- le curl 7.76.1 officiel donne 15xx-16xxMo/s, soit un peu plus
Sur le 3930K avec un serveur nspeed local :
- un client nspeed (dans le même processus, ou séparé) donne environ 6Gbps (soit la moitié de ce que j'avais hier :o)
- le curl 7.76.1 officiel donne 800Mo/s à 1000Mo/s, c'est assez variable
Dans le test combiné réception/envoi, j'avais 12.0 Gbps/8.2 Gbps, et là j'ai fait 6.5 Gbps/10.8 Gbps puis 7.0 Gbps/12.5 Gbps.
Peut-être que le get plus lent permet un put plus rapide.
J'ai l'impression qu'il essaye de garder nspeed et curl sur le même coeur, jusqu'à ce que ça sature, d'où un comportement un peu étrange.
Peut-être qu'il faudrait forcer l'affinité.
-
J'ai un léger écart, mais ce que je vois c'est surtout que Windows semble très incohérent.
Sur le 3500X avec un serveur nspeed local :
- un client nspeed (dans le même processus, ou séparé) donne entre 9,2Gbps et 11,2Gbps
- le curl 7.55.1 intégré à Windows donne 1110Mo/s, donc à priori un peu moins (à voir, en fonction de ce qui est compté par npeed et curl)
- le curl 7.76.1 officiel donne 15xx-16xxMo/s, soit un peu plus
Sur le 3930K avec un serveur nspeed local :
- un client nspeed (dans le même processus, ou séparé) donne environ 6Gbps (soit la moitié de ce que j'avais hier :o)
- le curl 7.76.1 officiel donne 800Mo/s à 1000Mo/s, c'est assez variable
J'ai l'impression qu'il essaye de garder nspeed et curl sur le même coeur, jusqu'à ce que ça sature, d'où un comportement un peu étrange.
Peut-être qu'il faudrait forcer l'affinité.
On peut sous cmd utiliser "start /affinity X .\nspeed server" pour fixer l'affinité du server. puis dans une autre fenetre curl et nspeed get avec une autre affinité.( https://docs.microsoft.com/en-us/archive/blogs/santhoshonline/how-to-launch-a-process-with-cpu-affinity-set )
sous Linux y'a taskset.
Je sais qu'iperf3 a un option d'affinité. Je vais voir si c'est compliqué a rajouter en Go mais pas avant la 1.0.
-
L'affinité n'a pas l'air de changer grand chose au final, sauf bien sûr si je force les deux processus a s'exécuter sur le même cœur logique ou physique, où là c'est bien plus lent.
-
L'affinité n'a pas l'air de changer grand chose au final, sauf bien sûr si je force les deux processus a s'exécuter sur le même cœur logique ou physique, où là c'est bien plus lent.
ok bon a savoir. merci.
-
iperf 3.9 Windows, en local sur le 3930K, TCP : 7Gbps à 9Gpbs, parfois 11Gps
C'est donc moins que les 12Gbps de nspeed hier, mais bien mieux que toutes les valeurs d'aujourd'hui.
Certes, du TCP pur c'est peut-être un peu plus simple que du HTTP, mais je ne sais pas si ça justifie un tel écart.
Sur le 3500X, c'est assez variable, mais potentiellement beaucoup plus rapide que nspeed.
Je lance "iperf3.exe -s", et :
- "iperf3.exe -c 127.0.0.1 -R" : 16Gbps à 23Gbps
- "iperf3.exe -c 127.0.0.1 -R -w 32M" : jusqu'à 40Gbps :o (mais parfois seulement un peu plus de 20Gbps)
- "iperf3.exe -c 127.0.0.1 -R -w 32M -l 1M" : j'alterne entre un test à 26-28Gbps, et un test à 44-45Gbps ???
- "iperf3.exe -c 127.0.0.1 -w 32M" : parfois un début à 40Gbps pendant quelques secondes, puis retour à 10Gbps (on ne peut pas mettre l'option "-w" côté serveur, j'ai l'impression que ça manque)
Ce n'est pas mieux avec plusieurs flux, parce que iperf3 est limité par le fait de n'utiliser qu'un seul thread.
-
https://github.com/microsoft/ethr
Je ne connaissais pas, c'est en Go comme nspeed.
Dans le mode par défaut (TCP) sous Windows sur le 3500X :
- un peu plus de 40Gbps avec "-l 128K" ou "-l 256K" (mais pas plus), et "-r" ou pas
- 60Gbps sur deux flux, dans le sens client vers serveur ("-l 256K -n 2")
- 80Gpbs sur deux flux, dans le sens serveur vers client ("-r -l 256K -n 2")
Rajouter plus de flux n'aide pas.
-
https://github.com/microsoft/ethr
Je ne connaissais pas, c'est en Go comme nspeed.
Dans le mode par défaut (TCP) sous Windows sur le 3500X :
- un peu plus de 40Gbps avec "-l 128K" ou "-l 256K" (mais pas plus), et "-r" ou pas
- 60Gbps sur deux flux, dans le sens client vers serveur ("-l 256K -n 2")
- 80Gpbs sur deux flux, dans le sens serveur vers client ("-r -l 256K -n 2")
Rajouter plus de flux n'aide pas.
Pas vu non plus pourtant j'ai cherché longtemps... c'est peut-être ouvert en public depuis peu.
pas mal. y'a peut-être du code a s'inspiré de et ca donne un bon point de comparaison.
en tout cas le code "iperf like" d'ethr peut facilement s'intégrer dans nspeed.
-
Même résultat avec Google
Nspeed 0.4
DEBU[0000] max cores = 16
Jobs:
0 GET {URL: "https://google.com", IPversion: 0, Instance: 0, timeout: 8s}
1 GET {URL: "http://scaleway.testdebit.info", IPversion: 0, Instance: 0, timeout: 8s}
DEBU[0000] spawning workload 0 https://google.com false
DEBU[0000] spawning workload 1 http://scaleway.testdebit.info false
DEBU[0001] cpu 0 8 core#0=9.090909085564034 core#1=0 core#10=0.9999999980209395 core#11=0 core#12=4.999999997962732 core#13=1.0000000004656613 core#14=0 core#15=2.02020201963782 core#2=1.0000000013969839 core#3=2.0000000004074536 core#4=2.02020201963782 core#5=1.9801980197306543 core#6=1.0101010093437939 core#7=2.0000000004074536 core#8=2.9702970302450473 core#9=0
INFO[0001] #0;0;0 B;0 B;0;https://google.com
INFO[0001] #1;0;0 B;0 B;0;http://scaleway.testdebit.info
DEBU[0002] cpu 0 8 core#0=8.163265307940682 core#1=0 core#10=4.000000000814907 core#11=3.0303030295012716 core#12=1.0000000013969839 core#13=0 core#14=2.020202020157478 core#15=0 core#2=0.9999999975552781 core#3=0 core#4=3.9603960394613087 core#5=0 core#6=1.0000000009313226 core#7=0 core#8=0 core#9=1.0204081627501405
INFO[0002] #0;0;0 B;0 B;0;https://google.com
INFO[0002] #1;0;0 B;0 B;0;http://scaleway.testdebit.info
DEBU[0003] cpu 0 8 core#0=9.090909091443597 core#1=1.0000000009313226 core#10=0 core#11=5.050505053504221 core#12=0.9999999975552781 core#13=1.9607843126624898 core#14=1.980198020643626 core#15=5.00000000174623 core#2=4.000000000814907 core#3=0.999999999476131 core#4=0.999999999476131 core#5=0.999999999476131 core#6=0 core#7=0.9900990096014213 core#8=0.9900990105857189 core#9=2.0000000004074536
INFO[0003] #0;0;0 B;0 B;0;https://google.com
INFO[0003] #1;0;0 B;0 B;0;http://scaleway.testdebit.info
DEBU[0003] LookupIp for google.com
DEBU[0003] 2a00:1450:4007:80f::200e
DEBU[0003] 216.58.206.238
DEBU[0003] LookupIp for scaleway.testdebit.info
DEBU[0003] 2001:bc8:3::7
DEBU[0003] 62.210.156.7
DEBU[0004] cpu 0 10 core#0=10.10101010112888 core#1=3.999999997904524 core#10=0 core#11=5.999999999767169 core#12=0 core#13=0 core#14=1.01010100981891 core#15=0.9999999975552781 core#2=0 core#3=1.0000000009313226 core#4=4.040404040314956 core#5=0 core#6=1.999999998952262 core#7=0 core#8=3.03030303092662 core#9=1.0000000009313226
INFO[0004] #0;0;0 B;0 B;0;https://google.com
INFO[0004] #1;0;0 B;0 B;0;http://scaleway.testdebit.info
DEBU[0005] cpu 0 10 core#0=10.10101010225728 core#1=2.0202020216273686 core#10=0.9900990105857189 core#11=1.999999998952262 core#12=2.9999999998835847 core#13=1.0101010112888003 core#14=3.9999999993597157 core#15=0 core#2=3.960396041287252 core#3=1.9801980192028426 core#4=1.01010100981891 core#5=1.0000000009313226 core#6=1.0101010112888003 core#7=0.999999999476131 core#8=0 core#9=0
INFO[0005] #0;0;0 B;0 B;0;https://google.com
INFO[0005] #1;0;0 B;0 B;0;http://scaleway.testdebit.info
DEBU[0006] cpu 0 10 core#0=9.09090908984008 core#1=1.01010100981891 core#10=0 core#11=0 core#12=1.9801980220844098 core#13=0.999999999476131 core#14=4.000000000814907 core#15=0 core#2=3.03030302945673 core#3=0 core#4=0.999999999476131 core#5=1.999999998952262 core#6=2.999999998486601 core#7=2.0000000004074536 core#8=1.0101010108136843 core#9=2.020202020157478
INFO[0006] #0;0;0 B;0 B;0;https://google.com
INFO[0006] #1;0;0 B;0 B;0;http://scaleway.testdebit.info
INFO[0006] #1 size = 94.6 kB (92.4 KiB) procotol = HTTP/1.1 local IP:port = [2a05:6xxxxxxxxxxxxxxxxxxx]:44774 remote IP:port = [2001:bc8:3::7]:80 DNSInfoTime = 3.077444274s ConnInfoTime = 3.114009968s FirstResponseByte = 3.150250834s
INFO[0006] job 0 got redirect
INFO[0006] #1 transfered 94642 bytes
DEBU[0007] cpu 1 9 core#0=9.090909091443597 core#1=0.999999999476131 core#10=0 core#11=0 core#12=1.0101010093437939 core#13=0.999999999476131 core#14=2.0000000004074536 core#15=0.9900990110422049 core#2=1.0101010112888003 core#3=5.00000000174623 core#4=4.000000000814907 core#5=2.0202020225776005 core#6=0.9999999999417925 core#7=3.9999999993597157 core#8=0 core#9=1.999999998952262
INFO[0007] #0;0;0 B;0 B;0;https://google.com
INFO[0007] #1;3.265513027;92.4 KiB;92.4 KiB;634;http://scaleway.testdebit.info
DEBU[0008] cpu 1 9 core#0=9.18367347217571 core#1=0 core#10=0 core#11=0 core#12=0 core#13=0 core#14=2.0202020186875878 core#15=1.0000000004656613 core#2=1.9801980197306543 core#3=6.060606059002543 core#4=0 core#5=3.99999999749707 core#6=1.0101010108136843 core#7=0 core#8=3.9999999993597157 core#9=0
INFO[0008] #0;0;0 B;0 B;0;https://google.com
INFO[0008] #1;3.265513027;92.4 KiB;92.4 KiB;634;http://scaleway.testdebit.info
DEBU[0009] cpu 1 7 core#0=9.183673466236153 core#1=1.0000000013969839 core#10=0.999999999476131 core#11=0.9900990110422049 core#12=0 core#13=1.0000000009313226 core#14=1.0101010112888003 core#15=3.999999997904524 core#2=1.0101010093437939 core#3=3.03030303092662 core#4=2.999999998428393 core#5=0.9999999999417925 core#6=2.9999999998835847 core#7=1.0101010108136843 core#8=5.999999999767169 core#9=0.999999999476131
INFO[0009] #0;0;0 B;0 B;0;https://google.com
INFO[0009] #1;3.265513027;92.4 KiB;92.4 KiB;634;http://scaleway.testdebit.info
INFO[0009] #0 size = -1 B (-1 B) procotol = HTTP/2.0 local IP:port = [2a05:6xxxxxxxxxxxxxxxxxxx]:50170 remote IP:port = [2a00:1450:4007:813::2004]:443 DNSInfoTime = 6.428978872s ConnInfoTime = 6.51283548s FirstResponseByte = 6.587627558s
INFO[0009] #0 crypto = TLS13 cipher = TLS_AES_128_GCM_SHA256 TLSDone in = 6.512777021s
INFO[0009] #0 transfered 13057 bytes
DEBU[0009] wait group ended
DEBU[0009] all workers done (3 remaining active goroutines)
DEBU[0009] main loop endedrc = 2
INFO[0009] #0 speed = 31.4 kbps time = 3331 ms (3.3311338360000002 s) size = 13.1 kB (12.8 KiB) url = https://google.com
INFO[0009] #1 speed = 231.9 kbps time = 3265 ms (3.265513027 s) size = 94.6 kB (92.4 KiB) url = http://scaleway.testdebit.info
total: speed = 258.6 kbps time = 3.331133836s size = 107699 Bytes ( 107.7 kB )
Problème réglé, ça venait du docker DNS qui ne communiquait pas avec le serveur, et mis en DNS primaire.
Donc si le DNS primaire tombe, le secondaire ne fonctonne pas avec le speedtest
-
peu de progrès vu les jours fériés/vacances et parce que j'ai pas mal décortiqué ethr: pas grand chose a en récupérer (sauf peut-être la mesure de latence) et le projet a plutôt l'air figé.
pour le module débit "a la iperf" je maintient donc mon choix initial (goben (https://github.com/udhos/goben)) mais de toute façon ce n'est pas pour de suite.
Je constate des débits faiblards en chiffré (https). La prochaine version, pour mercredi en principe, inclura un certificat autosigné (avec mkcert (https://github.com/FiloSottile/mkcert)) pour faire des tests https plus facilement.
-
v0.7 dispo. https://dl.nspeed.app/nspeed-client/v0.7/
un 'breaking change': les url /p et /g ont été supprimés car pas vraiment utiles. Tout ce fait avec '/' maintentant (/10g par exemple) et upload juste sur /
https://github.com/nspeed-app/nspeed/blob/main/CHANGELOG.md
# v0.7
## general
- global flags:
- `-self`: activate self-signed certificate for all clients (get & put)
- `-color` : use colors in output (by default there will be no color at all)
- `-cpu` : display cpu usage (every second). `-debug` & `-verbose` don't display cpu usage anymore
- news debug metrics: `ReadCount`,`WriteCount` (how many OS level Read & Write calls were performed) and `AverageReadSize`,`AverageWriteSize` (total volume/count)
- fix some usage messages
## server
- `-self` flag: listen in https mode using a self-signed certificate
- bigger buffer when sending
- paths in url for upload (`/p`) & download (`/g`) removed. just use the root path `/` for both (see the updated README.md examples)
- download paths can now have an extension. For instance `/10G.iso`. The Content-Type header will be set accordingly to https://golang.org/pkg/mime/#TypeByExtension.
- query parameters:
- `ct` query parameter added: set the returned content-type header, for instance: http://localhost:7333/1k.jpg?ct=text/plain will return a content-type of `text/plain` instead of `image/jpeg` ("ct" has precedence oever the extension. With no precedence or `ct` parameter, the default content-type is `application/octet-stream` ).
- `chunk_size` query parameter limited to 1 MiB (it's allocated once, this will be tuned later)
- `seed` query parameter removed (this will return later)
## client
- disable compression
- dns report is back in -verbose mode
- `-self` : same as global '-self' flag
## known issues / caveats
- the self-signed cert only work for 'localhost, 127.0.0.1,::1'. Next vesion will allow test https over a LAN between trusted machines, meanwhile use `-k` flag with nspeed or curl.
j'ai de gros souci de performance en https:
https:
./nspeed_linux_amd64 server -n 1 -self get -w 1 -self https://localhost:7333/1g
Job| Read| Write| Time|target
Job 1| 4.5 Gbps| 0 bps| 1.79|get https://localhost:7333/1g
Average| 4.5 Gbps| 0 bps| 1.79|
http:
./nspeed_linux_amd64 server -n 1 get -w 1 http://localhost:7333/1g
Job| Read| Write| Time|target
Job 1| 36.1 Gbps| 0 bps| 0.22|get http://localhost:7333/1g
Average| 36.1 Gbps| 0 bps| 0.22|
-
et ce n'est pas un souci de cpu on dirait:
HTTPS:
4:38PM WRN nspeed listening on https://127.0.0.1:7333 job=0
4:38PM --- | 4| 2| 2| 2| 1| 1| 6| 0|, active jobs: 2 / active goroutines: 7
4:38PM --- | 33| 38| 31| 37| 43| 41| 36| 32|, active jobs: 2 / active goroutines: 12
4:38PM --- | 39| 36| 36| 32| 34| 39| 33| 37|, active jobs: 2 / active goroutines: 11
4:38PM --- | 38| 41| 40| 35| 33| 40| 33| 27|, active jobs: 2 / active goroutines: 12
4:38PM --- | 35| 36| 39| 37| 32| 33| 37| 36|, active jobs: 2 / active goroutines: 12
4:38PM --- | 37| 27| 39| 34| 39| 40| 43| 36|, active jobs: 2 / active goroutines: 11
4:38PM --- | 35| 34| 34| 32| 27| 36| 34| 41|, active jobs: 2 / active goroutines: 12
4:38PM --- | 41| 33| 39| 35| 44| 35| 42| 36|, active jobs: 2 / active goroutines: 12
4:38PM --- | 37| 35| 30| 36| 34| 33| 36| 36|, active jobs: 2 / active goroutines: 12
4:38PM WRN job 0
Job| Read| Write| Time|target
Job 1| 4.7 Gbps| 0 bps| 8.00|get https://localhost:7333/10g
Average| 4.7 Gbps| 0 bps| 8.00|
HTTP:
4:48PM WRN nspeed listening on http://127.0.0.1:7333 job=0
4:48PM --- | 4| 2| 1| 1| 4| 3| 7| 6|, active jobs: 2 / active goroutines: 6
4:48PM --- | 85| 25| 55| 38| 9| 1| 1| 16|, active jobs: 2 / active goroutines: 10
4:48PM --- | 94| 1| 7| 18| 2| 84| 0| 4|, active jobs: 2 / active goroutines: 10
4:48PM --- | 84| 37| 8| 24| 15| 23| 1| 1|, active jobs: 2 / active goroutines: 10
4:48PM --- | 13| 94| 32| 24| 28| 3| 0| 0|, active jobs: 2 / active goroutines: 10
4:48PM --- | 1| 2| 31| 27|100| 3| 0| 5|, active jobs: 2 / active goroutines: 10
4:48PM --- | 14| 36| 53| 3| 54| 2| 1| 33|, active jobs: 2 / active goroutines: 10
4:48PM --- | 12| 2|100| 0| 30| 24| 1| 7|, active jobs: 2 / active goroutines: 10
4:48PM WRN job 0
Job| Read| Write| Time|target
Job 1| 41.5 Gbps| 0 bps| 7.71|get http://localhost:7333/40g
Average| 41.5 Gbps| 0 bps| 7.71|
(Intel i7-8559U CPU @ 2.70GHz - Linux 5.4.0-72 - Ubuntu 20.04.2 LTS)
-
Effectivement, pourtant TLS_AES_128_GCM_SHA256.
Voici ce que dit perf, il y a quand même du CPU consommé pour le TLS (et memmove, ensuite le findrunnable je ne sais pas si c'est normal) :
9.24% nspeed_linux_am nspeed_linux_amd64 [.] crypto/aes.gcmAesEnc
9.15% nspeed_linux_am nspeed_linux_amd64 [.] crypto/aes.gcmAesDec
6.96% nspeed_linux_am nspeed_linux_amd64 [.] runtime.memmove
5.92% nspeed_linux_am nspeed_linux_amd64 [.] runtime.findrunnable
4.53% nspeed_linux_am nspeed_linux_amd64 [.] runtime.selectgo
3.43% nspeed_linux_am nspeed_linux_amd64 [.] runtime.procyield
2.33% nspeed_linux_am nspeed_linux_amd64 [.] runtime.lock2
1.58% nspeed_linux_am nspeed_linux_amd64 [.] runtime.casgstatus
1.42% nspeed_linux_am nspeed_linux_amd64 [.] runtime.unlock2
1.34% nspeed_linux_am nspeed_linux_amd64 [.] runtime.mallocgcAES-NI semble pourtant être utilisé.
findrunnable/selectgo/procyield : est-ce qu'il n'y aurait pas un peu trop de découpage de tâches (trop petites ?) entre threads ?
Les coeurs ne saturent pas, mais ça se répartit bien, entre N+1 threads, pour N coeurs logiques ?
-
findrunnable/selectgo/procyield : est-ce qu'il n'y aurait pas un peu trop de découpage de tâches (trop petites ?) entre threads ?
Les coeurs ne saturent pas, mais ça se répartit bien, entre N+1 threads, pour N coeurs logiques ?
bonne piste! effectivement quand on réduit le nombre de cœurs a utiliser la perf augmente...
la variable d'env GOMAXPROCS permet de limiter le nombre de cœurs:
GOMAXPROCS=2 ./nspeed_linux_amd64 ...donne de meilleurs résultats que sans GOMAXPROCS
Je vais voir si on peut agir au niveau du code ou si y'a des caveats/workaround pour ce genre de chose.
-
apparemment le 'coupable' est ... HTTP/2 plus que le chiffrement
j'ai ajouté le forcage d'HTTP 1.1 et H2C (http/2 sans chiffrement) a nspeed et fait aussi quelque tests avec curl et un serveur nspeed et curl/nspeed avec un serveur nginx (fichiers de 1G,10G et 40GB sur un ssd M2, 'sendfile (https://docs.nginx.com/nginx/admin-guide/web-server/serving-static-content/#enabling-sendfile)' activé)
HTTP/1.1 sans chiffrement
server -n 1 get -w 1 http://localhost:7333/10g
Job| Read| Write| Time|target
Job 1| 41.4 Gbps| 0 bps| 1.93|get http://localhost:7333/10g
Average| 41.4 Gbps| 0 bps| 1.93|
curl: 48 Gbps
curl avec nginx: 30 Gbps puis s'écroule a 0 ?!
nspeed avec nginx: 30 Gbps
HTTP/1.1 avec chiffrement
server -self -n 1 get -self -w 1 -http11 https://localhost:7333/10g
Job| Read| Write| Time|target
Job 0| 13.9 Gbps| 0 bps| 5.76|get https://localhost:7333/10g
Average| 13.9 Gbps| 0 bps| 5.76|
curl: 12 Gbps
curl avec nginx: 9.6 Gbps
nspeed avec nginx: 9.3 Gbps
HTTP/2 avec chiffrement
server -self -n 1 get -w 1 -self https://localhost:7333/10g
Job| Read| Write| Time|target
Job 1| 4.6 Gbps| 0 bps| 8.00|get https://localhost:7333/10g
Average| 4.6 Gbps| 0 bps| 8.00|
curl: 5.6 Gbps
curl avec nginx: 8 Gbps
nspeed avec nginx: 5.6 Gbps
H2C
server -h2c -n 1 get -w 1 -h2c http://localhost:7333/10g
Job| Read| Write| Time|target
Job 1| 7.2 Gbps| 0 bps| 8.00|get http://localhost:7333/10g
Average| 7.2 Gbps| 0 bps| 8.00|
curl: 8.9 Gbps
Avec nginx c'est TLS1.3 / TLS_AES_256_GCM_SHA384 qui est utilisé que ce soit curl ou "nspeed get"
Avec "nspeed server" c'est TLS1.3 / TLS_AES_128_GCM_SHA256 qui est utilisé que ce soit curl ou "nspeed get"
Le chiffrement pénalise de x3 environ (40 a 13) donc mais HTTP/2 (sans chiffrement) bien plus environ x4 (40 a 7). Le mélange deux (HTTP/2 normal) explique donc les résultats (presque x10)
Je n'ai pas testé avec Apache mais j'ai testé avec Caddy, serveur écrit en Go et il fait moins bien que le serveur nspeed.
reste a voir pourquoi HTTP/2 fait moins bien que HTTP/1.1 pour du simple transfert de fichier et pourquoi nginx fait mieux que nspeed avec http/2 chiffré (peut-etre sendfile?).
La v0.8 la semaine prochaine, ajoutera ces options (forcé HTTP 1.1 et forcé H2C) ainsi qu'une nouvelle commande pour voir et changer les cyphers de chiffrement.
-
Je viens de tester avec hyper et alpn h2 fixer sur openssl pour le HTTP/2 et nginx comme serveur.
nspeed 0.7
./nspeed_linux_amd64 get http://localhost/1G.iso
{"level":"debug","time":"2021-05-22T11:59:41+02:00","message":"use self TLS: false"}
Jobs:
0 {Command: GET, URL: "http://localhost/1G.iso", IPversion: 0, Address: , Instance: 0, timeout: 8s}
Job| Read| Write| Time|target
Job 0| 39.7 Gbps| 0 bps| 0.20|get http://localhost/1G.iso
Average| 39.7 Gbps| 0 bps| 0.20|
GODEBUG=x509ignoreCN=0 ./nspeed_linux_amd64 -self get https://localhost/1G.iso
{"level":"debug","time":"2021-05-22T11:54:09+02:00","message":"use self TLS: true"}
Jobs:
0 {Command: GET, URL: "https://localhost/1G.iso", IPversion: 0, Address: , Instance: 0, timeout: 8s}
Job| Read| Write| Time|target
Job 0| 4.3 Gbps| 0 bps| 1.88|get https://localhost/1G.iso
Average| 4.3 Gbps| 0 bps| 1.88|
GODEBUG=x509ignoreCN=0 ./nspeed_linux_amd64 -self get https://localhost/1G.iso get https://localhost/1G.iso
{"level":"debug","time":"2021-05-22T12:04:35+02:00","message":"use self TLS: true"}
{"level":"debug","time":"2021-05-22T12:04:35+02:00","message":"use self TLS: true"}
Jobs:
0 {Command: GET, URL: "https://localhost/1G.iso", IPversion: 0, Address: , Instance: 0, timeout: 8s}
1 {Command: GET, URL: "https://localhost/1G.iso", IPversion: 0, Address: , Instance: 0, timeout: 8s}
Job| Read| Write| Time|target
Job 0| 3.4 Gbps| 0 bps| 2.35|get https://localhost/1G.iso
Job 1| 3.4 Gbps| 0 bps| 2.36|get https://localhost/1G.iso
Average| 6.8 Gbps| 0 bps| 2.36|
Les données sont en millisecondes et chaque test est exécuté 10 fois.
Les 2 derniers résultats sont basé sur l’exécution de 2 requêtes exécutées en parallèle.
Comme vous avez noté les résultats avec le http/2 est nettement moins bons, je trouve encore plus bizarre que le lancement en parallèle n’améliore rien (je pense à un problème avec mon code).
**************************
http1.1 min:180 max:252 avg:205.7~38.89159Gbps (10)
**************************
https min:886 max:1527 avg:1173.1~6.819538Gpbs (10)
**************************
https h2 min:1400 max:1579 avg:1481.9~5.398475Gbps (10)
**************************
2 https min:769 max:902 avg:826.4~19.361084Gbps (10)
**************************
2 https h2 min:2826 max:3133 avg:2973.7~5.380502Gbps (10)
-
intéressant tout ca.
j'ai testé le serveur h2o censé être un 'rapide': https://github.com/h2o/h2o
j'obtient en HTTP/2 (cipher=TLS_AES_256_GCM_SHA384 crypto=TLS13)
serveur h2o:
client nspeed 1 flux: 8.1 Gbps
client curl 1 flux: 12 Gbps
nspeed 4 flux: 19.8 Gbps
serveur nspeed:
client nspeed 1 flux: 4,3 Gbps
client curl 1 flux: 5,3 Gbps
client nspeed 4 flux: 14 Gbps
et en forcant HTTP1.1:
serveur h2o:
client nspeed 1 flux: 16 Gbps
client curl 1 flux: 11.2 Gbps
client nspeed 4 flux: 32 Gbps
serveur nspeed:
client nspeed 1 flux: 13 Gbps
client curl 1 flux: 12 Gbps
client nspeed 4 flux: 35 Gbps
bon apres y'a peut-être des réglages spécifiques à faire dans nginx ou h2o pour avoir mieux et un test sur localhost n'est pas forcément représentatif d'une meilleur performance sur réseau réel. Il faudrait avoir un serveur 40Gbs avec nspeed, apache, nginx et h2o pour faire des comparaisons plus précises.
Mais y'a nettement moins de performance en HTTP/2 avec le code Go. Reste a savoir pourquoi.
-
v0.8 dispo: https://dl.nspeed.app/nspeed-client/v0.8/
nouveau répertoire https://dl.nspeed.app/nspeed-client/latest pour toujours avoir la dernière version directement
peu de changements, juste une version pour aider au benchmarking d'http/2
v0.8
general
a few typos fixes
added -h2c mode to client & server to allow HTTP/2 Cleartext (H2C)
client
-http11 flag to force HTTP 1.1 when connecting to HTTP/2 server
cyphers
new command cyphers to list supported cyphers with that server (will test only TLS 1.2 and 1.3)
la nouvelle commande permet de lister les cyphers tls 1.2 et 1.3 supporté pas un serveur web,par exemple:
./nspeed_linux_amd64 cyphers lafibre.info
Jobs:
0 cyphers {Target: lafibre.info, delay: 0}
3:07PM lafibre.info:443 supports TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 job=0
3:07PM lafibre.info:443 supports TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 job=0
3:07PM lafibre.info:443 supports TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 job=0
3:07PM | WARN | job 0 ended
nothing to report
lafibre.info pas TLS 1.3 et pas de CHACHA20 ?!
./nspeed_linux_amd64 cyphers testdebit.info
Jobs:
0 cyphers {Target: testdebit.info, delay: 0}
3:08PM testdebit.info:443 supports TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 job=0
3:08PM testdebit.info:443 supports TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 job=0
3:08PM testdebit.info:443 supports TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 job=0
3:08PM testdebit.info:443 supports TLS 1.2 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 job=0
3:08PM testdebit.info:443 supports TLS 1.3 TLS_AES_128_GCM_SHA256 job=0
3:08PM testdebit.info:443 supports TLS 1.3 TLS_CHACHA20_POLY1305_SHA256 job=0
3:08PM testdebit.info:443 supports TLS 1.3 TLS_AES_256_GCM_SHA384 job=0
3:08PM | WARN | job 0 ended
nothing to report
-
petit début d'explication. en ajoutant "GODEBUG=http2debug=1" devant le serveur nspeed:
GODEBUG=http2debug=1 nspeed -verbose server -self -a ""
quand on fait un curl d'1GiB (curl -k -o /dev/null https://localhost:7333/1G), on voit (lignes filtrées):
2021/05/26 16:15:44 http2: server read frame SETTINGS len=18, settings: MAX_CONCURRENT_STREAMS=100, INITIAL_WINDOW_SIZE=1073741824, ENABLE_PUSH=0
2021/05/26 16:15:44 http2: server processing setting [MAX_CONCURRENT_STREAMS = 100]
2021/05/26 16:15:44 http2: server processing setting [INITIAL_WINDOW_SIZE = 1073741824]
2021/05/26 16:15:44 http2: server processing setting [ENABLE_PUSH = 0]
2021/05/26 16:15:44 http2: server read frame WINDOW_UPDATE len=4 (conn) incr=1073676289
2021/05/26 16:15:44 http2: server read frame HEADERS flags=END_STREAM|END_HEADERS stream=1 len=34
2021/05/26 16:15:44 http2: server read frame SETTINGS flags=ACK len=0
2021/05/26 16:15:45 http2: server read frame WINDOW_UPDATE len=4 (conn) incr=536870912
2021/05/26 16:15:45 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=536870912
2021/05/26 16:15:46 http2: server read frame WINDOW_UPDATE len=4 (conn) incr=536870912
2021/05/26 16:15:46 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=536870912
on a une INITIAL_WINDOW_SIZE a 1073741824 (1Go+) et curl envoie des WINDOW_UPDATE a 50% reçu (536870912 * 2 = 1073741824)
donc en gros tout les 500Mo recu curl envoi un WINDOW_UPDATE
avec NSpeed client: (nspeed get -self https://localhost:7333/1G)
on a
2021/05/26 16:22:28 http2: server read frame SETTINGS len=18, settings: ENABLE_PUSH=0, INITIAL_WINDOW_SIZE=4194304, MAX_HEADER_LIST_SIZE=10485760
2021/05/26 16:22:28 http2: server processing setting [ENABLE_PUSH = 0]
2021/05/26 16:22:28 http2: server processing setting [INITIAL_WINDOW_SIZE = 4194304]
2021/05/26 16:22:28 http2: server processing setting [MAX_HEADER_LIST_SIZE = 10485760]
2021/05/26 16:22:28 http2: server read frame WINDOW_UPDATE len=4 (conn) incr=1073741824
2021/05/26 16:22:28 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=49152
2021/05/26 16:22:28 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=16384
2021/05/26 16:22:28 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=32768
2021/05/26 16:22:28 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=16384
2021/05/26 16:22:28 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=32768
2021/05/26 16:22:28 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=16384
2021/05/26 16:22:28 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=16384
2021/05/26 16:22:28 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=32768
2021/05/26 16:22:28 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=16384
..... 57300+ lignes comme ca
2021/05/26 16:22:30 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=32768
2021/05/26 16:22:30 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=32768
2021/05/26 16:22:30 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=16384
2021/05/26 16:22:30 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=16384
2021/05/26 16:22:30 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=16384
2021/05/26 16:22:30 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=16384
2021/05/26 16:22:30 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=16384
2021/05/26 16:22:30 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=16384
2021/05/26 16:22:30 http2: server read frame WINDOW_UPDATE stream=1 len=4 incr=16384
on a une INITIAL_WINDOW_SIZE a 4194304 (4Mo) et tout les 16K reçu (des fois plus), nspeed envoi un WINDOW_UPDATE au serveur...pas étonnant que la performance soit moindre, le serveur est martelé de WINDOW_UPDATE et ajuste son tampon pour rien (nspeed client envoi 57K+ WINDOW_UPDATE, curl en envoi 2).
a voir donc pourquoi le client Go http/2 fait cela et si on peut corrigé (a priori ce n'est pas lié a la facon dont nspeed traite les données recu, la taille du buffer de reception au niveau application ne change rien). J'aurais voulu éviter de me plonger dans les détails d'HTTP/2 (!) mais je n'ai pas trop le choix on dirait.
-
La taille par défaut dans la norme est de seulement 65535.
Tu as testé avec un curl qui n'est pas à jour à priori.
Avant curl 7.52, c'était la taille par défaut (64Ko).
En 7.52 ils sont passés à 1Go (https://github.com/curl/curl/issues/1102).
En 7.69, ils ont réduit à 32Mo (https://github.com/curl/curl/issues/4939).
Si la window est assez large, les WINDOW_UPDATE reçus par le serveur ne devraient pas faire grand chose, à part consommer un peu de CPU.
Il n'y a que si le serveur avait déjà rempli la window du client, et a donc dû s'arrêter, que reprendre pour juste 16Ko/32Ko n'est pas très optimal, et qu'il serait bénéfique que le client attende soit une durée minimale, soit une taille minimale avant d'envoyer un WINDOW_UPDATE qui débloque le serveur.
-
La taille par défaut dans la norme est de seulement 65535.
Tu as testé avec un curl qui n'est pas à jour à priori.
Avant curl 7.52, c'était la taille par défaut (64Ko).
En 7.52 ils sont passés à 1Go (https://github.com/curl/curl/issues/1102).
En 7.69, ils ont réduit à 32Mo (https://github.com/curl/curl/issues/4939).
c'est le curl de base d'un Ubuntu 20.04 TLS (je voulais tester avec un curl d'une distro LTS populaire justement).
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.2 LTS
Release: 20.04
Codename: focal
curl -V
curl 7.68.0 (x86_64-pc-linux-gnu) libcurl/7.68.0 OpenSSL/1.1.1f zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0 librtmp/2.3
Release-Date: 2020-01-08
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS brotli GSS-API HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets
c'est bien 7.68 du "8 Jan 2020" , https://launchpad.net/ubuntu/focal/+source/curl (et comme d'hab Ubuntu a 1 an de retard sur des paquets importants...)
Si la window est assez large, les WINDOW_UPDATE reçus par le serveur ne devraient pas faire grand chose, à part consommer un peu de CPU.
Il n'y a que si le serveur avait déjà rempli la window du client, et a donc dû s'arrêter, que reprendre pour juste 16Ko/32Ko n'est pas très optimal, et qu'il serait bénéfique que le client attende soit une durée minimale, soit une taille minimale avant d'envoyer un WINDOW_UPDATE qui débloque le serveur.
oui y'a un truc qui cloche quand meme.
-
Le refactoring du code avance. l'api est commencé. l'ui aussi.
Un projet similaire est apparu: https://github.com/six-ddc/plow mais mais que 'client'. pas serveur.
c'est plus orienté latence & requetes/secondes que débit mais il y a peut-être des choses intéressantes a reprendre notamment l'UI web des courbes qui est exactement ce que je voulais faire (mais dans le cas de nspeed plus en 'replay' a la fin qu'en temps réel qui consomme des ressources cpu pour peu d'avantage).
C'est basé sur une autre lib http donc pas de http/2 ou autre.
-
v0.9 dispo: https://dl.nspeed.app/nspeed-client/v0.9/
ou https://dl.nspeed.app/nspeed-client/latest pour toujours avoir la dernière version directement
gros changements internes (refactoring) pour l'api et la préparation de l'interface web: https://github.com/nspeed-app/nspeed/blob/main/CHANGELOG.md ainsi que le moteur interne d’ordonnancement (scheduling des threads).
La grosse nouveauté visible est la command 'api' permettant a nspeed d'écouter en http pour recevoir des commandes (sorte d'API REST mais qu'avec un GET).
Ceci fonctionne en local ou distance. pour le moment nspeed n'est pas encore client de l'api donc utiliser curl par exemple ou un navigateur.
exemple en local:
nspeed api
puis ouvrez http://localhost:7333/api/v1/run?args=get%20https://scaleway.testdebit.info/1G/1G.iso sur la meme machine
(par défaut l'api n'ecoute que sur localhost)
ou en CLI:
curl http://localhost:7333/api/v1/run?args=get%20https://scaleway.testdebit.info/1G/1G.iso
(il faut remplacer les espaces par %20)
pour ouvrir l'api sur le LAN ou internet utiliser l'option -a comme avec 'server'.
nspeed api -a ""va ouvrir l'api sur tout les adresses de la machine (attention a pas laisser cela a poil sur le Net)
Cela permet donc de lancer nspeed a distance depuis une autre machine. pour le moment avec curl ou un navigateur mais plus tard nspeed utilisera aussi l'api comme "agent" (pour le moment on peut quand meme utiliser l'api depuis nspeed puisque c'est du 'get http' aussi mais on n'a pas le retour du resultat donc ca ne sert qu'a synchroniser des nspeed sur plusieurs machines en meme temps).
on peut partager l'api et le server sur le meme port:
nspeed server -apiou avoir chacun son port/interface:
nspeed server -a "" api -a tailscale0 -p 8888 -4le server écoute sur toutes interfaces/addresse port nspeed par défaut (7333), l'api n'est que sur l'interface tailscale0 port 8888 et en IPv4
Les étapes suivantes:
-traceroute (on pourra donc faire un traceroute depuis nspeed ou vers soi depuis un serveur nspeed via l'api)
-ping/latence (idem)
- metrics (format structurés des résultats pour : base de donnée, graphiques, prometheus, etc probablement au format: https://openmetrics.io/ )
- interface web
- info hardware/routage (crosstalk & erreurs carte réseau, bus pci, etc)
- api box (<<bbox uniquement pour le moment>>)
La mise en oeuvre de l' interface web est reculé apes les metrics car ce ne sert a pas a grand chose d'afficher du texte dans un navigateur autant être en ligne de commande. Je préfère avoir des métrics bien structurés et les présenter sous forme de tableaux ou courbes par exemple.
-
Hello,
depuis la dernière version, le "average" m'indique des chiffres étrange. Surement un réglage que j'ai raté. Avec un liens 10gb en local:
./nspeed.exe get -n 4 http://mafreebox.freebox.fr/gen/10G
Jobs:
0 HTTP client {Methdd: GET, URL: "http://mafreebox.freebox.fr/gen/10G", IPversion: 0, Address: , Group: 0, timeout: 8s, delay: 0s, h2c: false, http1.1:false}}
1 HTTP client {Methdd: GET, URL: "http://mafreebox.freebox.fr/gen/10G", IPversion: 0, Address: , Group: 0, timeout: 8s, delay: 0s, h2c: false, http1.1:false}}
2 HTTP client {Methdd: GET, URL: "http://mafreebox.freebox.fr/gen/10G", IPversion: 0, Address: , Group: 0, timeout: 8s, delay: 0s, h2c: false, http1.1:false}}
3 HTTP client {Methdd: GET, URL: "http://mafreebox.freebox.fr/gen/10G", IPversion: 0, Address: , Group: 0, timeout: 8s, delay: 0s, h2c: false, http1.1:false}}
10:08PM job 3 got redirect to http://mafreebox.freebox.fr:8095/fixed/10G (<nil>) job=3
10:08PM job 2 got redirect to http://mafreebox.freebox.fr:8095/fixed/10G (<nil>) job=2
10:08PM job 1 got redirect to http://mafreebox.freebox.fr:8095/fixed/10G (<nil>) job=1
10:08PM job 0 got redirect to http://mafreebox.freebox.fr:8095/fixed/10G (<nil>) job=0
10:08PM | WARN | all jobs ended:
Job| Read speed| Write speed| Time| Bytes read| Bytes written|target
Job 0| 4.0 Gbps| 0 bps| 7.96| 4.0 GB| 0 B|get http://mafreebox.freebox.fr/gen/10G (212.27.38.253:8095)
Job 1| 3.3 Gbps| 0 bps| 7.96| 3.3 GB| 0 B|get http://mafreebox.freebox.fr/gen/10G (212.27.38.253:8095)
Job 2| 3.7 Gbps| 0 bps| 7.96| 3.7 GB| 0 B|get http://mafreebox.freebox.fr/gen/10G (212.27.38.253:8095)
Job 3| 3.5 Gbps| 0 bps| 7.96| 3.5 GB| 0 B|get http://mafreebox.freebox.fr/gen/10G (212.27.38.253:8095)
Average| 14.5 Gbps| 0 bps| 7.96| 14.4 GB| 0 B|
-
Hello,
depuis la dernière version, le "average" m'indique des chiffres étrange. Surement un réglage que j'ai raté.
y'a effectivement un bug :o je vérifierai demain. on dirait que sur Windows en plus.
-
y'a effectivement un bug :o je vérifierai demain. on dirait que sur Windows en plus.
Yep. J'ai testé sur 3 machines différentes en 1G et 10GB et cela m'affiche des vitesses impossible ;D
-
Hello,
depuis la dernière version, le "average" m'indique des chiffres étrange. Surement un réglage que j'ai raté. Avec un liens 10gb en local:
./nspeed.exe get -n 4 http://mafreebox.freebox.fr/gen/10G
Jobs:
0 HTTP client {Methdd: GET, URL: "http://mafreebox.freebox.fr/gen/10G", IPversion: 0, Address: , Group: 0, timeout: 8s, delay: 0s, h2c: false, http1.1:false}}
1 HTTP client {Methdd: GET, URL: "http://mafreebox.freebox.fr/gen/10G", IPversion: 0, Address: , Group: 0, timeout: 8s, delay: 0s, h2c: false, http1.1:false}}
2 HTTP client {Methdd: GET, URL: "http://mafreebox.freebox.fr/gen/10G", IPversion: 0, Address: , Group: 0, timeout: 8s, delay: 0s, h2c: false, http1.1:false}}
3 HTTP client {Methdd: GET, URL: "http://mafreebox.freebox.fr/gen/10G", IPversion: 0, Address: , Group: 0, timeout: 8s, delay: 0s, h2c: false, http1.1:false}}
10:08PM job 3 got redirect to http://mafreebox.freebox.fr:8095/fixed/10G (<nil>) job=3
10:08PM job 2 got redirect to http://mafreebox.freebox.fr:8095/fixed/10G (<nil>) job=2
10:08PM job 1 got redirect to http://mafreebox.freebox.fr:8095/fixed/10G (<nil>) job=1
10:08PM job 0 got redirect to http://mafreebox.freebox.fr:8095/fixed/10G (<nil>) job=0
10:08PM | WARN | all jobs ended:
Job| Read speed| Write speed| Time| Bytes read| Bytes written|target
Job 0| 4.0 Gbps| 0 bps| 7.96| 4.0 GB| 0 B|get http://mafreebox.freebox.fr/gen/10G (212.27.38.253:8095)
Job 1| 3.3 Gbps| 0 bps| 7.96| 3.3 GB| 0 B|get http://mafreebox.freebox.fr/gen/10G (212.27.38.253:8095)
Job 2| 3.7 Gbps| 0 bps| 7.96| 3.7 GB| 0 B|get http://mafreebox.freebox.fr/gen/10G (212.27.38.253:8095)
Job 3| 3.5 Gbps| 0 bps| 7.96| 3.5 GB| 0 B|get http://mafreebox.freebox.fr/gen/10G (212.27.38.253:8095)
Average| 14.5 Gbps| 0 bps| 7.96| 14.4 GB| 0 B|
C'est amusant dans ton cas le Average correspond à la somme des 4 valeurs au dessus. Petite coquille dans ton code @kgersen ? ;D
En tout cas super boulot, je prendrai le temps de tester cette nouvelle version quand j'aurai un peu plus de temps libre !
-
le Average est toujours la somme des N flux oui.
Le problème est que les débits des flux ne sont pas bon. Ils sont calculés par une simple division de 'Bytes read' par 'Time' donc c'est l'un de ces 2 qui n'est pas bon. Mais vu que 'time' est bon (les test durent max 8 secondes par défaut (ce qui n'est pas trop long, pas trop court et pratique pour convertir des Bytes en bits) c'est "Bytes read" qui est trop élevé ce qui est tres embêtant car ce n'est pas une simple coquille ca et c'est que sur Windows...
-
le Average est toujours la somme des N flux oui.
Le problème est que les débits des flux ne sont pas bon. Ils sont calculés par une simple division de 'Bytes read' par 'Time' donc c'est l'un de ces 2 qui n'est pas bon. Mais vu que 'time' est bon (les test durent max 8 secondes par défaut (ce qui n'est pas trop long, pas trop court et pratique pour convertir des Bytes en bits) c'est "Bytes read" qui est trop élevé ce qui est tres embêtant car ce n'est pas une simple coquille ca et c'est que sur Windows...
D'accord je pensais le Average comme la moyenne des flux, je n'y connais vraiment pas grand chose en test de débit en CLI, ça m'étonnais aussi une coquille aussi flagrante. En tout cas merci pour les détails c'est sympa, du coup je passe un peu pour un débile avec mon message précédent ;D ;D
-
non pas de souci et j'avoue que y'a pas de doc et que ce terme a cette endroit n'est pas du tout intuitif , d'ailleurs je vais le changer.
Bug trouvé. je fais poster une nouvelle version aujourd'hui.
-
non pas de souci et j'avoue que y'a pas de doc et que ce terme a cette endroit n'est pas du tout intuitif , d'ailleurs je vais le changer.
Bug trouvé. je fais poster une nouvelle version aujourd'hui.
Wow! ce fut rapide!
Je testerais quand cela sera dispo et ne manquerait pas de faire un retour ici pour confirmer :D (bien que je suppose vous avez réussi à reproduire le "bug" sans trop de soucis)
-
Bug trouvé. je fais poster une nouvelle version aujourd'hui.
Je suis curieux de savoir quoi... car spécifique à windows
-
j'ai mis a jour la version directement sur https://dl.nspeed.app/nspeed-client/latest/ en écrasant l'ancienne.
C'est la v0.9-10-g51aad89 qui remplace donc la v0.9-2-g403caa4 (visible avec nspeed -version).
il y a des affichages en plus par rapport a l'ancienne version notamment l'url et ip finale et la latence de la connexion.
et la correction du 'Average' ;)
Je suis curieux de savoir quoi... car spécifique à windows
non en fait le bug était aussi sous Linux. C'était une erreur de calcul dans la boucle de lecture quand j'ai récrit celle-ci entre la 0.8 et la 0.9
-
D'accord je pensais le Average comme la moyenne des flux, je n'y connais vraiment pas grand chose en test de débit en CLI, ça m'étonnais aussi une coquille aussi flagrante. En tout cas merci pour les détails c'est sympa, du coup je passe un peu pour un débile avec mon message précédent ;D ;D
en fait pour être plus précis c'est le débit moyen et pas le total de la 1ere colonne mais pas la moyenne de la 1ere colonne non plus ;)
c'est tres visible quand un des flux est plus court que les autres, par exemple:
./nspeed_linux_amd64 get http://scaleway.testdebit.info/100M/100M.iso get http://scaleway.testdebit.info/1G/1G.iso
Jobs:
0 HTTP client {Method: GET, URL: "http://scaleway.testdebit.info/100M/100M.iso", IPversion: 0, Address: , Group: 0, timeout: 8s, delay: 0s, h2c: false, http1.1:false}}
1 HTTP client {Method: GET, URL: "http://scaleway.testdebit.info/1G/1G.iso", IPversion: 0, Address: , Group: 1, timeout: 8s, delay: 0s, h2c: false, http1.1:false}}
11:27AM | WARN | all jobs ended:
Job| Read speed| Write speed| Time| Bytes read| Bytes written|command
Job 0| 465.2 Mbps| 0 bps| 1.72| 100.0 MB| 0 B|get http://scaleway.testdebit.info/100M/100M.iso (62.210.156.7:80 - 5.528 ms)
Job 1| 809.3 Mbps| 0 bps| 8.00| 809.4 MB| 0 B|get http://scaleway.testdebit.info/1G/1G.iso (62.210.156.7:80 - 5.796 ms)
Total| 909.3 Mbps| 0 bps| 8.00| 909.4 MB| 0 B|
si on faisait le total on aurait 465+809= 1274 Mbps ce qui ne correspond a rien.
si on faisait la moyenne on aurait (465+809)/2 = 637 Mbps ce qui ne correspond a rien non plus.
Le 909.3 Mbps affiché vient de 909.4 MB divisé par 8 secondes et le 909.4 MB vient lui du total de la colonne "Bytes read".
On a donc reçu en tout 100MB plus 809MB soit 909.4 MB et cela a pris 8 secondes d'ou le 909.3 Mbps.
-
Tout est OK avec la nouvelle version! Merci de la mise à jours! :D
-
La 0.9-10 fonctionne bien mieux en effet :D
-
Bientôt une nouvelle version avec des graphiques interactifs!
ci-joint un screenshot teaser (sur une machine avec 32 cpu cores le graphique cpu fait un peu plat de spaghettis ...).
J'utilise le package Apache ECharts: https://echarts.apache.org/en/index.html.
L'idée est de pouvoir générer un fichier html unique contenant le "résultat final" et/ou un 'live web view' du test de debit (local ou distant vu que c'est du web).
Apache Echarts permet aussi directement de générer une image (png) depuis un graphique (voir cet exemple (https://echarts.apache.org/examples/en/editor.html?c=line-marker), en haut a droite la petite fleche 'Save as')
A terme je mettrais aussi en place un site web public pour héberger les fichier html résultats de façon a les partager simplement.
Le style des graphes sera paramétrable avec : https://echarts.apache.org/en/theme-builder.html (perso j'aime bien 'chalk' series 3)
ps: version dispo d'ici la fin de la semaine
-
superbe !
-
ps: version dispo d'ici la fin de la semaine
désolé pour ce ps un peu trop optimiste ;) cela fait plus d'un mois...
vacances, procastination, etc plus focus sur la sous-performance http/2 font que je n'ai pas publier de nouvelle version. La bonne nouvelle c'est que le "bug" dans l’implémentation d'HTTP/2 en Go a été plus ou moins résolu (du moins un premier correctif (https://go-review.googlesource.com/c/net/+/362834)). La moins bonne nouvelle est que je dois maintenant utiliser une version custom de Go si je veux build avec les correctifs de suite. sinon je devrais attendre qu'ils soient inclus dans la version générale de Go (ce qui a lieu que tous les 6 mois donc la prochaine, la 1.18 est prévue le 1 février 2022).
L'autre souci est macos/darwin, le cross-build simple que j'utilisais ne fonctionne pas correctement car certaines dépendances utilise du C donc nécessite un cross-build plus lourd (ou un Mac pour faire le build...mais je n'ai pas de Mac). Par exemple pour obtenir le taux d'usage CPU j'utilise https://github.com/shirou/gopsutil qui a ce souci en cross build. J'utilise soit https://github.com/wimpysworld/quickemu pour obtenir une VM de MacOS et build mais j'ai des problèmes de stabilité et soit https://github.com/neilotoole/xcgo pour tout build sur Linux mais je n'ai pas de certitude sur le binaire final. Si quelqu'un connait un moyen d'avoir une VM MacOS en quelques clics ou commandes je suis preneur. Ou si un quelqu'un connait le dev systeme (coding en C,C++,Go et devops CI/CD) et est sur Mac et souhaite m'aider, me MP. D'autant que y'a de plus en plus de Mac sous M1(ARM64) donc il me faudra un build pour cette version de Mac a un moment.
J'ai donc du passer plus de temps sur des aspects CI/CD (= devops) qu'a vraiment écrire du nouveau code...
Mais j'ai bon espoir d'avoir la 0.10 avant la fin du mois avec les graphes et les performances maxi pour http/2.
-
Je dis peut être une bêtise, mais il ne serait pas possible d'utiliser Github Actions pour le build macOS ?
-
Je dis peut être une bêtise, mais il ne serait pas possible d'utiliser Github Actions pour le build macOS ?
surement a terme quand le code sera open source mais j'aurais souhaité un truc 100% privé pour le moment et les runners Github ne sont pas gratuits pour les repos privés et 10x quand c'est macos ( https://docs.github.com/en/billing/managing-billing-for-github-actions/about-billing-for-github-actions )
Et dépendre d'un service en ligne pour les builds privés me gene un peu.
mais effectivement c'est la solution en dernier recours (tant que les runners macos restent gratuits...) et a terme quand j'ouvrirai le code.
-
Ah oui je n'avais pas pensé à l'aspect closed source. Je peux faire un build en cas de besoin, mais c'est forcément moins pratique que d'avoir un Mac accessible facilement.
-
Des nouvelles du projet ? :)
-
En vacances jusqu'a fin aout.
a la reprise je publierai un build avec tous les ajouts depuis la v0.9.
-
Super projet !
Je test ton programme sous linux car mon script de monitoring de ma bande passante fonctionne plus, le serveur en face est down :(
Par contre, j'ai constaté un truc bizarre je sais pas si c'est normal.
Jusqu’à 5 instances de dl pas de soucis mais après, il lit pas le fichier en entier.
J'utilise la version v0.9-10-g51aad89
./nspeed get -n 2 http://appliwave.testdebit.info/1G.iso
Job| Read speed| Write speed| Time| Bytes read| Bytes written|command
Job 0| 2.2 Gbps| 0 bps| 3.66| 1.0 GB| 0 B|get http://appliwave.testdebit.info/1G.iso ([2a05:46c0:100:1007::3]:80 - 8.980 ms)
Job 1| 2.1 Gbps| 0 bps| 3.75| 1.0 GB| 0 B|get http://appliwave.testdebit.info/1G.iso ([2a05:46c0:100:1007::3]:80 - 9.5 ms)
Total| 4.3 Gbps| 0 bps| 3.75| 2.0 GB| 0 B|
./nspeed get -n 5 http://appliwave.testdebit.info/1G.iso
Job| Read speed| Write speed| Time| Bytes read| Bytes written|command
Job 0| 1.0 Gbps| 0 bps| 7.67| 1.0 GB| 0 B|get http://appliwave.testdebit.info/1G.iso ([2a05:46c0:100:1007::3]:80 - 8.114 ms)
Job 1| 1.0 Gbps| 0 bps| 7.88| 1.0 GB| 0 B|get http://appliwave.testdebit.info/1G.iso ([2a05:46c0:100:1007::3]:80 - 8.299 ms)
Job 2| 1.1 Gbps| 0 bps| 7.42| 1.0 GB| 0 B|get http://appliwave.testdebit.info/1G.iso ([2a05:46c0:100:1007::3]:80 - 7.969 ms)
Job 3| 940.3 Mbps| 0 bps| 7.99| 939.7 MB| 0 B|get http://appliwave.testdebit.info/1G.iso ([2a05:46c0:100:1007::3]:80 - 8.445 ms)
Job 4| 1.1 Gbps| 0 bps| 7.30| 1.0 GB| 0 B|get http://appliwave.testdebit.info/1G.iso ([2a05:46c0:100:1007::3]:80 - 8.28 ms)
Total| 4.9 Gbps| 0 bps| 7.99| 4.9 GB| 0 B|
./nspeed get -n 7 http://appliwave.testdebit.info/1G.iso
Job| Read speed| Write speed| Time| Bytes read| Bytes written|command
Job 0| 838.8 Mbps| 0 bps| 7.99| 837.9 MB| 0 B|get http://appliwave.testdebit.info/1G.iso ([2a05:46c0:100:1007::3]:80 - 8.612 ms)
Job 1| 926.8 Mbps| 0 bps| 7.99| 925.3 MB| 0 B|get http://appliwave.testdebit.info/1G.iso ([2a05:46c0:100:1007::3]:80 - 8.408 ms)
Job 2| 819.7 Mbps| 0 bps| 7.98| 818.1 MB| 0 B|get http://appliwave.testdebit.info/1G.iso ([2a05:46c0:100:1007::3]:80 - 9.42 ms)
Job 3| 741.4 Mbps| 0 bps| 7.99| 740.3 MB| 0 B|get http://appliwave.testdebit.info/1G.iso ([2a05:46c0:100:1007::3]:80 - 9.30 ms)
Job 4| 851.3 Mbps| 0 bps| 8.00| 851.4 MB| 0 B|get http://appliwave.testdebit.info/1G.iso ([2a05:46c0:100:1007::3]:80 - 8.886 ms)
Job 5| 910.5 Mbps| 0 bps| 7.99| 909.4 MB| 0 B|get http://appliwave.testdebit.info/1G.iso ([2a05:46c0:100:1007::3]:80 - 8.597 ms)
Job 6| 838.6 Mbps| 0 bps| 7.99| 837.4 MB| 0 B|get http://appliwave.testdebit.info/1G.iso ([2a05:46c0:100:1007::3]:80 - 8.779 ms)
Total| 5.9 Gbps| 0 bps| 8.00| 5.9 GB| 0 B|
-
Je test ton programme sous linux car mon script de monitoring de ma bande passante fonctionne plus, le serveur en face est down :(
Petit problème sur le serveur SpeedTest de Massy, il sera de retour ce week-end.
-
Ah ok. Merci de l'information
-
Jusqu’à 5 instances de dl pas de soucis mais après, il lit pas le fichier en entier.
c'est normal car par défaut, un 'get' ou un 'put' s'arrête après 8 secondes s'il ne finit pas avant. Tu peux ajouter '-t N' a la commande pour prolonger au besoin (N en secondes).
apres usuellement ca ne sert a rien de tester plus longtemps sauf cas particulier. Ce n'est pas un outil de téléchargement complet mais de mesure du téléchargement. Tester 10 instances ca ferait 100 Go a transférer ce qui est beaucoup. J'ai pris 8 secondes car c'est pratique pour la conversion bps/octet et une durée ni trop courte, ni trop longue pour bien tester un débit.
Total| 5.9 Gbps| 0 bps| 8.00| 5.9 GB| 0 B|
a 5.9 Gbps on transfert 5.9 Go en 8 secondes.
Du coup dans ton exemple (connexion très supérieure a 1Gbps) il est mieux d'utiliser une mire de 10G ( http://appliwave.testdebit.info/10G.iso ) ca permet d'avoir aussi 8 secondes avec une seule instance. Idéalement il faudrait des mires de tailles infinies mais aucun serveur n'en propose (sauf le serveur nspeed a venir).
A noter également que l'option global -timeout ne fonctionne pas correctement dans la version public de nspeed. (cette option est censé arrêter tout les tests après une durée donnée).
-
Ah d'accord je comprends mieux.
Merci pour l'information.
-
on m'a signalé et j'ai constaté aussi que depuis peu que sur Windows 11, la commande powershell Get-NetAdapterHardwareInfo ne fonctionne plus qu'en étant administrateur.
Est-ce le cas chez vous (j'ai un version Insider seulement) ? sur Windows 10 cela marche t'il toujours ?
Je comptais utiliser les API qu'utilise cette commande pour obtenir des infos matériels sur les cartes réseaux.
-
Sous Powershell dans un compte admin sans élévation de privilège :
Get-NetAdapterHardwareInfo
Name Segment Bus Device Function Slot NumaNode PcieLinkSpeed PcieLinkWidth Version
---- ------- --- ------ -------- ---- -------- ------------- ------------- -------
Wi-Fi 0 61 0 0 17 5.0 GT/s 1 1.1
Carte 1000 Mbps 0 60 0 0 16 2.5 GT/s 1 1.1
Je vais voir sur un compte [utilisateur standard et j'éditerai.
-
Windows 10 ou 11 ?
-
J'ai pris 8 secondes car c'est pratique pour la conversion bps/octet et une durée ni trop courte, ni trop longue pour bien tester un débit.
J'utilisais 13 secondes en mode ADSL... maintenant avec le fibre ou BBR/CUBIC je ne sais pas.
edit: Je viens de relancer en mode 4G en BBR et il me semble que 13 secondes est encore nécéssaire pour avoir la
vitesse max..............
-
Sur un PC Portable en Utilisateur non admin
PS C:\Users\Dada> Get-NetAdapterHardwareInfo
Name Segment Bus Device Function Slot NumaNode PcieLinkSpeed PcieLinkWidth Version
---- ------- --- ------ -------- ---- -------- ------------- ------------- -------
Wi-Fi 0 0 20 3 Unknown 0 1.0
Windows 11 21H2 Build 22000.856
-
ok merci! ca doit être la version Insiders (22H2 22622.586) qui a le souci.
-
ok merci! ca doit être la version Insiders (22H2 22622.586) qui a le souci.
En espérant que cela ne soit pas intégré dans les futures versions "normales" de W11...
-
Sous Win10, user sans élévation de privilèges :
PS C:\Users> Get-NetAdapterHardwareInfo
Name Segment Bus Device Function Slot NumaNode PcieLinkSpeed PcieLinkWidth Version
---- ------- --- ------ -------- ---- -------- ------------- ------------- -------
Wi-Fi 0 6 0 0 5.0 GT/s 1 1.1
Ethernet 0 7 0 0 5.0 GT/s 1 1.1
Pas de Win11 sous la main pour tester.
-
Bonjour,
Windows 10 ou 11 ?
C'est sous Windows 11 et cela a fonctionné aussi en utilisateur normal.
-
Apres plus d'un an de teasing..., la v0.10 est dispo !
téléchargement a l'endroit habituel: https://dl.nspeed.app/nspeed-client/latest/
les changements: https://github.com/nspeed-app/nspeed/blob/main/CHANGELOG.md
Les grosses nouveautés:
- le support de HTTP/3
- la preview de l'interface web via l'API (cf exemple plus bas)
- des infos machines via l'API (minimales pour le moment)
Le build pour MacOs est un peu complexe à faire et est un peu moins complet que pour Windows et Linux (je n'ai pas de Mac ni l'intention d'en acheté un. Je fais des tests avec qemu/quickemu (https://github.com/quickemu-project/quickemu) sur un serveur Linux). Si un sponsor veut m'offrir un Macbook Pro M2 , je suis preneur ;)
Cela reste pour le moment un programme peu "user friendly" j'en suis conscient. L'épuration et l'accessibilité viendront apres la diffusion des sources.
La nouveau interface web permet de voir en temps réel les débits des interfaces (au niveau de l'OS) et du cpu. Elle peut servir pour autre chose qu'un test nspeed. C'est un peu un "moniteur système" simpliste en une page web.
Vous pouvez la lancer avec par exemple:
./nspeed api -p 8888 -browse
Et dans une autre fenêtre, lancer un test nspeed ou curl ou un test speedtest.net / nperf, etc , un teléchargement , etc.
Pour le moment c'est 'brut' et sans trop de contrôle. Ca marche a distance sur une machine sans interface comme un serveur ou un routeur (préciser l'option -a).
L'étape suivant pour la v0.11 est la génération des résultats de nspeed sous forme de fichier web incluant la même vue qu'en temps réel mais en utilisant les données du test: l'idée est de générer un fichier json des métrics du test et intégré ce json dans un ficher html (+javascript+css) qui peut se consulter sur n'importe quel navigateur.
-
./nspeed api -p 8888 -browse
J'ai pas la bonne version ?
philippemarques@MacBook-Pro-de-Philippe Downloads % ./nspeed_darwin_amd64 api -p 8888 -browse
flag provided but not defined: -browse
Usage of api: api [options]
Available options:
-4 use IPv4 only
-6 use IPv6 only
-a string
Hostname or ip address to listen (use "" for all interfaces/all addresses) (default "localhost")
-cert string
TLS certificate file
-key string
TLS Key file
-p int
Port to listen on (default 7333)
-self
listen in HTTPS using a self-signed TLS certificate
flag provided but not defined: -browse
philippemarques@MacBook-Pro-de-Philippe Downloads %
philippemarques@MacBook-Pro-de-Philippe Downloads % ./nspeed_darwin_amd64 -version
v0.9-10-g51aad89
-
J'ai pas la bonne version ?
non tu as la 0.9. La nouvelle c'est la 0.10.
-
Good Job !!
-
sur Mac, y'a pas grand chose encore car j'ai pas le code qu'il faut pour lire les statistiques des interfaces.
voila le code que j’utilise sur Linux:
// return rx/tx counters for interfaces - Linux version
func GetNetStats(interfaces []net.Interface, dir string) []float64 {
var values []float64
for _, itf := range interfaces {
var value int
file, err := os.Open(fmt.Sprintf("/sys/class/net/%s/statistics/%s_bytes", itf.Name, dir))
if err != nil {
value = -1
} else {
fmt.Fscanf(file, "%d", &value)
}
values = append(values, float64(value))
}
return values
}
c'est simplement une lecture des compteurs via sysfs (https://fr.wikipedia.org/wiki/Sysfs). peut-etre pas ce qu'il y a de plus performant et ne fonctionne pas sur les Linux qui n'ont pas de sysfs actif.
sur Windows, je fais un appel systeme a GetifEntry2Ex (https://learn.microsoft.com/en-us/windows/win32/api/netioapi/nf-netioapi-getifentry2ex) pour chaque interface.
Je n'ai pas encore rechercher de solution pour MacOS et les autres variantes Unix et *BSD. Si quelqu'un sait ce qu'il faut faire je suis preneur (code Go ou juste les appels systèmes à faire).
-
Regardes par là, il doit bien y avoir une structure définie dans un .h qui t'intéresse.
https://github.com/apple/darwin-xnu/tree/main/bsd/sys
-
os.Open(fmt.Sprintf("/sys/class/net/%s/statistics/%s_bytes
Le Code des OS pour Apple, dedans j'ai vu des trucs pour le Kernel avec les kext, je connais pas le nom de la fonction spécifique qui retourne les informations que tu nécessites "/sys/class/net/*" c'est certainement dans libsyscall
https://opensource.apple.com/releases/
-
Regardes si tu trouves ton bonheur par là ( c'est ce qui me semble le plus à jour)
Dans les kext-tools je suppose.
https://github.com/apple-oss-distributions/distribution-macOS/tree/macos-130
-
Dans les exemples, "nspeed put -n 2 https://bouygues.testdebit.info/ 1g" ne fonctionne pas.
Il faut faire "nspeed put -http11 -n 2 https://bouygues.testdebit.info/ 1g", parce que malheureusement tous ces serveurs ne semblent supporter que le HTTP/1.1 en upload (alors que le HTTP/2.0 fonctionne en download).
-
Dans les exemples, "nspeed put -n 2 https://bouygues.testdebit.info/ 1g" ne fonctionne pas.
Il faut faire "nspeed put -http11 -n 2 https://bouygues.testdebit.info/ 1g", parce que malheureusement tous ces serveurs ne semblent supporter que le HTTP/1.1 en upload (alors que le HTTP/2.0 fonctionne en download).
hum bonne trouvaille. je regarde ca.
a noter que 'put' c'est maintenant 'post' (nspeed est maintenant en phase avec les méthodes du protocol http)
-
a noter que, sous Linux, on peut ajouter "GODEBUG=http2debug=2 " devant nspeed pour voir une trace HTTP/2.
'put', en http/2, n'est pas supporter pas ce serveur.
je regarde pourquoi 'post' échoue aussi.
-
petit boulette dans le build:
- l'option '-html' est présente mais ne fonctionne pas (le fichier html généré est vide) , ce qui est normal car c'est prévu que pour la v0.11 ;)
- sur Windows, '-version' n'affiche pas la version de nspeed
Je publierai une mise a jour demain.
-
a noter que 'put' c'est maintenant 'post' (nspeed est maintenant en phase avec les méthodes du protocol http)
PUT et POST sont deux méthodes HTTP différentes.
Avec bouygues.testdebit.info, le test d'upload en HTTP/1.1 exploite des limitations :
- Avec PUT, le serveur répond "100 Continue", on envoie les données, et à la fin il répond "405 Method Not Allowed".
- Avec POST, le serveur répond "100 Continue", on envoie les données, et à la fin il répond par la page HTML.
En HTTP/2 le serveur répond en parallèle, puis termine l'échange.
Et même en essayant de tricher :
curl -vvv --http2-prior-knowledge -X POST -F "filecontent=@/dev/zero" -o /dev/null http://bouygues.testdebit.info/1G.isoCurl envoie la taille de la window HTTP/2, soit 64Ko, puis il s'arrête et il n'y a plus que le download qui continue.
Sinon, j'avais déjà relevé le comportement peu intuitif de la commande "nspeed server" sans l'option -a, ou avec une interface.
Le readme dit que par défaut ça utilise 127.0.0.1, mais ça dépend des machines :
- sur WSL j'ai 127.0.0.1 par défaut, et "nspeed server -6" échoue (mais "nspeed server -a ::1" fonctionne)
- sous Linux et Windows, j'ai ::1 par défaut (IPv6 seulement), et "nspeed server -4" fonctionne pour avoir l'IPv4
De même "-a lo" ou toute autre interface semble choisir IPV6.
Certes on peut :
- utiliser -a "" ou -a :: pour écouter sur toutes les interfaces en IPv4 et IPv6.
- donner deux commandes : "nspeed server -a enp5s0 -4 server -a enp5s0 -6" ou "nspeed server -a 127.0.0.1 server -a ::1"
De même -
-
PUT et POST sont deux méthodes HTTP différentes.
oui c'est juste que depuis le début le 'put' de nspeed faisait un POST.
avec la v0.10 j'ai changé cela. 'put' fait maintenant un 'PUT' et j'ai ajouté 'post' si on veut faire un POST. histoire d'être cohérent avec le protocole HTTP.
Sinon, j'avais déjà relevé le comportement peu intuitif de la commande "nspeed server" sans l'option -a, ou avec une interface.
Le readme dit que par défaut ça utilise 127.0.0.1, mais ça dépend des machines :
- sur WSL j'ai 127.0.0.1 par défaut, et "nspeed server -6" échoue (mais "nspeed server -a ::1" fonctionne)
- sous Linux et Windows, j'ai ::1 par défaut (IPv6 seulement), et "nspeed server -4" fonctionne pour avoir l'IPv4
De même "-a lo" ou toute autre interface semble choisir IPV6.
Certes on peut :
- utiliser -a "" ou -a :: pour écouter sur toutes les interfaces en IPv4 et IPv6.
- donner deux commandes : "nspeed server -a enp5s0 -4 server -a enp5s0 -6" ou "nspeed server -a 127.0.0.1 server -a ::1"
De même -
oui c'est "normal". 'nspeed server' fait par défaut 'nspeed server -a localhost' (comme le montre 'nspeed server -h')
il y une reso dns pour résoudre 'localhost'. Suivant l'hôte ca peut ne pas fonctionner pour IPv6, sans doute le cas de WSL ("ping -6 localhost" devrait avoir le même probleme non ?)
Je pourrais forcer pour résoudre directement localhost en 127.0.0.1 et ::1 pour éviter ce genre de problème mais c'est bien aussi de pas toujours s'adapter aux OS mal configurés ? j'ai pas tranché encore la.
cf aussi le CHANGELOG.md , il y a une note a ce sujet (https://github.com/nspeed-app/nspeed/blob/main/CHANGELOG.md#known-issues--caveats-1) ( qui n'est plus trop a jour car cela bind bien en IPv6 par défaut si la réso dns retourne ::1).
Pour écouter a la fois en IPv6 et IPv4 avec une seule commande 'server' ou plus généralement sur plus d'une adresse, il n'y a que "" qui fonctionne. Pour que ca fonctionne avec localhost ou n'importe quelle interface, il faudrait faire un SO_BINDTODEVICE ce qui n'est pas supporter directement en Go car ce n'est pas multiplateforme de base (ca a peut etre changé depuis , je n'ai pas creusé plus - c'est une histoire de "dual stack socket", entres autres). Ce n'est pas crucial pour le moment mais c'est dans la todo list.
Il est vrai que ca serait pratique de pouvoir 'nspeed server -a eth0' pour écouter sur toutes les IP (une ou plusieurs v4 et et une ou plusieurs v6) d'eth0.
-
il y une reso dns pour résoudre 'localhost'. Suivant l'hôte ca peut ne pas fonctionner pour IPv6, sans doute le cas de WSL ("ping -6 localhost" devrait avoir le même probleme non ?)
La configuration est bizarre : /etc/hosts n'a que 127.0.0.1 pour localhost, et a ip6-localhost et ip6-loopback pour ::1.
Les commandes host et nslookup font toujours une résolution DNS avec le serveur, et donc elles donnent 127.0.0.1 et ::1 (dans cet ordre).
Mais la libc se contente bien de /etc/hosts quand le nom de domaine est trouvé dedans, même s'il n'y a qu'une seule famille, donc "ping -6 localhost" ne fonctionne pas.
Pour écouter a la fois en IPv6 et IPv4 avec une seule commande 'server' ou plus généralement sur plus d'une adresse, il n'y a que "" qui fonctionne.
:: semble fonctionner aussi (du moins sous Linux, WSL et Windows), et n'a pas les éventuels problèmes avec les quotes en fonction du shell sous Windows.
La valeur par défaut actuelle à l'inconvénient d'avoir un comportement variable (mais le client reste cohérent, donc http://localhost:7333 fonctionnera bien).
Ecouter sur toutes les adresses par défaut serait plus agressif, l'idéal serait 127.0.0.1 + ::1, mais sans SO_BINDTODEVICE il n'y a probablement pas de façon de le faire.
-
Je pourrais forcer pour résoudre directement localhost en 127.0.0.1 et ::1 pour éviter ce genre de problème mais c'est bien aussi de pas toujours s'adapter aux OS mal configurés ? j'ai pas tranché encore la.
Tu connais la maxime des vieux barbus : you ask for it, you have it.
Si c'est mal configuré c'est pas de ton ressort. Ensuite, tu tranches comme tu veux.
Je sais pas trop ou tu veux aller avec l'outil, Je me doute que cela entre dans le cadre des outils de mesures pour les box.
Mais si tu te coltines une dual stack, je vois pas l'avantage concurrentiel avec iperf3 ou autres outils et cela te double le boulot pour réinventer la roue, autant que tu prennes les sources de iperf3 et en copie des bouts de code.
Par contre, si tu restreins à IPv6 et intègre les standards encore en devenir, là tu as un vrai avantage concurrentiel, avec cet outil, pendant que les autres continuent à se coltiner une dual stack et perdre leur temps, toi tu peux continuer à avancer.
Je l'accorde, il ne dois pas exister beaucoup de machine en mono stack exclusivement IPv6. Je vois bien ma dernière installation de Debian bookworm installe IPV4 que on le veuille ou pas, il faut ensuite tout désinstaller pour ne garder que une mono stack IPV6
-
J'ai fait un nouveau build expérimental et un nouveau format de distribution: https://dl.nspeed.app/nspeed-client/preview/ (pas pour Mac).
C'est en préparation du CI/CD pour automatiser les builds et ensuite publier les sources.
Changements:
- numéro de version de type "semantic versioning" (https://semver.org/). On passe donc a la v0.0.10 . "-version" devrait marcher correctement sur Windows.
- l'option -html est supprimée pour le moment
- utilisation de https://goreleaser.com/ pour automatiser les builds
- pour les architectures amd64 (x64) , le préfix '_v1' indique le niveau d'architecture (https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels). Je n'exclu pas dans l'avenir de générer des builds supplémentaires avec des niveaux plus élevés si cela améliore certaines performances. Idéalement il ne faudrait pas mettre _v1 quand c'est le niveau le plus bas mais juste _v2, _v3 ou _v4 sur les autres. Je n'ai pas creusé plus GoReleaser pour cela.
L'étape suivante sera d'utiliser les GitHub Actions pour faire tourner GoReleaser sur les serveurs CI/CD de Github et notamment sur des runner macos (https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners) pour produire le binaire darwin/macos.
-
update du build preview: https://dl.nspeed.app/nspeed-client/preview/ (Windows & Linux seulement).
(-version = v0.0.10-7-g3e22883-dirty)
- synchro interne quand on fait des get/put sur le(s) server(s) de la meme commande (plus besoin de -w 1. Dans de rares cas cela peut ne pas fonctionner, je n'ai pas encore trouvé la raison)
- changement de logique quand on combien des commandes 'qui ne s’arrêtent jamais' comme 'server' avec des commandes qui terminent comme 'get'. plus besoin de "server -n 1" pour faire un test local par exemple. le(s) serveur(s) s'arreteront quand il n'y a plus d'activité.
- épuration de l'affichage par défaut
- update lib http/3
on peut donc maintenant faire, des tests du genre:
./nspeed get http://localhost:7333/20g server
./nspeed get localhost:7333/20g server -self
./nspeed get -http3 localhost:7333/20g server -http3
ou
./nspeed get -n 2 http://localhost:7333/20g server put -n 4 http://localhost:7333/ 10g
et meme un truc du genre:
./nspeed get http://localhost:7333/20g server get -http3 localhost:7333/20g server -http3
-
update du build preview: https://dl.nspeed.app/nspeed-client/preview/ (Windows & Linux seulement).
(-version = v0.0.10-9-g453c5b4)
- correction d'un bug 100% cpu en mode serveur
-
update du build preview: https://dl.nspeed.app/nspeed-client/preview/ (Windows & Linux seulement).
(-version = v0.0.10-10-gfc2875e)
- modifications du client http (get/post/put):
- l'option --http11 est renommée --http1.1 - fonctionnement inchangé.
- ajout de l'option --http2 pour imposer/forcer l'utilisation de HTTP/2. Contrairement a curl par exemple, si le serveur en face ne supporte pas HTTP/2 la commande va échouer. alors que curl --http2 va tenter HTTP/2 en 1er mais fallback en HTTP1.1.
-
> - ajout de l'option --http2 pour imposer/forcer l'utilisation de HTTP/2.
tu peux la renommer "--forcehttp2" ?
-
> - ajout de l'option --http2 pour imposer/forcer l'utilisation de HTTP/2.
tu peux la renommer "--forcehttp2" ?
oui éventuellement avant la release v1.0.
J'ai été au plus rapide parce que j'en avais besoin pour un cas concret.
Il y aura a un moment une passe de réflexion sur toutes les options, leur noms, etc donc je verrai a ce moment.
-
Peut-être se baser sur les option CURL quand elles existent déjà chez CURL ?
-
Peut-être se baser sur les option CURL quand elles existent déjà chez CURL ?
dans la mesure du possible oui.
-
update du build preview: https://dl.nspeed.app/nspeed-client/preview/ (Windows & Linux seulement).
(-version = v0.0.10-11-g78ea76d)
- client http (post/put):
- correction d'un bug de calcul du débit final
- modification de quelques messages en mode -debug
[/quote]
-
~$ ./nspeed ciphers bouygues.testdebit.info
Jobs:
0-ciphers {Target: bouygues.testdebit.info (;), delay: 0, timeout:0s}
running...
this client has AES hardware support: true
bouygues.testdebit.info:443 supports TLS 2.0 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
bouygues.testdebit.info:443 supports TLS 2.0 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
bouygues.testdebit.info:443 supports TLS 2.0 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
bouygues.testdebit.info:443 supports TLS 3.0 TLS_AES_128_GCM_SHA256
bouygues.testdebit.info:443 supports TLS 3.0 TLS_AES_256_GCM_SHA384
bouygues.testdebit.info:443 supports TLS 3.0 TLS_CHACHA20_POLY1305_SHA256
all done
no metrics to report
La version mineure semble affichée comme une version majeure, c'est TLS 1.2 et TLS 1.3.
-
La version mineure semble affichée comme une version majeure, c'est TLS 1.2 et TLS 1.3.
ah bien vu ! merci je corrige.
-
update du build preview: https://dl.nspeed.app/nspeed-client/preview/ (Windows & Linux seulement).
(-version = v0.0.10-22-gba2ba49)
- ciphers: fixed TLS version text messages
- http/3: using now github.com/quic-go/quic-go (just a path change of github.com/lucas-clemente/quic-go)
- fixed a race condition in debug mode
- preparing metrics export
-
C'est voulu que nspeed ne renvoie plus le champ Server dans les headers ?
-
C'est voulu que nspeed ne renvoie plus le champ Server dans les headers ?
pas vraiment non :) je regarde cela.
-
update du build preview: https://dl.nspeed.app/nspeed-client/preview/ (Windows & Linux seulement).
(-version = v0.0.10-23-g45497b0-dirty)
- fixed missing 'Server' header
merci @ouno
-
update du build preview: https://dl.nspeed.app/nspeed-client/preview/ (Windows & Linux seulement).
(-version = v0.0.10-27-g0c02f16)
rien de nouveau en terme de fonctionalités:
- reduction des affichages en preparation de la nouvelle UI
- préparation en interne au mode 'benchmark'
-
update du build preview: https://dl.nspeed.app/nspeed-client/preview/ (Windows & Linux seulement).
(-version = v0.0.10-29-g4f7e829 )
- nouvelle commande 'bench' (raccourci 'b') (voir ./nspeed b -h)
- fix synchro interne client/server
- changement mineur affichages
tl;dr: bench permet de faire des tests locaux (localhost) directement sans taper une longue commande. c'est dans les faits juste un raccourci:
./nspeed b h1g est équivalent a
./nspeed server get localhost:7333/20gles benchs peuvent etre groupés (séparateur virgule) pour etre effectuer en meme temps:
./nspeed b h1g,h2g est équivalent a :./nspeed server -p 7333 get -n 1 http://localhost:7333/20g server -p 7334 -self get -n 1 -self -http2 https://localhost:7334/20g
et aussi a:
./nspeed b h1g b -p 7334 h2g
(l'avantage de grouper donc est la gestion auto du numéro de port quand il y a plusieurs serveurs).
voici un exemple des 3 versions d'HTTP en meme temps en GET:
~ ./nspeed b h1g,h2g,h3g
4:30PM | WARN | server listening on https://127.0.0.1:7335 (HTTP/3 on UDP) job=4
4:30PM | WARN | server listening on http://127.0.0.1:7333 job=0
4:30PM | WARN | server listening on https://127.0.0.1:7334 (H2C = false) job=2
running...
all done
Job| Read speed| Write speed| Time| Bytes read| Bytes written|command
Job 1| 38.9 Gbps| 0 bps| 4.11| 20.0 GB| 0 B|get http://localhost:7333/20g (127.0.0.1:7333 - 0.271 ms - HTTP/1.1)
Job 3| 6.6 Gbps| 0 bps| 8.00| 6.6 GB| 0 B|get -http2 https://localhost:7334/20g (127.0.0.1:7334 - 0.183 ms - HTTP/2.0)
Job 5| 1.2 Gbps| 0 bps| 8.00| 1.2 GB| 0 B|get -http3 https://localhost:7335/20g ( - 0.0 ms - HTTP/3.0)
Total| 27.8 Gbps| 0 bps| 8.00| 27.8 GB| 0 B|
on remarque que HTTP/1.1 termine trop vite, on peut changer la taille avec -s:
./nspeed b -s 40g h1g,h2g,h3g
4:32PM | WARN | server listening on https://127.0.0.1:7335 (HTTP/3 on UDP) job=4
4:32PM | WARN | server listening on http://127.0.0.1:7333 job=0
4:32PM | WARN | server listening on https://127.0.0.1:7334 (H2C = false) job=2
running...
all done
Job| Read speed| Write speed| Time| Bytes read| Bytes written|command
Job 1| 34.2 Gbps| 0 bps| 8.00| 34.2 GB| 0 B|get http://localhost:7333/40g (127.0.0.1:7333 - 0.142 ms - HTTP/1.1)
Job 3| 6.1 Gbps| 0 bps| 8.00| 6.1 GB| 0 B|get -http2 https://localhost:7334/40g (127.0.0.1:7334 - 0.88 ms - HTTP/2.0)
Job 5| 1.1 Gbps| 0 bps| 8.00| 1.1 GB| 0 B|get -http3 https://localhost:7335/40g ( - 0.0 ms - HTTP/3.0)
Total| 41.4 Gbps| 0 bps| 8.00| 41.4 GB| 0 B|
on peut aussi avoir plusieurs flux avec -n:
./nspeed b -s 40g -n 8 h1g,h1p
4:36PM | WARN | server listening on http://127.0.0.1:7334 job=9
4:36PM | WARN | server listening on http://127.0.0.1:7333 job=0
running...
all done
Job| Read speed| Write speed| Time| Bytes read| Bytes written|command
Job 1| 3.3 Gbps| 0 bps| 8.00| 3.3 GB| 0 B|get http://localhost:7333/40g (127.0.0.1:7333 - 0.188 ms - HTTP/1.1)
Job 2| 3.4 Gbps| 0 bps| 8.00| 3.4 GB| 0 B|get http://localhost:7333/40g (127.0.0.1:7333 - 0.213 ms - HTTP/1.1)
Job 3| 3.3 Gbps| 0 bps| 8.00| 3.3 GB| 0 B|get http://localhost:7333/40g (127.0.0.1:7333 - 0.334 ms - HTTP/1.1)
Job 4| 3.5 Gbps| 0 bps| 8.00| 3.5 GB| 0 B|get http://localhost:7333/40g (127.0.0.1:7333 - 0.189 ms - HTTP/1.1)
Job 5| 3.4 Gbps| 0 bps| 8.00| 3.4 GB| 0 B|get http://localhost:7333/40g (127.0.0.1:7333 - 0.160 ms - HTTP/1.1)
Job 6| 3.3 Gbps| 0 bps| 7.99| 3.3 GB| 0 B|get http://localhost:7333/40g (127.0.0.1:7333 - 0.308 ms - HTTP/1.1)
Job 7| 3.4 Gbps| 0 bps| 8.00| 3.4 GB| 0 B|get http://localhost:7333/40g (127.0.0.1:7333 - 0.370 ms - HTTP/1.1)
Job 8| 3.3 Gbps| 0 bps| 7.99| 3.3 GB| 0 B|get http://localhost:7333/40g (127.0.0.1:7333 - 0.319 ms - HTTP/1.1)
Job 10| 0 bps| 7.0 Gbps| 8.00| 0 B| 7.0 GB|put http://localhost:7334/ 40.0 GB (127.0.0.1:7334 - 0.123 ms - )
Job 11| 0 bps| 6.9 Gbps| 8.00| 0 B| 6.9 GB|put http://localhost:7334/ 40.0 GB (127.0.0.1:7334 - 0.326 ms - )
Job 12| 0 bps| 6.9 Gbps| 8.00| 0 B| 6.9 GB|put http://localhost:7334/ 40.0 GB (127.0.0.1:7334 - 0.196 ms - )
Job 13| 0 bps| 6.5 Gbps| 8.00| 0 B| 6.5 GB|put http://localhost:7334/ 40.0 GB (127.0.0.1:7334 - 0.294 ms - )
Job 14| 0 bps| 7.3 Gbps| 8.00| 0 B| 7.3 GB|put http://localhost:7334/ 40.0 GB (127.0.0.1:7334 - 5.294 ms - )
Job 15| 0 bps| 7.2 Gbps| 8.00| 0 B| 7.2 GB|put http://localhost:7334/ 40.0 GB (127.0.0.1:7334 - 0.349 ms - )
Job 16| 0 bps| 7.5 Gbps| 8.00| 0 B| 7.5 GB|put http://localhost:7334/ 40.0 GB (127.0.0.1:7334 - 0.698 ms - )
Job 17| 0 bps| 7.2 Gbps| 8.00| 0 B| 7.2 GB|put http://localhost:7334/ 40.0 GB (127.0.0.1:7334 - 2.857 ms - )
Total| 26.9 Gbps| 56.5 Gbps| 8.00| 26.9 GB| 56.5 GB|
bugs connus:
- "failed to serve: quic: Server closed" arrive parfois avec HTTP/3 (qui est toujours en dev).
- "-6" peut échouer sur certaines machines (résolution de 'localhost' en IPv6 ne fonctionne par correctement).
-
merci @ouno
Merci à toi !
- nouvelle commande 'bench' (raccourci 'b') (voir ./nspeed b -h)
C'est bizarre chez moi le mode bench paraît moins performant que le mode normal sous Windows:
Mode bench: 28.2 Gbps
>nspeed-v0.0.10-29-g4f7e829.exe b -4 h1g
6:25PM | WARN | server listening on http://127.0.0.1:7333 job=0
running...
all done
Job| Read speed| Write speed| Time| Bytes read| Bytes written|command
Job 1| 28.2 Gbps| 0 bps| 5.67| 20.0 GB| 0 B|get http://localhost:7333/20g (127.0.0.1:7333 - 0.0 ms - HTTP/1.1)
Total| 28.2 Gbps| 0 bps| 5.67| 20.0 GB| 0 B|
Mode manuel en lançant nspeed server et nspeed client séparément: 43.2 Gbps
>nspeed-v0.0.10-29-g4f7e829.exe -verbose server -a 127.0.0.1 -t 120 -s 60G
6:27PM | INFO | job 0 = HTTP server {Address: "127.0.0.1", port: 7333, IPversion: 0, max_size: 64.4 GB, max_request, max duration: 2m0s, UseTLS: false, H2C: false, maxruns: 0, max life: 0s}
6:27PM | INFO | waiting on infinite jobs to be ready
6:27PM | WARN | server listening on http://127.0.0.1:7333 job=0
6:27PM | INFO | all infinite jobs are ready
running - hit ctrl-C or send a kill signal to end
6:27PM | INFO | rootHandler: GET - /20g
6:27PM | INFO | streaming 20g bytes (= 20000000000 bytes) with extention:
6:27PM | INFO | AverageReadSize=0 AverageWriteSize=262147 ReadBPS="0 bps" ReadCount=0 TotalRead=0 TotalWrite=20000000000 WriteBPS="43.3 Gbps" WriteCount=76293 duration=3.6971852 job=0 url="download 20g to 127.0.0.1:51675 (chunk=262144)"
>nspeed-v0.0.10-29-g4f7e829.exe get http://127.0.0.1:7333/20g
running...
all done
Job| Read speed| Write speed| Time| Bytes read| Bytes written|command
Job 0| 43.2 Gbps| 0 bps| 3.70| 20.0 GB| 0 B|get http://127.0.0.1:7333/20g (127.0.0.1:7333 - 0.942 ms - HTTP/1.1)
Total| 43.2 Gbps| 0 bps| 3.70| 20.0 GB| 0 B|
Autre chose de bizarre (toujours sous Windows), j'ai de meilleures perfs avec nspeed server quand j'utilise un client en Perl:
Mode manuel en lançant nspeed server et un client HTTP en Perl: 51.2 Gbps
6:31PM | INFO | rootHandler: GET - /20g
6:31PM | INFO | streaming 20g bytes (= 20000000000 bytes) with extention:
6:31PM | INFO | AverageReadSize=0 AverageWriteSize=262147 ReadBPS="0 bps" ReadCount=0 TotalRead=0 TotalWrite=20000000000 WriteBPS="51.2 Gbps" WriteCount=76293 duration=3.1257905 job=0 url="download 20g to 127.0.0.1:51723 (chunk=262144)"
C'est sans doute lié aux spécificités de l'interface localhost qui n'est pas très représentative d'une vraie utilisation réseau, mais je n'ai pas d'interface réseau assez rapide pour tester...
-
J'avoue n'avoir pas fait encore trop de tests avec Windows. Effectivement sur ma machine Windows, j'ai les memes écarts.
Sur Linux c'est identique.
Y'a peut-etre une gestion des process/threads différents entre les 2 architectures ou un bizarrerie quelque part dans la synchro de mon code....
Le build de l'exe est fait sur Linux, peut-etre cela joue aussi (encore que ca ne devrait pas).
A creuser en tout cas pour la suite. je note.
-
update du build preview de la v0.0.11: https://dl.nspeed.app/nspeed-client/preview/
(-version = v0.0.10-88-g47e506c )
tres grosse mise a jour (le code a quasiment doublé) donc sans doute beaucoup de bugs ...
on dispose maintenant de versions pour:
Windows sur x64, arm64 et arm6
Linux sur x64,4 variantes mips, arm64 et arm6
Darwin (macos) x64 (arm a venir).
J'ai testé sur un router ubiquity er-x (mipsle_hardfloat), ca fonctionne.
Les changements: https://github.com/nspeed-app/nspeed/blob/preview/CHANGELOG.md (qui reprend des changement déja introduits par les versions preview précedentes)
Zoom sur les changements principaux:
- l'arrivé du traitement par lots (batches) grâce au commandes "from" et "then". On peut maintenant enchaîner des commandes ou les lire depuis un fichier ou un site web. Il y a des exemples sur https://dl.nspeed.app/ , par exemple:
./nspeed from https://dl.nspeed.app/bbrcubicCela va télécharger un fichier texte et lire les commandes qu'il y a dedans. Ca marche aussi avec un fichier local.
La syntaxe pour le fichier est la même qu'en ligne de commande (voir les fichiers d'exemple).
Chaque ligne correspondant a un lot de traitement (donc les lignes sont exécutées une après l'autre et pas toute en meme temps).
Autre exemples:
./nspeed from https://dl.nspeed.app/cfpour ceux qui ont une freebox: https://dl.nspeed.app/freebox
- la sortie des résultats en json avec en option une échantillonnage réglable ("-rate 100ms" par exemple). Utiliser '-' pour sortie sur l'écran directement par exemple:
./nspeed -json - get google.com
Le json inclut la gateway, l'interface et l'ip utilisée pour atteindre la cible.
- le serveur n'a plus de port par défaut 7333 et utilise maintenant un port libre au hasard. on peut toutefois toujours choisir le port qu'on souhaite avec -p.
NB: la sortie en html bien que indiquée dans le CHANGELOG n'est pas dispo dans cette preview.
a suivre tres vite, la sortie en html donc...
-
Bonjour!
Je me permet de répondre dans ce vieux topic, j'éspère sans causer de soucis :-X
J'ai tenter de faire tourner nspeed sur un UDM mais j'ai toujours une erreur "exec format error", j'ai tester les 2 versions pour linux disponible sur /latest. Je m'y prends mal ou pas moyen de faire tourner cela sur cet OS?
-
As-tu essayé la version ARM64 ?
-
As-tu essayé la version ARM64 ?
https://dl.nspeed.app/nspeed-client/latest/
Cela serait la version darwin ici? (juste pour être sur)
-
Non, c'est pour Apple,
Plutot cette version : https://dl.nspeed.app/nspeed-client/preview/nspeed_linux_arm64/
-
Ah! autant pour moi je n'avais pas tester la "preview".
C'est "mieux" ;D cela se lance, mais ça ne fait rien :D :
/nspeed get -n 4 https://mafreebox.freebox.fr/gen/10G
running jobs of '#0' (0)...
no metrics to report
batch :
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
-
oui c'est la preview qu'il faut utiliser ;)
faut pas de https mais http avec les mires des freebox:
./nspeed get -n 4 http://mafreebox.freebox.fr/gen/10G
ou tu peux faire:
./nspeed from https://dl.nspeed.app/freeboxca fait 4 tests
-
Merci!!
Donc j'ai bien un sushi dans le potage quelque part, test sur l'UDM:
./nspeed get -n 10 http://mafreebox.freebox.fr/gen/10G
running jobs of '#0' (0)...
batch #0:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#0| 4.0 Gbps| 0 bps| 8.00| 4.0 GB| 0 B|5 x get http://mafreebox.freebox.fr:8095/fixed/10G (IPv4 - 0.356 ms - HTTP/1.0 - )
speedtest-cli (bon, on est aux heures de pointes et chez free donc..)
speedtest -s 23884
Speedtest by Ookla
Server: ORANGE - Puteaux (id: 23884)
ISP: Free SAS
Idle Latency: 8.13 ms (jitter: 0.51ms, low: 7.37ms, high: 8.38ms)
Download: 6654.76 Mbps (data used: 6.5 GB)
9.33 ms (jitter: 10.62ms, low: 7.28ms, high: 230.68ms)
Upload: 6676.23 Mbps (data used: 11.9 GB)
8.05 ms (jitter: 0.58ms, low: 7.02ms, high: 12.35ms)
Packet Loss: 0.0%
En tout cas merci pour cet outils! je suis avec le support de ubiquity et cela va aider.
-
la freebox limite a 5 max le nombre de flux de sa mire.
le speedtest-cli utilise 8 ou 16 flux donc dur de comparer.
Apres un routeur n'est pas forcement un bon "client". il peut router a 10Gbps sans pourtant pouvoir lui-meme télécharger a 10Gbps. c'est pas son job. Ce ne sont pas les memes 'circuits internes" qui sont utilisés quand il ne fait que router.
Du coup il est mieux de tester toujours depuis une machine apres le routeur.
-
Totalement d'accord mais ayant pour le moment fait les tests dans tous les sens, je commence à ne plus comprendre pourquoi ca coince et surtout ou.. En éspérant que ubiquiti ai une idée parcque quand on à pris l'habitude d'avoir 5/6gb à tout heure de dispo sous le pied, 2/3gbs sur la ligne ca coince un peut ;D
-
Autre question pour toi @kgersen.
La version arm64 de l'outil fonctionne bien de la même façons que la version windows (dans le sens pas de limitation spécial)?
Testé ce matin, obtenant 9.5GB sur la version windows via un pc derrière switch puis box, avec 4 flux (je comprends que la box max a 4), mon routeur devrait donc, si pas de limitation du soft, obtenir pareil, mais ma logic est peut-être fossé. Je veux juste m'assurer que l'outil est OK avant de m'en servir d'exemple avec le support :) Merci!
-
oui c'est le meme code source compilé pour différents cpu/os.
"mon routeur devrait donc, si pas de limitation du soft, obtenir pareil"
non par forcement , ton routeur n'est peut-être pas assez puissant 'localement' pour recevoir 9.5 Gbps sur lui-meme mais tout a fait capable de router 10Gbps entre 2 de ses interfaces.
C'est son cpu et ses buffers locaux qui déterminent sa capacité local a recevoir a ce débit (en plus faut décoder http).
tu peux ajouter l'option -cpu (et l'option -color) pour voir ce qui se passe niveau charge du routeur:
./nspeed -cpu -color get -n 4 http://mafreebox.freebox.fr/gen/10G
sinon
./nspeed -info
donne des infos sur le cpu, coeurs, etc
éventuellement les commandes 'lscpu' ou 'cat /proc/cpuinfo' peuvent fournir en plus d'infos sur le cpu du routeur.
pour finir, nspeed a une fonction api et moniteur:
./nspeed api -a "" -p 7777 -stats(ctrl-c pour arreter, remplace "" par le nom d'une interface ou une addresse ip pour limiter l'accès a cette interface/ip).
ensuite depuis un PC avec un navigateur:
http://ip_du_routeur:7777/rt pour voir le moniteur
Tu peux aussi mettre un serveur nspeed dans un pc:
./nspeed server -a "" -p 7777
ca devient un serveur web générateur de mires
du coup depuis ton routeur:
./nspeed get -n 4 http://ip_du_pc:7777/10gca test un flux en local coté LAN de ton routeur
Tu peux aussi inverser et mettre nspeed en serveur dans le routeur.
Avec l'api tu peux même déclencher plusieurs PC en test en meme temps...mais ca devient complexe a expliquer (faut que je rédige une meilleur doc un jour)...
-
AH! tout cela est parfait! cela me donne plus de choses a tester et monitorer! Merci énormément pour les infos! je vais m'y remettre! :D
-
ps: tu as aussi depuis peu un mode tcp dans nspeed, donc -P tcp de chaque coté (cilent et serveur) pour faire un test. Malheureusement la freebox n'a pas ce mode de mire et y'a pas de serveurs publics non plus.
Mais tu peux tester en local entre 2 machines ou de/vers ton routeur.
serveur en mode tcp:
./nspeed server -P tcp -p 7777 -a ""(le choix du port 7777 est libre)
Client en mode tcp:
download:
./nspeed get -size 10g tcp://ip_du_serveur:7777upload:
./nspeed put -size 10g tcp://ip_du_serveur:7777
C'est comparable a iperf3 (qui lui a des serveurs publics).
Tu peux aussi avec l'option -json obtenir le résultat en json pour automatiser des tests.. et l'option -html pour générer un rapport mais ce point n'est pas terminé...
-
Ok je ne pensais pas que l'application était aussi complète! c'est top et le fait qu'elle fonctionne sur le routeur va me permettre d'avoir un meilleur points de comparaisons et de poids avec le support! Merci encore pour les informations et l'aide! c'est vraiment top!
-
Il y a maintenant une version pour Mac ARM (cpu Mx):
https://dl.nspeed.app/nspeed-client/preview/nspeed_darwin_arm64/
nb: pas testée du tout !
-
Merci, ça semble bien marcher sur les quelques essais que j'ai faits...
Est-ce qu'il y a des fonctions particulières que tu aimerais que j'essaie ?
-
Merci, ça semble bien marcher sur les quelques essais que j'ai faits...
Est-ce qu'il y a des fonctions particulières que tu aimerais que j'essaie ?
oui, ajoute "api -browse" en debut d'un test pour voir si ca ouvre bien un navigateur avec les bonnes stats d'interfaces et de cpu.
par exemple:
./nspeed api -browse from https://dl.nspeed.app/cf
la partie de code spécifique a chaque OS étant les compteurs cpu et d'interfaces.
merci
-
Ça semble bien marcher, à un étrange "glitch négatif" près que j'ai eu une fois (voir dernière capture).
-
Nice merci.
C'est peut être un bug d'approximation ou de compteur qui boucle.
On verra avec le version suivante.
-
J'ai un soucis que je ne peux expliquer depuis récement avec un UDM entre le pc et la box.
Speedtest marche bien en download (bien que doit y'avoir un sacré goulot en ce moment sur mon pm car c'est pas la joie), mais alors en upload il est dans les choux total, soit la barre au démarrage ne bouge pas mais affiche 1/2gb puis d'un coup passe a droite au max mais pas plus que 2gb, soit elle reste bloquer sur 1/2gb.
Un nperf me donne les perfs attendu, et osciile souvant entre 7.5 up et 7.5 down sans soucis.
Voulant vérifier si le soucis est possiblement local, je veux tester avec nspeed, mais la c'est pire.
Nspeed ne dépasse pas les ~4gbps:
./nspeed -cpu -color get -n 5 http://mafreebox.freebox.fr/gen/42G
running jobs of '#0' (0)...
| c0| c1| c2| c3| c4| c5| c6| c7| c8| c9|c10|c11|c12|c13|c14|c15| jobs | threads|
| 3| 0| 7| 0| 25| 0| 0| 0| 0| 0| 0| 0| 3| 0| 0| 7| 5 | 29 |
| 0| 0| 0| 0| 0| 2| 0| 0| 0| 0| 0| 0| 0| 0| 0| 5| 5 | 29 |
| 0| 0| 0| 0| 0| 0| 2| 0| 0| 0| 0| 0| 0| 0| 2| 5| 5 | 29 |
| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 3| 2| 2| 0| 5 | 29 |
| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 3| 2| 0| 0| 5 | 29 |
| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 5| 0| 0| 0| 5 | 29 |
| 0| 0| 2| 0| 2| 0| 0| 0| 0| 0| 0| 0| 0| 9| 2| 0| 5 | 29 |
| 0| 0| 0| 0| 0| 2| 0| 0| 0| 0| 0| 0| 0| 3| 9| 0| 5 | 29 |
batch #0:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#0| 4.1 Gbps| 0 bps| 7.99| 4.1 GB| 0 B|5 x get http://mafreebox.freebox.fr:8095/fixed/42G (IPv4 - 0.0 ms - HTTP/1.0 - )
J'avoue ne pas trop comprendre ou regarder ou ce qui coince avec nspeed. Je suis sur la toute dernière version preview.
Lorsque j'étais direct sur la box, aucun soucis, nspeed me donnait 9.5gbps de moyenne.
-
On dirait que le routeur entre la fbx et le Pc limite le débit par connexion tcp...
si tu fait -n 1 au lieu de -n 5 ca donne quoi ? et -n 2 ?
les speedtests ne montrent pas ce probleme car il utilisent bien plus que 5 connexions en meme temps.
Il faudrait voir en mono session (possible avec speedtest.net) ce que cela donne.
-
On dirait que le routeur entre la fbx et le Pc limite le débit par connexion tcp...
si tu fait -n 1 au lieu de -n 5 ca donne quoi ? et -n 2 ?
les speedtests ne montrent pas ce probleme car il utilisent bien plus que 5 connexions en meme temps.
Il faudrait voir en mono session (possible avec speedtest.net) ce que cela donne.
En effet je commence à me demander si ce ne serait pas le cas, mais je ne trouve pas de doc, poste ou autre qui le confirme n'y si il y a une configuration qui le ferait sauter..
-n 1:
./nspeed -cpu -color get -n 1 http://mafreebox.freebox.fr/gen/10G
running jobs of '#0' (0)...
| c0| c1| c2| c3| c4| c5| c6| c7| c8| c9|c10|c11|c12|c13|c14|c15| jobs | threads|
| 0| 0| 0| 0| 0| 1| 0| 10| 0| 0| 0| 0| 0| 0| 0| 0| 1 | 9 |
| 0| 0| 0| 0| 0| 2| 6| 3| 0| 0| 0| 0| 0| 0| 0| 0| 1 | 9 |
| 0| 0| 0| 3| 0| 0| 2| 0| 0| 0| 0| 0| 0| 0| 0| 0| 1 | 9 |
| 0| 0| 0| 0| 0| 0| 0| 3| 0| 0| 0| 0| 0| 0| 0| 0| 1 | 9 |
| 0| 0| 0| 0| 0| 0| 0| 3| 0| 0| 0| 0| 0| 0| 0| 0| 1 | 9 |
| 0| 0| 0| 0| 0| 0| 0| 3| 0| 0| 0| 0| 0| 0| 0| 0| 1 | 9 |
| 0| 0| 0| 0| 0| 2| 6| 11| 0| 0| 0| 0| 0| 0| 0| 0| 1 | 9 |
| 0| 0| 0| 0| 0| 0| 3| 11| 0| 0| 0| 0| 0| 0| 0| 0| 1 | 7 |
batch #0:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#0| 3.9 Gbps| 0 bps| 7.97| 3.9 GB| 0 B|get http://mafreebox.freebox.fr:8095/fixed/10G (IPv4 - 0.0 ms - HTTP/1.0 - )
-n 2:
./nspeed -cpu -color get -n 2 http://mafreebox.freebox.fr/gen/10G
running jobs of '#0' (0)...
| c0| c1| c2| c3| c4| c5| c6| c7| c8| c9|c10|c11|c12|c13|c14|c15| jobs | threads|
| 0| 0| 0| 0| 0| 0| 0| 12| 0| 0| 0| 0| 0| 0| 0| 0| 2 | 14 |
| 0| 2| 0| 0| 0| 0| 0| 38| 0| 0| 3| 0| 0| 0| 0| 0| 2 | 14 |
| 0| 0| 0| 0| 0| 0| 0| 22| 0| 0| 2| 0| 0| 0| 0| 0| 2 | 14 |
| 0| 2| 16| 0| 0| 0| 0| 17| 0| 0| 0| 0| 0| 0| 0| 0| 2 | 14 |
| 0| 0| 0| 0| 0| 0| 0| 35| 0| 0| 0| 0| 0| 0| 0| 0| 2 | 14 |
| 0| 0| 0| 0| 0| 0| 0| 18| 0| 0| 0| 0| 0| 0| 0| 0| 2 | 14 |
| 0| 0| 0| 2| 0| 0| 0| 20| 0| 2| 0| 0| 0| 0| 0| 0| 2 | 14 |
| 0| 0| 0| 0| 0| 0| 0| 25| 0| 2| 0| 0| 0| 0| 0| 0| 2 | 4 |
batch #0:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#0| 3.1 Gbps| 0 bps| 7.99| 3.1 GB| 0 B|2 x get http://mafreebox.freebox.fr:8095/fixed/10G (IPv4 - 0.503 ms - HTTP/1.0 - )