Auteur Sujet: Freebox révolution fibre (FTTH) : Débit en téléchargement de 1 Gb/s (Lu 230426 fois)

vivien · « **le:** 09 février 2011 à 07:28:54 »

Inédit : Freebox révolution fibre : le débit en téléchargement est de 1 Gb/s (contre 100 Mb/s annoncé)
Attention toutefois, l'offre reste officiellement à 100 Mb/s, Free pourrait baisser le débit...

Free n'en avait pas parlé dans sa conférence de presse sur la Freebox Révolution mais le débit des premiers abonnés Freebox est de 1 Gb/s. Le débit réel est plutôt de 600 Mb/s en IPv4 car le chipset ne semble pas pouvoir suivre. Il est probable que le NAT soit réalisé par le chipset Broadcom BCM6368 de la FreeBox Server épaulé de 32 Mo ram DDR PC3200 400 MHz (La FreeBox Server possède aussi un ARM9 / SoC ARM 88F6281 à 1,2 GHz épaulé de 512 Mo ram DDR2-800, mais ce chipset semble plus dédié aux fonctions NAS et serveur Web).

Un grand remerciement à Barbatoutes pour m'avoir accueilli dimanche dernier dans son appartement de Paris 19ème afin de réaliser de longs tests et une séance photos pour suivre la fibre jusqu'au local égout (les photos sont dans le post Paris19 : Photos d'une installation Freebox Révolution fibre)

La Freebox server fibre :

Petit test avec IPERF, logiciel qui permet de faire des tests de débit en ram (sans générer des accès disque ce qui permet de monter à 10 Gb/s avec les CPU actuel et à condition de disposer d'une carte 10 Gb/s)

IPERF - 3,99 Gio téléchargé en 60 secondes - 572 Mbs de débit moyen :

On devrait pouvoir aller plus vie avec une puce plus puissante que le Broadcom BCM6368 de la FreeBox Server.
A tester aussi (quand il sera disponible pour la Freebox Révolution) : Le mode bridge. Ce dernier permet d'avoir directement l'adresse IPv4 sur le PC de test et permet de moins solliciter le Broadcom BCM6368. Bien sur, si c'est le bus interne du BCM668 qui sature pas de solution software possible : il faut se connecter directement avec le PC en fibre pour avoir 1 Gb/s.

Le Moniteur système de linux Ubuntu :

L'analyse d'une capture Wireshark :

Iperf avec un intervalle de rapport toutes les secondes :
$ iperf -s -i 1 [ ID] Interval Transfer Bandwidth [ 4] 0.0- 1.0 sec 52.1 MBytes 437 Mbits/sec [ 4] 1.0- 2.0 sec 65.9 MBytes 552 Mbits/sec [ 4] 2.0- 3.0 sec 71.9 MBytes 603 Mbits/sec [ 4] 3.0- 4.0 sec 69.3 MBytes 581 Mbits/sec [ 4] 4.0- 5.0 sec 67.6 MBytes 567 Mbits/sec [ 4] 5.0- 6.0 sec 68.2 MBytes 572 Mbits/sec [ 4] 6.0- 7.0 sec 72.8 MBytes 611 Mbits/sec [ 4] 7.0- 8.0 sec 74.0 MBytes 621 Mbits/sec [ 4] 8.0- 9.0 sec 74.3 MBytes 623 Mbits/sec [ 4] 9.0-10.0 sec 74.6 MBytes 626 Mbits/sec [ 4] 10.0-11.0 sec 73.2 MBytes 614 Mbits/sec [ 4] 11.0-12.0 sec 66.1 MBytes 554 Mbits/sec [ 4] 12.0-13.0 sec 71.0 MBytes 595 Mbits/sec [ 4] 13.0-14.0 sec 58.9 MBytes 494 Mbits/sec [ 4] 14.0-15.0 sec 66.8 MBytes 560 Mbits/sec [ 4] 15.0-16.0 sec 61.3 MBytes 515 Mbits/sec [ 4] 16.0-17.0 sec 70.6 MBytes 592 Mbits/sec [ 4] 17.0-18.0 sec 70.6 MBytes 593 Mbits/sec [ 4] 18.0-19.0 sec 72.7 MBytes 610 Mbits/sec [ 4] 19.0-20.0 sec 75.3 MBytes 632 Mbits/sec [ 4] 0.0-20.0 sec 1.35 GBytes 578 Mbits/sec

Conclusion :
Avec IPERF il est possible de monter à un débit de 600 Mb/s en moyenne au niveau réseau en IPv4 (il est possible que le traitement d'Iv6 soit moins optimisé et donc plus lent)./size]

vivien · « **Réponse #1 le:** 09 février 2011 à 07:44:27 »

Iperf, c'est bien, mais avec un téléchargement réel avec Firefox ?

Voici le comparatif entre une ligne ADSL proche du NRA, la Freebox optique ancienne génération et la Freebox Révolution fibre sur un fichier réel de 655 Mo téléchargé avec Firefox :

Je précise que ce débit est impacté par les "faibles" performances de mon PC portable équipé de seulement 1 Go ram. Le disque dur a un peu de mal à suivre et les accès disque "cassent" le débit internet. Il tourne sous Ubuntu ce qui permet d'utiliser au maximum ses capacités. Un test comparant Windows XP, Windows 7 et Linux installés sur un même PC avec différents navigateur va bientôt être réalisé.

Voici le débit affiché par Firefox :

Le graphique ci-dessous est généré à partir d'une capture wireshark fait sur le PC client. On y remarque de nombreuses pauses dans le transfert. C'est peu visible mais la Rwin (fenêtre de réception TCP autrement dit les paquets envoyés et non acquittés) se remplie. La cause de la pause est donc une absence de réponse de la part du PC client, probablement occupé à transférer sur disque le fichier.

La même capture mise en forme de manière à voir le débit. On remarque un débit moyen de 600 Mb/s hors pauses lié au PC client :

vivien · « **Réponse #2 le:** 09 février 2011 à 07:44:36 »

Et en Upload ?

En Upload le débit est de 50 Mb/s (49 Mb/s IP) après un burst de 15ms pendant lequel le débit n'est pas limité (enfin si par l'interface 1 Gb/s et le Broadcom BCM6368 de la Freebox server)

Voici un test avec IPERF en TCP. Le protocole TCP adapte son débit aux différents éléments du réseau afin de ne pas perdre de paquets en saturant des buffers. C'est un très bon protocole (contrairement à UDP qui envoie sans se soucier de savoir si les données arrivent) mais le démarrage n'est pas immédiat.

On voit bien le slow-start TCP et le burst d'environ 15ms avant que le débit ne soit limité à 50 Mb/s.
C'est nettement moins que SFR en Gpon qui propose un burst de 1120 Ms (voir article SFR Fibre propose un débit réel de 100 Mb/s en upload pendant 1120 millisecondes

Afin de mieux montrer ce petit burst, j'ai réalisé des tests en UDP. Avec UDP on indique le débit auquel on envoie les données. J'ai choisi d'envoyer les paquets à un débit fixe de 95 Mb/s, que les paquets arrivent ou non. Une fois le débit limité à 50 Mb/s, près de la moitié de mes paquets n'arrivent pas à destination.

La capture Wireshark est bien sûr réalisée sur le serveur qui reçoit les flux (sans quoi sur l'èmetteur on verrait 95 Mb/s tout le temps)

Un zoom sur le début du transfert :

Les informations d'IPERF sur le PC recevant les flux. Excepté les 15 premières ms, 49% des paquets envoyés sont dropés, le débit est 49 Mb/s IP :
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 3] 0.0- 0.5 sec 3.85 MBytes 64.6 Mbits/sec 0.042 ms 1304/ 4052 (32%) [ 3] 0.5- 1.0 sec 2.92 MBytes 49.0 Mbits/sec 0.061 ms 1982/ 4067 (49%) [ 3] 1.0- 1.5 sec 2.92 MBytes 49.0 Mbits/sec 0.056 ms 1969/ 4053 (49%) [ 3] 1.5- 2.0 sec 2.92 MBytes 49.0 Mbits/sec 0.079 ms 1969/ 4054 (49%) [ 3] 2.0- 2.5 sec 2.92 MBytes 49.0 Mbits/sec 0.032 ms 1975/ 4059 (49%) [ 3] 2.5- 3.0 sec 2.92 MBytes 49.0 Mbits/sec 0.066 ms 1981/ 4066 (49%) [ 3] 3.0- 3.5 sec 2.92 MBytes 49.0 Mbits/sec 0.074 ms 1981/ 4065 (49%) [ 3] 3.5- 4.0 sec 2.92 MBytes 49.0 Mbits/sec 0.067 ms 1980/ 4064 (49%) [ 3] 4.0- 4.5 sec 2.92 MBytes 49.0 Mbits/sec 0.052 ms 1978/ 4063 (49%) [ 3] 4.5- 5.0 sec 2.92 MBytes 49.0 Mbits/sec 0.062 ms 1977/ 4061 (49%) [ 3] 5.0- 5.5 sec 2.92 MBytes 49.0 Mbits/sec 0.035 ms 1981/ 4065 (49%) [ 3] 5.5- 6.0 sec 2.92 MBytes 49.0 Mbits/sec 0.072 ms 1979/ 4064 (49%) [ 3] 6.0- 6.5 sec 2.90 MBytes 48.6 Mbits/sec 0.057 ms 1933/ 4000 (48%) [ 3] 6.5- 7.0 sec 2.95 MBytes 49.4 Mbits/sec 0.062 ms 1996/ 4097 (49%) [ 3] 7.0- 7.5 sec 2.89 MBytes 48.4 Mbits/sec 0.061 ms 1955/ 4014 (49%) [ 3] 7.5- 8.0 sec 2.96 MBytes 49.6 Mbits/sec 0.113 ms 1997/ 4107 (49%) [ 3] 8.0- 8.5 sec 2.92 MBytes 49.0 Mbits/sec 0.052 ms 1971/ 4055 (49%) [ 3] 8.5- 9.0 sec 2.92 MBytes 49.0 Mbits/sec 0.137 ms 1978/ 4062 (49%) [ 3] 9.0- 9.5 sec 2.92 MBytes 49.0 Mbits/sec 0.096 ms 1973/ 4058 (49%) [ 3] 9.5-10.0 sec 2.91 MBytes 48.9 Mbits/sec 0.090 ms 1972/ 4050 (49%) [ 3] 0.0-10.0 sec 59.4 MBytes 49.8 Mbits/sec 0.098 ms 38830/81177 (48%)

vivien · « **Réponse #3 le:** 09 février 2011 à 07:44:41 »

Que donne un transfert UDP en download ? 600 Mb/s ?

Je ne vous cache pas ma déception sur ce test qui permet généralement de montrer le débit nominal du tuyau. La puce Broadcom BCM6368 de la Freebox semble plus impacté pars mon trafic UDP constitué pourtant de paquet de 1,5 Ko (plus les paquets sont petits, plus on utilise le CPU pour un même débit). Le débit est donc décevant, on perd des paquets à partir de 100 Mb/s.

Envoi d'un trafic à 100 Mb/s en UDP vers la Freebox :
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 4] 0.0- 1.0 sec 11.9 MBytes 99.9 Mbits/sec 0.120 ms 54/ 8546 (0.63%) [ 4] 1.0- 2.0 sec 12.0 MBytes 101 Mbits/sec 0.120 ms 0/ 8548 (0%) [ 4] 2.0- 3.0 sec 12.0 MBytes 100 Mbits/sec 0.107 ms 13/ 8547 (0.15%) [ 4] 3.0- 4.0 sec 11.9 MBytes 100 Mbits/sec 0.119 ms 36/ 8546 (0.42%) [ 4] 4.0- 5.0 sec 11.8 MBytes 99.3 Mbits/sec 0.110 ms 105/ 8547 (1.2%) [ 4] 5.0- 6.0 sec 12.0 MBytes 100 Mbits/sec 0.117 ms 6/ 8547 (0.07%) [ 4] 6.0- 7.0 sec 12.0 MBytes 101 Mbits/sec 0.124 ms 0/ 8546 (0%) [ 4] 7.0- 8.0 sec 11.9 MBytes 100 Mbits/sec 0.119 ms 24/ 8547 (0.28%) [ 4] 8.0- 9.0 sec 12.0 MBytes 101 Mbits/sec 0.117 ms 0/ 8547 (0%) [ 4] 9.0-10.0 sec 12.0 MBytes 100 Mbits/sec 0.123 ms 9/ 8546 (0.11%) [ 4] 0.0-10.0 sec 119 MBytes 100 Mbits/sec 0.121 ms 246/85470 (0.29%)
On perd déjà 0,29% des paquets avec un trafic de 100 Mb/s UDP et la gigue est trop importante.

Envoi d'un trafic à 200 Mb/s en UDP vers la Freebox :
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 3] 0.0- 1.0 sec 24.0 MBytes 201 Mbits/sec 0.072 ms 111/17239 (0.64%) [ 3] 1.0- 2.0 sec 24.1 MBytes 203 Mbits/sec 0.077 ms 19/17243 (0.11%) [ 3] 2.0- 3.0 sec 23.8 MBytes 200 Mbits/sec 0.068 ms 231/17241 (1.3%) [ 3] 3.0- 4.0 sec 23.9 MBytes 200 Mbits/sec 0.069 ms 227/17240 (1.3%) [ 3] 4.0- 5.0 sec 23.9 MBytes 200 Mbits/sec 0.065 ms 211/17241 (1.2%) [ 3] 5.0- 6.0 sec 23.8 MBytes 200 Mbits/sec 0.074 ms 245/17239 (1.4%) [ 3] 6.0- 7.0 sec 23.6 MBytes 198 Mbits/sec 0.079 ms 399/17240 (2.3%) [ 3] 7.0- 8.0 sec 24.0 MBytes 202 Mbits/sec 0.060 ms 100/17244 (0.58%) [ 3] 8.0- 9.0 sec 24.0 MBytes 201 Mbits/sec 0.064 ms 110/17242 (0.64%) [ 3] 9.0-10.0 sec 24.1 MBytes 202 Mbits/sec 0.063 ms 29/17238 (0.17%) [ 3] 0.0-10.0 sec 239 MBytes 201 Mbits/sec 0.063 ms 1681/172413 (0.97%)
On perd 0,97% des paquets avec un trafic de 200 Mb/s.

Envoi d'un trafic à 300 Mb/s en UDP vers la Freebox :
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 4] 0.0- 1.0 sec 35.2 MBytes 295 Mbits/sec 0.052 ms 548/25643 (2.1%) [ 4] 1.0- 2.0 sec 35.7 MBytes 299 Mbits/sec 0.045 ms 196/25626 (0.76%) [ 4] 2.0- 3.0 sec 34.8 MBytes 292 Mbits/sec 0.039 ms 800/25641 (3.1%) [ 4] 3.0- 4.0 sec 35.3 MBytes 296 Mbits/sec 0.045 ms 444/25614 (1.7%) [ 4] 4.0- 5.0 sec 35.1 MBytes 294 Mbits/sec 0.039 ms 620/25637 (2.4%) [ 4] 5.0- 6.0 sec 35.1 MBytes 294 Mbits/sec 0.037 ms 548/25572 (2.1%) [ 4] 6.0- 7.0 sec 34.9 MBytes 293 Mbits/sec 0.035 ms 823/25706 (3.2%) [ 4] 7.0- 8.0 sec 35.5 MBytes 298 Mbits/sec 0.046 ms 306/25641 (1.2%) [ 4] 8.0- 9.0 sec 35.1 MBytes 295 Mbits/sec 0.035 ms 587/25639 (2.3%) [ 4] 9.0-10.0 sec 33.9 MBytes 284 Mbits/sec 0.048 ms 1483/25640 (5.8%) [ 4] 0.0-10.0 sec 350 MBytes 294 Mbits/sec 0.046 ms 6354/256364 (2.5%)
On perd 2,5% des paquets avec un trafic de 300 Mb/s.

Envoi d'un trafic à 400 Mb/s en UDP vers la Freebox :
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 3] 0.0- 1.0 sec 40.5 MBytes 340 Mbits/sec 0.049 ms 5320/34198 (16%) [ 3] 1.0- 2.0 sec 40.6 MBytes 340 Mbits/sec 0.048 ms 5700/34630 (16%) [ 3] 2.0- 3.0 sec 37.8 MBytes 317 Mbits/sec 0.065 ms 7463/34412 (22%) [ 3] 3.0- 4.0 sec 40.1 MBytes 337 Mbits/sec 0.046 ms 5930/34553 (17%) [ 3] 4.0- 5.0 sec 41.3 MBytes 347 Mbits/sec 0.031 ms 5012/34480 (15%) [ 3] 5.0- 6.0 sec 40.7 MBytes 342 Mbits/sec 0.037 ms 5427/34479 (16%) [ 3] 6.0- 7.0 sec 36.9 MBytes 309 Mbits/sec 0.035 ms 8189/34482 (24%) [ 3] 7.0- 8.0 sec 41.7 MBytes 350 Mbits/sec 0.044 ms 4652/34431 (14%) [ 3] 8.0- 9.0 sec 32.9 MBytes 276 Mbits/sec 0.047 ms 10900/34394 (32%) [ 3] 9.0-10.0 sec 35.8 MBytes 300 Mbits/sec 0.024 ms 8969/34482 (26%) [ 3] 0.0-10.3 sec 388 MBytes 318 Mbits/sec 15.301 ms 67577/344685 (20%)
On perd 20% des paquets avec un trafic de 400 Mb/s, la FreeBox server a décroché et n'arrive plus à suivre.
Le trafic reçu est de seulement 318 Mb/s, le reste est perdu.

Envoi d'un trafic à 500 Mb/s en UDP vers la Freebox :
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 4] 0.0- 1.0 sec 39.4 MBytes 331 Mbits/sec 0.036 ms 15115/43236 (35%) [ 4] 1.0- 2.0 sec 36.5 MBytes 306 Mbits/sec 0.044 ms 17436/43447 (40%) [ 4] 2.0- 3.0 sec 37.2 MBytes 312 Mbits/sec 0.040 ms 16928/43486 (39%) [ 4] 3.0- 4.0 sec 36.8 MBytes 309 Mbits/sec 0.055 ms 17235/43481 (40%) [ 4] 4.0- 5.0 sec 39.2 MBytes 329 Mbits/sec 0.051 ms 15496/43466 (36%) [ 4] 5.0- 6.0 sec 39.0 MBytes 327 Mbits/sec 0.050 ms 15662/43477 (36%) [ 4] 6.0- 7.0 sec 37.0 MBytes 311 Mbits/sec 0.048 ms 17062/43480 (39%) [ 4] 7.0- 8.0 sec 38.9 MBytes 326 Mbits/sec 0.045 ms 15708/43471 (36%) [ 4] 8.0- 9.0 sec 31.0 MBytes 260 Mbits/sec 0.046 ms 21332/43479 (49%) [ 4] 9.0-10.0 sec 39.2 MBytes 328 Mbits/sec 0.036 ms 15545/43476 (36%) [ 4] 0.0-10.3 sec 374 MBytes 306 Mbits/sec 15.449 ms 167581/434693 (39%)
On perd 39% des paquets avec un trafic de 500 Mb/s.
L'envoi de plus de paquets gêne encore plus le CPU et le débit réel reçu diminue : on ne reçoit plus 306 Mb/s de paquets UDP.

Envoi d'un trafic à 600 Mb/s en UDP vers la Freebox :
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 3] 0.0- 1.0 sec 36.7 MBytes 308 Mbits/sec 0.020 ms 26120/52302 (50%) [ 3] 1.0- 2.0 sec 36.8 MBytes 309 Mbits/sec 0.041 ms 26440/52719 (50%) [ 3] 2.0- 3.0 sec 30.4 MBytes 255 Mbits/sec 0.046 ms 30810/52482 (59%) [ 3] 3.0- 4.0 sec 35.5 MBytes 298 Mbits/sec 0.053 ms 27442/52766 (52%) [ 3] 4.0- 5.0 sec 35.1 MBytes 294 Mbits/sec 0.062 ms 27324/52333 (52%) [ 3] 5.0- 6.0 sec 31.3 MBytes 263 Mbits/sec 0.053 ms 30475/52833 (58%) [ 3] 6.0- 7.0 sec 34.3 MBytes 288 Mbits/sec 0.051 ms 28196/52649 (54%) [ 3] 7.0- 8.0 sec 34.9 MBytes 293 Mbits/sec 0.044 ms 27738/52640 (53%) [ 3] 8.0- 9.0 sec 35.5 MBytes 298 Mbits/sec 0.102 ms 26856/52213 (51%) [ 3] 9.0-10.0 sec 34.0 MBytes 285 Mbits/sec 0.061 ms 28785/53045 (54%) [ 3] 0.0-10.0 sec 345 MBytes 289 Mbits/sec 0.045 ms 280305/526231 (53%)
On perd 53% des paquets avec un trafic de 600 Mb/s.
Le débit réel continue de diminuer : on ne reçoit plus 289 Mb/s de paquets UDP.

Conclusion :
La Freebox Server n'est pas à l'aise avec les paquets UDP utilisés par certains VPN. Préférez le protocole TCP pour vos VPN.
La quasi totalité des autres services utilisant de la bande passante sont eux en TCP.
En attendant un test sur TCP en IPv6...

vivien · « **Réponse #4 le:** 09 février 2011 à 07:44:49 »

Que donne les tests de débit ?

J'ai testé de nombreux tests de débits. La quasi-totalité indiquent des débits farfelus.

Explications : Ces tests sont fait en TCP et il faut télécharger un gros fichier pour laisser le temps à une connexion TCP de monter en débit (le slow-start expliqué plus haut).

Les meilleurs tests de débit sont ceux développés par Ookla (SpeedTest, DegroupTest,...). Ookla a une petite astuce pour que la connexion TCP monte plus vite en débit : ils démarrent plusieurs connexions TCP en parallèle et cumulent les débits des ces différentes connexions.

SpeedTest sous Linux :

Le débit affiché sous évalué en downlad car la connexion TCP n'a pas le temps de monter.
En upload, l'utilisation du burst permet d'afficher un débit largement supérieur au débit en régime établi (49 Mb/s IP)

SpeedTest sous Windows XP :

Windonws XP a une pile TCP/IP non optimisée pour les hauts débits.
Une optimisation est possible mais cela ne permet pas d'atteindre les débit de Linux ou MacOS X.

DegroupTest : des résultats médiocre qui s'expliquent !
Le test de débit de DegroupTest (https://www.degrouptest.com/test-debit.php), est basé comme SPeedTest sur la technologie Ookla.
Toutefois les débits ne dépassent pas 100 Mbs.
L'explication est simple : DegroupTest loue un serveur chez OVH relié en 100 Mb/s...

Conclusion :
Aucun test de débit sur une page web permet de montrer le vrai débit de la Freebox Révolution fibre.
Il faut préférer des téléchargement de fichier si vous avez une machine puissante ou utiliser IPERF.

vivien · « **Réponse #5 le:** 09 février 2011 à 07:44:54 »

Conclusion :

La Freebox Révolution fibre mérite bien son nom de révolution. Free communique officiellement sur un débit de 100 Mb/s en download. Ce non bridage en download est-il temporaire ou définitif ?

Seul l'avenir nous le dira...

Quel débit serait-il possible d'atteindre en mode bridge ? (si il arrive un jour - il n'est toujours pas disponible pour la Freebox Révolution). Le mode bridge permet d'avoir directement l'adresse IPv4 sur le PC de test et permet de moins solliciter la puce qui aujourd'hui limite le débit : Le Broadcom BCM6368. Ne pas faire de NAT devrait libérer des ressources pour faire passer plus de paquet. Toutefois si c'est son bus interne qui sature pas de solution a part se passer de la Freebox et se connecter directement en fibre.

En attendant les heureux abonnés Freebox Révolution fibre peuvent déjà profiter de ce que sera Internet dans 10 ans dans les grandes villes Françaises.

Le débit de l'offre Frebox Révolution fibre est officiellement de 100 Mb/s :

Barbatoutes · « **Réponse #6 le:** 09 février 2011 à 09:33:09 »

Excellent, merci pour ce reportage ! C'est vrai que je suis très heureux de mon "investissement", je ne pouvais pas m'attendre à de tels débits !

Il serait temps que Degrouptest se mette à la page et propose un test permettant d'évaluer sa connexion optique.

Plop · « **Réponse #7 le:** 09 février 2011 à 10:27:39 »

Merci pour ce reportage

Pourquoi penses-tu que c'est le broadcom qui fait NAT ? Quand on regarde le PCB, ça a l'air d'être vraiment le Marvell 88F6281 le CPU principal, non ? Le switch est relié à ce Marvell, et le broadcom est relié au switch en GE. Le switch n'ayant que 6 ports, CPU Marvell+SFP+Broadcom+4 ports 1000Base-T en même temps, ça fait un de trop ?

À mon avis lorsque le SFP est présent, le broadcom n'est pas du tout utilisé.

Optrolight · « **Réponse #8 le:** 09 février 2011 à 12:05:34 »

Très intéressant ces tests. Ça montre aussi que les équipements de Free supporte déjà de tel connexion.

Par contre il serait intéressant de connaître le nombre d'abonné fibré sur ce switch optique dans le nro tester.

J'entend par là est ce que les débits constatés sont ils les mêmes avec 100, 1000, 2000 utilisateurs??? Le nro est alimenté avec quel débit??

Bref histoire de voir qu'elle débit en pratique chacun aura (si il n'y a pas de bridage) quand il y aura beaucoup de clients connecter??

vivien · « **Réponse #9 le:** 09 février 2011 à 13:39:22 »

Citation de: Plop le 09 février 2011 à 10:27:39

Pourquoi penses-tu que c'est le broadcom qui fait NAT ?

C'est uniquement les performances qui m'orientent vers une saturation du Broadcom BCM6368, il me semble que l'ARM9 / SoC ARM 88F6281 à 1,2 GHz devrait pouvoir gérer un trafic de 1 Gb/s, s'il n'est pas utilisé pour des taches annexes.

Quand le mode bridge arrivera sur la FreeBox révolution, on pourra avancer dans le diagnostique.

Citation de: Optrolight le 09 février 2011 à 12:05:34

Le nro est alimenté avec quel débit??

Les NRO de Free sont "alimentés" en 10 Gb/s. Le switch est en fait des Cisco Catalyst 4510R reliés entre-eux en boucle en 10 Gb/s. Il y a 8 cartes de 48 ports par switch, soit 384 clients par Cisco Catalyst 4510R.
Free met 3 Cisco Catalyst 4510R par baie. on monte donc à 1152 clients fibre par baie.

Des photos sont disponibles ici

netegalkaka · « **Réponse #10 le:** 09 février 2011 à 17:42:04 »

A quand la même chose chez SFR?

Punaise j'ai hâte que la mutualisation SFR/FREE soit effective afin de pouvoir m'abonner chez FREE fibre.

robotek · « **Réponse #11 le:** 09 février 2011 à 18:30:00 »

Citation de: Plop le 09 février 2011 à 10:27:39

Merci pour ce reportage

Pourquoi penses-tu que c'est le broadcom qui fait NAT ? Quand on regarde le PCB, ça a l'air d'être vraiment le Marvell 88F6281 le CPU principal, non ? Le switch est relié à ce Marvell, et le broadcom est relié au switch en GE. Le switch n'ayant que 6 ports, CPU Marvell+SFP+Broadcom+4 ports 1000Base-T en même temps, ça fait un de trop ?

À mon avis lorsque le SFP est présent, le broadcom n'est pas du tout utilisé.

Non, je pense que c'est l'inverse:

le Broadcom BCM6368 est utilisé en CPU central. Il possède deux interfaces giga.
Router de l'une vers l'autre (avec nat) doit pouvoir permettre d'approcher les 450Mb/s full duplex, mais ne permettra pas d'atteindre le giga toujours en full duplex. (limitation interne due à l'architecture de la puce si ma mémoire est bonne).

Puisqu'il dispose d'un accélérateur nat, de deux ports giga, il doit probablement être utilisé comme cpu central:
- port 0: connecté au sfp.
- port 1: connecté au switch;

sur le switch à 6 ports, tu vas avoir les 4 Ethernet, le BCM6368, et tout au bout, l'ARM 9.

C'est comme ça que j'aurais fait, pour éviter les limitations du CPU en routage d'une interface à l'autre.