Les performances LTE des nouveaux iPhone Xs progressent considérablement, Réactions à la publication du 18/09/2018

[SartMatt]

L'appli Speedtest (smartphone) me donne une IP dite externe en 92.xx.xx.4 et sur nperf.com (pc win7) j'ai une IP (non qualifiée mais sous le nom du serveur) en 92.xx.xx.89 ... alors que l'on est sur la même connexion et au même moment.

Deux IP publiques différentes selon qu'on est sur le téléphone ou sur un PC avec le téléphone en mode modem, ça peut venir du fait que sur certains téléphones/opérateur il peut y avoir une configuration d'APN différente pour le téléphone lui même et pour le mode modem.
C'était le cas par exemple avec l'iPhone et Orange, où il y avait un APN (orange) pour la connexion Internet du téléphone et un autre pour le mode modem (orangenew.fr), c'est peut-être encore le cas aujourd'hui. Voir ici par exemple : http://forum.macbidouille.com/index.php?showtopic=303762
Sinon, ça peut aussi venir du fait qu'un opérateur peut avoir plusieurs passerelles entre son NAT et Internet, avec passage de l'une à l'autre en fonction de la charge, de la destination, du protocole, etc...

[teac68]

L'appli Speedtest (smartphone) me donne une IP dite externe en 92.xx.xx.4 et sur nperf.com (pc win7) j'ai une IP (non qualifiée mais sous le nom du serveur) en 92.xx.xx.89 ... alors que l'on est sur la même connexion et au même moment.

Deux IP publiques différentes selon qu'on est sur le téléphone ou sur un PC avec le téléphone en mode modem, ça peut venir du fait que sur certains téléphones/opérateur il peut y avoir une configuration d'APN différente pour le téléphone lui même et pour le mode modem.
C'était le cas par exemple avec l'iPhone et Orange, où il y avait un APN (orange) pour la connexion Internet du téléphone et un autre pour le mode modem (orangenew.fr), c'est peut-être encore le cas aujourd'hui. Voir ici par exemple : http://forum.macbidouille.com/index.php?showtopic=303762
Sinon, ça peut aussi venir du fait qu'un opérateur peut avoir plusieurs passerelles entre son NAT et Internet, avec passage de l'une à l'autre en fonction de la charge, de la destination, du protocole, etc...

Je prends
Et cette IP en 10.xx ?? que l'on retrouve dans les paramètres du tel n'est donc pas une IP publique et encore moins celle d'une box.
Un vrai bordel pour atteindre un serveur derrière une connexion 4G, VPN obligatoire.

[SartMatt]

Et cette IP en 10.xx ?? que l'on retrouve dans les paramètres du tel n'est donc pas une IP publique et encore moins celle d'une box.

Cette IP privée, elle vient du fait que les réseaux mobiles sont NATés, notamment pour palier à la pénurie d'IPv4.

[iAPX]

Et tout ça pour quoi?!?

Parce que en fait 10Mbps suffisent très largement pour un smartphone, généralement bridé d'ailleurs par son réseau et rendu peu agréable pour les interactions sur le web (incluant charger une page) par les pertes de paquets qui peuvent générer des attentes de plusieurs secondes, bande-passante dispo ou pas, et d'ailleurs pour de nombreux utilisateurs la bande-passante est tellement énorme par rapport à la quantité de données incluse dans leur forfait (en Amérique du Nord par exemple), qu'il ne faudrait que quelques minutes (voir juste 1 mn!) pour l'épuiser totalement.

Les "performances" en 4G ou LTE pour moi ne se réduisent pas à une bande-passante, si tant est qu'elle soit suffisante, comme 10Mbps, mais aussi et surtout à sa tenue dans des zones mal couvertes et une diminution des paquets perdus dans ce même cas.
Je crois que la 5G essaye d'atteindre ces objectifs et c'est bien plus intéressant car ça va amener une meilleure expérience dans de nombreux cas et bien plus uniforme qu'actuellement!

[Ritchi]

Bonjour
Perso, avec mon Samsung S7 et un abonnement à 4,99€, j'obtiens des résultats 3 fois supérieurs à ceux d'AT&T: 248Mbps
[attachment=57538:Screensh...peedtest.jpg]
Ritchi

Le Wi-Fi est activé sur ton téléphone...

Bonjour Lionel,

Après une longue journée de travail, je découvre ton message.
Le screenshot que je t’ai envoyé a été fait ce matin sur mon téléphone, mais si tu regardes bien , le test de débit a été fait le 09 août 2018 à 23h26 sur le réseau Orange à mon domicile.
L’icone Wifi, bluetooth , le 71% de batterie, et l'heure 7h16 correspondent à la barre de menu de mon téléphone de ce matin, heure à laquelle j’ai fait mon intervention.
Jamais je n’aurais osé truander les lecteurs de ce forum en mettant un fake news et une capture d'écran bidouillée.

Certes je n’ai pas utilisé l’application utilisée par les testeurs américains, mais juste l’application SpeedTest sur Androïd. Les résultats me semblent quand même comparables.

De part mon métier, je suis tout à fait convaincu que le Mimo 4x4 est une très belle feature 4G qui va donner, aux mobiles compatibles, plus de ressources réseaux et donc plus de débits, en attendant la 5G qui permet déjà des débits mesurées en centaines de Mbps dans ses premières démonstrations clients.

Pour finir, je préciserai que teac68 (que je salue au passage) est un parfait inconnu pour moi et je le remercie pour avoir pris « ma défense » en mettant en évidence que le test avait bien été effectué sur un réseau cellulaire.
A l’occasion, je testerai de che moi les débits obtenus avec un iPhone.

Ritchi

Tu as 2 IP, une WAN, normal , mais une LAN, qui ne peut provenir que par une box et que tu n'aurais pas si tu étais en LTE pur. .De plus, Orange ne fait pas de forfait à 4,99€/mois.DDOnc je suppose que ton test est donc fait sur une box orange en Fibre Optique, pas en 4G LTE, et comme le disait Lionel du fait que le WiFi soit activé, il a by-passé le LTE sans que tu t'en rende compte, ta bonne foi n'est pas en cause. Vérifie l'IP de ta Box Fibre et cela te confirmera ce que j'avance..
Tu peux essayer nperf.com, l'un des meilleurs Speedtest actuel (et apres 10 ans d'admin grenouille.com, on peut dire que je suis "aware" au sujet de la metrique de débit )

Bonjour,

Alors pour info voici un screenshot de ma facture SOSH de septembre 2018:
 Capture_d___e__cran_2018_09_19_a___20.19.21.png ( 90.5 Ko ) Nombre de téléchargements : 20


Et ce soir j'ai refait le test de débit et voici les résultats qui sont certes un peu moins élevés que cet été:
 Screenshot_20180919_201520_Speedtest.jpg ( 335.26 Ko ) Nombre de téléchargements : 24


Sincèrement,
Ritchi

[kwak-kwak]

Attention à l'article: il s'agit de la remonté de tests par une appli or les résultats peuvent-être biaisés par plusieurs facteurs comme par exemple :
- On ne sais pas quel est de délai temporel de la prise de mesure (depuis la date de sortie de chaque téléphone, ou la date de sortie du téléphone le plus récent) ? Les réseaux ont pu évoluer entre temps.
- Il est possible (et probable) que les premiers acquéreurs d'iPhone neufs se situent majoritairement en zone très bien desservie
- Quand on a un tout nouveau téléphone on a tendance a faire des tests en condition optimale pour se rassurer sur son achat. Avec le temps, les tests se font surtout quand le réseau merde (pour trouver l'origine d'une panne) où pour tester un réseau dans une zone ou l'on suppose que cela marchera mal.

A titre personnel, j'ai souvenir avoir fait des speedtest à plus de 100 Mb/s chez Free en 2015 sur un téléphone de 2015 à 300€ : Moto X play

Enfin en marge de ce que fait remarquer iAPX, les débits quand tout va bien ont au final peut d'importance pour bien du monde, le fait d'avoir 100mb/s ou 1Gb/s ne changeant par grand chose pour l'utilisateur d'un téléphone. A l'inverse, il me semblerait bien plus intéressant de savoir comment cela se passe quand tout va mal (en limite de réception) et en faisant le test au même endroit et au même moment avec d'autres téléphone pour avoir un semblant de protocole expérimental. Or dans ces situations, c'est en général bien plus la qualité de l'antenne qui importe. Car dans ces conditions avoir 2mb/s stable, 100kbit/s stable, 100 kbit/s par intermittence, ou pas de réseau du tout, font au final une grosse différence sur l'expérience utilisateur.

[_Panta]

@Ritchi : J'attends toujours ton test nPerf ... Tant que je ne verrais pas de "mes yeux vus" les debits donné par nPerf ainsi que les info réseau associé, c'est à dire théoriquement au niveau des 220Mb/s que te ton Ookla Speedtesdt, je ne reste toujours pas convaincu
Tu en as pour 30 secondes,si jamais tu as le temps on t'en remercira
https://www.nperf.com/fr/

. alors que l'on est sur la même connexion et au même moment. nPerf à aucun moment n'affiche l'IP du tél en 10.xx.

Et oui, car il n'y a aucune raison qu'il le fasse. Il s'en tape de la pate interne.

Ce message a été modifié par _Panta - 19 Sep 2018, 20:42.

[Ambroise]

Cela est lié à l'implémentation du Mimo 4x4 contre 2x2 sur les précédents modèles.

Doubler les performances de communication tout en diminuant la consommation c'est plutôt impressionnant.
Comme quoi Apple est encore capable d'audace : ça semblait être un pari fou de remplacer une puce ARM par une puce x86 : mais les résultats sont là.

[_Panta]

A titre personnel, j'ai souvenir avoir fait des speedtest à plus de 100 Mb/s chez Free en 2015 sur un téléphone de 2015 à 300€ : Moto X play

C'est plus souvent le FAI qui limite, rarement la puce, dans le cas de nos forfaits grand public

[Ritchi]

@Ritchi : J'attends toujours ton test nPerf ... Tant que je ne verrais pas les debits donné par nPerf ainsi que les info réseau associé, c'est à dire théoriquement au dessus de 220Mb/s que te ton Ookla Speedtesdt, je ne reste toujours pas convaincu

. alors que l'on est sur la même connexion et au même moment. nPerf à aucun moment n'affiche l'IP du tél en 10.xx.

Et oui, car il n'y a aucune raison qu'il le fasse. Il s'en tape de la pate interne.

Bonsoir,

Je viens d'installer nPerf sur mon S7 et voici les résultats:
 Screenshot_20180919_213827_nPerf.jpg ( 535.59 Ko ) Nombre de téléchargements : 20


Ils sont encore mieux que lors de ma première intervention, et CELA SANS AUCUNE RETOUCHE DE LA CAPTURE D'ÉCRAN.
Très sincèrement et en toute bonne foi,
Ritchi
PS: Si tu passes par Guyancourt, ma ville de résidence, alors je t'invite à faire le test depuis chez moi.

[_Panta]

Merci, toute ambiguïté est levé pour moi : tu es bien en 4G+ (LTE-A) - >ce que ne precise pas du tout Speedtest, et pourtant c'est primordial comme info.

Maintenant, avec une nuit de recul et d'analyse comparative Ookla Speedtest/nPerf,j'espere que vous comprendrez mieux ce que je disais hier au sujet de cet ambiguïté de <speedtest (comme le fait qu'il me donne une connexion WiFi alors que je suis en LTE, certes routé en wifi au niveau local chez moi, mais qui n'avait strictement aucune raison d'être

Ce message a été modifié par _Panta - 19 Sep 2018, 21:15.

[kwak-kwak]

Sosh fibre (via lien Ethenet 1Gb/s sur Livebox): https://www.nperf.com/r/351765041-NqelRRTp


Ipconfig, vu depuis le PC :

Code

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : home
   Description . . . . . . . . . . . : Intel(R) Ethernet Connection I217-V
   Physical Address. . . . . . . . . : 74-D4-xx-xx-xx
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : 2a01:xxxxxxxxxxxxxxxxxxxxxxxxx
   Temporary IPv6 Address. . . . . . : 2a01:xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   Link-local IPv6 Address . . . . . : fe80::xxxxxxxxxxxxxxxxxxxxxxxxxx
   IPv4 Address. . . . . . . . . . . : 192.168.1.10(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Thursday, September 13, 2018 19:02:19
   Lease Expires . . . . . . . . . . : Thursday, September 20, 2018 21:43:20
   Default Gateway . . . . . . . . . : fe80:xxxxxxxxxxxxxxxxxxxxxxxx
                                       192.168.1.1
   DHCP Server . . . . . . . . . . . : 192.168.1.1
   DHCPv6 IAID . . . . . . . . . . . : 10xxxxxxx
   DHCPv6 Client DUID. . . . . . . . : 00-01-xxxxxxxxxxxxxxxxxxxxx
   DNS Servers . . . . . . . . . . . : fe80::xxxxxxxxxxxxxxxxxxxxxx
                                       192.168.1.1
   NetBIOS over Tcpip. . . . . . . . : Enabled
   Connection-specific DNS Suffix Search List :
                                       home

Sosh mobile (via partage USB depuis smartphone Moto X Play) : https://www.nperf.com/r/351757559-28kdFNNA


Ipconfig, vu depuis le PC :

Code

Ethernet adapter Ethernet 2:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Remote NDIS based Internet Sharing Device
   Physical Address. . . . . . . . . : 02-6E-0F-XX-XX-XX
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::xxxxxxxxxxxxxxx
   IPv4 Address. . . . . . . . . . . : 192.168.42.17(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Wednesday, September 19, 2018 21:31:30
   Lease Expires . . . . . . . . . . : Wednesday, September 19, 2018 22:31:30
   Default Gateway . . . . . . . . . : 192.168.42.129
   DHCP Server . . . . . . . . . . . : 192.168.42.129
   DHCPv6 IAID . . . . . . . . . . . : 43xxxxxxx
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-xxxxxxxxxxxxxxxxxxxxx
   DNS Servers . . . . . . . . . . . : 192.168.42.129
   NetBIOS over Tcpip. . . . . . . . : Enabled

En tant qu'ancien technicien télécom, je confirme que les réseaux 4G sont nattés sur des classes A (10.x.x.x). Le téléphone a connaissance de l'adresse en 10.x.x.x car il est directement dessus. Via partage USB, le téléphone en mode modem faut aussi office de routeur et pose automatiquement un double nattage avec un classe C (192.168.x.x). Le PC ne peut avoir connaissance de l'adresse en 10.x.x.x que s'il effectue un trace route vers une adresse internet.
Le site web ( nperf, speedtest, ...) n'a connaissance que de l'adresse du point de sortie de l'opérateur et ne peut pas voir derrière : dans le cas présent 90.65.105.168.

De même le mode de réseau LTE, 3G, Fibre, Wifi, ... ne peut être déterminé que par l'application installée sur le téléphone (elle va chercher l'info dans le téléphone). Un site distant ne peut pas obtenir ces infos autrement. Il peut tout au mieux tenter de déduire un type de connexion depuis l'IP de sortie de l'opérateur.

La config de mon téléphone en 4G (on voit bien l'adressage réseau en 10.x.x.x):




Ce message a été modifié par kwak-kwak - 19 Sep 2018, 21:38.

[SartMatt]

Comme quoi Apple est encore capable d'audace : ça semblait être un pari fou de remplacer une puce ARM par une puce x86 : mais les résultats sont là.

Chut, tu vas donner des boutons à certains avec ce genre de remarques

cet ambiguïté de <speedtest (comme le fait qu'il me donne une connexion WiFi alors que je suis en LTE, certes routé en wifi au niveau local chez moi, mais qui n'avait strictement aucune raison d'être

Je répète : techniquement, il ne PEUT PAS déterminer le type de connexion qui se cache derrière le routeur auquel tu es connecté en Wi-Fi. Ni lui, ni aucun autre. Ce que confirme kwak-kwak juste au dessus. Ce n'est donc pas une ambiguïté. C'est juste une limitation technique, absolument pas spécifique à Speedtest.

nPerf ne reconnait pas non plus le type de connexion ("type de connexion: inconnu"... on peut difficilement faire plus clair !). Tout ce qu'il fait, c'est reconnaitre ton FAI, ce qui, dans le cas de Free, permet de voir si c'est du mobile (mais sans savoir si derrière c'est de la 2, 3 ou 4G) ou du fixe (sans savoir si c'est de l'ADSL, du VDSL ou de la Fibre) parce que le nom est différent, tandis qu'avec d'autres opérateurs la distinction est impossible. Cf là encore le message de kwak-kwak qui confirme ce que je disais hier soir, on voit bien sur ses deux captures nPerf qu'nPerf est incapable de distinguer la connexion fibre de la connexion mobile, parce qu'Orange a le même nom commercial exposé en fixe et en mobile (attention, à ne pas confondre avec le nom du réseau mobile, "Orange F", ce nom n'est visible que sur le smartphone/box 4G, pas sur un ordinateur connecté en Wi-Fi à une box 4G...).

Il n'y a donc que quand il est exécuté directement sur la machine dotée du modem (et via une appli native, pas au sein d'un navigateur) que Speedtest ou autre peut déterminer avec certitude qu'il s'agit d'une connexion mobile et la génération de connexion mobile utilisée (avec un smartphone en mode modem sur un ordinateur, il ne saura pas déterminer la génération, et il ne peut même pas être absolument certain que la connexion derrière est du cellulaire, un smartphone Android branché en USB partage sa connexion, quelle qu'elle soit, donc y compris si c'est une connexion Wi-Fi...).

Ce message a été modifié par SartMatt - 19 Sep 2018, 22:06.

[iAPX]

...

cet ambiguïté de <speedtest (comme le fait qu'il me donne une connexion WiFi alors que je suis en LTE, certes routé en wifi au niveau local chez moi, mais qui n'avait strictement aucune raison d'être

Je répète : techniquement, il ne PEUT PAS déterminer le type de connexion qui se cache derrière le routeur auquel tu es connecté en Wi-Fi. Ni lui, ni aucun autre. Ce que confirme kwak-kwak juste au dessus. Ce n'est donc pas une ambiguïté. C'est juste une limitation technique, absolument pas spécifique à Speedtest.
...

J'ai cru lire juste l'inverse dans le post de @kwak-kwak avec un mode d'emploi très simple et vérifiable, sans même aller jouer sur la reconnaissance du bousin qui fait le NAT ou idem sur le second NAT
On fait beaucoup de choses avec juste traceroute et ping, bien plus en faisant l'équivalent de ping à la main (détermination de fenêtre temporelle et/ou quantitative dans du tunneling avec bufferisation, repérer ainsi un WireGuard VPN en intermédiaire), etc.

Ce message a été modifié par iAPX - 20 Sep 2018, 03:27.

[406]

j'ai fait un test en avril avec mon iPhone X au moment ou je suis passé de free à orange. j'avais 269 Mbps en réception et 24 en envoi en 4G.
 debit_03.jpg ( 83.62 Ko ) Nombre de téléchargements : 10


Ce message a été modifié par 406 - 20 Sep 2018, 14:31.

[SartMatt]

...

cet ambiguïté de <speedtest (comme le fait qu'il me donne une connexion WiFi alors que je suis en LTE, certes routé en wifi au niveau local chez moi, mais qui n'avait strictement aucune raison d'être

Je répète : techniquement, il ne PEUT PAS déterminer le type de connexion qui se cache derrière le routeur auquel tu es connecté en Wi-Fi. Ni lui, ni aucun autre. Ce que confirme kwak-kwak juste au dessus. Ce n'est donc pas une ambiguïté. C'est juste une limitation technique, absolument pas spécifique à Speedtest.
...

J'ai cru lire juste l'inverse dans le post de @kwak-kwak avec un mode d'emploi très simple et vérifiable, sans même aller jouer sur la reconnaissance du bousin qui fait le NAT ou idem sur le second NAT On fait beaucoup de choses avec juste traceroute et ping, bien plus en faisant l'équivalent de ping à la main (détermination de fenêtre temporelle et/ou quantitative dans du tunneling avec bufferisation, repérer ainsi un WireGuard VPN en intermédiaire), etc.

Non. kwak-kwak dit bien, comme moi, que le type de connexion ne peut être détecté que par une application native directement sur l'appareil exploitant cette connexion, pas sur un appareil passant par du Wi-Fi :

De même le mode de réseau LTE, 3G, Fibre, Wifi, ... ne peut être déterminé que par l'application installée sur le téléphone (elle va chercher l'info dans le téléphone). Un site distant ne peut pas obtenir ces infos autrement. Il peut tout au mieux tenter de déduire un type de connexion depuis l'IP de sortie de l'opérateur.

ping et traceroute ne permettent pas non plus de déterminer le type de connexion. Comme le précise kwak-kwak, ça permet éventuellement de le deviner si on sait que l'une des IP par lesquelles on passe correspond à tel ou tel type de connexion. Mais ce n'est pas une détection "technique" du type de connexion, c'est juste une détection d'IP couplée à une connaissance préalable du type de connexion associée à une IP...

Et avec quelques limitations, par exemple une IP de Free Mobile, on sera quasi certain que c'est une connexion mobile (mais pas absolument certain... celui qui lance ça depuis une machine du réseau de Free Mobile peut tout a fait passer par une IP identifiée "Free Mobile" sans qu'il y ait le moindre segment "mobile" dans sa connexion), mais on ne pourra tout de même pas déterminer son type exact, on pourra juste le déduire des performances... Une connexion mobile à plus de 100 Mbits/s, on saura dire que c'est de la 4G. Une connexion Orange fixe à plus de 100 Mbit/s, on saura dire que c'est de la fibre...

Mais ce n'est en aucun cas une détection technique de la nature de la connexion, c'est juste de la supposition d'après l'ensemble des informations dont on dispose (ie les différentes IP de la route et les performances). "tenter de déduire" n'est pas "détecter".


Ce message a été modifié par SartMatt - 20 Sep 2018, 08:40.

[teac68]

Merci, toute ambiguïté est levé pour moi : tu es bien en 4G+ (LTE-A) - >ce que ne precise pas du tout Speedtest, et pourtant c'est primordial comme info.

Maintenant, avec une nuit de recul et d'analyse comparative Ookla Speedtest/nPerf,j'espere que vous comprendrez mieux ce que je disais hier au sujet de cet ambiguïté de <speedtest (comme le fait qu'il me donne une connexion WiFi alors que je suis en LTE, certes routé en wifi au niveau local chez moi, mais qui n'avait strictement aucune raison d'être

Tout ça pour ça ??
Au final nPerf et Speedtest disent la même chose en terme de débit (ce que j'ai constaté là où je me trouve), mesures qui restent indicatives.
Speedtest précise bien si l'on est sur LTE ou Wifi : les débits mesurés sont ceux de la "ligne" box ou tél en direct.
La seule chose "dérangeante" c'était cette petite icône wifi sur la capture ... qui n'avait aucune incidence.

[iAPX]

...
Mais ce n'est en aucun cas une détection technique de la nature de la connexion, c'est juste de la supposition d'après l'ensemble des informations dont on dispose (ie les différentes IP de la route et les performances). "tenter de déduire" n'est pas "détecter".

Rien n'étant certain en ce bas-monde, on ne peut donc jamais "détecter" alors

Quand à savoir détecter par quoi du traffic TCP/IP passe, au moins avant d'être noyé dans le bruit, c'est faisable et fait depuis longtemps chaque stack ip et type de connexion ayant sa signature propre, pour ça qu'on peut détecter un passage par un VPN et même mieux son type, un saut via du cellulaire, ou de l'analyse de paquet in-depth là aussi quand on est pas noyé par le bruit ambiant d'Internet (qui nécessite juste plus de temps pour avoir une analyse statistique probante).

Mais cette application ne fait probablement pas cela.

[_Panta]

Merci, toute ambiguïté est levé pour moi : tu es bien en 4G+ (LTE-A) - >ce que ne precise pas du tout Speedtest, et pourtant c'est primordial comme info.

Maintenant, avec une nuit de recul et d'analyse comparative Ookla Speedtest/nPerf,j'espere que vous comprendrez mieux ce que je disais hier au sujet de cet ambiguïté de <speedtest (comme le fait qu'il me donne une connexion WiFi alors que je suis en LTE, certes routé en wifi au niveau local chez moi, mais qui n'avait strictement aucune raison d'être

Tout ça pour ça ??
Au final nPerf et Speedtest disent la même chose en terme de débi

Si tu avais suivi, tu aurais vu que c'est pas le débit qui m'importais, mais la nature de ce débit, qui n'est pas clair sur Speedtest ...

[teac68]

Si tu avais suivi, tu aurais vu que c'est pas le débit qui m'importais, mais la nature de ce débit, qui n'est pas clair sur Speedtest ...

J'ai suivi dés le départ, en amont de ta 1ère intervention j'avais déjà donné des éléments qui démontraient l'origine du débit mesuré.
Sartmatt t'avais aussi répondu en image : mais comme le débit te semblait surréaliste, il ne pouvait provenir que d'une box ...

Une simple installation de l'appli sur ton propre tél, un petit test rapide avec comparo de ce donne nPerf et hop doutes dissipés de suite.
La petite bête était nulle part et tu ne l'as pas trouvée ... c'tout.

Ce message a été modifié par teac68 - 21 Sep 2018, 08:59.

[Ambroise]

Comme quoi Apple est encore capable d'audace : ça semblait être un pari fou de remplacer une puce ARM par une puce x86 : mais les résultats sont là.

Chut, tu vas donner des boutons à certains avec ce genre de remarques

C'est vrai que ça va être difficile maintenant d'affirmer que la puce T2 démontre que les mac ne sont plus qu'à 25 minutes de se passer de x86.

[maaah]

Maintenant, avec une nuit de recul et d'analyse comparative Ookla Speedtest/nPerf,j'espere que vous comprendrez mieux ce que je disais hier au sujet de cet ambiguïté de <speedtest

Pas le moins du monde.
Le speedtest disait qu'il était en LTE et il était en ... LTE. 3 pages de débat pour rien non?

(comme le fait qu'il me donne une connexion WiFi alors que je suis en LTE, certes routé en wifi au niveau local chez moi, mais qui n'avait strictement aucune raison d'être

C'est discutable. Tu était bien en wifi, même s'il y avait un téléphone encore derrière, mais ça l'outil quel qu'il soit ne peut pas le savoir.
Dans les même conditions nperf dit "inconnu", ok, on est pas plus avancé mais pourquoi pas.

En tous cas bravo pour ta patience Matt, je sais pas comment tu fais.

[kwak-kwak]

...

cet ambiguïté de <speedtest (comme le fait qu'il me donne une connexion WiFi alors que je suis en LTE, certes routé en wifi au niveau local chez moi, mais qui n'avait strictement aucune raison d'être

Je répète : techniquement, il ne PEUT PAS déterminer le type de connexion qui se cache derrière le routeur auquel tu es connecté en Wi-Fi. Ni lui, ni aucun autre. Ce que confirme kwak-kwak juste au dessus. Ce n'est donc pas une ambiguïté. C'est juste une limitation technique, absolument pas spécifique à Speedtest.
...

J'ai cru lire juste l'inverse dans le post de @kwak-kwak avec un mode d'emploi très simple et vérifiable, sans même aller jouer sur la reconnaissance du bousin qui fait le NAT ou idem sur le second NAT
On fait beaucoup de choses avec juste traceroute et ping, bien plus en faisant l'équivalent de ping à la main (détermination de fenêtre temporelle et/ou quantitative dans du tunneling avec bufferisation, repérer ainsi un WireGuard VPN en intermédiaire), etc.

Je confirme les propos de SartMatt, seul l'hôte peut vendre la mèche sur le type de connexion utilisé par ce dernier. Le site distant n'en a aucune idée, tout au mieux il peut tenter de faire une déduction via l'IP de sortie de l'opérateur. Le nattage casse toute possibilité de traçage par le site web. Sur mes captures d'écran, les tests étant fait avec le navigateur web de mon PC (et non l'appli du téléphone), nPerf n'a aucun moyen de déterminer le type de connexion "finale" (le navigateur web ne dévoilant pas ces éléments).
Le traceroute ne donne que le nom et l'adresse IP des routeurs, pas la norme utilisé pour le transfert des données.


D'ailleurs le transit avec l'usage du téléphone en mode modem peut très bien être : PC -> USB -> téléphone -> connexion mobile 2G/3G ou 4G -> Antenne relais -> Lien FH -> Lien cuivre agrégé SDSL 4x2Mb/s -> DSLAM -> Fibre -> backbone de l'opérateur -> Internet. (En 4G, chez Orange, la quasi intégralité des baies LTE est directement fibrée et sur les nouveaux déploiements, la baie 4G (la partie logique) est même virtualisée en data center, le site n'accueillant plus que les antennes connectées au data-center via un lien fibré). De fait le "type de connexion" a peu de sens du point de vue du site web, car le transit peut se faire par bien des mediums.

Ce message a été modifié par kwak-kwak - 21 Sep 2018, 03:08.

[SartMatt]

D'ailleurs le transit avec l'usage du téléphone en mode modem peut très bien être : PC -> USB -> téléphone -> connexion mobile 2G/3G ou 4G -> Antenne relais -> Lien FH -> Lien cuivre agrégé SDSL 4x2Mb/s -> DSLAM -> Fibre -> backbone de l'opérateur -> Internet. (En 4G, chez Orange, la quasi intégralité des baies LTE est directement fibrée et sur les nouveaux déploiements, la baie 4G (la partie logique) est même virtualisée en data center, le site n'accueillant plus que les antennes connectées au data-center via un lien fibré). De fait le "type de connexion" a peu de sens du point de vue du site web, car le transit peut se faire par bien des mediums.

Et vu qu'un smartphone en USB partage sa connexion Internet quelle qu'elle soit, donc y compris si c'est via Wi-Fi, on peut même avoir un truc comme ça : PC -> USB -> téléphone -> box fibre -> backbone de l'opérateur -> Internet

Une application native pourrait alors détecter que la connexion passe par un téléphone mobile alors que dans les faits, il n'y a pas l'ombre du moindre paquet transitant sur le réseau mobile.

[Lafaboune]

Une question concernant le ping chez Orange en fibre, kwak-kwak & SartMatt, je suis tout ouï.

D'où le ping à 3ms, qui est le ping normal d'une connexion fibre (et qui confirme que les 21ms de Ritchi, c'est pas de la fibre...).

et :

* ping : 21ms. C'est crédible pour du LTE. Peu crédible pour de la fibre, surtout pas avec un serveur de test hébergé par l'opérateur. En fibre on devrait avoir tout au plus 5ms.

Comme le fiston de Panda, mon ping Fibre Orange est autour des 20 ms (je n'ai pas le souvenir d'avoir eu beaucoup plus que 20 ms, encore moins dans les 40 ms).

Egalement, même si je suis tout à fait d'accord que des pings de 21ms c'est pourri en fibre, il s'avère que je viens de d'installer la fibre ce soir, c'est pour ça que j'étais pas chez moi, dans le nouvel appartement de mon fils ainé, et que j'ai été très surpris des pings de merde (et des débit moisi) qu'il a, 37ms par moment, alors les 21ms du gars, rien d'étonnant non plus, avec Orange :

Quelle(s) pourrai(en)t en être les raisons ?
Pour être honnête, je ne vois pas, en utilisation, de différence avec la connexion xDSL que j'avais avant, peut-être parce que je ne joue pas aux FPS en ligne.

[SartMatt]

Comme le fiston de Panda, mon ping Fibre Orange est autour des 20 ms (je n'ai pas le souvenir d'avoir eu beaucoup plus que 20 ms, encore moins dans les 40 ms).
Quelle(s) pourrai(en)t en être les raisons ?

Ping vers où ? Si c'est un serveur hébergé chez Orange, et proche géographiquement ça me parait pas normal que ça soit aussi lent. À voir si c'est récurrent ou juste passager.

Si c'est vers un serveur hébergé en dehors d'Orange ou éloigné géographiquement, ça n'a rien d'anormal. Il faut ajouter environ 1ms de ping supplémentaire tous les 100 km parcourus (200 000 km/s et le ping mesure un temps aller-retour), sans compter les latences supplémentaires induites par les équipements actifs traversés (routeurs, répéteurs...), d'autant plus nombreux que la distance est grande. Sachant que même un serveur proche géographiquement, il peut être éloigné d'un point de vue réseau. Si par exemple tu es à Marseille et que tu ping un serveur situé chez ton voisin, mais sur un réseau d'un opérateur dont l'interconnexion la plus proche avec ton opérateur est à Paris (peu probable en pratique ^^), ce serveur est d'un point de vue réseau à plus de 1500km de chez toi, avec une latence de plus de 15ms rien qu'à cause du temps de propagation.

Dans mon cas et dans celui de Ritchi, le ping était fait vers un serveur proche et au sein du réseau d'Orange. Lui avec un serveur à Paris pingé depuis la banlieue parisienne, moi avec un serveur à Lyon pingé depuis Grenoble.

Si je ping un serveur plus éloigné, ça monte. Par exemple avec le serveur qui gère orange.fr, probablement situé en région parisienne, j'atteins 11ms. google.fr, situé en dehors du réseau d'Orange, mais avec sans doute une excellente interconnexion, ça monte à 14. qwant.fr, en dehors d'Orange et avec une interconnexion moins bonne, 22ms. whitehouse.gov, il faut traverser l'Atlantique, paf, 81ms. Et ucs.edu, ça monte à 154ms, parce qu'en plus de l'Atlantique, il faut probablement traverser les USA vu que les grosses universités hébergent souvent elles mêmes leurs sites (j'ai la flemme de chercher les IP dans une base de géoloc, mais je vois que le segment sur lequel le délai est le plus long, avec 138ms à lui tout seul, ça part d'un routeur dont le nom contient "paris1" et ça arrive à un routeur "phx1-ar3", donc probablement Phoenix dans l'Arizona).

Pour être honnête, je ne vois pas, en utilisation, de différence avec la connexion xDSL que j'avais avant, peut-être parce que je ne joue pas aux FPS en ligne.

C'est normal, une bonne liaison ADSL, ça ne fait qu'une quinzaine de ms de plus qu'une fibre.

[kwak-kwak]

Une question concernant le ping chez Orange en fibre, kwak-kwak & SartMatt, je suis tout ouï.

D'où le ping à 3ms, qui est le ping normal d'une connexion fibre (et qui confirme que les 21ms de Ritchi, c'est pas de la fibre...).

et :

* ping : 21ms. C'est crédible pour du LTE. Peu crédible pour de la fibre, surtout pas avec un serveur de test hébergé par l'opérateur. En fibre on devrait avoir tout au plus 5ms.

Comme le fiston de Panda, mon ping Fibre Orange est autour des 20 ms (je n'ai pas le souvenir d'avoir eu beaucoup plus que 20 ms, encore moins dans les 40 ms).

Egalement, même si je suis tout à fait d'accord que des pings de 21ms c'est pourri en fibre, il s'avère que je viens de d'installer la fibre ce soir, c'est pour ça que j'étais pas chez moi, dans le nouvel appartement de mon fils ainé, et que j'ai été très surpris des pings de merde (et des débit moisi) qu'il a, 37ms par moment, alors les 21ms du gars, rien d'étonnant non plus, avec Orange :

Quelle(s) pourrai(en)t en être les raisons ?
Pour être honnête, je ne vois pas, en utilisation, de différence avec la connexion xDSL que j'avais avant, peut-être parce que je ne joue pas aux FPS en ligne.

- Le test de débit (abusivement appelé bande passante), mesure le débit du point le plus lent entre ton appareil et le site web, sur l'ensemble de la liaison. Si le site web sature, il y a de forte chance que ce soit lui le plus lent. Chez moi, le plus lent est bien souvent la connexion wifi de mes appareils qui culmine à 110 Mb/s pour mon tel portable et 100Mb/s pour mon ordinateur portable. (Mon PC fixe est câblé en Gigabit (1000BASE-T ))

- Le ping fait l'addition de toutes les lenteurs sur l'ensemble de la liaison : Tu peux avoir
* Un PC avec un driver réseau merdique
* Un PC verrolé (les cas les plus courant sont avec Cacaoweb qui détourne ta connexion sur un proxy, ou avec un client P2P sans limite sur l'upload : les joies du piratage de films quand on ne comprend rien à la technologie )
* Un routeur qui déconne (chez toi, ou ailleurs sur la liaison)
* Une liaison wifi avec de la perte de paquet (dans un environnement perturbé par d'autres réseaux wifi par exemple, ce qui oblige à réémettre les paquets)
* Un point sur la liaison qui sature
* Ou même le serveur de test qui sature.

=> Si ton ordinateur est en connexion wifi "rapide" de type 802.11 ac il me semble que le routeur attend de remplir une pile avant d'envoyer un burst de données (à vérifier). Si tu émets peu, ou des petits paquets, le routeur ne pouvant remplir la pile, un peu de ping peut être généré le temps que le routeur se décide à tout de même envoyer le paquet. Le problème s'aggrave sur les liaisons multi-canals. Le wifi est par exemple très mal aimé des gamers pour bien des raisons...

=> Un test de liaison doit se faire en priorité via un bon vieux câble ethernet et sans équipement intermédiaire, ce qui sur un MacBook récent est assez difficile à faire

PS: S'il y a des gens qui ont leur abonnement internet chez SFR / Red / La Poste ou parfois chez Bouygues, ils disposent peut-être aussi de la "fausse fibre" : le FTTLA, ou en terme moins savant : le bon vieux câble. Les débits sont bien moins bon que la fibre et le réseau est sujet à la saturation.

Ce message a été modifié par kwak-kwak - 24 Sep 2018, 15:54.

[_Panta]

....

Ce message a été modifié par _Panta - 22 Sep 2018, 00:35.

[Lafaboune]

Dans mon cas et dans celui de Ritchi, le ping était fait vers un serveur proche et au sein du réseau d'Orange.

C'est le cas, la valeur donnée était celle du test sur serveur Orange le plus proche.

=> Un test de liaison doit se faire en priorité via un bon vieux câble ethernet et sans équipement intermédiaire

C'est le cas aussi, je n'utilise jamais le Wifi sur Desktop, ni Bluetooth, d'ailleurs

Merci pour vos réponses.