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à.