Que vaut votre connexion internet?, Peut-être moins que ce qu'on veut vous faire croire !

[Laszlo Lebrun]

Beaucoup testent leur connexion internet avec des pages de test comme Ookla.
C'est pratique et ça sort en une minute la vitesse de transfert de votre connection.
Oui mais...
Les FAI ont depuis longtemps des serveurs dans chaque ville proche, dédiés à ces tests qui vous sortent plein pot le temps du test, par exemple:
dus.wsqm.telekom-dienste.de.prod.hosts.ooklaserver.net

Mais pourtant votre internet se traîne...

C'est que dans la vraie vie il n'y a pas que le dernier mille de votre connection qui compte. Il y a toute la qualité de l'infrastructure derrière. Et là c'est souvent pas joli-joli.
On veut vous vendre de la fibre, mais c'est comme mettre un moteur de Koenigsegg dans une 404 ( ) roulant sur des routes de Somalie.

Un bien meilleur test est donné avec https://packetstats.com/ qui envoie des paquets de test à travers le monde et mesure la réponse.

Testez, pour voir...

Ce message a été modifié par Laszlo Lebrun - 11 Feb 2024, 18:57.

[Benzebut]

Beaucoup testent leur connexion internet avec des pages de test comme Ookla.
C'est pratique et ça sort en une minute la vitesse de transfert de votre connection.
Oui mais...

Sauf que cela ne mesure par la même chose pour surfer sur internet.
Les sites comme https://www.speedtest.net mesurent la vitesse de connexion et le ping avec le serveur le plus proche.
Le site https://packetstats.com/ ne mesure que le ping avec des grands serveurs internationaux, indépendamment de votre connexion.

Ce qui génère bien évidemment des écarts dans les comparaisons. Ou pour garder la comparaison automobile, cela revient à comparer la vitesse moyenne de votre 404 sur une autoroute allemande et une piste en Somalie...

[Laszlo Lebrun]

Beaucoup testent leur connexion internet avec des pages de test comme Ookla.
C'est pratique et ça sort en une minute la vitesse de transfert de votre connection.
Oui mais...

Sauf que cela ne mesure par la même chose pour surfer sur internet.
Les sites comme https://www.speedtest.net mesurent la vitesse de connexion et le ping avec le serveur le plus proche.
Le site https://packetstats.com/ ne mesure que le ping avec des grands serveurs internationaux, indépendamment de votre connexion.

Ce qui génère bien évidemment des écarts dans les comparaisons. Ou pour garder la comparaison automobile, cela revient à comparer la vitesse moyenne de votre 404 sur une autoroute allemande et une piste en Somalie...

Bien sûr ce n'est pas la même chose ni les mêmes chiffres, mais la qualité de la liaison internet sur tout le parcours est en pratique beaucoup plus importante (et malheureusement vraiment négligée) que la performance Ookla pour laquelle les FAI trichent en mettant des serveurs dédiés (que je soupçonne priorisés sur leurs lignes).

Quand internet se traîne, un traceroute revéle la plupart du temps que ça coince à partir des relais du FAI, pas sur le dernier segment jusqu'à l'utilisateur (et encore moins chez l'utilisateur).
Naturellement quand on se plaint à la hotline (en supposant qu'on arrive à la joindre) ils nous sortent le schéma habituel de vérification de notre équipement qui ne peut qu'être défectueux...


Ce message a été modifié par Laszlo Lebrun - 8 Feb 2024, 14:57.

[Polo35230]

Beaucoup testent leur connexion internet avec des pages de test comme Ookla.
C'est pratique et ça sort en une minute la vitesse de transfert de votre connection.
Oui mais...
Les FAI ont depuis longtemps des serveurs dans chaque ville proche, dédiés à ces tests qui vous sortent plein pot le temps du test, par exemple:
dus.wsqm.telekom-dienste.de.prod.hosts.ooklaserver.net

Mais pourtant votre internet se traîne...

C'est que dans la vraie vie il n'y a pas que le dernier mille de votre connection qui compte. Il y a toute la qualité de l'infrastructure derrière. Et là c'est souvent pas joli-joli.
On veut vous vendre de la fibre, mais c'est comme mettre un moteur de Koenigsegg dans une 404 ( ) roulant sur des routes de Somalie.

Un bien meilleur test est donné avec https://packetstats.com/ qui envoie des paquets de test à travers le monde et mesure la réponse.

Testez, pour voir...

Je ne vois pas trop l'intérêt de ce test qui mesure la latence des pings vers un serveur aux US, par exemple.

Si tu as un pb sur internet, comme le ping mesure le temps d'aller et retour d'un message ICMP, tu sauras effectivement que ça rame, ou que la liaison entre le site de test et toi est rompue, mais tu ne sauras pas si c'est sur ta liaison abonné ou sur un autre tronçon.
Tu ne pourras pas en conclure que le pb est chez ton FAI.
De plus ce n'est pas un test de bout en bout.
Via le terminal, un ping vers le site distant est beaucoup plus significatif.
De même que le traceroute, qui donnera certaines indications, et encore, pas toujours, car certains équipement sur le trajet peuvent bloquer le protocole ICMP.

Si ça rame et que tu penses que c'est ta liaison internet qui en est la cause, le SpeeedTest te donnera des éléments pour qualifier un éventuel pb lié à la charge (par exemple) sur cette liaison.
Ces flux vers un serveur de test ne sont pas priorisés. C'est vérifiable:
Tu lances un SpeedTest (et que ça) vers un serveur de ton FAI (en principe, le débit observé devrait correspondre à la vitesse de ta liaison.
Tu fais un 2ème test alors qu'il y a des flux internet (streaming ou autre). Tu pourras constater que le débit est inférieur à celui du 1er test.

Après, pour la fibre, tout dépend de l'usage que tu as d'internet.
Pour moi, il y a un avant et un après...

[Laszlo Lebrun]

Via le terminal, un ping vers le site distant est beaucoup plus significatif.

C'est comme une photo par rapport à un film.
L'interêt c'est de voir la regularité des temps de transfert.

Si ça rame et que tu penses que c'est ta liaison internet qui en est la cause, le SpeeedTest te donnera des éléments pour qualifier un éventuel pb lié à la charge (par exemple) sur cette liaison.

Ben non ça ne te donnera que la vitesse vers le premier serveur de to FAI. Si ça se traîne après, tu ne verras rien.

Tu fais un 2ème test alors qu'il y a des flux internet (streaming ou autre). Tu pourras constater que le débit est inférieur à celui du 1er test.

Le test ne dure pas assez longtemps: le streaming est bufferisé.
Et les problèmes de FAI sont souvent des problèmes de DNS: ça coince à l'initialisation d'une communication.
Un page Internet c'est (malheureusement) des centaines de serveurs à joindre.

[Polo35230]

Le titre de ton message, cest "Que vaut votre connexion internet"
Et ben, ce qu'elle vaut est directement lié au lien fourni par ton opérateur.
Et c'est pas le test vers un serveur à Sidney qui te dira si c'est bon ou pas sur celle-ci.
Le test "paketstats" est un simple ping. Si tu as un temps de latence élevé et des variations élevées de ceux-ci (gigue), tu ne pourras pas en conclure que le pb est chez ton FAI.
Le Speedtest injecte en plus un flux saturant (non prioritaire) pour voir la bande passante disponible.

Via le terminal, un ping vers le site distant est beaucoup plus significatif.

C'est comme une photo par rapport à un film.
L'interêt c'est de voir la regularité des temps de transfert.

Le ping vers le site qui correspond au nom de domaine de l'URL sera beaucoup plus significatif que le "paketstas" qui fait des ping vers le serveur de Sidney

Si ça rame et que tu penses que c'est ta liaison internet qui en est la cause, le SpeeedTest te donnera des éléments pour qualifier un éventuel pb lié à la charge (par exemple) sur cette liaison.

Ben non ça ne te donnera que la vitesse vers le premier serveur de to FAI. Si ça se traîne après, tu ne verras rien.

Le Speedtest ne donne pas la vitesse, mais le débit. Il tient compte de la charge.
Mais oui,si tu rames en navigant, le Speedtest ne te dira pas où (sauf si c'est sur ta liaison d'accès. Le plus courant).
Mais "Paketstats" non plus.

Ce message a été modifié par Polo35230 - 9 Feb 2024, 09:03.

[Benzebut]

Et les problèmes de FAI sont souvent des problèmes de DNS: ça coince à l'initialisation d'une communication.
Un page Internet c'est (malheureusement) des centaines de serveurs à joindre.

Ce test ne dira pas non plus sur quel serveur cela bloque au niveau des DNS.
Et cela ne donne en aucun cas une indication sur la connexion internet de l'utilisateur, qui n'est que le chainon final avec une multitude d'intermédiaires entre...

[Laszlo Lebrun]

Ce test ne dira pas non plus sur quel serveur cela bloque au niveau des DNS.
Et cela ne donne en aucun cas une indication sur la connexion internet de l'utilisateur, qui n'est que le chainon final avec une multitude d'intermédiaires entre...

C'est pas faux, mais ça me fait une belle jambe de savoir par un traceroute que le serveur p3e9bf49b.dip0.t-ipconnect.de a encore traîné 12s pour relayer?
Tu auras beau prouver par un log a la hotline de ton FAI que le problème vient de chez eux et leur mettre le nez dans leur caca, ils ne reconnaîtront jamais que c'est de leur faute.

[Polo35230]

Ce test ne dira pas non plus sur quel serveur cela bloque au niveau des DNS.
Et cela ne donne en aucun cas une indication sur la connexion internet de l'utilisateur, qui n'est que le chainon final avec une multitude d'intermédiaires entre...

C'est pas faux, mais ça me fait une belle jambe de savoir par un traceroute que le serveur p3e9bf49b.dip0.t-ipconnect.de a encore traîné 12s pour relayer?
Tu auras beau prouver par un log a la hotline de ton FAI que le problème vient de chez eux et leur mettre le nez dans leur caca, ils ne reconnaîtront jamais que c'est de leur faute.

Ben si, justement, en analysant le traceroute, et en faisant un whois de l'adresse IP de la machine (routeur ou autre...) p3e9bf49b.dip0.t-ipconnect.de , tu te rendras compte que tu n'es plus sur le réseau de ton opérateur.
L'anayse des temps pourra te dire ou ça coince entre les équipements réseau.
Si ce n'est pas au niveau des équipements de ton opérateur, ce ne sera donc pas la peine de l'appeler...

Mais on a bien compris que tu lui en voulait

Ce message a été modifié par Polo35230 - 9 Feb 2024, 16:26.

[Benzebut]

C'est pas faux, mais ça me fait une belle jambe de savoir par un traceroute que le serveur p3e9bf49b.dip0.t-ipconnect.de a encore traîné 12s pour relayer?
Tu auras beau prouver par un log a la hotline de ton FAI que le problème vient de chez eux et leur mettre le nez dans leur caca, ils ne reconnaîtront jamais que c'est de leur faute.

Bien cela fait toute la différence. Car si le serveur p3e9bf49b.dip0.t-ipconnect.de a encore traîné 12s pour relayer, mais que ce serveur n'est pas celui de votre FAI, il n'est en rien responsable des débits qui existent avant ses infrastructures. Ce n'est même pas la peine de le déranger pour cela, avec ou sans log de traceroute.
Votre FAI n'est responsable que du service rendu à vous client sur son infrastructure pour ses services...

[Laszlo Lebrun]

Bien cela fait toute la différence. Car si le serveur p3e9bf49b.dip0.t-ipconnect.de a encore traîné 12s pour relayer, mais que ce serveur n'est pas celui de votre FAI, il n'est en rien responsable des débits qui existent avant ses infrastructures. Ce n'est même pas la peine de le déranger pour cela, avec ou sans log de traceroute.
Votre FAI n'est responsable que du service rendu à vous client sur son infrastructure pour ses services...

D'après le nom, il n'y a pas photo. le FAI c'est T-online et t-ipconnect.de est un des ses domaines.

[g4hd]

J'aime rêvasser devant ces arabesques sans queue ni tête dévoilées par Litlle Snitch / Show Network Monitor…
Est-ce hors sujet ?

Ce message a été modifié par g4hd - 9 Feb 2024, 23:09.

[Benzebut]

D'après le nom, il n'y a pas photo. le FAI c'est T-online et t-ipconnect.de est un des ses domaines.

Et votre FAI en France est-il T-online ?
Sinon, cela signifie simplement qu'il y a eu des ralentissements sur ce tronçon au moment du test sur l'infrastructure du fournisseur allemand T-online. Et fournir ces historiques traceroute à votre fournisseur français ne servira strictement à rien pour valider la qualité de votre connexion. Encore une fois, votre FAI n'est responsable que du service rendu à vous client sur son infrastructure pour ses services...

[Laszlo Lebrun]

D'après le nom, il n'y a pas photo. le FAI c'est T-online et t-ipconnect.de est un des ses domaines.

Et votre FAI en France est-il T-online ?
Sinon, cela signifie simplement qu'il y a eu des ralentissements sur ce tronçon au moment du test sur l'infrastructure du fournisseur allemand T-online. Et fournir ces historiques traceroute à votre fournisseur français ne servira strictement à rien pour valider la qualité de votre connexion. Encore une fois, votre FAI n'est responsable que du service rendu à vous client sur son infrastructure pour ses services...

Je ne suis pas en France.
Mais quand j'y suis j'ai SFR comme FAI et c'est pas mieux.

[Benzebut]

J'aime rêvasser devant ces arabesques sans queue ni tête dévoilées par Litlle Snitch / Show Network Monitor…
Est-ce hors sujet ?

C'est corrélé. Le nombre d'intervenants sur ces forums qui justifient l'installation de l'application Litlle Snitch pour qualifier la qualité de leurs connexions ou se sentir protéger sur leurs équipements...

Je ne suis pas en France.
Mais quand j'y suis j'ai SFR comme FAI et c'est pas mieux.

Et là où vous êtes, votre fournisseur est-il l'allemand T-online ? Sinon, même commentaire que précédemment, cela ne démontre en rien la qualité du service de votre FAI là où vous êtes connecté.
Et lorsque vous êtes en France, le fournisseur SFR ne fait pas mieux que quoi ?

[Laszlo Lebrun]

Et là où vous êtes, votre fournisseur est-il l'allemand T-online ? Sinon, même commentaire que précédemment, cela ne démontre en rien la qualité du service de votre FAI là où vous êtes connecté.

ben oui, évidemment !

Et lorsque vous êtes en France, le fournisseur SFR ne fait pas mieux que quoi ?

...que t-online, quoi d'autre?

[Benzebut]

Et là où vous êtes, votre fournisseur est-il l'allemand T-online ? Sinon, même commentaire que précédemment, cela ne démontre en rien la qualité du service de votre FAI là où vous êtes connecté.

ben oui, évidemment !

Donc nous progressons enfin dans la discussion de manière constructive. Votre FAI est l'allemand T-online. Ainsi que donnent vos résultats par https://www.speedtest.net pour votre connexion ? S'ils sont conformes aux débits annoncés ou à ceux de https://packetstats.com/ dans les tests ?

Et lorsque vous êtes en France, le fournisseur SFR ne fait pas mieux que quoi ?

...que t-online, quoi d'autre?

Il faudrait donc faire là aussi des tests sur le fournisseur SFR pour valider cette hypothèse de manière concrète. Sinon Georges va demander encore du café...

[baron]

ben oui, évidemment !
[…]
...que t-online, quoi d'autre?

Note de la modération :
Un peu plus de considération pour ceux qui tentent de vous comprendre serait apprécié. Ce qui semble évident pour l'un (p.ex. un lieu de résidence) ne l'est pas forcément pour les autres. (Et ce qui est pensé avec humour n'est pas toujours reçu comme tel…).
Merci d'en tenir compte.

[Laszlo Lebrun]

Donc nous progressons enfin dans la discussion de manière constructive. Votre FAI est l'allemand T-online. Ainsi que donnent vos résultats par https://www.speedtest.net pour votre connexion ?

(¥) DOWNLOAD Mbps (7) UPLOAD Mbps
77.75 31.19
conforme au 75Mbits vendus.

S'ils sont conformes aux débits annoncés ou à ceux de https://packetstats.com/ dans les tests ?

ben non, pas du tout:
image

Il faudrait donc faire là aussi des tests sur le fournisseur SFR pour valider cette hypothèse de manière concrète. Sinon Georges va demander encore du café...

Je le ferai quand j'y serai, promis.


P.S. et chez vous ça donne quoi?

Ce message a été modifié par Laszlo Lebrun - 11 Feb 2024, 18:20.

[Polo35230]

On ne peut pas comparer les 2 tests. Dans un cas, le débit, et dans l'autre, la latence

-Pour le speedtest, on ne sait pas quel est le serveur de test. On peut supposer que c'est un serveur (77.75.31.19) de United Internet (AT-Kabeline). Donc, tout près de chez toi, dans les locaux de ton opérateur.
Et là tu ne donnes que le débit (conforme à ton abonnement 75Mbps) sans donner la latence pourtant indiquée dans le Speedtest

-Pour le Packetstat, dans la copie d'écran, on ne sait pas non plus quel est le serveur visé, mais dans la liste des serveurs proposés, il n'y en a pas un seul en Allemagne. Quel serveur as-tu pris?
Mais c'est vrai que le résultat (fichier image) n'est pas bon.

- Un bien meilleur test, c'est de faire un ping de ton forum préféré (macbidouille.com)
Tu pourras comparer avec le mien (100 Mbps dans les 2 sens)
Ta liaison (si c'est 75 Mbps) devrait te donner une latence entre 12 et 15ms

Code

polo@imac-de-polo ~ % ping macbidouille.com -c 10
PING macbidouille.com (188.114.96.2): 56 data bytes
64 bytes from 188.114.96.2: icmp_seq=0 ttl=54 time=12.880 ms
64 bytes from 188.114.96.2: icmp_seq=1 ttl=54 time=9.943 ms
64 bytes from 188.114.96.2: icmp_seq=2 ttl=54 time=8.834 ms
64 bytes from 188.114.96.2: icmp_seq=3 ttl=54 time=8.390 ms
64 bytes from 188.114.96.2: icmp_seq=4 ttl=54 time=9.191 ms
64 bytes from 188.114.96.2: icmp_seq=5 ttl=54 time=8.822 ms
64 bytes from 188.114.96.2: icmp_seq=6 ttl=54 time=10.725 ms
64 bytes from 188.114.96.2: icmp_seq=7 ttl=54 time=10.266 ms
64 bytes from 188.114.96.2: icmp_seq=8 ttl=54 time=8.505 ms
64 bytes from 188.114.96.2: icmp_seq=9 ttl=54 time=8.841 ms

--- macbidouille.com ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 8.390/9.640/12.880/1.310 ms

Les pings ne sont pas réguliers (ma p'tite femme regarde la TV et le protocole icmp n'est pas prioritaire, contrairement aux flux temps réel)

Ce message a été modifié par Polo35230 - 11 Feb 2024, 21:51.

[Polo35230]

Par curiosité, j'ai tracé (avec wireshark) un Paketstats vers le serveur de San-Francisco.
Et là, surprise, ce ne sont pas des pings, donc, ce n'est pas le protocole ICMP qui est utilisé, mais des paquets HTTP avec 0 datas...
D'ou le nom de Paketstats

Si on ping le serveur de San-Francisco (146.190.139.78), voilà ce que ça donne

Code

polo@imac-de-polo ~ % ping 146.190.139.78 -c 10
PING 146.190.139.78 (146.190.139.78): 56 data bytes
64 bytes from 146.190.139.78: icmp_seq=0 ttl=53 time=159.526 ms
64 bytes from 146.190.139.78: icmp_seq=1 ttl=53 time=158.663 ms
64 bytes from 146.190.139.78: icmp_seq=2 ttl=53 time=158.530 ms
64 bytes from 146.190.139.78: icmp_seq=3 ttl=53 time=158.400 ms
64 bytes from 146.190.139.78: icmp_seq=4 ttl=53 time=159.610 ms
64 bytes from 146.190.139.78: icmp_seq=5 ttl=53 time=157.891 ms
64 bytes from 146.190.139.78: icmp_seq=6 ttl=53 time=158.684 ms
64 bytes from 146.190.139.78: icmp_seq=7 ttl=53 time=157.945 ms
64 bytes from 146.190.139.78: icmp_seq=8 ttl=53 time=158.173 ms
64 bytes from 146.190.139.78: icmp_seq=9 ttl=53 time=158.662 ms

--- 146.190.139.78 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 157.891/158.608/159.610/0.552 ms

Stable, pas de gigue...

[Laszlo Lebrun]

- Un bien meilleur test, c'est de faire un ping de ton forum préféré (macbidouille.com)

Code

$ ping macbidouille.com
PING macbidouille.com (172.67.179.240): 56 data bytes
64 bytes from 172.67.179.240: icmp_seq=0 ttl=56 time=103.341 ms
Request timeout for icmp_seq 1
64 bytes from 172.67.179.240: icmp_seq=2 ttl=56 time=103.711 ms
64 bytes from 172.67.179.240: icmp_seq=3 ttl=56 time=104.241 ms
64 bytes from 172.67.179.240: icmp_seq=4 ttl=56 time=103.825 ms
64 bytes from 172.67.179.240: icmp_seq=5 ttl=56 time=103.152 ms
64 bytes from 172.67.179.240: icmp_seq=6 ttl=56 time=102.939 ms
64 bytes from 172.67.179.240: icmp_seq=7 ttl=56 time=159.033 ms

Mais il faut rester plus longtemps de temps en temps il y a des ratés vraiment foireux.

Et pour rester sur macbidouille:

Code

traceroute to macbidouille.com (172.67.179.240), 64 hops max, 52 byte packets
1  speedport.ip (192.168.2.1)  2.313 ms  1.858 ms  2.000 ms
2  p3e9bf49b.dip0.t-ipconnect.de (62.155.244.155)  9.207 ms  6.828 ms  5.817 ms
3  nyc-sb5-i.nyc.us.net.dtag.de (62.154.5.157)  100.044 ms  100.013 ms  100.097 ms
4  87.128.239.250 (87.128.239.250)  99.017 ms  98.954 ms  97.325 ms
5  if-ae-0-2.tcore3.njy-newark.as6453.net (216.6.90.14)  101.215 ms  104.583 ms  101.182 ms
6  66.198.70.2 (66.198.70.2)  175.213 ms  100.774 ms  101.536 ms
7  * 172.70.112.2 (172.70.112.2)  108.650 ms  101.844 ms
8  172.67.179.240 (172.67.179.240)  102.958 ms  102.950 ms  102.777 ms

les 100ms sont perdus à la ligne 3 sur le serveur nyc-sb5-i.nyc.us.net.dtag.de (dtag.de c'est Deutsche Telekom.AG, la maison mère de t-online).

Ce message a été modifié par Laszlo Lebrun - 11 Feb 2024, 22:24.

[Polo35230]

Alors, c'est vrai que que la ligne 2 est cohérente par raport à la vitesse de ta liaison.
C'est vrai aussi que la ligne 3 pose question.
Entre l'équipement d'ipconnect.de et celui de dtag.de (un whois donne Deutch Telekom), c'est tout le temps le cas?
Si c'est vrai, alors oui, il y a pb. Entre des équipements opérateurs, les temps devraient être inférieurs.

Les lignes suivantes montrent qu'il n'y a pas de pb
Elles sont toutes autour de 100ms.

En remarque, les temps enre les lignes ne sont pas forcément progressifs, alors qu'on pourrait le penser, tout simplement, parce que les temps indiqués ne sont pas les temps mesurés entre les équipements traversés, mais le temps entre l'équipement traversé et le Mac (ce ne sont pas des pings, même si c'est aussi de l'ICMP)
Et, en fct de la charge réseau, ces temps peuvent légèrement varier.
Si, après plusieurs traceroute, tu constate (ligne 3) des temps autour de 100ms, voir plus, c'est qu'il y a pb.
Les whois des adresses IP des routeurs lignes 2 et 3 montrent que c'est une liaison interco entre ton FAI et Deutsh Telekom.

Ça me fait penser qu'à une époque (c'est vieux...) des abonnés FREE se plaignaient de la lenteur de leurs connexions.
À cette époque, Free, qui n'avait pas encore une architecture conséquente squattait (par endroit) le réseau de France-Télécom.
Il se disait (sûrement des mauvaises langues ) à l'époque, que les flux étaient bridés (trafic shapping) au niveau de l'interco entre es 2 opérateurs pour limiter la bande passante des abonnés FREE (coûte cher, la bande passante...)

Ce message a été modifié par Polo35230 - 12 Feb 2024, 10:56.

[Benzebut]

P.S. et chez vous ça donne quoi?

Et voila mes retours sur le site de macbidouille en ce début de semaine :

CODE

iMac-Pro-8Xeon-de-Benoit:~ benoit$ ping macbidouille.com -c 10
PING macbidouille.com (188.114.96.2): 56 data bytes
64 bytes from 188.114.96.2: icmp_seq=0 ttl=57 time=3.395 ms
64 bytes from 188.114.96.2: icmp_seq=1 ttl=57 time=3.199 ms
64 bytes from 188.114.96.2: icmp_seq=2 ttl=57 time=3.228 ms
64 bytes from 188.114.96.2: icmp_seq=3 ttl=57 time=2.684 ms
64 bytes from 188.114.96.2: icmp_seq=4 ttl=57 time=2.849 ms
64 bytes from 188.114.96.2: icmp_seq=5 ttl=57 time=3.056 ms
64 bytes from 188.114.96.2: icmp_seq=6 ttl=57 time=2.850 ms
64 bytes from 188.114.96.2: icmp_seq=7 ttl=57 time=3.377 ms
64 bytes from 188.114.96.2: icmp_seq=8 ttl=57 time=3.155 ms
64 bytes from 188.114.96.2: icmp_seq=9 ttl=57 time=2.806 ms

--- macbidouille.com ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.684/3.060/3.395/0.237 ms
iMac-Pro-8Xeon-de-Benoit:~ benoit$

Dans votre ligne de code, la liaison est perdue sur la ligne 3 et l'hypothèse de Polo35230 serait la mienne également. Lors de la liaison, Deutch Telekom doit avoir un passerelle vers des flux limitants la bande passante. Ce qui est d'ailleurs toujours le cas chez Free pour la partie téléphone cellulaire, dont une partie du réseau est encore celui d'Orange...

[Laszlo Lebrun]

Dans votre ligne de code, la liaison est perdue sur la ligne 3 et l'hypothèse de Polo35230 serait la mienne également. Lors de la liaison, Deutch Telekom doit avoir un passerelle vers des flux limitants la bande passante. Ce qui est d'ailleurs toujours le cas chez Free pour la partie téléphone cellulaire, dont une partie du réseau est encore celui d'Orange...

...d'après le nom des serveurs, je me demande si ma connexion de Düsseldorf vers Paris ne passe pas par New-York?
...d'après leur IP, c'est même certain:

Geolocation data from IP2Location (Product: DB6, 2024-2-1)
IP Address: 62.154.5.157
Country: United States
Region: New York
City: New York City
ISP: Deutsche Telekom AG
Organization: Not available
Latitude: 40.7132
Longitude: -74.0061


Ce message a été modifié par Laszlo Lebrun - 12 Feb 2024, 14:08.

[Polo35230]

@Benzebut
Quand je vois le résultat de tes pings sur macbidouille, je me demande si tu n'es pas dans les locaux de l'hébergeur de macbidouille (CloudFlare?)

@Lazio Lebrun.
Je ne pense pas que l'adresse IP soit à Nework. La géolocalisation des adresses IP n'est pas fiable.
Je suis chez Orange, près de Rennes, et quand mon adresse IP publique change (après un reboot, par exemple), je peux être géolocalisé ailleurs.
As-tu fais plusieurs traceroute pour vérifier les temps de la ligne 3 ?

Pour moi, en regardant ton traceroute. On peut supputer, mais ce n'est pas sûr non plus...
Les whois et les noms des routeurs dans le traceroute ne permettent pas de savoir exactement où ils sont...
Mais bon, on peut toujours essayer...
Ligne1: Ta box
Ligne 2: Ton Opérateur
Ligne 3: Deutsch TeleKom en Allemagne
Ligne 4: Deutsch TeleKom
Ligne 5: Newark (côte Est des US) sur un équipement de Tata Communication (câblo-opérateur indien)
Ligne8: Cloudflare (hébergeur de Macbidouille San-Francisco?)

[Laszlo Lebrun]

@Benzebut
Quand je vois le résultat de tes pings sur macbidouille, je me demande si tu n'es pas dans les locaux de l'hébergeur de macbidouille (CloudFlare?)
...
Ligne 5: Newark (côte Est des US) sur un équipement de Tata Communication (câblo-opérateur indien)
Ligne8: Cloudflare (hébergeur de Macbidouille San-Francisco?)

Ah oui, Macbidouille est hébergé en Californie !

Geolocation data from IP2Location (Product: DB6, 2024-2-1)
Domain Name: macbidouille.com
Country: United States
Region: California
City: San Francisco
ISP: CloudFlare Inc.
Organization: Not available
Latitude: 37.7757
Longitude: -122.3952

Donc New-York n'est pas idiot.
Mais alors pourquoi j'ai entre 120mS et 450ms alors que les autres tournent à moins de 50ms.

Et quand je teste avec unserveur a SanFrancisco c'est pas follichon non plus
packetstats.com vers san Francisco

Que donnent vos tests avec packetstats?

Ce message a été modifié par Laszlo Lebrun - 12 Feb 2024, 18:31.

[Polo35230]

Mais alors pourquoi j'ai entre 120mS et 450ms alors que les autres tournent à moins de 50ms.

La réponse est dans le traceroute post #22
Ce sont les 100ms (ligne 3 de la liaison d'interco entre T-Online et Deutsch Telekom) qui te plombent.
La valeur retournée devrait être de l'ordre de 12ms environ.
Après, ça dépote. Donc, tu devrais avoir des pings autour de 14 ms

As-tu fait plusieurs fois des traceroute vers macbidouille en observant les temps de la ligne 3.
C'est pour valider l'hypothèse que les pbs sont liés à l'interco. En fct des heures (en soirée, par exemple) le trafic est plus important.
Tu dis que tu observe des valeurs entre 120 et 450ms.
Ligne 3, tu devrais avoir alors des temps dans cette fourchette.
Si c'est vérifié, le pb sera qualifié (mais non résolu...)

Que donnent vos tests avec packetstats?

Avec paketstats, je suis entre 160 ms et 165ms.
mais c'est pas comparable aux pings.

Laisse tomber packetstats.

[Laszlo Lebrun]

mais c'est pas comparable aux pings.
Laisse tomber packetstats.

Ben si !
Quand je ping Macbidouille, j'ai aussi 120-140 ms. Si je prends un serveur aux pays-bas, près de chez moi, c'est à peine meilleur, on descend à 80ms. Pas terrible comme résultat.
Et l'internet ne marche pas avec des pings sur un serveur, mais pratiquement chaque page appelle des dizaines, voie des centaines de serveurs un peu partout, publipollution oblige.
Si à chaque fois le contenu met >100ms à s'initialiser, l'experience utilisateur n'est pas top...

Ce message a été modifié par Laszlo Lebrun - 12 Feb 2024, 21:36.

[Polo35230]

Ben si !
Quand je ping Macbidouille, j'ai aussi 120-140 ms. Si je prends un serveur aux pays-bas, près de chez moi, c'est à peine meilleur, on descend à 80ms. Pas terrible comme résultat.
Et l'internet ne marche pas avec des pings sur un serveur, mais pratiquement chaque page appelle des dizaines, voie des centaines de serveurs un peu partout, publipollution oblige.
Si à chaque fois le contenu met >100ms à s'initialiser, l'experience utilisateur n'est pas top...

Ben non !
Tu compares le temps de ton ping avec mon temps de packetsats. C'est pas comparable.
Si on veut vraiment comparer, pour le ping de macbidouille, tu es à 120ms, je suis à 8 ms, et @Benzebut à 3 ms.

Tu ne veux pas donner les temps d'interco pour valider l'hypothèse d'un pb de bridage sur ce lien.

Eh oui, une connexion sur un serveur au Amsterdam peut être plus lente qu'une connexion San-Francisco.

Eh oui aussi, bien sûr, le web ne marche pas avec des pings sur un serveur.
Mais quand tu constates avec un ping (de 56 octets) et un traceroute (outil de base pour faire un diagnostique réseau) qu'il y a des pbs, tu peux être sûr que ces pbs seront amplifiés en affichant une page web ( contrôle de flux TCP et segments TCP pleins de 1500 octets)

Bref, tu peux faire tourner Packetstats toute la journée, c'est pas lui qui te diras où est le pb, et en plus il te bouffe de la bande passante

Bon, j'arrête là.

[Laszlo Lebrun]

Bref, tu peux faire tourner Packetstats toute la journée, c'est pas lui qui te diras où est le pb, et en plus il te bouffe de la bande passante

C'est vrai, il ne te dira pas *où* est le problème, mais il mettra un problème en évidence, surtout s'il es sporadique. Et visiblement il y en a un avec mon FAI.
Quand à la bande passante, si une message minuscule par seconde est un problème, alors on peut reprendre le modem 1440 Bauds.

Tu ne veux pas donner les temps d'interco pour valider l'hypothèse d'un pb de bridage sur ce lien.

??? Que n'aurais-je pas voulu donner comme info?
J'ai donné les pings, le traceroute, les whois, il manque quoi?

Ce message a été modifié par Laszlo Lebrun - 13 Feb 2024, 10:53.

[Mac Arthur]

" Que vaut votre connexion internet?, Peut-être moins que ce qu'on veut vous faire croire !"

On ne veut rien nous faire croire du tout, il suffit de lire ce qui est écrit, c'est comme le Port Salut.
Un FAI ne peut pas transmettre plus vite que ce qu'il reçoit, ça date des cours de maths avec des baignoires qui se remplissent avec des robinets et se vident avec des bondes.
Je paie pour 120Mbps en up et 120Mbps en down et j'ai 120Mbps dans les 2 sens avec un ping de 2ms.
Evidemment mon FAI est correctement équipé avec des backbones qui lui permettent de suivre.
Alors ensuite on peut aller chercher un fichier au fin fond de tataouine et là c'est sûr que ça va coincer
Packetstats ne sert à rien dans ce cas.
Little Snitch me permet de surveiller toutes mes connexions entrantes et sortantes (et Dieu sait si ça pullule sans qu'on ne s'en rende compte) avec les débits correspondant.
Le reste n'est que...

[Benzebut]

@Benzebut
Quand je vois le résultat de tes pings sur macbidouille, je me demande si tu n'es pas dans les locaux de l'hébergeur de macbidouille (CloudFlare?)

J'en suis loin, mais c'est l'effet Jeux Olympiques sur la capitale. Le réseau fibre a été mis à jour en 40 Gb/s théorique pour accueillir la terre entière et garantir les débits requis cet été 2024. Donc évidemment, les temps de latence sont faibles actuellement pour faire ces tests sur macbidouille...

C'est vrai, il ne te dira pas *où* est le problème, mais il mettra un problème en évidence, surtout s'il es sporadique. Et visiblement il y en a un avec mon FAI.
Quand à la bande passante, si une message minuscule par seconde est un problème, alors on peut reprendre le modem 1440 Bauds.

Non toujours pas. Ce que vous mesurez c'est l'envoi de paquets sur le réseau à partir de votre connexion vers un serveur distant. Toute la beauté du protocole est qu'il va choisir le chemin disponible entre ces 2 points sans rationalité dans le parcours. Vous pouvez passer par l'Europe, les Etats-Unis ou l'Asie, même pour une connexion proche. Avec des optimisations différentes et de fait des latences associées. Pour faire une nouvelle analogie, lorsqu'un stade se vide, tous les individus présents vont prendre la direction de la sortie, mais chacun avec un comportement différent et dans des délais associés. Mais au final, tous sortiront comme annoncé...

Donc encore une fois, cela ne mesure par la même chose pour surfer sur internet et ces informations Packetstats ne seront guère exploitables...

Ce message a été modifié par Benzebut - 13 Feb 2024, 16:26.

[Laszlo Lebrun]

J'en suis loin, mais c'est l'effet Jeux Olympiques sur la capitale. Le réseau fibre a été mis à jour en 40 Gb/s théorique pour accueillir la terre entière et garantir les débits requis cet été 2024. Donc évidemment, les temps de latence sont faibles actuellement pour faire ces tests sur macbidouille...

La fibre, c'est le dernier mile.
Or le Traceroute le montre clairement: ce n'est pas le dernier mile qui est en cause.

C'est vrai, il ne te dira pas *où* est le problème, mais il mettra un problème en évidence, surtout s'il es sporadique. Et visiblement il y en a un avec mon FAI...

Non toujours pas. Ce que vous mesurez c'est l'envoi de paquets sur le réseau à partir de votre connexion vers un serveur distant.

Mais avant de partir pour le grand voyage par monts et par vaux que tu décris, il passe d'abord par les serveurs du FAI qui décortiquent entre autres le DNS.
Et c'est là que se fait la différence La fameuse étape 3 de 100mS de mes traceroute.

[Polo35230]

Je reviens...

Pour redire que pour vérifier l'hypothèse d'un bridage de la liaison d'interco entre ton FAI et Deutsche Telekom, il faut faire PLUSIEURS traceroute vers Macbidouille (une dizaine par exemple) et observer les temps donnés ligne 3.

Si les temps sont élevés (par exemple >100ms), alors oui, c'est que cette liaison d'interconnexion est bien bridée, vraisemblablement par QoS (trafic shaping-policy, qui permet de garantir un débit, mais aussi de le limiter)

Ton FAI ne le reconnaîtra pas.
Passe chez Deutsche Teleckom!

Ce message a été modifié par Polo35230 - 13 Feb 2024, 20:25.

[Laszlo Lebrun]

Pour redire que pour vérifier l'hypothèse d'un bridage de la liaison d'interco entre ton FAI et Deutsche Telekom

Mais je suis chez Deutsche Telekom = T-online !

il faut faire PLUSIEURS traceroute vers Macbidouille (une dizaine par exemple) et observer les temps donnés ligne 3.

Je ne t'ai pas attendu: j'en ai déjà fait des centaines !

Si les temps sont élevés (par exemple >100ms), alors oui, c'est que cette liaison d'interconnexion est bien bridée, vraisemblablement par QoS (trafic shaping-policy, qui permet de garantir un débit, mais aussi de le limiter)
Ton FAI ne le reconnaîtra pas.

Ça c'est vrai ! Tu as beau leur mettre le nez dans leur m**de, ils ne reconnaissent absolument rien !
Mais mon voisin est chez Vodafone par le câble, et c'est pas mieux chez lui non plus...
Ils ont tous leurs démos trafiquées Ookla (avec qui ils sont sûrement en cheville) et considèrent le problème réglé quand l'aiguille est sur 75Mbit/s.
Ils peuvent ainsi vendre des centaines ou des milliers de contrats à 75Mbit/s en ayant derrière une infrastructure complètement sous-dimensionnée qui n'en gère pas le centième...

Ce message a été modifié par Laszlo Lebrun - 13 Feb 2024, 20:51.

[Polo35230]

Je ne t'ai pas attendu: j'en ai déjà fait des centaines !

Et ils sont tous au dessus de 100ms?

Tiens, un bon test de débit
Lance un Speedtest.
Clique sur "Changer de serveur"
Dans la barre de recherche, tape San Francisco
Prends San Francisco, CA -Wave
Lance le test

[Laszlo Lebrun]

Je ne t'ai pas attendu: j'en ai déjà fait des centaines !

Et ils sont tous au dessus de 100ms?

Pratiquement tous, oui.

Tiens, un bon test de débit...

Le problème est ailleurs: une fois qu'un flux est initialisé il passe sans délai. Un download passe en général dans les normes si l'autre côté suit et qu'il ne faut pas relancer le flux.
C'est l'initialisation qui prend du temps.
Et quand tu surfes normalement, il y a des centaines d'initialisations vers des centaines de serveurs publipoubelles qui font que ça n'avance pas.

[Polo35230]

Le problème est ailleurs: une fois qu'un flux est initialisé il passe sans délai. Un download passe en général dans les normes si l'autre côté suit et qu'il ne faut pas relancer le flux.
C'est l'initialisation qui prend du temps.
Et quand tu surfes normalement, il y a des centaines d'initialisations vers des centaines de serveurs publipoubelles qui font que ça n'avance pas.

Tu parles de normes (?), mais quels sont les débits donnés par le test en upload et en download?
À la louche, pour moi, si lien d'interco est bridé, vu les temps indiqués dans le traceroute, tu devrais être autour de 5 ou 6Mbps.

Quand tu dis que l'initialisation est lente, tu parles de quoi? Des requêtes DNS?
Bien sûr qu'il y a des connexions HTTP vers d'autres sites (publicités, métrologie)
Déjà, pour ça, un bloqueur de pub peut empêcher la plupart de ces connexions.
Mais tu as une liaison internat à 75Mbps. Ces connexions ne devraient pas te ralentir.
As-tu essayé de changer de DNS?
Celui de google par exemple (8.8.8.8)?

Fais un:
nslookup macbidouille.com
Et poste le résultat

Ce message a été modifié par Polo35230 - 13 Feb 2024, 23:10.

[Benzebut]

La fibre, c'est le dernier mile.
Or le Traceroute le montre clairement: ce n'est pas le dernier mile qui est en cause.

Pas dans le cas présent. La fibre utilisée en 40 Gb/s théorique concerne les premiers et derniers miles, car cela reste sur la même infrastructure dans Paris et explique ces faibles latences actuellement. Ce qui donne l'impression d'être dans les locaux de l'hébergeur de macbidouille...

Mais avant de partir pour le grand voyage par monts et par vaux que tu décris, il passe d'abord par les serveurs du FAI qui décortiquent entre autres le DNS.
Et c'est là que se fait la différence La fameuse étape 3 de 100mS de mes traceroute.

Non toujours pas. Et cela n'a rien à voir avec les FAI allemands (testez un autre fournisseur), des mesures trafiquées (testez un site de mesure alternatif), des DNS décortiquées (changez de serveur DNS) ou autres théories du complot. C'est simplement le fonctionnement normal en interconnexion au niveau du réseau. Et c'est largement ce qui est annoncé par les FAI sur les infrastructures qu'ils possédent.
Cas de mon nslookup sur le serveur macbidouille :

CODE

iMac-Pro-8Xeon-de-Benoit:~ benoit$ nslookup macbidouille.com
Server: 192.168.1.254
Address: 192.168.1.254#53

Non-authoritative answer:
Name: macbidouille.com
Address: 188.114.97.2
Name: macbidouille.com
Address: 188.114.96.2

[Laszlo Lebrun]

Cas de mon nslookup sur le serveur macbidouille :

Quel rapport avec le temps de latence des serveurs du FAI?
J'ai le même type de réponse.

[Polo35230]

Cas de mon nslookup sur le serveur macbidouille :

Quel rapport avec le temps de latence des serveurs du FAI?
J'ai le même type de réponse.

Aucun rapport bien sûr avec le temps de latence des pings, mais quand tu dis que c'est "l'initialisation qui prends du temps", perso, je ne sais pas trop ce que ça veut dire, alors je traduis qu'il y a un pb dans les requêtes DNS (en plus du pb de la ligne 3)
Parce que, parfois, on peut cumuler les emmerdes ...

Et effectivement, si au niveau de la configuration DNS, il y a des bizarreries (on va pas les détailler), la requête DNS peut prendre du temps.
Tiens, si tu analyses la page d'accueil du forum de macbidouille, il y a 5 connexions HTTP sur 5 sites différents, donc 5 requêtes DNS:
forum.macbidouille.com
w3.org
google-analytics.com (mon navigateur est chrome)
googlesyndaction.com
doubleclick.net

C'est pour ça que le nlookup est intéressant.
Tu nous dis que tu as le même type de réponse que celui de Benzebut, mais tu ne nous dis pas l'adresse IP de ton serveur DNS.
Même chose pour le test de débit du post #37, on n'a pas la réponse...
On ne peut pas tout deviner

Ce message a été modifié par Polo35230 - 14 Feb 2024, 17:06.

[Laszlo Lebrun]

Aucun rapport bien sûr avec le temps de latence des pings, mais quand tu dis que c'est "l'initialisation qui prends du temps", perso, je ne sais pas trop ce que ça veut dire, alors je traduis qu'il y a un pb dans les requêtes DNS (en plus du pb de la ligne 3)

J'ai changé les deux serveurs de DNS par des serveurs locaux à Dusseldorf et à Siegen
https://public-dns.info/nameserver/de.html
161.97.150.198
91.26.45.59

mais ça n'arrange rien, il y a toujours uen latence au 3ème hop:

Code

$ traceroute macbidouille.com
traceroute: Warning: macbidouille.com has multiple addresses; using 172.67.179.240
traceroute to macbidouille.com (172.67.179.240), 64 hops max, 52 byte packets
1  192.168.2.1 (192.168.2.1)  5.193 ms  6.644 ms  6.327 ms
2  p3e9bf49b.dip0.t-ipconnect.de (62.155.244.155)  6.791 ms  6.534 ms  19.663 ms
3  nyc-sb5-i.nyc.us.net.dtag.de (62.154.5.161)  273.299 ms  136.201 ms  99.328 ms
4  87.128.239.250 (87.128.239.250)  103.526 ms  99.624 ms  98.926 ms
5  * * *
6  66.198.70.2 (66.198.70.2)  107.658 ms  105.748 ms  105.730 ms
7  172.70.108.2 (172.70.108.2)  104.072 ms
    162.158.156.3 (162.158.156.3)  102.832 ms
    172.70.228.2 (172.70.228.2)  103.303 ms
8  172.67.179.240 (172.67.179.240)  101.806 ms  102.052 ms  101.895 ms

[Polo35230]

Je n'ai pas été assez précis, dans le post #37, c'était pour lancer un Speedtest...

Lance un Speedtest.
Clique sur "Changer de serveur"
Dans la barre de recherche, tape San Francisco
Prends San Francisco, CA -Wave
Lance le test

On aura une idée précise des débits dans les 2 sens.
Si l'hypothèse du bridage (la ligne 3) se vérifie, je pense que tu aura des débits proches de 5 Mbps.

[Laszlo Lebrun]

Je n'ai pas été assez précis, dans le post #37, c'était pour lancer un Speedtest...
...
Si l'hypothèse du bridage (la ligne 3) se vérifie, je pense que tu aura des débits proches de 5 Mbps.

Mais Speedtest c'est Ookla !
C'est ce que je vous dis depuis le début: C'est du bidon !
Resultat du speedtest

[Polo35230]

Le premier serveur DNS est celui d'un hébergeur : Contabo
Le 2ème (KONRAD-KNOBLAUCH-GERA-NET) semble être vaguement relié à Deutsch Telekm.

Pourquoi n'utilises tu pas un DNS de Deutsche Telekom?
194.25.0.68 par exemple

Mais Speedtest c'est Ookla !
C'est ce que je vous dis depuis le début: C'est du bidon !
Resultat du speedtest

Tu n'as pas fait le bon test
Tu as choisi un serveur de Dusseldorf. Les résultats sont bons (73Mbps et 37Mbps), mais tu ne passes pas par le même chemin que celui de macbidouille.

Clique sur "Changer de serveur"
Dans la barre de recherche, tape San Francisco
Prends San Francisco, CA -Wave
Lance le test

Ce message a été modifié par Polo35230 - 14 Feb 2024, 20:50.

[Laszlo Lebrun]

Clique sur "Changer de serveur"
Dans la barre de recherche, tape San Francisco
Prends San Francisco, CA -Wave
Lance le test

Presque kif-kif
Ookla c'est du pipeau !
Ça sort des vitesses de rêve avec 200ms de latence !
C'est pas comme ça qu'on évalue la qualité d'une connexion.

Ce message a été modifié par Laszlo Lebrun - 14 Feb 2024, 21:32.

[Polo35230]

Alors là, oui, le test de débit est bon

Et pour le DNS, tu as mis 194.25.0.68 pour voir si ça change quelque chose en naviguant?

[Polo35230]

Bon, là, je suis sec...
Le pb est peut-être uniquement au niveau de la navigation web...

Un truc curieux, c'est ton serveur DNS (161.97.150.198) qui est chez un hébergeur (Contabo)
Tu as été chez eux, à un moment donné?
Tu utilises peut-être un proxy chez eux.
Ça pourrait expliquer certaines lenteurs.

-Change le DNS et mets un DNS de Deutsche Telekom (194.25.0.68)
-Y a-t-il un proxy configuré dans ton navigateur?
-Y a-t-il un proxy configuré dans la conf réseau du Mac?
-Fais un : ifconfig (pour voir les interfaces), et poste le résultat.
-Fais un : netstat -r (pour voir les tables de routage), et poste le résultat.

Si après tout ça on ne trouve pas d'explications, de honte, je laisse tomber l'informatique, et je me mets à la broderie

[Laszlo Lebrun]

Bon, là, je suis sec...
Le pb est peut-être uniquement au niveau de la navigation web...

Un truc curieux, c'est ton serveur DNS (161.97.150.198) qui est chez un hébergeur (Contabo)
Tu as été chez eux, à un moment donné?
Tu utilises peut-être un proxy chez eux.
Ça pourrait expliquer certaines lenteurs.

-Change le DNS et mets un DNS de Deutsche Telekom (194.25.0.68)
-Y a-t-il un proxy configuré dans ton navigateur?
-Y a-t-il un proxy configuré dans la conf réseau du Mac?
-Fais un : ifconfig (pour voir les interfaces), et poste le résultat.
-Fais un : netstat -r (pour voir les tables de routage), et poste le résultat.

Si après tout ça on ne trouve pas d'explications, de honte, je laisse tomber l'informatique, et je me mets à la broderie

J'ai essayé de changer de DNS en choisissant un DNS proche puis un autre de Telekom les deux ayant une bonne note de 100%, sans que ça change notoirement le résultat, puis ai finalement remis le réglage du routeur Telekom.
metstat-r donne:

Code

netstat -r
Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            speedport.ip       UGSc           48        0     en1      
127                localhost          UCS             0        0     lo0      
localhost          localhost          UH              1      128     lo0      
169.254            link#6             UCS             1        0     en1      !
192.168.2          link#6             UCS             5        0     en1      !
192.168.2.1/32     link#6             UCS             1        0     en1      !
speedport.ip       70:97:41:8d:61:9c  UHLWIir        14      269     en1   1191
6bebf8-speedhomewl 70:97:41:6b:eb:f8  UHLWI           0        3     en1   1173
sec842519103a42    84:25:19:10:3a:42  UHLWI           0        0     en1    737
192.168.2.156/32   link#6             UCS             0        0     en1      !
                   56:1c:27:e2:3:1c   UHLWI           0        1     en1    896
                   12:9a:1e:69:79:78  UHLWI           0       10     en1   1171
224.0.0/4          link#6             UmCS            1        0     en1      !
mdns.mcast.net     1:0:5e:0:0:fb      UHmLWI          0        0     en1      
255.255.255.255/32 link#6             UCS             0        0     en1      !

Internet6:
Destination        Gateway            Flags         Netif Expire
default            fe80::1%en1        UGc             en1      
default            fe80::%utun0       UGcI          utun0      
localhost          localhost          UHL             lo0      
p200300cc0f1709130 link#6             UC              en1      
p200300cc0f1709131 28:f0:76:1b:36:a   UHL             lo0      
p200300cc0f1709133 28:f0:76:1b:36:a   UHL             lo0      
fe80::%lo0         fe80::1%lo0        UcI             lo0      
fe80::1%lo0        link#1             UHLI            lo0      
fe80::%en1         link#6             UCI             en1      
fe80::1%en1        70:97:41:8d:61:9c  UHLWIir         en1

j'ai arrêté a partir de là pour ne pas révèler mes IP V6 permanentes
À noter: netstat -r met beaucoup de temps à afficher les infos en IPV6.
Du coup, j'ai aussi essayé de désactiver IPv6, un classique... Sans amélioration non plus...

En fait on fait la même chose que les hotlines: on cherche le problème de mon côté et dans mon (mes) ordi(s) ou mon routeur. Ce serait légitime si...
-Si je n'avais pas les mêmes résultats quels que soient mes OS et materiels utilisés.
-Si mon voisin n'avait pas pratiquement les mêmes résultats sur son autre ligne Telekom avec un autre routeur Telekom et un autre matériel.
Cherchez le dénominateur commun...

Ce message a été modifié par Laszlo Lebrun - 15 Feb 2024, 06:15.

[Polo35230]

En fait on fait la même chose que les hotlines: on cherche le problème de mon côté et dans mon (mes) ordi(s) ou mon routeur. Ce serait légitime si...
-Si je n'avais pas les mêmes résultats quels que soient mes OS et materiels utilisés.
-Si mon voisin n'avait pas pratiquement les mêmes résultats sur son autre ligne Telekom avec un autre routeur Telekom et un autre matériel.
Cherchez le dénominateur commun...

Mouais...
Tu laches des infos au compte-gouttes et tu ne réponds que partiellement aux questions posées.

Il y a bien un bridage (la fameuse ligne 3), mais tu ne dois pas passer tout le temps par là.
Il y a autre chose.
Bien possible que le pb vienne aussi de ta conf, qu'on découvre progrssivement...

DNS IPv4 chez un hébergeur...
Doubles requêtes DNS IPV4 IPv6.
Adresses IP permanentes associées à certains équipements.
Complexe sans connaître en détail les confs réseau de tes équipements.

[Mac Arthur]

Ça s'appelle "garder la main" sur le post...

[Benzebut]

DNS IPv4 chez un hébergeur...
Doubles requêtes DNS IPV4 IPv6.
Adresses IP permanentes associées à certains équipements.
Complexe sans connaître en détail les confs réseau de tes équipements.

Voire l’utilisation d'un VPN, antivirus ou autre applications qui brident et filtrent les connexions sur ces serveurs à partir de macOS...

Mais Speedtest c'est Ookla !
C'est ce que je vous dis depuis le début: C'est du bidon !
Resultat du speedtest

Encore une fois, non. Et si vous n'avez pas confiance en SpeedTest, il y a des alternatives de disponibles pour des mesures trafiquées par d'autres :

https://www.nperf.com/fr/
https://www.zoneadsl.com/test-debit-internet.html
https://www.degrouptest.com/test-debit.php
https://www.quechoisir.org/outil-speedtest-n64483/

Ce message a été modifié par Benzebut - 15 Feb 2024, 11:40.

[Laszlo Lebrun]

Il y a bien un bridage (la fameuse ligne 3), mais tu ne dois pas passer tout le temps par là.
Il y a autre chose.
Bien possible que le pb vienne aussi de ta conf, qu'on découvre progrssivement...

...et de la conf de mon voisin aussi, lequel n'a que du standard?
Essayez de ne pas occulter celà. C'est essentiel.

Ce message a été modifié par Laszlo Lebrun - 15 Feb 2024, 12:10.

[Mac Arthur]

Et si le voisin avait posé une "bretelle"

Ce message a été modifié par Mac Arthur - 15 Feb 2024, 12:27.

[Benzebut]

...et de la conf de mon voisin aussi, lequel n'a que du standard?
Essayez de ne pas occulter celà. C'est essentiel.

Justement, que donnent les tests et résultats de la configuration de votre voisin, qui n'a que du "standard" par son opérateur allemand ?

[Mac Arthur]

Excellente remarque.
Il faudrait demander au voisin de s'inscrire sur le forum et qu'il nous explique LUI sa vision des choses pour éviter l'effet prisme déformant.

On aurait ainsi 2 sons de cloche à comparer (les 2 sons hein, pas les cloches!).
Parce que si ce post doit servir de lanceur d'alerte pour précipiter la chute d'Ookla il faut que je sois au courant.
J'ai toutes mes économies chez eux.
Sacré MB, à l'aube de jeter un vrai pavé dans la mare.
Je contacte Mediapart ou on attend encore un peu?....

[Laszlo Lebrun]

...et de la conf de mon voisin aussi, lequel n'a que du standard?
Essayez de ne pas occulter celà. C'est essentiel.

Justement, que donnent les tests et résultats de la configuration de votre voisin, qui n'a que du "standard" par son opérateur allemand ?

Quand on a regardé ensemble, il avait des résultats semblables.
Je ne vais pas le redéranger pour la même chose.
On va en rester là. Ça tourne en rond.
Thank you for the fish...

[Polo35230]

On va en rester là. Ça tourne en rond.

Oui, j'en dormais plus

[Mac Arthur]

Et pourtant elle tourne...

[Benzebut]

Quand on a regardé ensemble, il avait des résultats semblables.
Je ne vais pas le redéranger pour la même chose.
On va en rester là. Ça tourne en rond.
Thank you for the fish...

Effectivement, c'est préférable d'en rester là sur cette configuration speedport.ip chez les voisins Outre-Rhin. Et penser à changer le titre du sujet pour plus de clarté.

[Laszlo Lebrun]

Effectivement, c'est préférable d'en rester là sur cette configuration speedport.ip chez les voisins Outre-Rhin. Et penser à changer le titre du sujet pour plus de clarté.

Je reviendrai sur le sujet quand je serai en France avec un FAI SFR...

Ce message a été modifié par Laszlo Lebrun - 16 Feb 2024, 14:23.