Speed test Train at Home trop bas : pourquoi, et comment mesurer votre vrai débit

Si le speed test de Train at Home vient d'afficher quelque chose comme 15 Mbps sur une connexion que vous savez bien plus rapide, votre méfiance est justifiée — et vous n'êtes pas seul à le constater. Ce guide explique pourquoi, à partir de mesures réelles prises sur le même Mac et la même ligne, et comment vérifier votre débit réel séparément. Voir le guide de configuration optimale pour la vue d'ensemble.

Comment Train at Home mesure vraiment votre débit

Le mineur embarque directement la bibliothèque Python speedtest-cli. Il lance un nouveau test juste avant chaque tentative d'inscription (journalisé comme Running speedtest..., puis Speedtest completed with results: {'download_mbps': …, 'upload_mbps': …}), et réutilise un résultat en cache le reste du temps (Using cached speedtest result) — environ 3 à 4 tests par jour en fonctionnement normal. Point essentiel : il choisit automatiquement un serveur Ookla selon la latence, sans aucun contrôle de l'utilisateur sur celui qui est sélectionné.

Il n'existe aucun seuil local de réussite ou d'échec

Chercher, dans une journée entière de journaux CLI, quoi que ce soit ressemblant à un minimum de débit — « insufficient », « too slow », « minimum … mbps », « threshold », « bandwidth » — ne donne aucun résultat. Sur cette version, le speed test ressemble à de la télémétrie remontée en amont, pas à un filtre local qui bloquerait le minage.

Les chiffres réels

Sur un Mac, une ligne fibre gigabit, un après-midi :

Source	Descendant	Montant
networkQuality de macOS (par défaut, multi-flux)	~995 Mbps	~715 Mbps
speedtest-cli, serveur proche (536 km)	266 Mbps	289 Mbps
speedtest-cli, serveur distant (501 km, curieusement)	15,5 Mbps	28,7 Mbps
Journal de Train at Home, 16h02	371 Mbps	301 Mbps
Journal de Train at Home, 17h36	13,8 Mbps	30,0 Mbps

Même Mac. Même ligne. Même après-midi. L'écart entre un résultat de « 15 Mbps » et un résultat de « 370 Mbps » venait entièrement du serveur Ookla tiré au sort — pas de la connexion réelle.

Cela a une vraie conséquence, au-delà d'un chiffre qui fait peur : le jour même où ces données ont été relevées, le point d'entrée /miner/register/status de l'orchestrateur a répondu 500 trois fois de suite. Le mineur s'est alors réinscrit avec un tout nouvel identifiant de file — repartant de la fin. Rien ne prouve que cet échec précis ait été causé par le résultat bas, mais c'est un rappel qu'un mauvais résultat de speed test n'est pas purement cosmétique ; si vous vous retrouvez aussi replacé en fin de file, le guide sur la position dans la file montre comment confirmer ce qui s'est passé.

Pourquoi le débit compte mécaniquement, même sans minimum strict

Entraîner un modèle sur Internet plutôt que sur l'interconnexion d'un datacenter n'est pas gratuit. L'article technique du projet décrit un besoin de compression d'environ 100 à 300× sur les transferts d'activations et de gradients pour garder des temps de transfert comparables à ceux d'un datacenter, et rapporte environ 128× de compression atteinte dans ses propres expériences — explicitement pensé autour d'un débit domestique « typique » de 50 à 200 Mbps. Autrement dit : le système est conçu pour tolérer une connexion domestique ordinaire, pas pour en exiger une exotique. Ce contexte est utile quand un seul résultat bas vous inquiète — l'architecture part déjà de l'hypothèse d'un débit domestique, pas d'un débit de datacenter.

Mesurer votre vrai débit avec networkQuality

macOS embarque son propre outil de débit et de réactivité, indépendant de tout ce que fait Train at Home. D'après man networkQuality sur ce Mac :

• networkQuality seul lance l'upload et le download en parallèle (c'est le chiffre « multi-flux » utilisé dans le tableau ci-dessus) et affiche un résumé de capacité et de réactivité.
• networkQuality -s lance les tests séquentiellement, ce qu'il faut si vous voulez des scores de réactivité (RPM) séparés pour la descente et la montée, et pas seulement un score combiné.
• networkQuality -v ajoute une sortie détaillée.
• networkQuality -c produit un JSON exploitable par machine plutôt qu'un résumé lisible.

networkQuality

ou, pour un détail séquentiel plus complet :

networkQuality -s -v

Si networkQuality affiche quelque chose de proche du débit annoncé par votre fournisseur d'accès pendant que le résultat de Train at Home n'y ressemble en rien, vous avez confirmé que le problème vient du serveur de test tiré au sort, pas de votre ligne.

Ce qu'il faut écarter avant de blâmer votre connexion

1. Comparez d'abord avec networkQuality, comme ci-dessus, avant de soupçonner votre ligne.
2. Signalez à Macrocosmos les écarts vraiment extrêmes — un résultat 20 fois inférieur à la réalité sur une ligne stable est un signal utile pour eux, pas seulement pour vous.
3. Écartez séparément les causes locales : un VPN actif au moment du test (une précaution générale à envisager pendant l'entraînement, même si Macrocosmos n'a rien publié officiellement à ce sujet), une liaison montante occupée par autre chose sur votre réseau, et, de façon moins certaine, une connexion Wi-Fi plutôt que filaire.

Checklist

1. Si un résultat semble alarmant, ne paniquez pas immédiatement — vérifiez d'abord avec networkQuality (ou networkQuality -s -v).
2. Souvenez-vous que le speed test semble être de la télémétrie, pas un filtre de réussite/échec, sur cette version.
3. Si vous avez aussi été réinscrit à peu près au même moment, consultez le guide sur la position dans la file pour confirmer ce qui s'est passé.
4. Écartez un VPN et une liaison montante occupée avant de penser que quelque chose est cassé.
5. Si votre résultat networkQuality est lui aussi franchement mauvais, c'est un signal réel à approfondir — ce guide porte spécifiquement sur l'écart entre les deux outils, pas sur le diagnostic d'une ligne réellement lente.
6. Si les ports ou l'accessibilité P2P vous inquiètent aussi, voir le guide réseau et ports.

Pour le reste d'une configuration stable — installation, veille, suivi — consultez le guide de configuration optimale complet.