Auteur Sujet: NSpeed: nouveau projet de mesure de débit  (Lu 50486 fois)

0 Membres et 1 Invité sur ce sujet

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
NSpeed: nouveau projet de mesure de débit
« Réponse #60 le: 14 avril 2021 à 12:55:01 »
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.

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
NSpeed: nouveau projet de mesure de débit
« Réponse #61 le: 19 avril 2021 à 15:09:09 »
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 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 ,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



hwti

  • Abonné Orange Fibre
  • *
  • Messages: 2 237
  • Chambly (60)
NSpeed: nouveau projet de mesure de débit
« Réponse #62 le: 20 avril 2021 à 02:10:22 »
- 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.

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
NSpeed: nouveau projet de mesure de débit
« Réponse #63 le: 20 avril 2021 à 11:40:41 »
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.

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
NSpeed: nouveau projet de mesure de débit
« Réponse #64 le: 28 avril 2021 à 22:24:31 »
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.


hwti

  • Abonné Orange Fibre
  • *
  • Messages: 2 237
  • Chambly (60)
NSpeed: nouveau projet de mesure de débit
« Réponse #65 le: 29 avril 2021 à 01:11:47 »
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).

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
NSpeed: nouveau projet de mesure de débit
« Réponse #66 le: 29 avril 2021 à 11:17:30 »
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


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


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.

hwti

  • Abonné Orange Fibre
  • *
  • Messages: 2 237
  • Chambly (60)
NSpeed: nouveau projet de mesure de débit
« Réponse #67 le: 29 avril 2021 à 11:30:15 »
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).

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
NSpeed: nouveau projet de mesure de débit
« Réponse #68 le: 29 avril 2021 à 11:57:58 »
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.




kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
NSpeed: nouveau projet de mesure de débit
« Réponse #69 le: 29 avril 2021 à 15:39:26 »
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.

cayenne

  • Abonné Free fibre
  • *
  • Messages: 105
  • Niort (79)
NSpeed: nouveau projet de mesure de débit
« Réponse #70 le: 30 avril 2021 à 10:22:23 »
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 :

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
NSpeed: nouveau projet de mesure de débit
« Réponse #71 le: 30 avril 2021 à 10:31:58 »
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...