La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => 
K-Net => Opérateurs grand public alternatifs => Espace technique internet K-Net => Discussion démarrée par: kidalex93 le 20 janvier 2019 à 18:01:55
-
Salut a tous, ce soir je me dit je fais un test et la je suis a max 100 Mega, alors que mon installation a pas bouger depuis hier, hier j'etait bien a 940 mais aujourd'hui poufff
(https://www.speedtest.net/result/7972979615.png) (https://www.speedtest.net/result/7972979615)
-
Je viens de regarder sur votre panel kbox et tous les éléments connectés semblent être en 100mbs
-
oui c'est mon cable qui est pourrie je vient de le changer et la
(https://www.speedtest.net/result/7973001350.png) (https://www.speedtest.net/result/7973001350)
en tous cas merci Damien.
-
Ah la différence flagrante !
-
Vous avez vu qu'un gros warning est désormais visible devant chaque équipement LAN sur le panel kbox si la connexion n'est pas en gbs ?
-
non j'ai pas vu ca, je regarde
-
pas mal je sais que tout mes équipement a part mon pc portable supporte le Gigabite.
-
L'idéal, cela serait que le test de débit puisse avoir l'information de la box...
Peut-être dans quelques années...
=> https://www.arcep.fr/actualites/les-communiques-de-presse/detail/n/regulation-par-la-data-3.html
Développement d'une API " carte d'identité de l'accès " : coup d'envoi début 2019
La mesure de la qualité de service est particulièrement complexe sur les réseaux fixes : il est à ce jour impossible techniquement pour un outil web de connaître avec certitude la technologie d'accès (cuivre, câble, fibre, etc.) sur laquelle a été réalisé un test. Ce manque de caractérisation de la mesure rend les données difficilement exploitables, voire, dans certains cas, induit en erreur le consommateur.
L'Arcep a lancé en début d'année 2018 un vaste chantier sollicitant toutes les parties prenantes afin de résoudre ce problème majeur. L'écosystème a convergé vers la mise en place d'une Application Programming Interface (API) implèmentée directement dans la box des opérateurs et accessible aux outils qui respectent le Code de conduite. Cette interface permettra de transmettre les informations qui constituent la " carte d'identité de l'accès ", telles que la technologie d'accès, mais aussi le débit souscrit par le consommateur, la qualité du Wi-Fi, etc, et ce dans le plein respect de la vie privée. Les contributions des différents acteurs ont permis de faire èmerger les spécifications détaillées du fonctionnement de cette API.
Courant janvier, l'Arcep réunira les parties prenantes dans un comité de suivi du développement de l'API et publiera l'ensemble de ces spécifications.
-
Donc en gros ont pourra voir le débit comme dans le cuivre a combien ont syncronise ? Car c'est vrai qu'avec la fibre a part avoir un bon pc et les bon câble pour faire le test, c'est le seul moyens de connaître son debit.
-
Cela permettrait d'avoir de nombreux indicateurs :
Coté WAN :
- Débit souscrit en FTTH
- Débit de synchronisation en xDSL
- Débit entre la box et l'ONT (si le cable est mauvais entre la box et l'ONT tout est limité à 100 Mb/s)
- Savoir si le test de débit a été réalisé alors qu'une autre personne utilise Internet sur la box
Coté LAN :
- Technologie utilisé (Ethernet, WiFi, CPL, autre)
- Débit de la technologie
- d'autres informations en Wi-Fi
-
Ce serait assez chouette ça Vivien. Mais de l'autre côté, il faudrait aussi quelque chose pour connaître la fiabilité d'un serveur speedtest. Car eux aussi ont un impact sur le test final et certaines fois un gros impact (jeudi vers un serveur particulier, plusieurs tests autour de 650/700mbs alors que j'avais du 950mbs avec d'autres)
-
Pour ça il y a le "Code de conduite de la qualité de service internet"
La version 2018 est là https://www.arcep.fr/uploads/tx_gspublication/code-de-conduite-qs-internet-2018_FR.pdf
La version 2019 promet d'aller plus loin : "En 2019, la démarche de co-construction se poursuivra pour alimenter la prochaine version du Code de conduite, aux exigences affinées ou renforcées, afin d'accompagner progressivement la montée en compétence de l'écosystème."
-
Donc si je comprends bien, un des objectifs de l'ARCEP à moyen terme est de rendre bien + fiables toutes les mesures de qualité, que ce soit du côté de l'abonné (détails sur box/abo) et ce code de conduite ?
(peut-être déplacer tout ça dans un autre topic ?)
-
Pouvoir faire un nperf (ou mieux une techno propriétaire, directement entre la k-box et l'infra k-net) directement sur le kbox serait bien .., la kbox indiquant déjà si elle est reliée en 1gbps au media converter. Ca serait déjà un bon indicateur pour savoir si le soucis vient coté client ou pas. Et ça évité de cherchez le soucis au mauvais endroit.
-
Pas possible, une box opérateur n'a pas le CPU pour faire un speedtest a 1Gbit/s.
-
On en parle dans un autre sujet :
Les chips des box savent router à 1 Gb/s grâce a des accélérateurs : le premier paquet de chaque connexion TCP passe par le CPU, mais pas les paquets suivants.
Même chose pour la VoIP où il y a des accélérateurs.
En conséquence le processeur est très faible et si c'est lui qui est l’origine / destination du trafic, ce qui est le cas pour un test local, il y a une limitation aux alentour de 200 à 300 Mb/s pour les chips récent qui font du 1 Gb/s.
La Freebox révolution et la Freebox 4k (c'est la même box coté IAD) et la Freebox Delta est équipé d'un second CPU de NAS qui lui sait gérer un test local à haut débit.
La Freebox v5 / Cristal n'a qu'un seul processeur.
Je ne sais pas le choix qui a été fait pour la Freebox One.
Voici la réponse du chef de projet de CPE FTTH Sagem le 31 juillet 2006 :
Explication des performances non satisfaisantes vues sur un téléchargement HTTP.
Fonctionnement des Accélérateurs:
Lorsque l'utilisateur lance un téléchargement TCP/UDP, les premiers paquets qui sont responsables de l'établissement de la connexion passent par le CPU(chemin classique :NAT/FIREWALL/policies...), une fois le lien est établie tous les prochains paquets passeront par les accélérateurs (chemin rapide). Les accélérateurs n'analyse que l'entête TCP/IP du paquet et pas son contenue.
Cas d'un transfert de texte par MSN MESSENGER:
Lorsque un client utilise MSN MESSENGER pour chatter se dernier se connecte sur le port 1863/TCP à un serveur de chez Microsoft. dans ce cas le Nat est traversé proprement et le message retour est bien identifié par le Firewall du F@st3374.
Cas d'un transfert de vidéo par MSN MESSENGER :
Les problèmes arrivent lorsque le client demande une connexion vocale/video. Dans ce cas, MSN MESSENGER va demander au serveur de choisir un autre port pour faire passer le flux vidéo. Et le problème c'est que ce port est choisie au hasard entre le port TCP/9000 et TCP/65535. Pour que le flux
vidéo provenant du serveur soit identifier par le firewall du F@st3374 et qu'il soit forwardé correctement, tous les paquets msn( TCP et destPort/srcPort = 1863) passeront par une fonction de traitement supplèmentaire qui permet d'analyser les contenues des paquets en plus de leurs entêtes TCP/IP.
Dans ce cas le flux vidéo passera par les accélérateurs(chemin rapide) mais tous les paquets msn(TCP-port =1863) passeront par le CPU(chemin classique).
Cas du port 80:
Si pour une raison ou pour une autre le MSN MESSENGER n'arrive pas à se connecter au serveur Microsoft sur le port 1863 alors il retombe sur le port 80 en faisant du HTTP tunneling. Affin de supporter ce cas bien particulier le F@st3374 fait passer touts les paquets HTTP(port 80) par le même chemin par lequel passe les paquets msn (port 1863).
Solution immédiate :
Ne supporter que le chat en mode texte dans le cas où le client MSN MESSENGER fait du backup sur le port 80. Et si dans ce cas particulier l'utilisateur veut faire du Chat en mode vidéo il doit installer UPNP sur son poste qui va s'en charger de communiquer avec le Firewall du F@st3374 pour ouvrir les bons ports.
Je reste à votre disposition pour tout éclaircissement supplèmentaire.
Cordialement.
A noter que le même phénomène est utilisé sur le port 21 pour le FTP.
Note : Les box équipées de Watchdog reboot lors d'un transfert HTTP à 20 Mb/s ou plus, le CPU étant utilisé à 100%, le watchdog est là pour rétablir la situation via un reboot