Auteur Sujet: Bouygues lance sa Bbox ultym XGS-PON à 8 Gbit/s (Lu 54927 fois)

hwti · « **Réponse #192 le:** 09 août 2023 à 13:46:23 »

Citation de: Myck205 le 09 août 2023 à 13:30:20

Pour le coup, ça semble être la même avec bouygue (la box en moins).

Pour l'instant il n'y a aucun soucis de clairement identifié, à part certains serveurs de test de débit.

Comme chez Free et SFR, les 8Gbps vendus sont proches des 100% de ce qui est possible sur l'arbre, donc le débit maximum dépend de l'activité des autres utilisateurs.
Mais l'offre vient d'être lancée, donc l'arbre XGS-PON ne doit pas être très rempli.

On ne sait pas quel modèle d'OLT est utilisé (Bouygues a du Huawei et Nokia/Alcatel), donc pour les limitations communes à tous les arbres on ne peut que faire des suppositions :
- s'il a un seul port 10Gbps (pour l'ensemble GPON et XGS-PON) : risque important de saturation
- s'il a plusieurs ports 10Gbps, tout dépend du type d'agrégation : ça pourrait saturer si le trafic d'un abonné passe toujours par le même port, ou éventuellement saturer sur une connexion si c'est réparti en fonction des IP/ports
- s'il a au moins un port >10Gbps, il ne devrait pas y avoir de saturation
Bien sûr, il faut dans tous les cas que la collecte suive, et les différents peerings ou transits si le serveur est sur un autre réseau.

Myck205 · « **Réponse #193 le:** 09 août 2023 à 14:25:58 »

Citation de: hwti le 09 août 2023 à 13:46:23

Pour l'instant il n'y a aucun soucis de clairement identifié, à part certains serveurs de test de débit.

Comme chez Free et SFR, les 8Gbps vendus sont proches des 100% de ce qui est possible sur l'arbre, donc le débit maximum dépend de l'activité des autres utilisateurs.
Mais l'offre vient d'être lancée, donc l'arbre XGS-PON ne doit pas être très rempli.

On ne sait pas quel modèle d'OLT est utilisé (Bouygues a du Huawei et Nokia/Alcatel), donc pour les limitations communes à tous les arbres on ne peut que faire des suppositions :
- s'il a un seul port 10Gbps (pour l'ensemble GPON et XGS-PON) : risque important de saturation
- s'il a plusieurs ports 10Gbps, tout dépend du type d'agrégation : ça pourrait saturer si le trafic d'un abonné passe toujours par le même port, ou éventuellement saturer sur une connexion si c'est réparti en fonction des IP/ports
- s'il a au moins un port >10Gbps, il ne devrait pas y avoir de saturation
Bien sûr, il faut dans tous les cas que la collecte suive, et les différents peerings ou transits si le serveur est sur un autre réseau.

OK, donc ça sera encore plus variable dans le futur.

C'est que du Huawei chez bouygue (c'est le moins cher), Alcatel j'ai vu chez SFR (en plus d'alticelab).

hwti · « **Réponse #194 le:** 09 août 2023 à 20:43:46 »

Citation de: Myck205 le 09 août 2023 à 14:25:58

C'est que du Huawei chez bouygue (c'est le moins cher), Alcatel j'ai vu chez SFR (en plus d'alticelab).

Tout indique qu'ils ont toujours des OLT Alcatel en plus des Huawei, et en 2018 Vivien disait qu'il s'agissait des plus anciens, en ZTD (donc potentiellement ceux de Paris, à moins qu'ils aient été remplacés) :

Citation de: vivien le 27 octobre 2018 à 19:21:58

A noter que Bouygues Telecom a des OLT Alcatel en ZTD et des OLT Huawei en ZMD.

Ce n'est pas lié la zone mais au fait que Bouygues a déployé au début des NRO uniquement en ZTD puis depuis 2 ans ne déploie plus que des nouveau NRO en ZMD et qu'entre temps le fournisseur à changé.

Citation de: Mackila le 09 août 2022 à 14:42:39

Je suis sur un OLT Alcatel (enfin c'est ce que disait la BBox avant de retourner dans son carton).

Citation de: Florian le 15 octobre 2022 à 11:15:57

Je suis un olt alcatel, même comportement (routeur mikrotik, ont alcatel).

Pegasus38 · « **Réponse #195 le:** 09 août 2023 à 22:52:04 »

Citation de: Rom 1 le 09 août 2023 à 13:44:01

C'est un peu ce qu'on constate en quittant Free pour un autre opérateur. Malgré les débits annoncés, on ressent des lenteurs au niveau du surf et d'accès aux services du web. Quand on regarde plus en détail, on remarque des pertes de paquets mais aussi des saturations vers certains services, dues la plupart du temps non à des saturations locales et des problèmes d'infrastructures en aval comme cela peut arriver en fonction du succès de l'opérateur et/ou d'un manque de dimansionnement, mais en amont entre le réseau de Free et l'ensemble du web à savoir les liens de peering et de transit. YouTube et Netflix en étaient les exemples criants et ce problème est loin d'être réglé pour l'ensemble des services.

Pour ma part la navigation web était bien mieux chez Free que chez Bouygues, le jour et la nuit. En revanche depuis que je suis chez Sosh, il y a même pas débat entre les 3 opérateurs, et de loin.

Vous savez si SFR sature sur Paris centre ? J'essai de comprendre qui a investi le plus d'argent sur les infra à Paris.

Antoinel · « **Réponse #196 le:** 09 août 2023 à 23:27:06 »

Les chiffres et rapport de nperf ne te donnent pas raison sur l'internet fixe.

Orange / Sosh ne sont pas 1er depuis un certain moment. Free était sur la première place du podium pendant longtemps jusqu'au mois dernier où ils se sont fait voler la première place par Bouygues.

Tous les détails : https://media.nperf.com/files/publications/FR/2023-07-19_Barometre-connexions-fixes-metropole-nPerf-S1-2023.pdf

Citer

C’est effectivement Bouygues Telecom qui, au global, affiche les évolutions nettes les plus
importantes depuis 2021, toute catégorie confondue. On peut constater aussi bien en Haut Débit
et Très Haut Débit, qu’il enregistre les meilleures progressions.

L’avance de Free sur le débit descendant est en train de fondre et Bouygues Telecom parvient
même à prendre le lead sur le dernier mois en proposant en moyenne à ses clients très haut débit,
un débit descendant approchant les 400 Mb/s.

Pegasus38 · « **Réponse #197 le:** 09 août 2023 à 23:31:48 »

Ces résultats sont vraiment à prendre avec des pincettes... tout le monde sait que c'est orange le numero 1 en qualité de service. La différence se joue au niveau de la box et du matériel des gens

Antoinel · « **Réponse #198 le:** 09 août 2023 à 23:43:03 »

Ces résultats sont obtenus avec un protocole agrée par l'arcep et sont repris par Free et les FAI. Par exemple, pour Free Fixe en 2022, https://iliad-strapi.s3.fr-par.scw.cloud/CP_200123_91e3fc9e6e.pdf

Rom 1 · « **Réponse #199 le:** 10 août 2023 à 00:51:47 »

Citation de: Pegasus38 le 09 août 2023 à 22:52:04

Pour ma part la navigation web était bien mieux chez Free que chez Bouygues, le jour et la nuit. En revanche depuis que je suis chez Sosh, il y a même pas débat entre les 3 opérateurs, et de loin.

Vous savez si SFR sature sur Paris centre ? J'essai de comprendre qui a investi le plus d'argent sur les infra à Paris.

Un problème particulier ou une saturation locale ne permet pas de savoir le niveau de qualité des infrastructures global d'un opérateur. Pour ça qu'on tente de dresser une appréciation générale à partir d'un grand échantillon et pas juste quelques cas. Sinon, pour prendre le mobile par exemple, on pourrait sélectionner des zones où Orange n'est pas très bon et en conclure que c'est représentatif, ce qui n'est pas le cas.

kgersen · « **Réponse #200 le:** 10 août 2023 à 08:05:33 »

Citation de: Antoinel le 09 août 2023 à 23:43:03

Ces résultats sont obtenus avec un protocole agrée par l'arcep et sont repris par Free et les FAI. Par exemple, pour Free Fixe en 2022, https://iliad-strapi.s3.fr-par.scw.cloud/CP_200123_91e3fc9e6e.pdf

le probleme est qu'il y a une dépendance financière entre ceux qui mesurent et ceux qui sont mesuré et pire maintenant avec l'api box ceux qui sont mesuré sont maintenant prévenu en temps réel qu'une mesure a lieu...
Il n'y a pas de protocole agrée sur la mesure elle-meme. On ne sait pas de facon scientifique comment les mesures sont faites. NPerf parle de "Le speed test repose sur un algorithme unique permettant de mesurer précisément les débits descendant et montant ainsi que la latence de votre connexion."
Il n'y a pas d'algorithme standardisé, reproductible par qui veut, open source et définie par l'arcep ou autre et agrée par tout le monde. Ce qui est défini et agrée c'est l'api box qui permet d'informer le FAI qu'une mesure a lieu et fournir des meta data.
D'ailleurs tout le problème est la, les FAI ne devraient pas à avoir leur mot a dire dans ces histoires de mesure de débit , il n'y a pas besoin d'avoir leur agréement. Ils ne devraient pas savoir qui mesure et comment.
Mais la c'est eux qui financent et eux qui imposent un accès contrôlé aux metadata des box sous des prétextes fallacieux (vie privée, sécurité et autre bullshit que les gens avalent parce qu'ils n'ont pas les compétences pour comprendre exactement de quoi il s'agit ou qu'ils ne font pas l'effort de creuser plus le sujet).
Il n'ya pas d'accès public aux données bruts collectées (anonymisées), elle ne sont pas en open data. Pas d'info sur les serveurs, leur charge pendent une mesure, pas d'info sur le traitement et l'épuration des données, etc rien absolument rien n'est défini et standardisé.

Un peu comme le label "élu produit de l'année" c'est donc avant tout du marketing. Mais pire car l'ARCEP a apposé son sceau dessus.
Pour moi citer le rapport nperf (et d'autres) c'est se moquer des utilisateurs.

Pegasus38 · « **Réponse #201 le:** 10 août 2023 à 08:31:45 »

Complétement d'accord, il faudrait que chacun ait la même box, la même offre, et le même ordinateur. Sans parler de la latence.

Quelqu'un avait déjà subit des saturations chez Bouygues à Paris avec l'offre 2Gb ou moins ? On m'a toujours dit que Bouygues ne saturait pas, hormis quelques fois sur les rips.

Myck205 · « **Réponse #202 le:** 10 août 2023 à 08:43:05 »

Citation de: Pegasus38 le 09 août 2023 à 22:52:04

Pour ma part la navigation web était bien mieux chez Free que chez Bouygues, le jour et la nuit. En revanche depuis que je suis chez Sosh, il y a même pas débat entre les 3 opérateurs, et de loin.

Vous savez si SFR sature sur Paris centre ? J'essai de comprendre qui a investi le plus d'argent sur les infra à Paris.

Quelqu'un du forum y avait souscris, c'était très variable. C'était en zmd il le semble.

kgersen · « **Réponse #203 le:** 10 août 2023 à 10:20:26 »

coupure réparée. Il s'avère que la jarretière dans le PMI pour ma fibre a été "pincé" par l'espece de trappe/porte au niveau du boitier FAI Free (module opérateur). Le boitier Bytel étant au dessus de tout les autres toutes les fibres Bytel doivent traverser les autres boitiers (Free, SFR) et Orange est l'OI.
L'intervention a juste consisté a remplacer cette fibre et a la positionner mieux de façon que les futurs intervenants ne la coincent pas en refermant les portes des différents modules...

Ca ressemble a cela mais avec tout plein de fibres:

arrivé des logements en bas, boitier Bytel tout en haut , ma fibre a été 'pincé' par la porte Free.

Apres ce n'est pas forcement un technicien Free qui a pincé la fibre. Tout les techs peuvent ouvrir toutes les portes suivant l'intervention qu'ils ont à faire.
Et ce n'est pas forcement "volontaire" juste du travail mal fait.
Et y'a tellement de fibres entassées que la porte du module du bas par exemple ne ferme pas complétement ...(probleme de "cable management" ou de sous-dimensionnement des boitiers?)

Ce qui n'excuse pas l'incident.

du coup ca remarche:

Citation de: hwti le 08 août 2023 à 19:33:10

Pareil en http (pour éliminer le TLS, le serveur semble limité à HTTP/1.1) ?

oui http ou https meme résultat pour hivane.testdebit.info

Citation de: hwti le 09 août 2023 à 02:08:16

Le site indique qu'iperf3 est disponible sur les ports 5200-5209.
En pratique seuls 5200, 5201 et 5205 semblent fonctionner (aussi bien pour ping.online.net que ping6.online.net), les autres ne répondent pas (démons iperf3 plantés et non relancés ?).
Et sinon :
Code: [Sélectionner]
rcv_tcp_congestion cubic
Sur ping(6)-ams1.online.net (peut-être moins intéressant pour les débits élevés, à cause de la latence), le port 5200 ne répond pas, et connexion refusée sur les ports 5202/5204.
Il y a donc les ports 5201/5203/5205/5206/5207/5208/5209, mais certains semblent toujours occupés (peut-être qu'il y a des clients qui lancent des tests longs, ou que que le serveur iperf3 est bloqué).
Là aussi le serveur est en Cubic.

j'ai réussi a choper un iperf3 sur ping.online.net mais c'est du bol y'a plein de 'the server is busy' donc pas pu tester avec -C ou --get-server-output

Code: [Sélectionner]

iperf3 -c ping.online.net -p 5200 -R
Connecting to host ping.online.net, port 5200
Reverse mode, remote host ping.online.net is sending
[  5] local 192.168.10.3 port 51680 connected to 62.210.18.40 port 5200
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   737 MBytes  6.18 Gbits/sec
[  5]   1.00-2.00   sec   815 MBytes  6.83 Gbits/sec
[  5]   2.00-3.00   sec   826 MBytes  6.93 Gbits/sec
[  5]   3.00-4.00   sec   808 MBytes  6.78 Gbits/sec
[  5]   4.00-5.00   sec   857 MBytes  7.19 Gbits/sec
[  5]   5.00-6.00   sec   861 MBytes  7.23 Gbits/sec
[  5]   6.00-7.00   sec   836 MBytes  7.01 Gbits/sec
[  5]   7.00-8.00   sec   269 MBytes  2.25 Gbits/sec
[  5]   8.00-9.00   sec  76.3 MBytes   640 Mbits/sec
[  5]   9.00-10.00  sec  91.5 MBytes   767 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  6.06 GBytes  5.20 Gbits/sec  2589             sender
[  5]   0.00-10.00  sec  6.03 GBytes  5.18 Gbits/sec                  receiver

iperf Done.

curieux la chute après l'atteinte du max.

pour ams:

Code: [Sélectionner]

iperf3 -V --get-server-output -c ping-ams1.online.net -p 5201 -R -C cubic
Control connection MSS 1448
Time: Thu, 10 Aug 2023 08:11:46 GMT
Connecting to host ping-ams1.online.net, port 5201
Reverse mode, remote host ping-ams1.online.net is sending
      Cookie: ......
      TCP MSS: 1448 (default)
[  5] local 192.168.10.3 port 49986 connected to 163.172.208.7 port 5201
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 10 second test, tos 0
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   556 MBytes  4.67 Gbits/sec
[  5]   1.00-2.00   sec   206 MBytes  1.73 Gbits/sec
[  5]   2.00-3.00   sec  15.9 MBytes   134 Mbits/sec
[  5]   3.00-4.00   sec  18.2 MBytes   153 Mbits/sec
[  5]   4.00-5.00   sec  17.3 MBytes   145 Mbits/sec
[  5]   5.00-6.00   sec  15.5 MBytes   130 Mbits/sec
[  5]   6.00-7.00   sec  14.2 MBytes   119 Mbits/sec
[  5]   7.00-8.00   sec  17.9 MBytes   150 Mbits/sec
[  5]   8.00-9.00   sec  15.8 MBytes   132 Mbits/sec
[  5]   9.00-10.00  sec  16.2 MBytes   136 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   978 MBytes   820 Mbits/sec  6001             sender
[  5]   0.00-10.00  sec   893 MBytes   749 Mbits/sec                  receiver
rcv_tcp_congestion cubic

Server output:
iperf 3.1.3
Linux ping-ams1 4.4.0-104-generic #127-Ubuntu SMP Mon Dec 11 12:16:42 UTC 2017 x86_64
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Time: Thu, 10 Aug 2023 08:11:46 GMT
Accepted connection from .......... port 49970
      Cookie: ....
      TCP MSS: 1448 (default)
[  7] local 163.172.208.7 port 5201 connected to ........... port 49986
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 10 second test
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  7]   0.00-2.00   sec   847 MBytes  3.55 Gbits/sec  5983    245 KBytes
[  7]   2.00-4.00   sec  33.8 MBytes   142 Mbits/sec    0    334 KBytes
[  7]   4.00-6.00   sec  32.5 MBytes   136 Mbits/sec    4    223 KBytes
[  7]   6.00-8.00   sec  32.5 MBytes   136 Mbits/sec    0    314 KBytes
[  7]   8.00-10.00  sec  32.5 MBytes   136 Mbits/sec   14    304 KBytes
[  7]  10.00-10.02  sec  0.00 Bytes  0.00 bits/sec    0    304 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bandwidth       Retr
[  7]   0.00-10.02  sec   978 MBytes   819 Mbits/sec  6001             sender
[  7]   0.00-10.02  sec  0.00 Bytes  0.00 bits/sec                  receiver
CPU Utilization: local/sender 0.9% (0.0%u/0.8%s), remote/receiver 0.7% (0.0%u/0.7%s)


iperf Done.

a noter: c'est iperf 3.1.3 de 2016 sur les serveurs Online