Auteur Sujet: API pour consulter l'état de charge des serveurs de test ?  (Lu 1763 fois)

0 Membres et 1 Invité sur ce sujet

ouno

  • Abonné Orange Fibre
  • *
  • Messages: 169
  • Orvault (44)
API pour consulter l'état de charge des serveurs de test ?
« le: 14 janvier 2022 à 20:39:35 »
Bonjour,

Est-ce qu'il existe une API pour consulter l'état de charge des serveurs de test de débit listés sur https://testdebit.info ?

Je pose cette question car en soirée j'ai des résultats assez surprenants lorsque je fais des tests de débit depuis une ligne Orange FTTH vers les serveurs Scaleway:
[checkFtthFr v0.10]                              Linux 4.19.0-13-amd64 (x86_64)
--------------------------- 2022-01-14 18:40:16 GMT ---------------------------
Paramétrage réseau actuel du système:
  net.core.default_qdisc: fq
  net.core.rmem_max: 212992
  net.core.wmem_max: 212992
  net.ipv4.tcp_adv_win_scale: 1
  net.ipv4.tcp_congestion_control: bbr
  net.ipv4.tcp_mem: 187191      249591  374382
  net.ipv4.tcp_no_metrics_save: 0
  net.ipv4.tcp_rmem: 4096       131072  6291456
  net.ipv4.tcp_sack: 1
  net.ipv4.tcp_timestamps: 1
  net.ipv4.tcp_window_scaling: 1
  net.ipv4.tcp_wmem: 4096       16384   4194304
  => Latence TCP max pour une réception à 1 Gbps: 27 ms
  => Latence TCP max pour une émission à 700 Mbps: 35 ms

Test TCP Internet: téléchargement depuis l'AS 12876 (Scaleway) [BBR]
  --> Latence: 9.72 ms                  [gigue: 0.54 ms]
  --> Débit: 104.43 Mo/s (835.46 Mbps)  [fluctuation: 4.09%]

Test TCP Internet: téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
  --> Latence: 10.01 ms                 [gigue: 4.22 ms]
  --> Débit: 983.23 Ko/s (7.87 Mbps)    [fluctuation: 34.30%]

Test TCP Internet: envoi vers l'AS 12876 (Scaleway) [BBR]
  --> Latence: 9.72 ms                  [gigue: 0.54 ms]
  --> Débit: 75.01 Mo/s (600.08 Mbps)   [fluctuation: 0.38%]

[!] La connexion aux serveurs de test semble affectée par une très forte congestion réseau
      (indicateur de congestion: 99.06%)
--------------------------- 2022-01-14 18:41:00 GMT ---------------------------

Le ratio de 0.94% entre le débit CUBIC et le débit BBR me paraît trop extrême, du coup j'imagine que c'est le serveur de test CUBIC lui-même (ping.online.net) qui est saturé en soirée et que cela fausse les résultats ?
S'il y avait un moyen de consulter la charge des serveurs de test avant de lancer les tests cela permettrait d'éviter de lancer un test qui ne serait pas significatif de toutes façons.

A titre de comparaison voilà le même test réalisé à peu près au même moment avec la même ligne mais vers les serveurs de test de débit de Bouygues Telecom:
[checkFtthFr v0.10]                              Linux 4.19.0-13-amd64 (x86_64)
--------------------------- 2022-01-14 18:46:14 GMT ---------------------------
Paramétrage réseau actuel du système:
  net.core.default_qdisc: fq
  net.core.rmem_max: 212992
  net.core.wmem_max: 212992
  net.ipv4.tcp_adv_win_scale: 1
  net.ipv4.tcp_congestion_control: bbr
  net.ipv4.tcp_mem: 187191      249591  374382
  net.ipv4.tcp_no_metrics_save: 0
  net.ipv4.tcp_rmem: 4096       131072  6291456
  net.ipv4.tcp_sack: 1
  net.ipv4.tcp_timestamps: 1
  net.ipv4.tcp_window_scaling: 1
  net.ipv4.tcp_wmem: 4096       16384   4194304
  => Latence TCP max pour une réception à 1 Gbps: 27 ms
  => Latence TCP max pour une émission à 700 Mbps: 35 ms

Test TCP Internet: téléchargement depuis l'AS 5410 (Bouygues Telecom) [BBR]
  --> Latence: 8.58 ms                  [gigue: 0.37 ms]
  --> Débit: 117.68 Mo/s (941.47 Mbps)  [fluctuation: 0.00%]

Test TCP Internet: téléchargement depuis l'AS 5410 (Bouygues Telecom) [CUBIC]
  --> Latence: 7.89 ms                  [gigue: 0.56 ms]
  --> Débit: 117.68 Mo/s (941.47 Mbps)  [fluctuation: 0.00%]

Test TCP Internet: envoi vers l'AS 5410 (Bouygues Telecom) [BBR]
  --> Latence: 8.58 ms                  [gigue: 0.37 ms]
  --> Débit: 75.24 Mo/s (601.90 Mbps)   [fluctuation: 1.06%]
--------------------------- 2022-01-14 18:46:47 GMT ---------------------------

vivien

  • Administrateur
  • *
  • Messages: 41 238
    • Twitter LaFibre.info
API pour consulter l'état de charge des serveurs de test ?
« Réponse #1 le: 14 janvier 2022 à 21:37:07 »
Pas d'API, mais je donne volontier les infos si tu me donne le nom des serveurs.

Je ne met pas les données en temps réel, pour éviter le jeu de surcharger le serveur pour s'amuser.

ouno

  • Abonné Orange Fibre
  • *
  • Messages: 169
  • Orvault (44)
API pour consulter l'état de charge des serveurs de test ?
« Réponse #2 le: 14 janvier 2022 à 22:36:00 »
Pas d'API, mais je donne volontier les infos si tu me donne le nom des serveurs.
Merci, c'est le serveur que j'ai cité au-dessus dans mon message (ping.online.net), à 19h40 en HTTP.

Je ne met pas les données en temps réel, pour éviter le jeu de surcharger le serveur pour s'amuser.
Je comprends... Du coup peut-être qu'il serait envisageable de fournir l'info "charge < 50%" ou "charge > 50%" par exemple ?
Comme ça les outils de tests pourraient choisir de changer de serveur s'ils reçoivent "charge > 50%", ou bien attendre et retenter plus tard, ou encore faire le test quand même tout en sachant que les résultats seront moins fiables.

Dans mon cas ce serait très utile: j'ai fait un petit programme qui compare automatiquement les performances mono-connexion TCP BBR et CUBIC (pour un même AS), afin de détecter d'éventuels problèmes de congestion.
Le problème c'est qu'on ne peut jamais être sûr que ce n'est pas le serveur de test lui-même qui est surchargé.

vivien

  • Administrateur
  • *
  • Messages: 41 238
    • Twitter LaFibre.info
API pour consulter l'état de charge des serveurs de test ?
« Réponse #3 le: 15 janvier 2022 à 08:17:46 »
ping.online.net ce n'est pas un serveur .testdebit.info et je n'ai donc pas l'information.

Je suis intéressé par ton programme et par tes résultats, j'ai un peu de mal à comprendre comment cela se passe, car à part iPerf3 on doit avoir deux serveurs différents pour faire des tests Cubic / BBR, et c'est pas souvent que l'on a deux serveurs avec une configuration (hors BBR / Cubic) et une localisation identique.

J'aimerais bien une extension à Apache2 qui permet de définir un virtualhost en BBR et un autre virtualhost en Cubic sur un même serveur.

Un autre travail qui serait intéressant, c'est qq chose qui permet de diagnostique si le serveur a un algorithme de contrôle de congestion basé sur la perte de paquets (Cubic par exemple) ou sur la latence (BBR par exemple). Cela peut se faire en analysant le comportement en rajoutant artificiellement des pertes de paquets avec NetEM. Toutefois aujourd'hui j'ai besoin de créer une référence BBR et une référence Cubic pour une latence simulée identique au serveur testé avec la même taille de fichier. C'est donc possible, mais bien compliqué.

ouno

  • Abonné Orange Fibre
  • *
  • Messages: 169
  • Orvault (44)
API pour consulter l'état de charge des serveurs de test ?
« Réponse #4 le: 15 janvier 2022 à 11:04:45 »
Je suis intéressé par ton programme et par tes résultats, j'ai un peu de mal à comprendre comment cela se passe, car à part iPerf3 on doit avoir deux serveurs différents pour faire des tests Cubic / BBR, et c'est pas souvent que l'on a deux serveurs avec une configuration (hors BBR / Cubic) et une localisation identique.
C'est précisément le problème. Mon programme est vraiment très simple et utilise les serveurs scaleway.testdebit.info / ping.online.net d'une part pour les tests sur Scaleway, et bouygues.testdebit.info / paris.testdebit.info d'autre part pour les tests sur Bouygues Telecom.
Ce sont les seuls serveurs que j'ai trouvés qui permettaient de remplir toutes les conditions (offrir du CUBIC et du BBR depuis un même AS et depuis une même localisation physique, d'après les infos indiquées sur testdebit.info).
Mais malheureusement il reste la possibilité à chaque fois que l'un des deux serveurs soit plus chargé que l'autre...
Je voulais essayer de résoudre ce problème avant de mettre à dispo le prog, mais je peux mettre à dispo la version actuelle.

J'aimerais bien une extension à Apache2 qui permet de définir un virtualhost en BBR et un autre virtualhost en Cubic sur un même serveur.
Effectivement ça serait bien pratique !

Un autre travail qui serait intéressant, c'est qq chose qui permet de diagnostique si le serveur a un algorithme de contrôle de congestion basé sur la perte de paquets (Cubic par exemple) ou sur la latence (BBR par exemple). Cela peut se faire en analysant le comportement en rajoutant artificiellement des pertes de paquets avec NetEM. Toutefois aujourd'hui j'ai besoin de créer une référence BBR et une référence Cubic pour une latence simulée identique au serveur testé avec la même taille de fichier. C'est donc possible, mais bien compliqué.
Oui j'imagine que cela peut vite devenir compliqué si on veut faire ça de manière rigoureuse, surtout si on veut gérer par exemple le cas où la connexion au serveur souffre déjà de base d'une perte de paquets plus ou moins importante, qui vient s'ajouter à celle que l'on génère pour tester...

vivien

  • Administrateur
  • *
  • Messages: 41 238
    • Twitter LaFibre.info
API pour consulter l'état de charge des serveurs de test ?
« Réponse #5 le: 15 janvier 2022 à 12:19:00 »
scaleway.testdebit.info c'est un VM, je n'ai pas la certitude qu'on ait le même comportement qu'un serveur bare metal.

C'est un Ubuntu 18.04 LTS (noyau HWE, celui d'Ubuntu 20.04) je vais l'upgrader dans les prochains jours en 20.04.

N’hésites pas a partager la version actuelle.

ouno

  • Abonné Orange Fibre
  • *
  • Messages: 169
  • Orvault (44)
API pour consulter l'état de charge des serveurs de test ?
« Réponse #6 le: 19 janvier 2022 à 08:05:58 »
scaleway.testdebit.info c'est un VM, je n'ai pas la certitude qu'on ait le même comportement qu'un serveur bare metal.
Pour moi ce n'est pas du tout gênant que scaleway.testdebit.info soit une VM étant donné que c'est sur ping.online.net que les perfs s'effondrent à certaines heures.
Sur scaleway.testdebit.info tout est ok.

N’hésites pas a partager la version actuelle.
En fait après réflexion je me dis que si on ne peut pas savoir si les serveurs de test sont surchargés ou pas, alors il vaut mieux faire en sorte qu'ils soient le moins chargés possible pour avoir des résultats fiables.
Or distribuer un programme qui cible spécifiquement certains serveurs de test contribuerait à concentrer la charge sur ces serveurs, ce qui ne me paraît pas une très bonne idée  :-\

Du coup je me dirige plutôt vers un programme de test compatible avec les serveurs iPerf3. C'est vrai que c'est intéressant de pouvoir comparer différents CCAs depuis un même serveur de test.
Par contre je me demande comment la queuing discipline est gérée ? Parce qu'avec BBR par exemple il est (était ?) préconisé d'utiliser du fair queuing alors que traditionnellement on utilise autre chose en CUBIC...
Ce paramètre est impactant pour les résultats j'imagine, mais je n'ai pas vu comment il était géré/automatisé dans iPerf3.

vivien

  • Administrateur
  • *
  • Messages: 41 238
    • Twitter LaFibre.info
API pour consulter l'état de charge des serveurs de test ?
« Réponse #7 le: 19 janvier 2022 à 10:59:32 »
Par contre je me demande comment la queuing discipline est gérée ? Parce qu'avec BBR par exemple il est (était ?) préconisé d'utiliser du fair queuing alors que traditionnellement on utilise autre chose en CUBIC...
Ce paramètre est impactant pour les résultats j'imagine, mais je n'ai pas vu comment il était géré/automatisé dans iPerf3.

Tu parle du protocole de Queuing Discipline (qdisc) ?

La valeur par défaut des distributions linux récentes : FQ_CODEL

Qdisc détermine la façon dont le serveur va envoyer les données et lisser le trafic en sortie. FQ ou FQ_CODEL permet de privilégier les trafics qui se 'vident' des files par rapport à ceux qui bouchonnent parce que le récepteur est 'lent' ou a un lien saturé.

FQ_CODEL est le paramétrage par défaut recommandé par « systemd ». Il permet des hauts débits et une représentativité des serveurs sur Internet.

FQ permet d’augmenter les débits dans certains cas, en corrigeant des défauts des réseaux radio par exemple, le choix de FQ n’est pas représentatif de la majorité des serveurs CDN.

ouno

  • Abonné Orange Fibre
  • *
  • Messages: 169
  • Orvault (44)
API pour consulter l'état de charge des serveurs de test ?
« Réponse #8 le: 19 janvier 2022 à 11:17:45 »
Tu parle du protocole de Queuing Discipline (qdisc) ?
Tout à fait.
Ce paramètre ne semble pas être géré par iPerf3, alors qu'il est impactant, au même titre que le choix de CCA, non ?

La valeur par défaut des distributions linux récentes : FQ_CODEL

Qdisc détermine la façon dont le serveur va envoyer les données et lisser le trafic en sortie. FQ ou FQ_CODEL permet de privilégier les trafics qui se 'vident' des files par rapport à ceux qui bouchonnent parce que le récepteur est 'lent' ou a un lien saturé.

FQ_CODEL est le paramétrage par défaut recommandé par « systemd ». Il permet des hauts débits et une représentativité des serveurs sur Internet.

FQ permet d’augmenter les débits dans certains cas, en corrigeant des défauts des réseaux radio par exemple, le choix de FQ n’est pas représentatif de la majorité des serveurs CDN.

Voilà, selon l'âge de la distribution on peut avoir une multitude de configurations possibles entre les qdisc et les CCAs, avec des CCAs qui fonctionnent mieux s'ils sont associés à certains qdisc d'après ce que j'ai compris etc.

vivien

  • Administrateur
  • *
  • Messages: 41 238
    • Twitter LaFibre.info
API pour consulter l'état de charge des serveurs de test ?
« Réponse #9 le: 19 janvier 2022 à 11:31:48 »
Je suis intéressé pour en savoir plus.

Pour les tests Arcep 2022, il y aura une partie des tests réalisés :
- Cubic + http/2
- BBR + http/3 (si le test sait gérer http/3, sinon http/2)

Le Queuing Discipline serait FQ_CODEL pour Cubic.

Pour BBR, il en faudrait un autre ?

Hugues

  • AS2027 MilkyWan
  • Modérateur
  • *
  • Messages: 10 550
  • Lyon (69) / St-Bernard (01)
    • Twitter
API pour consulter l'état de charge des serveurs de test ?
« Réponse #10 le: 19 janvier 2022 à 11:39:15 »
CAKE ?

ouno

  • Abonné Orange Fibre
  • *
  • Messages: 169
  • Orvault (44)
API pour consulter l'état de charge des serveurs de test ?
« Réponse #11 le: 19 janvier 2022 à 14:08:25 »
Je suis intéressé pour en savoir plus.
Moi aussi  ;D

Le problème c'est que l'on trouve beaucoup d'infos contradictoires/obsolètes sur le sujet car la situation a évolué:
https://groups.google.com/g/bbr-dev/c/4jL4ropdOV8
https://groups.google.com/g/bbr-dev/c/RfxfI1gT_I8

Il y a aussi des discussions sans fin sur quelle devrait être la valeur par défaut dans systemd entre FQ et FQ_CODEL, où ils parlent des interactions avec BBR:
- https://github.com/systemd/systemd/issues/9725
- https://github.com/systemd/systemd/issues/5090

Et il y a encore beaucoup de sources (même récentes) qui disent qu'il faut utiliser FQ avec BBR, sans trop justifier.
Du coup on sait pas si ce sont juste des infos obsolètes qui sont reprises ou s'il y a vraiment une raison.

En tout cas, j'imagine que selon les versions utilisées sur les serveurs de test, le choix de la qdisc en plus du CCA peut avoir un impact plus ou moins grand.

Pour les tests Arcep 2022, il y aura une partie des tests réalisés :
- Cubic + http/2
- BBR + http/3 (si le test sait gérer http/3, sinon http/2)

Le Queuing Discipline serait FQ_CODEL pour Cubic.

Pour BBR, il en faudrait un autre ?
D'après https://github.com/google/bbr/blob/master/Documentation/bbr-quick-start.md#obtain-kernel-sources-with-tcp-bbr par exemple, on dirait que FQ est toujours conseillé dans certains cas, même si ce n'est plus un pré-requis strict à l'utilisation de BBR comme ça l'était avant.