La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Free => 
Actus fibre Free => Discussion démarrée par: fmauNeko le 30 novembre 2015 à 22:38:27
-
Bonsoir,
Je viens de voir passer ça : http://dev.freebox.fr/blog/?p=2067 (http://dev.freebox.fr/blog/?p=2067) qui parle de, je cite
Amélioration des débits en mode routeur, aussi bien en IPv4 qu’en IPv6, maintenant équivalents à ceux du mode bridge
Les fibrés peuvent confirmer ? Si ça s'avère vrai, ce qu'on croyait etre une limitation matérielle serait donc juste un bug ou une mauvaise optimisation qui a mis autant d'années à etre corrigée ?
-
Je confirme : les débits son multipliés par deux en FTTH en IPv4 et encore plus en IPv6.
SpeedTest réalisé par nicolem (https://lafibre.info/profile/nicolem/) :
(https://lafibre.info/images/free_debit/201511_speedtest_free_mode_routeur.jpg)
-
V6 pas assez puissante !!! on en reparle très bientôt :-) une surprise arrive ...
Le teaser d'Optrolight est fini. ;)
-
Waw, sympa ! Et on a des nouvelles des débits en IPv6 ? Sinon, je serai curieux de savoir comment ils ont fait vu tout ce qui a été dit ici sur une limitation matérielle de la FBx V6 ! :D
-
Bonsoir,
Je viens de voir passer ça : http://dev.freebox.fr/blog/?p=2067 (http://dev.freebox.fr/blog/?p=2067) qui parle de, je cite
Les fibrés peuvent confirmer ? Si ça s'avère vrai, ce qu'on croyait etre une limitation matérielle serait donc juste un bug ou une mauvaise optimisation qui a mis autant d'années à etre corrigée ?
L'optimisation, c'est souvent mis de coté au profit "d'un truc qui marche"
Même a 400 mbps, on pouvait dire que ca marchait bien. D'autres bugs étaient plus dérangeant. Faut croire qu'avec le temps, Free a aussi voulu montrer qu'il savait faire dans la dentelle quand il veut ;) Le matériel est limitant, mais on peut toujours aller chercher des gains en optimisant son code.
-
Comme quoi une correction de driver ça prend du temps chez Broadcom ::)
-
Je ne suis pas sur que ce soit dans le Broadcom (ne pas oublier qu'elle a deux CPU)
Les performances IPv6 seraient proches de celle en IPv4.
-
Dans tous les cas, il y a un dev qui mérite sa prime de fin d'année ^^
Mais je serais curieux moi aussi de savoir si c'était coté Freebox, Broadcom, ou autre, la cause des débits limités (puisque il semble que c'est même mieux que en bridge avant MAJ)
-
Je ne suis pas sur que ce soit dans le Broadcom (ne pas oublier qu'elle a deux CPU)
Les performances IPv6 seraient proches de celle en IPv4.
c'est encore d'actualité les trés bon rapports broadcom/free ou les choses ont évolué depuis l'adsl ?
-
Commercialement, vu le remplacement récent des DSLAM en Broadcom (10k DSLAMs ça fait une centaine de milliers de chips), je pense que ça continue de se passer plutôt bien ;)
-
Il y a surement de bonnes relations entre Broadcom et Free mais c'est bien free qui a réécrit le firmware pour gagner en débit !!
-
L'upload est ""pourri"" sur la capture. C'est l'offre qui n'est pas symétrique ?
-
Free vend bien du 1 gbits down et 200 mbits up.
Pas de débit symetrique.
-
L'upload est ""pourri"" sur la capture. C'est l'offre qui n'est pas symétrique ?
Oui pas de symétrie. bref conforme à l'offre !!
-
Merci :)
-
Il y a surement de bonnes relations entre Broadcom et Free mais c'est bien free qui a réécrit le firmware pour gagner en débit !!
Firmware ou driver?
-
heu je t'avoue que j'ai du mal à voir la différence (le frimaware utilise un driver?) :D
-
Hello,
A mon avis, l'amélioration du débit vient de l'implèmentation de l'accélération matérielle côté chipset broadcom.
Free est je crois le seul à proposer la fonctionnalité de port forwarding suivant l'IP source sur sa box (ce qui permet par exemple d'ouvrir le port 80 pour un autre service depuis l'IP du boulot ;-) ). A mon avis cela a complexifié l’implèmentation de l'accélération HW qui du coup ne devait pas être complète. Depuis le temps broadcom a du amélioré (ou ouvrir) son accélérateur HW et Free en profite.
Ce genre de truc se voit aussi ailleurs, par exemple dans le routeur ERLite ou l'offload (l'accélérateur HW du chipset) était désactivé en cas de règle "modify" concernant le failover dans le firmware 1.6, puis activé même avec le failover dans le firmware 1.7.
=> ca prend du temps, mais le moindre truc non supporté dans un accélérateur hardware peut pourrir les perfs.
C'est bien, ça montre clairement que broadcom et Free travaillent ensemble pour la correction des bugs réseaux.
Ce qui m'intéresse aussi, c'est l'amélioration du débit IPv6. Il me semble que le 6rd n'était pas du tout accéléré et du coup les perfs étaient pourries en IPv6.
Soit Free et broadcom ont implèmenté l'accélérateur hardware pour le 6rd, soit Free a mis à jour son infrastructure pour supprimer (ENFIN) ce truc qu'est le 6rd, soit seul les clients fibres sont déjà en dual-stack...
-
Ban ça alors ??? Je l'avais pas vu venir celle-là
-
Ben de base, les clients FTTH ont de l'IPv6 natif, pour le reste, je me prononce pas :)
-
Un test à 945 Mb/s :
-
Ne pas oublier que la Freebox révolution utilise en plus du petit Broadcom BCM6368, un processeur Marvell Kirkwood 88F6281 à 1,5 Ghz.
Plusieurs expert pensent que c'est le Marvell Kirkwood 88F6281 qui fait le NAT et le 6RD.
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é.
Il semblerait donc que ce soit la première hypothèse de Plop qui était correct http://www.mail-archive.com/frnog@frnog.org/msg13701.html (http://www.mail-archive.com/frnog@frnog.org/msg13701.html)
Et si on regarde les photos de la carte mère, ca parait en effet logique.
http://www.presence-pc.com/image/FreeboxV6-035,0101-277286-0-2-3-1-jpg-.html (http://www.presence-pc.com/image/FreeboxV6-035,0101-277286-0-2-3-1-jpg-.html)
http://www.presence-pc.com/actualite/photoreportages/75-18-freebox-revolution-serveur-demontage.html (http://www.presence-pc.com/actualite/photoreportages/75-18-freebox-revolution-serveur-demontage.html)
(https://lafibre.info/images/free/201101_Freebox_server_ouverte_1.jpg)
(https://lafibre.info/images/free/201101_Freebox_server_ouverte_2.jpg)
(https://lafibre.info/images/free/201101_Freebox_server_ouverte_3.jpg)
(https://lafibre.info/images/free/201101_Freebox_server_ouverte_4.jpg)
La puce broadcom ne semble d'ailleurs pas relié directement au switch, mais a une autre puce placé entre le connecteur SFP et le switch. Je n'y connais pas grand chose en électronique, mais je suppose que cela fait office d'interrupteur entre les deux(?) .
Le Marvell Kirkwood (https://lafibre.info/images/free/201101_Marvell_Kirkwood_88F6281_2_Hardware_Spec.pdf) peut lui monter jusqu'à 1.5Ghz et serait donc en effet plus puissant que le Broadcom 6368.
Il possède deux interfaces Gb lui aussi, mais à priori, 1 seul serait utilisé vers le switch puisque celui ci ne possède que 6 interfaces.
- N'aurait il pas fallut que le SFP/BCM soit relié directement a la 2nd interface Gb du kirkwood pour que celui ci soit capable de router 1 Gb en full duplex? (ou alors à deux interfaces Gb du switch, mais il ne resterait plus que 3 ports Gb pour l'abonné)
Est-ce le cas en pratique ? je ne vois pas de 'liens' direct entre les composants, mais il me semble qu'il peut y avoir plusieurs couches...
- Le kirkwood a aussi pas mal d'autres occupations (Nas smb/ftp, dhcp, dns, téléphonie, i/o hdd et wifi...), la limitation pourrait aussi venir de la, si ce n'est pas la bande passante entre les composants qui limite?
Cela pourrait éventuellement être mis en évidence en désactivant le maximum de services (nas, wifi) entre deux mesures.
- Une dernière hypothèse qui pourrait expliquer les mesures serait qu'il n'y avait pas 1 Gb de bande passante dispo sur le backbone à ce moment la. Ce serait étonnant vu le faible nombre d'abonnés ftth, mais ca reste possible.
Vivement le mode bridge ^^
-
hâte de tester ça ;) dès que je retourne chez moi vendredi
-
hum...
j'ai déjà vu le chipset broadcom dans des routeurs et modem VDSL (le Zyxel que j'ai en a un), et le chipset marvell dans des NAS.
Mais utiliser les 2 en même temps pour le réseau, j'en doute. Mon avis serait plutôt que le broadcom gère le réseau, le marvel les services.
Au fait, c'est quoi l'IPv6 de la box ?
Suivant le bug http://dev.freebox.fr/bugs/task/14104 l'interface est accessible en IPv6, seulement voilà:
moi@chezmoi:~$ telnet {monipv6}::1 80
Trying {monipv6}::1...
telnet: Unable to connect to remote host: Connection refused
???
-
bonne nouvelle pour les freenautes qui auront enfin le service dont free fait la pub depuis des mois !
Mieux vaut tard que jamais comme on dit. :)
-
Je dois dire que je pensais moi aussi que c'était une limitation matérielle, et j'ai été surpris par cette annonce. C'est au moins un des avantages de Free, concevoir lui-même ses matériels (sauf switchs FTTH...), et de pouvoir les adapter à ses besoins, et de les supporter sur toute la durée qu'ils souhaitent (ce qui n'est pas le cas d'autres FAIs comme Bouygues par exemple...).
Je dis donc bravo à Free pour cette réalisation. J'aimerais bien savoir également si la gestion de l'IPv6 a changé (IPv6 natif ?)...
-
bonne nouvelle pour les freenautes qui auront enfin le service dont free fait la pub depuis des mois !
Des annéessssss !
-
Il y a surement de bonnes relations entre Broadcom et Free mais c'est bien free qui a réécrit le firmware pour gagner en débit !!
heu je t'avoue que j'ai du mal à voir la différence (le frimaware utilise un driver?) :D
Ta phrase m'a laissé penser qu'il y avait un firmware dans le chipset broadcom. C'est peut être une mauvaise interprétation de ma part.
Cela m'a paru plus cohérent que ce soit le driver de broadcom qui soit réécrit par Free.
-
Ca tient le Gbps si la box fait autre chose en même temps ? :p
et si je lance 3 wget en meme temps d'un meme poste, j'ai environ 3x300 Mbps ? ou 1 vraiment plus gros que les 2 autres ...
-
bonne nouvelle pour les freenautes qui auront enfin le service dont free fait la pub depuis des mois !
Mieux vaut tard que jamais comme on dit. :)
Juste les petites lettres qui vont disparaître :)
-
Good news mais effectivement il faut que le proc est d autres choses
Cela dit meme chose pour la livebox play
Avec la v7 il ne devrait plus y avoir ces limites
-
Ben de base, les clients FTTH ont de l'IPv6 natif, pour le reste, je me prononce pas :)
Bonjour Hugues,
Es-tu bien sûr de ce que tu avances ? (https://lafibre.info/images/smileys/@GregLand/cs.gif)
-
C'est vrai que je pensais que c'était du 6rd. Après, les tests de débits sont encourageants :
-
Ben, ouais. Je l'ai lu sur LaFibre, après je sais plus où, mais le 6RD est la uniquement car certains DSLAMs ne sont (étaient ?) pas compatible IPv6, sur la fibre ça a toujours été du natif, je te retrouve ca :)
[EDIT] : ici. https://lafibre.info/ipv6/ipv6-et-freebox-ftth/ (https://lafibre.info/ipv6/ipv6-et-freebox-ftth/) (Ah mince, en fait ils ne donnent pas la réponse, je continue de chercher...)
-
Ah bah sympa alors. Le déploiement sur xDSL serait bien aussi, surtout que ça concerne la majorité des clients. Et ensuite sur le mobile ce serait encore mieux ;D
-
Ah bah sympa alors. Le déploiement sur xDSL serait bien aussi, surtout que ça concerne la majorité des clients. Et ensuite sur le mobile ce serait encore mieux ;D
Pour moi, la gestion de l'IPv6 quand tu es en mode bridge est tellement minable que je passe par un tunnel chez HE, j'ai passé des jours a tenter de faire marcher le truc, alors que HE avait déjà des fichiers de conf pour mon routeur, et tout...
-
Ffth, dernière mise à jour de la v6, mais toujours 450mbps.
Tant pis.
-
Un PC un peu limité peut-être ?
-
Apparemment un firmware 3.2.1 serait déjà de sortie pour corriger les redémarrages en série observés par les (certains ?) utilisateurs du mode bridge.
-
Bizare, bizare ... j'obtiens 215mb/s en déscente et 465mb/s (!!) en montée ...
(https://www.speedtest.net/result/4879149627.png)
J'aimerais bien comprendre comment on peut en arriver à un ratio asymétrique inversé.
Sinon, j'aime beaucoup (beaucoup) mon ping ;-)
A+
TM
-
Pour moi, la gestion de l'IPv6 quand tu es en mode bridge est tellement minable que je passe par un tunnel chez HE, j'ai passé des jours a tenter de faire marcher le truc, alors que HE avait déjà des fichiers de conf pour mon routeur, et tout...
...HE ? (https://lafibre.info/images/smileys/Confus/Confus_77.gif)
-
Bizare, bizare ... j'obtiens 215mb/s en déscente et 465mb/s (!!) en montée ...
Tu as le même genre de résultats sur https://testdebit.info ?
C'est quand bizarre d'avoir un débit descendant aussi faiblard. Le débit montant m'étonne moins, il y a des endroits où les abonnés Free FTTH ont un débit montant supérieur à ce qui est prévu officiellement (problèmes de réglage ou tests j'imagine).
@Marco POLO : Hurricane Electric (https://en.wikipedia.org/wiki/Hurricane_Electric).
-
Hurricane Electric.
-
Hurricane Electric.
...Mais encore ? (https://lafibre.info/images/smileys/Confus/Confus_18.gif)
-
Un service qui te propose du transit IPv6 gratuit via un tunnel (comme un VPN mais sans chiffrage en gros) pour avoir un prefixe et une connectivité IPv6 même si ton FAI ne le gère pas.
-
Apparemment un firmware 3.2.1 serait déjà de sortie pour corriger les redémarrages en série observés par les (certains ?) utilisateurs du mode bridge.
http://dev.freebox.fr/bugs/task/19227
-
Un service qui te propose du transit IPv6 gratuit via un tunnel (comme un VPN mais sans chiffrage en gros) pour avoir un prefixe et une connectivité IPv6 même si ton FAI ne le gère pas.
...Merci. (https://lafibre.info/images/smileys/@GregLand/ay.gif)
-
You're welcome ! J'ai moi même appris ça y'a quelques mois sur LaFibre :)
-
Trop tard pour moi ! xD
Pendant des années, j'ai regretté cette limitation. Et aujourd'hui, on apprend que ce n'était pas une limitation matérielle. C'est ptèt' pas cool ce que je vais dire, mais je pense qu'ils n'auraient pas dû corriger le problème. 5 ans pour trouver le problème, ça ne fait pas sérieux...
-
Oh, je pense que c'était juste sur la roadmap mais qu'ils s'en foutaient pas mal :)
-
Ou que ça demandait un très gros boulot niveau ingénierie ?
-
Tu as le même genre de résultats sur https://testdebit.info ?
C'est quand bizarre d'avoir un débit descendant aussi faiblard. Le débit montant m'étonne moins, il y a des endroits où les abonnés Free FTTH ont un débit montant supérieur à ce qui est prévu officiellement (problèmes de réglage ou tests j'imagine).
Oui (215 / 434 testé à l'instant encore), c'est vraiment bizare presque systématiquement le double en up qu'en down. Vraiment j'aimerais bien comprendre le pourquoi du comment.
-
Bonsoir,
Me concernant, je ne vois pas d'améliorations :
(https://www.speedtest.net/result/4879573902.png)
-
Un PC un peu limité peut-être ?
Normalement un i74790k avec SSD c'est encore pas mal :D
-
Ben de base, les clients FTTH ont de l'IPv6 natif, pour le reste, je me prononce pas :)
Depuis quand?
-
Pour moi, depuis qu'il y'a de l'IPv6, sauf que j'ai pas de source, du coup c'est con. Je ferai un test des que je trouve un abonné FTTH dispo sur Twitter.
-
Clairement la différence est impressionnante... J'avais le souvenir d'être plutôt dans les 300/150Mb auparavant
(https://www.speedtest.net/result/4880255209.png) (https://www.speedtest.net/my-result/4880255209)
-
Trop tard pour moi ! xD
Pendant des années, j'ai regretté cette limitation. Et aujourd'hui, on apprend que ce n'était pas une limitation matérielle. C'est ptèt' pas cool ce que je vais dire, mais je pense qu'ils n'auraient pas dû corriger le problème. 5 ans pour trouver le problème, ça ne fait pas sérieux...
bah peut être que dans le dev de la v7, ils se sont aperçu que la v6 pouvait être corrigé par une optimisation.
free s'en fiche, ce que les gens vont retenir c'est pas qu'ils ont mis 5 ans fournir le service promis mais juste qu'ils ont 1 Gbps !
Suffit de lire leur bible UF :
Toujours plus pour le même prix ! Nous vous l’annoncions hier, Free a fait un bon en avant en améliorant les débits en mode routeur, qui sont maintenant équivalents à ceux du mode bridge, aussi bien en IPv4 qu’en IPv6.
Quand je lis ca, je sais pas si je dois rire ou pas.
-
@Phach : En même temps depuis quand les autres opérateurs ont des box qui routent le 1 Gbps ?
@jud : C'est la première fois que je vois un upload aussi élevé chez Free. :o
-
@Phach : En même temps depuis quand les autres opérateurs ont des box qui routent le 1 Gbps ?
depuis qu'ils le proposent commercialement.
-
Clairement la différence est impressionnante... J'avais le souvenir d'être plutôt dans les 300/150Mb auparavant
(https://www.speedtest.net/result/4880255209.png) (https://www.speedtest.net/my-result/4880255209)
La chance l'upload ;)
-
depuis qu'ils le proposent commercialement.
C'est bien là où je veux en venir, il me semble que ça ne fait pas si longtemps (pas 5 ans en tout cas). Moi je trouve plutôt positif de voir qu'on arrive à atteindre le 1 Gbps sur une box aussi "vieille" qui est sortie avant la disponibilité des offres 1 Gbps. M'enfin bref, chacun voit ça comme il veut.
-
techniquement c'est bien, je ne conteste pas.
C'est plutôt tout le foin qu'on fait autour alors que commercialement free est sensé vendre du gigabit(*) à grand renfort de publicité depuis longtemps.
D'un coté free s'offusque, certe à juste titre, que SFR/numericable utilise abusivement le terme fibre. Mais ca gène personne que free ne fournisse pas le gigabit promis, en mode routeur (c'est à dire, à priori, la config d'une grande majorité des gens)
et quand je lis, "free vous offre plus pour le même prix", c'est abusé je trouve.
-
C'est vrai que même si c'était bien indiqué dans les mentions légales, j'ai toujours trouvé ça un peu dommage de communiquer autant sur le 1 Gbps en sachant qu'il y avait une telle limitation.
-
Il m'a toujours semblé entendre que free vendait "jusqu'à 1Gb" et donc normal de pas toujours les atteindre, maintenant les chanceux qui ont la fibre free sont encore plus content ;D
-
Jusqu'à ... c'est pour l'ADSL, non?
-
Pas de débit garanti sur les offres grand public, donc c'est "jusqu'à" pour tous.
-
C'est jusqu'à chez tous les opérateurs?
-
Trop tard pour moi ! xD
Pendant des années, j'ai regretté cette limitation. Et aujourd'hui, on apprend que ce n'était pas une limitation matérielle. C'est ptèt' pas cool ce que je vais dire, mais je pense qu'ils n'auraient pas dû corriger le problème. 5 ans pour trouver le problème, ça ne fait pas sérieux...
Ils ont finalement trouvé comment on enlève le frein à main?
-
Tu rigoles c'est la Rolls des box, c'est un frein de parking électrique
-
D'un coté free s'offusque, certe à juste titre, que SFR/numericable utilise abusivement le terme fibre. Mais ca gène personne que free ne fournisse pas le gigabit promis, en mode routeur (c'est à dire, à priori, la config d'une grande majorité des gens)
Pas seulement le mode le plus utilisé, surtout le seul mode permettant de profiter :
- du Wifi
- du partage du disque dur de la Freebox
- de l'accès au Web sur le Player (sauf pour ceux possédant un NAT-routeur et capables de configurer un pont dessus)
- des fonctions DLNA du Player
etc.
Qui sont justement des fonctions mises en avant et des avantages décisifs pour certains par rapport à des box moins riches en fonctionnalités.
C'est un peu comme les voitures VW : elles peuvent être peu èmettrices de gaz carbonique (non nocif), peu èmettrices d'oxydes d'azote (nocif), l'un ou l'autre alternativement mais pas les deux à la fois.
-
D'un coté free s'offusque, certe à juste titre, que SFR/numericable utilise abusivement le terme fibre. Mais ca gène personne que free ne fournisse pas le gigabit promis, en mode routeur (c'est à dire, à priori, la config d'une grande majorité des gens)
Ben justement : ça n'a pas l'air de gêner grand monde que NC ne *puisse pas* structurellement tenir 400M dans les zones 400 faute de dimensionnement.
A la différence de Free, c'est pas tout à fait clair. Et ils insistent sur le fait qu'il n'y a pas de différence. :P
-
Pas de débit garanti sur les offres grand public, donc c'est "jusqu'à" pour tous.
Je veux bien le "pas garanti"....
Mais du 311/609 (!!), faut m'expliquer en quoi l'absence de paramétrage de QoS spécifique à un utilisateur serait responsable d'un tel résultat asymétrique inversé restant toujours dans un ratio U/D proche de 2 :
https://www.speedtest.net/result/4880631695.png
(sachant que j'ai testé "au cul" de la FB avec un top patch S/STP, en désactivant les AV & co sur la machine, et que je n'ai pas de problème sur des LAN avec cette machine à maxer le débit dans les 2 sens)
Pourquoi un tel ratio inversé de 2 ? Il vient d'où ... paramétré à quel niveau ? Cisco coté NRO ?
-
Oui. Erreur côté nro..
-
...C'est plutôt tout le foin qu'on fait autour alors que commercialement free est sensé vendre du gigabit(*) à grand renfort de publicité depuis longtemps...
...Mais il vendait bien du 1 Gbps, seulement, il ne précisait pas que ce n'était qu'en mode bridge... (https://lafibre.info/images/smileys/@GregLand/ap.gif)
-
Et encore, ce n'était pas tout à fait 1 Gbps...
-
Je veux bien le "pas garanti"....
Mais du 311/609 (!!), faut m'expliquer en quoi l'absence de paramétrage de QoS spécifique à un utilisateur serait responsable d'un tel résultat asymétrique inversé restant toujours dans un ratio U/D proche de 2 :
https://www.speedtest.net/result/4880631695.png
(sachant que j'ai testé "au cul" de la FB avec un top patch S/STP, en désactivant les AV & co sur la machine, et que je n'ai pas de problème sur des LAN avec cette machine à maxer le débit dans les 2 sens)
Pourquoi un tel ratio inversé de 2 ? Il vient d'où ... paramétré à quel niveau ? Cisco coté NRO ?
En fait, la limite à 200 Mb/s en upload, c'est artificiel, c'est un bridage côté NRO ou box. Naturellement, les SFP 1 Gb/s font du 1 Gb/s symétrique. Donc je parierais que c'est une erreur de paramétrage du port de ta ligne. Il y a aussi probablement aussi inversion uplink/downlink.
-
Clairement la différence est impressionnante... J'avais le souvenir d'être plutôt dans les 300/150Mb auparavant
(https://www.speedtest.net/result/4880255209.png) (https://www.speedtest.net/my-result/4880255209)
Tu ne comptes pas déménager par hasard? 8)
-
L'upload est ""pourri"" sur la capture. C'est l'offre qui n'est pas symétrique ?
Pourris ? 200Mbps c'est ce que propose les concurrents en upload.
-
Tu ne comptes pas déménager par hasard? 8)
Haha, non je me suis endetté pour un quart de siècle pour vivre là! :x
Cela va bientôt faire un an que je suis fibré, il faut voir qu'auparavant j'avais à peine 6-8Mb en ADSL dans le même logement. (ligne > 3km) On ne pouvait pas regarder une chaîne en HD et utiliser internet en parallèle: que de chemin parcouru!
Pour moi c'est clairement ce genre de ligne très dense avec un mauvais débit ADSL qui devraient être ciblées dans une politique commerciale volontariste... Les abonnés sont plus à même d'accepter d'ouvrir leur porte pour accepter un minimum de travaux d'installation...
Reste qu'à part l'auto-hébergement, les usages pour un tel niveau de service chez les particulier ne sont pas encore légions...
-
Ma v6 qui bloque sous les 500mbps avec un bon pc, dernier firmware en ftth, c'est bien une R1... Comme j'ai deux fbx, j'avais gardé l'autre information en mémoire. Et la r2 est en adsl pour longtemps encore si on doit attendre l'arrivée des bofs sur sem@fibre qui n'a pas encore fibré ce village...
Donc la R1, c'est vraiment pas le modèle qu'il faut avoir. D'un autre côté, ça montre que celle-ci est fiable, car elle n'a pas été changée depuis la migration v4 vers v6 faite dès la sortie de la v6
-
Ma v6 qui bloque sous les 500mbps avec un bon pc, dernier firmware en ftth, c'est bien une R1... Comme j'ai deux fbx, j'avais gardé l'autre information en mémoire. Et la r2 est en adsl pour longtemps encore si on doit attendre l'arrivée des bofs sur sem@fibre qui n'a pas encore fibré ce village...
Donc la R1, c'est vraiment pas le modèle qu'il faut avoir. D'un autre côté, ça montre que celle-ci est fiable, car elle n'a pas été changée depuis la migration v4 vers v6 faite dès la sortie de la v6
C'est curieux, je croyais que la différence en la r1 et la r2 était minime (disque dur principalement il me semble) ? en tout cas le CPU est le meme et pour le routage en FTTH c'est 100% fait par le CPU donc ca devrait être identique. Ton souci de limitation a 500mbps vient peut-etre d'ailleurs ?
-
Ma v6 qui bloque sous les 500mbps avec un bon pc, dernier firmware en ftth, c'est bien une R1... Comme j'ai deux fbx, j'avais gardé l'autre information en mémoire. Et la r2 est en adsl pour longtemps encore si on doit attendre l'arrivée des bofs sur sem@fibre qui n'a pas encore fibré ce village...
Donc la R1, c'est vraiment pas le modèle qu'il faut avoir. D'un autre côté, ça montre que celle-ci est fiable, car elle n'a pas été changée depuis la migration v4 vers v6 faite dès la sortie de la v6
La R1 tient le gigabit, on a eu confirmation. Cela vient d'autre part.
-
La R1 tient le gigabit, on a eu confirmation. Cela vient d'autre part.
Le Gbits ... c'est vite dit ;-) .. enfin bon, à ce niveau la, on n'est plus à 150 Mbits près 8) ;D ;D
(http://i67.tinypic.com/d4j9s.jpg)
-
oui mais surtout on ne le répètera jamais assez. Faire du gigabit est diffcile. il y a pleins de paramètres dans toutes la chaine de la mesures qui rentre en jeu. La box en est un mais pas le seul !
-
Oui, il y avait un soupçon d'ironie dans mon commentaire précédent.
D'ailleurs, c'est facile de constater que le résultat est difficilement répétable. Et puis, si j'ai bien compris, pour avoir ce type de débit, on dépend énormèment des petits copains de "Switch" et "NRO", j'imagine que le lien alimentant le local est du type 10 Gbits voir vraiment au mieux 40 Gbits, il ne faut donc pas que tout le monde s'amuse à faire des tests de débit en même temps
-
J'ai pas la possibilité de retourner sur ce site avant un certain temps, j'ai bien quelques détails à vérifier.
-
@CariBoo : C'est toujours le même éternel problème de statistique. A ce débit le test est vite fini donc tu n'encombres pas les tuyaux bien longtemps, même si pendant ce court laps de temps tu occupes beaucoup de place.
-
Moi je confirme que ma Freebox V6 au boulot a bien été MAJ, mais pas d'augmentation de débit, j'ai réussi à faire une pointe vers 600 Méga pas plus en mode routeur
-
Bon, pour l'IPv6 ce n'est pas encore ça:
wget -O /dev/null http://mafreebox.freebox.fr/gen/1G
--2015-12-03 16:14:41-- http://mafreebox.freebox.fr/gen/1G
Résolution de mafreebox.freebox.fr (mafreebox.freebox.fr)... 212.27.38.253, fd0f:ee:b0::1
Connexion vers mafreebox.freebox.fr (mafreebox.freebox.fr)|212.27.38.253|:80...connecté.
requête HTTP transmise, en attente de la réponse...302 Moved Temporarily
Emplacement: http://mafreebox.freebox.fr:8095/fixed/1G [suivant]
--2015-12-03 16:14:41-- http://mafreebox.freebox.fr:8095/fixed/1G
Connexion vers mafreebox.freebox.fr (mafreebox.freebox.fr)|212.27.38.253|:8095...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 1073741824 (1,0G) [application/octet-stream]
Sauvegarde en : «/dev/null»
15% [====================> ] 163 604 702 111M/s
wget -O /dev/null http://mafreebox6.freebox.fr/gen/1G
--2015-12-03 16:15:27-- http://mafreebox6.freebox.fr/gen/1G
Résolution de mafreebox6.freebox.fr (mafreebox6.freebox.fr)... fd0f:ee:b0::1
Connexion vers mafreebox6.freebox.fr (mafreebox6.freebox.fr)|fd0f:ee:b0::1|:80...connecté.
requête HTTP transmise, en attente de la réponse...302 Moved Temporarily
Emplacement: http://mafreebox6.freebox.fr:8095/fixed/1G [suivant]
--2015-12-03 16:15:27-- http://mafreebox6.freebox.fr:8095/fixed/1G
Connexion vers mafreebox6.freebox.fr (mafreebox6.freebox.fr)|fd0f:ee:b0::1|:8095...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 1073741824 (1,0G) [application/octet-stream]
Sauvegarde en : «/dev/null»
11% [===============> ] 124 876 182 59,4M/s
Débit divisé par 2 en local....
Alors c'est peut-être aussi lié à l'ERL qui bride, mais l'offload a l'air de bien fonctionner (CPU qui n’atteint même pas 15%).
-
...Alors c'est peut-être aussi lié à l'ERL qui bride, mais l'offload a l'air de bien fonctionner (CPU qui n’atteint même pas 15%).
...Qu'est-ce que cet ERL (http://www.wikiwand.com/fr/Erl) vient faire ici ? A moins qu'il ne s'agisse d'"Echo Return Loss" (pas de définition dans Wikipédia et je n'en ai pas trouvé non plus sur le net !)? (https://lafibre.info/images/smileys/@GregLand/cs.gif)
-
C'est lui : https://www.ubnt.com/edgemax/edgerouter-lite/
Après on en parle tellement sur le forum, difficile d'écrire autre chose...
-
Ceci étant dit, plein de définitions sur ces deux articles :
https://lafibre.info/raccordement-immeuble/lexique/
https://lafibre.info/ftth-la-fibre-optique-gpon-ou-p2p/techno-fibre/
-
Bon, pour l'IPv6 ce n'est pas encore ça:
...
Débit divisé par 2 en local....
Alors c'est peut-être aussi lié à l'ERL qui bride, mais l'offload a l'air de bien fonctionner (CPU qui n’atteint même pas 15%).
c'est pas clair du tout ton test et ta config la... pourquoi tu parles d'ERL ? t'es en mode bridge et les wget sont fait depuis un ERL ?
En v4 tu utilises l'ip public anycast, en v6 tu utilises une ULA : dans un cas tu traverses l'acceleration implèmentée dans l'autre cas c'est pas sur.
De toute facon c'est pas le routage/briding que tu mesures la, mais la performance de sortie du processus qui génère des données sur le port 8095... Ce processus n'a peut-être pas été optimisé pour IPv6 ou c'est le wget de l'ERL en IPv6 qui peut etre la cause... etc bref il faut un référentiel connu de comparaison et enlever l'ERL qui introduit une inconnu (ou mesurer avant en ce placant des 2 cotés de l'ERL).
et faire un vrai test de routage/bridging ...
-
C'est lui : https://www.ubnt.com/edgemax/edgerouter-lite/
Après on en parle tellement sur le forum, difficile d'écrire autre chose...
Merci Nico: en effet, il fallait deviner ! Il faut dire que vous autres G33ks, vous oubliez un peu trop fréquemment que des profanes de mon acabit essaient de comprendre/apprendre sans avoir nécessairement connaissance de toutes ces abréviations. (https://lafibre.info/images/smileys/@GregLand/ay.gif)
Ceci étant dit, plein de définitions sur ces deux articles :
https://lafibre.info/raccordement-immeuble/lexique/
...Ah ! En voilà un sujet qu'il est très intéressant... (https://lafibre.info/images/smileys/@GregLand/ay.gif) (https://lafibre.info/images/smileys/@GregLand/ay.gif) (https://lafibre.info/images/smileys/@GregLand/ay.gif)
https://lafibre.info/ftth-la-fibre-optique-gpon-ou-p2p/techno-fibre/
...Cela avait été l'objet de mon tout premier sujet sur ce site (http://forum.freenews.fr/index.php?topic=42661.msg632518#msg632518), publié à la demande de Vivien (http://forum.freenews.fr/index.php?PHPSESSID=ecafg6gp5afbuoen9ai4g6qim2&topic=42661.msg702161#msg702161) il y a plus de sept ans, et depuis effacé par ce dernier: j'y présentais le document que j'avais réalisé aux fins de présentation de la Fibre Optique que j'avais préparé pour l'Assemblée Générale de Copropriété de mon immeuble et traitais de l'historique du fibrage de celui-ci ... Mais je vais quand même lire ce sujet: j'ai certainement des choses à apprendre dans ces quinze pages... Bref, ces deux derniers topics me réservent certainement quelques heures de lecture... (https://lafibre.info/images/smileys/messages/Messages_113.gif)
-
Pour moi, depuis qu'il y'a de l'IPv6, sauf que j'ai pas de source, du coup c'est con.
Désolé alors mais c'est très probablement bullshit :$
=> On fait une recherche Google sur la fin du reverse des abonnés fibre Free, accompagnée du début de leurs préfixes IPv6: https://www.google.com/search?q="fbxo+proxad+net"+2a01 (https://www.google.com/search?q="fbxo+proxad+net"+2a01)
=> On regarde le premier résultat
=> On a une adresse IPv6 d'abonné fibre
=> L'adresse IPv4 de cet abonné est encapsulée exactement de la même manière que pour les abonnés 6rd.
2a01:e34:ec11:5730:2268:9dff:fef3:3bf
= 0x4e 0xc1 0x15 0x73
= 78.193.21.115
= her75-1-78-193-21-115.fbxo.proxad.net. (fbxo = Freebox optique)
-
J'attends la réponse d'abonnés Free Fibre pour vérifier (coucou Marco Polo :) ), Je fais rarement des vérités générales sur les Forums (IRL, c'est une autre histoire).
Pour la recherche accompagnée des préfixes, c'est pas une mauvaise idée, mais rien ne vaut un bon vieux traceroute :)
-
LaFibre.info n'est pas un forum réservé aux ingénieurs en telecom réseaux. Il n'y a pas de mal à poser une question pour mieux comprendre.
Traceroute des deux IP depuis Adeli :
$ mtr -rwc100 2a01:e34:ec11:5730:2268:9dff:fef3:3bf
Start: Thu Dec 3 19:15:13 2015
HOST: lafibre.info Loss% Snt Last Avg Best Wrst StDev
1.|-- bgp1.adeli.biz 0.0% 100 0.3 2.4 0.2 170.2 17.0
2.|-- cr5.rt.ielo.net 0.0% 100 14.0 11.0 7.7 126.6 13.2
3.|-- frpar01-a9k1.rt.ielo.net 0.0% 100 8.8 8.3 7.9 9.0 0.0
4.|-- proxad.ebgp.ielo.net 0.0% 100 8.2 8.3 8.0 11.6 0.4
5.|-- 2a01:e00:18::1 15.0% 100 10.5 9.9 7.8 11.8 1.1
6.|-- ? ? 100.0 100 0.0 0.0 0.0 0.0 0.0
7.|-- ? ? 100.0 100 0.0 0.0 0.0 0.0 0.0
8.|-- ? ? 100.0 100 0.0 0.0 0.0 0.0 0.0
9.|-- ? ? 100.0 100 0.0 0.0 0.0 0.0 0.0
10.|-- ? ? 100.0 100 0.0 0.0 0.0 0.0 0.0
11.|-- 2a01:e34:ec11:5730:2268:9dff:fef3:3bf 0.0% 100 12.5 11.1 9.1 38.7 3.6
$ mtr -rwc100 78.193.21.115
Start: Thu Dec 3 19:18:11 2015
HOST: lafibre.info Loss% Snt Last Avg Best Wrst StDev
1.|-- portevlan.adeli.biz 0.0% 100 0.3 0.7 0.3 8.1 1.1
2.|-- sw1-le9lyon-ge-1-4.ix-customers-le9lyon.ielo.net 0.0% 100 1.6 3.3 1.5 30.1 5.8
3.|-- te-2-3-frpar01-a9k1.rt.ielo.net 0.0% 100 8.0 8.1 7.9 8.4 0.0
4.|-- pni-free.th2-prs.fr.rt.ielo.net 0.0% 100 8.0 8.1 8.0 9.5 0.2
5.|-- th2-49m-2-po2.intf.routers.proxad.net 0.0% 100 7.9 7.9 7.8 9.8 0.2
6.|-- fey75-49m-2-v900.intf.nro.proxad.net 0.0% 100 8.0 8.0 7.9 8.5 0.0
7.|-- her75-4k-1-v700.nro.proxad.net 0.0% 100 7.9 8.1 7.8 13.3 0.7
8.|-- her75-1-78-193-21-115.fbxo.proxad.net 0.0% 100 7.8 7.8 7.7 10.4 0.3
-
Désolé alors mais c'est très probablement bullshit :$
=> On fait une recherche Google sur la fin du reverse des abonnés fibre Free, accompagnée du début de leurs préfixes IPv6: https://www.google.com/search?q="fbxo+proxad+net"+2a01 (https://www.google.com/search?q="fbxo+proxad+net"+2a01)
=> On regarde le premier résultat
=> On a une adresse IPv6 d'abonné fibre
=> L'adresse IPv4 de cet abonné est encapsulée exactement de la même manière que pour les abonnés 6rd.
2a01:e34:ec11:5730:2268:9dff:fef3:3bf
= 0x4e 0xc1 0x15 0x73
= 78.193.21.115
= her75-1-78-193-21-115.fbxo.proxad.net. (fbxo = Freebox optique)
Pour moi ça ne prouve rien, sinon que certaines Freebox optiques ont été en 6rd.
-
Super le HS....
Bon, sinon désolé Marco POLO, mais j'ai vu tellement de post concernant l'ERL que pour moi tout le monde sait que c'est un petit routeur plutôt performant :'( En fait non.
c'est pas clair du tout ton test et ta config la... pourquoi tu parles d'ERL ? t'es en mode bridge et les wget sont fait depuis un ERL ?
En v4 tu utilises l'ip public anycast, en v6 tu utilises une ULA : dans un cas tu traverses l'acceleration implèmentée dans l'autre cas c'est pas sur.
C'est un test rapidement fait en remote et qui correspond au 'test du débit local' proposé par la freebox. J'ai découvert que ça fonctionne en IPv6 (c'te nom mafreebox6.freebox.fr :o) maintenant alors je me suis amusé :D
Mon setup étant loin je ne peux le modifier (en journée). C'est Freebox mini server (en VDSL) <---> ERL <---> PC.
Etant obligé de faire du MSS clamping sur l'ERL pour réduire de 20 octets le MSS supporté, c'est un bon indicateur que je suis en 6rd.
Aussi, j'ai foiré ma première configuration du clamping (je passais par une règle "modify" qui désactivait l’accélération hardware) du coup j'avais 20MB/s en IPv6 (toujours le max en IPv4) avant de me rendre compte qu'il fallait passer par une option du firewall (plutôt que le modify) pour avoir l’accélérateur hardware.
Et enfin, un "top" sur le PC (2 coeurs) pendant les wget montre qu'en IPv4 wget utilise 50% de CPU (donc 100% d'un des 2 coeurs) et donc je pense que c'est le PC le facteur limitant, tandis qu'en IPv6, wget utilise 30% donc pas la totalité d'un coeur.
De toute facon c'est pas le routage/briding que tu mesures la, mais la performance de sortie du processus qui génère des données sur le port 8095... Ce processus n'a peut-être pas été optimisé pour IPv6 ou c'est le wget de l'ERL en IPv6 qui peut etre la cause... etc bref il faut un référentiel connu de comparaison et enlever l'ERL qui introduit une inconnu (ou mesurer avant en ce placant des 2 cotés de l'ERL).
et faire un vrai test de routage/bridging ...
Complètement d'accord. Ce n'est pas un test labo scientifique, mais plutôt le truc fait rapidement en coin de table.
Seulement voilà, d'un côté on lit que Free implèmente une double stack pour les clients fibre, d'un autre on a du 6rd. Moi je suis quasiment certain d'avoir du 6rd (et je suis en VDSL).
Maintenant j'aimerai bien savoir si l'encapsulation impact les performances, et aussi sur quel processeur, comment cela a été implèmenté, etc. etc. C'est plus de la curiosité qu'autre chose, vu que de toute façon je suis limité par le VDSL. Si t'as moyen de tester tout ça, ça m'intéresse :D
En fait, mon avis sur l'architecture de la box, c'est que le broadcom ne fait que gérer le routage, et depuis le firmware 3.2.0, il intègre un accélérateur hardware plus optimisé et donc atteint le 1Gbps. Je ne sais pas s'il y avait déjà un accélérateur pour l'IPv6 avant, mais à mon avis pour avoir 60MB/s, le forward IPv6 semble également optimisé. A mon avis, le processus de test tourne sur le Marvell (ainsi que le site mafreebox et le NAS et les services) et depuis la 3.2.0 Free a intégré la stack IPv6 sur le Marvell. Je suppose que cette stack est encore à ses débuts et donc n'est pas forcement optimisé. Au final pour moi soit c'est la stack IPv6 implèmenté côté Marvell qui limite le débit, soit c'est le forward IPv6 sur le Broadcom qui est partiellement hardware (ou mal accéléré, ou pas optimisé).
Je ne sais pas par contre si l'encapsulation 6rd est (a été) en hardware sur le Broadcom. J'ai une proposition de test que je décris si quelqu'un peut donner son avis (ou tester) dessus:
- pour cela il faut la fibre et tester en IPv6 vers un serveur extérieur qui tient la charge en IPv6 explicitement
- évidemment, s'assurer que le PC tienne la charge en IPv6 en ethernet (genre atteindre 60MB/s avec le test de débit local ;) en IPv6 sans prendre 100% du CPU)
- vérifier si le MSS clamp est nécessaire ou pas (dual-stack ou encapsulation) si on se place derrière un routeur (comme dans ma config)
- si le MSS clamp est nécessaire, simplement voir si le débit PC <-> Freebox <-> serveur ne maximise pas la ligne
Si le débit est optimum (genre 100MB/s et plus) => 6rd est accéléré en hardware
Sinon (genre 40-60MB/s et moins) => soit 6rd, soit le forward IPv6 et partiellement/pas du tout accéléré
Bref, comme dit, c'est plus de la curiosité.
Après, mon opinion, c'est que le 6rd c'était bien... il y a 5 ans. Maintenant, ça doit disparaitre.... (c'est Soooooo 2010's ;) )
D'ailleurs, c'est du dual-stack qui se déploie chez Orange, ou également du 6rd ?
-
Perso, jamais réussi à faire marcher IPv6 avec la box en Bridge, c'est une horreur.
Bon ben si tu le dis, Free fait donc aussi du 6Rd en fibre, c'est bien dommage vu qu'ils ont tout le réseau compatible (Il me semble que c’était les DSLAMs V1/V2 qui ne géraient pas IPv6)
Sinon pour l'architecture, tu oublies le Marvell ou c'est moi ? ^^'
-
IPv6 "natif"pour Orange, pas d'artifice.
-
Bon, pour l'IPv6 ce n'est pas encore ça:
wget -O /dev/null http://mafreebox.freebox.fr/gen/1G
--2015-12-03 16:14:41-- http://mafreebox.freebox.fr/gen/1G
Résolution de mafreebox.freebox.fr (mafreebox.freebox.fr)... 212.27.38.253, fd0f:ee:b0::1
Connexion vers mafreebox.freebox.fr (mafreebox.freebox.fr)|212.27.38.253|:80...connecté.
requête HTTP transmise, en attente de la réponse...302 Moved Temporarily
Emplacement: http://mafreebox.freebox.fr:8095/fixed/1G [suivant]
--2015-12-03 16:14:41-- http://mafreebox.freebox.fr:8095/fixed/1G
Connexion vers mafreebox.freebox.fr (mafreebox.freebox.fr)|212.27.38.253|:8095...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 1073741824 (1,0G) [application/octet-stream]
Sauvegarde en : «/dev/null»
15% [====================> ] 163 604 702 111M/s
wget -O /dev/null http://mafreebox6.freebox.fr/gen/1G
--2015-12-03 16:15:27-- http://mafreebox6.freebox.fr/gen/1G
Résolution de mafreebox6.freebox.fr (mafreebox6.freebox.fr)... fd0f:ee:b0::1
Connexion vers mafreebox6.freebox.fr (mafreebox6.freebox.fr)|fd0f:ee:b0::1|:80...connecté.
requête HTTP transmise, en attente de la réponse...302 Moved Temporarily
Emplacement: http://mafreebox6.freebox.fr:8095/fixed/1G [suivant]
--2015-12-03 16:15:27-- http://mafreebox6.freebox.fr:8095/fixed/1G
Connexion vers mafreebox6.freebox.fr (mafreebox6.freebox.fr)|fd0f:ee:b0::1|:8095...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 1073741824 (1,0G) [application/octet-stream]
Sauvegarde en : «/dev/null»
11% [===============> ] 124 876 182 59,4M/s
Débit divisé par 2 en local....
Alors c'est peut-être aussi lié à l'ERL qui bride, mais l'offload a l'air de bien fonctionner (CPU qui n’atteint même pas 15%).
à savoir:
1) ce /gen/1G est un soft local sur la box qui génère du traffic TCP (ala iperf), et il est plus couteux pour la box en CPU de gérer cette session TCP que de router le même type de traffic, donc n'attendez pas forcèment du gigabit garanti par cette voie.
2) le /gen/1G sera plus rapide en IPv4 car le hardware a une assistance pour le calcul des checksum en v4
3) les performances en routage IPv6 seront bien meilleures en mode routeur qu'en mode bridge, je n'ai pas optimisé le path du mode bridge étant donné le très faible pourcentage de la base abonné qui l'utilise (0.0028%)
-
Super, merci pour cette réponse.
à savoir:
1) ce /gen/1G est un soft local sur la box qui génère du traffic TCP (ala iperf), et il est plus couteux pour la box en CPU de gérer cette session TCP que de router le même type de traffic, donc n'attendez pas forcèment du gigabit garanti par cette voie.
Normal. Par contre ça tourne sur quel processeur ? Le Marvell ou le broadcom ?
2) le /gen/1G sera plus rapide en IPv4 car le hardware a une assistance pour le calcul des checksum en v4
D'accord, cela peut facilement expliquer la différence de performance. Il ne vous est pas possible de modifier le calcul de checksum fait par le hardware pour le TCP/UDP pour prendre en compte le pseudo header IPv6 ?
3) les performances en routage IPv6 seront bien meilleures en mode routeur qu'en mode bridge, je n'ai pas optimisé le path du mode bridge étant donné le très faible pourcentage de la base abonné qui l'utilise (0.0028%)
C'est bon à savoir.
J'ai l'impression que sur ce forum, beaucoup utilisent (ou ont utilisé) le server en mode bridge justement pour atteindre le Gb. Donc définitivement l'IPv6 en bridge est a oublier (du moins pour l'instant).
-
Super, merci pour cette réponse.Normal. Par contre ça tourne sur quel processeur ? Le Marvell ou le broadcom ?
Marvell, le Broadcom ne sert qu'au xDSL
D'accord, cela peut facilement expliquer la différence de performance. Il ne vous est pas possible de modifier le calcul de checksum fait par le hardware pour le TCP/UDP pour prendre en compte le pseudo header IPv6 ?
non, c'est le hardware qui parse le paquet et trouve tout seul l'offset du checksum L4 à mettre à jour, et il ne reconnait que IPv4
-
Marvell, le Broadcom ne sert qu'au xDSL
non, c'est le hardware qui parse le paquet et trouve tout seul l'offset du checksum L4 à mettre à jour, et il ne reconnait que IPv4
Ok merci.
Sinon, j'ai survolé rapidement la datasheet du marvell 88F6281 (même si d'après un démontage le chipset semble être un 88E6161). Autant pour la réception de paquets IPv6 les checksum, c'est à la main, autant je pense qu'en transmission TCP/UDP IPv6, il y a un moyen de limiter le calcul du checksum au pseuso-header, puis de laisser le hardware s'occuper du reste en "feignant" un entête IPv4 de 40 octets (<IPv4HdLen> = 0xa) et en lui passant le checksum du pseudo-header (dans <L4iChk> field) + <L4Chk_Mode> = 0 pour pas que le hard calcul avec le mauvais pseudo-header. Mais ça a peut-être déjà été testé et c'est même implèmenté (ou alors ça ne fonctionne pas).
A voir si le chipset de la freebox contient les même fields dans l'entête du paquet descriptor... en général les devices se ressemblent tous à quelques petites modifications près.
-
Et une petite question pour M. Bizon : il y a plusieurs hardware différent pour la Freebox révolution (4 il me semble avec des évolutions importantes sur le WiFi) : Les performances avec un câble Ethernet sont les mêmes pour les 4 hardwares ?
Il n'y a pas différentes générations de Marvell Kirkwood ? Ils sont tous à 1,5 Ghz ?
3) les performances en routage IPv6 seront bien meilleures en mode routeur qu'en mode bridge, je n'ai pas optimisé le path du mode bridge étant donné le très faible pourcentage de la base abonné qui l'utilise (0.0028%)
0,0028% ? Je pensais qu'il y en aurai plus. Si on part sur 140 000 clients Free FTTH, cela fait.... seulement 392 clients !
-
Ok merci.
Sinon, j'ai survolé rapidement la datasheet du marvell. Autant pour la réception de paquets IPv6 les checksum, c'est à la main, autant je pense qu'en transmission TCP/UDP IPv6, il y a un moyen de limiter le calcul du checksum au pseuso-header, puis de laisser le hardware s'occuper du reste en "feignant" un entête IPv4 de 40 octets (<IPv4HdLen> = 0xa) et en lui passant le checksum du pseudo-header (dans <L4iChk> field) + <L4Chk_Mode> = 0 pour pas que le hard calcul avec le mauvais pseudo-header. Mais ça a peut-être déjà été testé et c'est même implèmenté (ou alors ça ne fonctionne pas).
J'ai rarement reçu une réponse technique d'aussi grande qualité de la part d'un abonné...
ça mérite un test, je vous tiens au courant
-
Et une petite question pour M. Bizon : il y a plusieurs hardware différent pour la Freebox révolution (4 il me semble avec des évolutions importantes sur le WiFi) : Les performances avec un câble Ethernet sont les mêmes pour les 4 hardwares ?
Il n'y a pas différentes générations de Marvell Kirkwood ? Ils sont tous à 1,5 Ghz ?
au final 2 versions seulement, le wifi est sur un slot mini PCIe, ce qui change c'est la carte mère r1 ou r2
les performances sont légèrement supérieures sur la r2, mais étant donné qu'il reste de l'idle quand on route 1Gbit/s de TCP sur la r1, ça n'est pas visible, sauf à artificiellement reduire la MTU car c'est le pps qui limite
-
Super le HS....
Bon, sinon désolé Marco POLO, mais j'ai vu tellement de post concernant l'ERL que pour moi tout le monde sait que c'est un petit routeur plutôt performant :'( En fait non....
...No hay problemo ! (https://lafibre.info/images/smileys/@GregLand/en.gif)
-
J'ai rarement reçu une réponse technique d'aussi grande qualité de la part d'un abonné...
ça mérite un test, je vous tiens au courant
Avec plaisir, ça fait plaisir de voir des corps Free ici :)
-
D'ailleurs, c'est du dual-stack qui se déploie chez Orange, ou également du 6rd ?
Dual stack jusqu'à l'abonné, 6pe dans le backbone.
-
J'ai rarement reçu une réponse technique d'aussi grande qualité de la part d'un abonné...
ça mérite un test, je vous tiens au courant
Maxime, ça fait grave plaisir ce que tu dis. Déjà le fait que tu sois présent ici c'est très cool, mais en plus une réponse comme ça, c'est cool :) (bon faut avouer que Fuli10 tu déchires aussi !)
-
0,0028% ? Je pensais qu'il y en aurai plus. Si on part sur 140 000 clients Free FTTH, cela fait.... seulement 392 clients !
0.0028% sur 140.000, cela fait même 3.92 clients. Je pense que Maxime Bizon voulait dire 2.8%, soit 3920 ?
-
3) les performances en routage IPv6 seront bien meilleures en mode routeur qu'en mode bridge, je n'ai pas optimisé le path du mode bridge étant donné le très faible pourcentage de la base abonné qui l'utilise (0.0028%)
En tout cas, bravo Maxime pour le patch, et c'est sympa de venir en discuter ici. Pour moi, c'est la surprise de l'année chez Free. Tout le monde pensait que la limitation du débit venait du hardware de de la v6, pas assez puissant pour router du gigabit en mode routeur en NAT, et qu'il faudrait attendre la v7 pour cela.
Et merci pour tous ces développements depuis de nombreuses années chez Free.
-
0.0028% sur 140.000, cela fait même 3.92 clients. Je pense que Maxime Bizon voulait dire 2.8%, soit 3920 ?
c'est sur l'ensemble des Freebox v6
-
Même sur l'ensemble des v6, mettons 4 millions, cela ferait 0.000028 * 4 10^6 = 112 abonnés Free. Je pense quand même qu'il y en a un peu plus que cela. Déjà sur ce forum, on doit être plusieurs dizaines en IPv6. Bon, de toute façon, il est probable qu'une très petite minorité d'abonnés ont activé le v6. Mais c'est quand même l'avenir.
Il avait été dit que la France était bien placée dans le monde pour l'IPv6, justement grâce à Free. J'ai retrouvé un article d'UF qui parlait de 21% des adresses en IPv6 :
"Free, 1er opérateur français avec 21% de ses adresses en IPV6"
http://www.universfreebox.com/article/31000/Free-1er-operateur-francais-avec-21-de-ses-adresses-en-IPV6
En tout cas, je suis en IPv6 (mais en VDSL2...)
-
Sinon, j'ai survolé rapidement la datasheet du marvell 88F6281 (même si d'après un démontage le chipset semble être un 88E6161).
le 6161 c'est le switch, le 6281 c'est le kirkwood
Autant pour la réception de paquets IPv6 les checksum, c'est à la main, autant je pense qu'en transmission TCP/UDP IPv6, il y a un moyen de limiter le calcul du checksum au pseuso-header, puis de laisser le hardware s'occuper du reste en "feignant" un entête IPv4 de 40 octets (<IPv4HdLen> = 0xa) et en lui passant le checksum du pseudo-header (dans <L4iChk> field) + <L4Chk_Mode> = 0 pour pas que le hard calcul avec le mauvais pseudo-header. Mais ça a peut-être déjà été testé et c'est même implèmenté (ou alors ça ne fonctionne pas).
bon c'était trop beau.
pour connaître la taille de TCP + DATA afin de faire l'opération de checksum, le hardware se sert du total_length IPv4.
Au même endroit dans l'IPv6 il y a le flow label, généralement à 0. Dans ce cas çà donne une taille négative et ça checksum aléatoirement n'importe quoi.
en patchant le flow label pour chaque paquet pour émuler total_length cela fonctionne parfaitement, mais vous serez d'accord que ce n'est pas une bonne idée.
-
Même sur l'ensemble des v6, mettons 4 millions, cela ferait 0.000028 * 4 10^6 = 112 abonnés Free. Je pense quand même qu'il y
oops effectivement c'est 0.28% il est l'heure d'aller dormir.
-
Pour revenir au sujet de base je pense que Free bride le débit vers 950 Mb/s comme il le bride à 200 Mb/s le up.
Au vu des différents forums tous les tests affichés ne dépassent pas ce seuil.
A quand le test de 1 Gb/s ou plus ?
(https://www.speedtest.net/result/4878052594.png)
-
0,0028% ? Je pensais qu'il y en aurai plus. Si on part sur 140 000 clients Free FTTH, cela fait.... seulement 392 clients !
c'était 0.28% en fait mais ton chiffre est le bon
cette stats est sur l'ensemble des v6 toutefois (FTTH + xdsl), il y a peut être plus de gens en bridge en FTTH qu'en xdsl
-
Pour revenir au sujet de base je pense que Free bride le débit vers 950 Mb/s comme il le bride à 200 Mb/s le up.
Au vu des différents forums tous les tests affichés ne dépassent pas ce seuil.
A quand le test de 1 Gb/s ou plus ?
tututut
1 Gb/s c'est le débit ethernet (on invente rien, la techno s'appelle comme ça)
si en enlève tout l'overhead, ça doit donner environ 950 Mbit/s en IP, et il me semble que speedtest affiche le débit des données over-TCP donc encore moins (940 semble une bonne cible)
mais de toutes façons, votre PC est lui même connecté en gigabit ethernet, donc si c'est plein sur le WAN, c'est plein sur le LAN.
-
c'était 0.28% en fait mais ton chiffre est le bon
cette stats est sur l'ensemble des v6 toutefois (FTTH + xdsl), il y a peut être plus de gens en bridge en FTTH qu'en xdsl
Oui, parce que le mode (soi-disant) "bridge" est vraiment limité et celui que des précédentes Freebox était mieux!
Avant des optimisations, je pense que les freenautes voudraient des fonctionnalités.
-
Etant obligé de faire du MSS clamping sur l'ERL pour réduire de 20 octets le MSS supporté, c'est un bon indicateur que je suis en 6rd.
Aussi, j'ai foiré ma première configuration du clamping (je passais par une règle "modify" qui désactivait l’accélération hardware) du coup j'avais 20MB/s en IPv6 (toujours le max en IPv4) avant de me rendre compte qu'il fallait passer par une option du firewall (plutôt que le modify) pour avoir l’accélérateur hardware.
Mais pourquoi faire ça?
Tu peux pas diffuser le bonne MTU plutôt?
Après, mon opinion, c'est que le 6rd c'était bien... il y a 5 ans. Maintenant, ça doit disparaitre.... (c'est Soooooo 2010's ;) )
Oui c'est dommage d'être à la traine après avoir été leader!
-
Oui, parce que le mode (soi-disant) "bridge" est vraiment limité et celui que des précédentes Freebox était mieux!
sachant que c'est le même code...
la seule différence sur la v6 est qu'il n'y a pas de wifi sur le mode bridge, le but étant de mettre un routeur à l'arrière.
Avant des optimisations, je pense que les freenautes voudraient des fonctionnalités.
donnez les liens du bugtracker concernant les features demandées sur le mode bridge
-
Oui c'est dommage d'être à la traine après avoir été leader!
sachant que le 6RD est fait par la freebox, je ne vois pas ce que ça change pour l'abonné
on passerait en natif en gardant les même préfixes, personne ne verrait la différence.
la MTU plus basse à l'heure de l'IPv6 n'est plus un problème, car annoncée par RA.
-
sachant que le 6RD est fait par la freebox, je ne vois pas ce que ça change pour l'abonné
on passerait en natif en gardant les même préfixes, personne ne verrait la différence.
la MTU plus basse à l'heure de l'IPv6 n'est plus un problème, car annoncée par RA.
Est-ce que le MTU serait plus grand en natif ?
Est-ce que le 6RD utilise beaucoup de CPU ou est-il accéléré en hardware ? Ce qui pourrait impacter les débits en IPv6 par rapport à l'IPv4.
-
Est-ce que le MTU serait plus grand en natif ?
de 20 octets
Est-ce que le 6RD utilise beaucoup de CPU ou est-il accéléré en hardware ? Ce qui pourrait impacter les débits en IPv6 par rapport à l'IPv4.
avec le dernier firmware, 1 Gbit/s en mode routeur, y compris pour l'ipv6
-
Mais pourquoi faire ça?
Tu peux pas diffuser le bonne MTU plutôt?
Tout simplement parce que je ne connais pas assez bien l'IPv6. J’apprends dès maintenant car je suis sûr que ce sera "hype" dans quelques années de maitriser l'IPv6 ;)
Je viens d'apprendre qu'il est possible de faire ça avec le RA, et je vous en remercie tous, je vais tester :D (j'ai découvert le MSS clamping quand j'ai commencé à regarder pourquoi ça fragmente. Ça vient des explications sur le net qui concernent tous l'IPv4 et passent par le clamping....).
En tout c'est cool les forums, ça permet d'apprendre de ses erreurs afin d’éviter ça par exemple (http://dev.freebox.fr/bugs/task/16928).
J'ai rarement reçu une réponse technique d'aussi grande qualité de la part d'un abonné...
ça mérite un test, je vous tiens au courant
Ce n'est pas très qualitatif car c'est qu'un tas de données techniques bruts hors de tout contexte. Mais au moins j'étais sûr que vous comprendrez, ou qu'au moins vous saurez qui pourrait comprendre... ;)
le 6161 c'est le switch, le 6281 c'est le kirkwood
bon c'était trop beau.
pour connaître la taille de TCP + DATA afin de faire l'opération de checksum, le hardware se sert du total_length IPv4.
Au même endroit dans l'IPv6 il y a le flow label, généralement à 0. Dans ce cas çà donne une taille négative et ça checksum aléatoirement n'importe quoi.
en patchant le flow label pour chaque paquet pour émuler total_length cela fonctionne parfaitement, mais vous serez d'accord que ce n'est pas une bonne idée.
Dure de trouver la spec du 6161, mais ils doivent tous beaucoup se ressembler n'est ce pas ? ;)
Bon, sinon je pensais que le CRC se basait sur le champs "byte_count" du descripteur (et pas de l'entête IP). Tant pis.
Après s'il y a un loopback qui le permet, rien n’empêche de passer le paquet 2 fois, une fois juste pour le calcul du CRC, la seconde fois pour le transmettre. Mais bon, au final c'est complexifier le code pour bien peu de chose: au final seul le test débit local sera limité en IPv6 :D Je ne pense pas que les CRC sont recalculés pendant le "routage" du l'IPv6.
de 20 octets
Et dire que je râle sur le 6rd justement à cause de ces 20 octets... Il me semble qu'en utilisant le VC/Mux en ADSL, Free propose le meilleurs débit en ADSL justement parce que le VC/Mux permet de gagner quelques octets dans les entêtes ATM (bon OK, les entêtes ATM représentent un plus gros pourcentage sur une trame de 1500 octets). Et là on jette en pâture 20 octets/1500 quand on utilise l'IPv6 (en plus de "complexifier" le paramétrage d'un routeur en IPv6 derrière la box, ou du 6rd d'un modem pour supporter l'IPv6). Dommage...
-
de 20 octets
avec le dernier firmware, 1 Gbit/s en mode routeur, y compris pour l'ipv6
Ce gain colossal avec la 3.2.0 est du à un gros travail d'optimisation de tous les codes propriétaires ou est-ce aussi du à un changement de version du noyau ?
Il me semble que plusieurs des dernières versions du noyau ont apporté pas mal d'améliorations, aussi bien sur les architectures ARM que dans la gestion réseau, système de fichier EXT3/4 et bien d'autre choses qui peuvent avoir un rapport avec le FBX SERVER.
-
Tout simplement parce que je ne connais pas assez bien l'IPv6.
En réalité, à part l'ajout des adresses routables autoconf (l'autoconf n'existait en IPv4 qu'en local non-routable : adresse APIPA), IPv6 ressemble à IPv4.
En IPv4, tu peux utiliser un tunnel sur IP exactement comme 6in4 utilisé chez Free : le 4in4.
En IPv4, tu peux annoncer la MTU aussi bien en DHCP qu'en PPP.
La MTU sera enregistrée par le composant IP qui va la transmettre aux couches UDP, TCP...
J’apprends dès maintenant car je suis sûr que ce sera "hype" dans quelques années de maitriser l'IPv6 ;)
C'est déjà "hype"!
C'est facile parce que les concepts IPv6 sont proches ou équivalents à ceux de IPv4 raisonnable (donc sans le NAT pour économiser les adresses).
Je viens d'apprendre qu'il est possible de faire ça avec le RA, et je vous en remercie tous, je vais tester :D (j'ai découvert le MSS clamping quand j'ai commencé à regarder pourquoi ça fragmente. Ça vient des explications sur le net qui concernent tous l'IPv4 et passent par le clamping....).
Le MSS ne concerne que TCP, il n'y pas que TCP pour les communications client-serveur dans la vie. Et Google Chrome remet à l'honneur UDP pour surfer sur le Web.
Fixer la MTU dans par interface ou bien la table de routage concerne tous les protocoles.
Et dire que je râle sur le 6rd justement à cause de ces 20 octets... Il me semble qu'en utilisant le VC/Mux en ADSL, Free propose le meilleurs débit en ADSL justement parce que le VC/Mux permet de gagner quelques octets dans les entêtes ATM (bon OK, les entêtes ATM représentent un plus gros pourcentage sur une trame de 1500 octets). Et là on jette en pâture 20 octets/1500 quand on utilise l'IPv6 (en plus de "complexifier" le paramétrage d'un routeur en IPv6 derrière la box, ou du 6rd d'un modem pour supporter l'IPv6). Dommage...
Il y a aussi le critère de "pureté".
-
Effectivement, il serait intéressant de savoir comment Google détermine la MTU maximum dans son protocole QUIC (Quick UDP Internet Connections) (https://en.wikipedia.org/wiki/QUIC) qui remplace TCP dans Chrome pour certains services Google.
J'imagine que Chrome fait une connexion TCP pour récupérer le MTU via la MSS transmis le paquet [SYN-ACK] du serveur et éventuellement modifié par le réseau pour diminuer la MTU.
-
2. Protocol overview
In this memo, we describe a technique for using the Don't Fragment
(DF) bit in the IP header to dynamically discover the PMTU of a path.
The basic idea is that a source host initially assumes that the PMTU
of a path is the (known) MTU of its first hop, and sends all
datagrams on that path with the DF bit set. If any of the datagrams
are too large to be forwarded without fragmentation by some router
along the path, that router will discard them and return ICMP
Destination Unreachable messages with a code meaning "fragmentation
needed and DF set" [7]. Upon receipt of such a message (henceforth
called a "Datagram Too Big" message), the source host reduces its
assumed PMTU for the path.
La RFC 1191 (https://tools.ietf.org/html/rfc1191) date de 1990!
-
Effectivement, il serait intéressant de savoir comment Google détermine la MTU maximum dans son protocole QUIC (Quick UDP Internet Connections) (https://en.wikipedia.org/wiki/QUIC) qui remplace TCP dans Chrome pour certains services Google.
J'imagine que Chrome fait une connexion TCP pour récupérer le MTU via la MSS transmis le paquet [SYN-ACK] du serveur et éventuellement modifié par le réseau pour diminuer la MTU.
Dixit la doc (https://www.chromium.org/quic) mais elle n'est peut-etre pas a jour le découverte de MTU dans QUIC est en chantier donc pour le moment c'est un MTU max a 1350 en IPv6 et 1370 en IPv4.
-
man ip(7) (http://man7.org/linux/man-pages/man7/ip.7.html)
IP_MTU (since Linux 2.2)
Retrieve the current known path MTU of the current socket.
Returns an integer.
IP_MTU is valid only for getsockopt(2) and can be employed
only when the socket has been connected.
IP_MTU_DISCOVER (since Linux 2.2)
Set or receive the Path MTU Discovery setting for a socket.
When enabled, Linux will perform Path MTU Discovery as defined
in RFC 1191 on SOCK_STREAM sockets. For non-SOCK_STREAM
sockets, IP_PMTUDISC_DO forces the don't-fragment flag to be
set on all outgoing packets. It is the user's responsibility
to packetize the data in MTU-sized chunks and to do the
retransmits if necessary. The kernel will reject (with
EMSGSIZE) datagrams that are bigger than the known path MTU.
IP_PMTUDISC_WANT will fragment a datagram if needed according
to the path MTU, or will set the don't-fragment flag
otherwise.
The system-wide default can be toggled between
IP_PMTUDISC_WANT and IP_PMTUDISC_DONT by writing
(respectively, zero and nonzero values) to the
/proc/sys/net/ipv4/ip_no_pmtu_disc file.
Path MTU discovery value Meaning
IP_PMTUDISC_WANT Use per-route settings.
IP_PMTUDISC_DONT Never do Path MTU Discovery.
IP_PMTUDISC_DO Always do Path MTU Discovery.
IP_PMTUDISC_PROBE Set DF but ignore Path MTU.
When PMTU discovery is enabled, the kernel automatically keeps
track of the path MTU per destination host. When it is
connected to a specific peer with connect(2), the currently
known path MTU can be retrieved conveniently using the IP_MTU
socket option (e.g., after an EMSGSIZE error occurred). The
path MTU may change over time. For connectionless sockets
with many destinations, the new MTU for a given destination
can also be accessed using the error queue (see IP_RECVERR).
A new error will be queued for every incoming MTU update.
While MTU discovery is in progress, initial packets from
datagram sockets may be dropped. Applications using UDP
should be aware of this and not take it into account for their
packet retransmit strategy.
To bootstrap the path MTU discovery process on unconnected
sockets, it is possible to start with a big datagram size (up
to 64K-headers bytes long) and let it shrink by updates of the
path MTU.
To get an initial estimate of the path MTU, connect a datagram
socket to the destination address using connect(2) and
retrieve the MTU by calling getsockopt(2) with the IP_MTU
option.
It is possible to implement RFC 4821 MTU probing with
SOCK_DGRAM or SOCK_RAW sockets by setting a value of
IP_PMTUDISC_PROBE (available since Linux 2.6.22). This is
also particularly useful for diagnostic tools such as
tracepath( 8 ) that wish to deliberately send probe packets
larger than the observed Path MTU.
-
Ceci étant dit, plein de définitions sur ces deux articles :
https://lafibre.info/raccordement-immeuble/lexique/
https://lafibre.info/ftth-la-fibre-optique-gpon-ou-p2p/techno-fibre/
J'ai retrouvé, au fin fond de mes marque-pages, des sites assez complets donnant la définition de la plupart des acronymes utilisés en informatique:
Le premier sur le site de WikiPédia/WikiWand (http://www.wikiwand.com/fr/Abr%C3%A9viations_en_informatique_A#/overview), et
Le Jargon Français (http://jargonf.org/wiki/Accueil).
Pour ceux que ça intéresse... (https://lafibre.info/images/smileys/@GregLand/bk.gif)
-
Attention si vous testez les débits de votre réseau local en utilisant votre Freebox comme serveur local. Depuis la dernière mise à jour Free offre la possibilité de se connecter de façon sécurisée à la box, ce qui est très bien mais qui a un impact monstrueux sur les débits.
Visiblement un bug empêche de se connecter à la Freebox en FTP non sécurisé depuis cette mise à jour et je suis coincé autour de 5 Mo/s alors que j'étais plutôt à 45 Mo/s avant (limité par le disque dur).
Peut-être que mbizon pourra nous dire s'il reste des optimisations à faire ou si on est déjà au taquet.
-
Je pense que tu parles de la mise à jour à la 3.3, et son support de let's encrypt ? Oui, il est connu que le cryptage peut être lourd pour le processeur, et faire baisser les débits. Je l'avais constaté avec un boîtier VPN.
Je viens d'ailleurs de faire cette mise à jour, et d'activer le domaine et la demande de certificat. Je n'ai pas encore fait de test de débit interne sur le LAN.
-
Le seul vrai problème (que j'ai déjà rapporté sur le bug tracker) c'est qu'on ne puisse plus se connecter en FTP non sécurisé. Pour le débit ça me parait pas anormal même si la baisse est drastique.
-
J'ai retrouvé, au fin fond de mes marque-pages, des sites assez complets donnant la définition de la plupart des acronymes utilisés en informatique:
Le premier sur le site de WikiPédia/WikiWand (http://www.wikiwand.com/fr/Abr%C3%A9viations_en_informatique_A#/overview), et
Le Jargon Français (http://jargonf.org/wiki/Accueil).
Pour ceux que ça intéresse... (https://lafibre.info/images/smileys/@GregLand/bk.gif)
Merci, c'est dans mes marque-pages également!
-
Je pense que tu parles de la mise à jour à la 3.3, et son support de let's encrypt ? Oui, il est connu que le cryptage peut être lourd pour le processeur, et faire baisser les débits. Je l'avais constaté avec un boîtier VPN.
Je viens d'ailleurs de faire cette mise à jour, et d'activer le domaine et la demande de certificat. Je n'ai pas encore fait de test de débit interne sur le LAN.
Pourtant le CPU de la V6 (Kirkwood 88F6281) supporte l'acceleration matérielle pour le chiffrement (demontrer ici avec SSL a l'époque (https://www.altechnative.net/2011/05/22/hardware-accelerated-ssl-on-marvell-kirkwood-arm-using-openssl-on-fedora/)). Free ne l'a peut-etre pas utilisé ?
-
Ouaip, c'est ce que j'espérais apprendre de Maxime Bizon. Ça me parait pas impossible qu'ils aient choisi une implèmentation complètement logicielle pour une première version.
-
Pourtant le CPU de la V6 (Kirkwood 88F6281) supporte l'acceleration matérielle pour le chiffrement (demontrer ici avec SSL a l'époque (https://www.altechnative.net/2011/05/22/hardware-accelerated-ssl-on-marvell-kirkwood-arm-using-openssl-on-fedora/)). Free ne l'a peut-etre pas utilisé ?
Je viens de regarder le lien, cela ne semble pas tout à fait direct, et c'est peut-être pourquoi cela n'a pas encore été implèmenté. Maxime Bizon ignore peut-être cette possibilité ?
The reason kernel patches are required is because acceleration depends on the BSD style cryptodev kernel interface. There is an alternative, more up to date project that provides this much less intrusively: Cryptodev-linux. It provides a standalone driver that doesn’t require the entire kernel to be recompiled for it, and it works with the 2.6.36+ kernels.
-
Attention si vous testez les débits de votre réseau local en utilisant votre Freebox comme serveur local. Depuis la dernière mise à jour Free offre la possibilité de se connecter de façon sécurisée à la box, ce qui est très bien mais qui a un impact monstrueux sur les débits.
Visiblement un bug empêche de se connecter à la Freebox en FTP non sécurisé depuis cette mise à jour et je suis coincé autour de 5 Mo/s alors que j'étais plutôt à 45 Mo/s avant (limité par le disque dur).
désolé, on regarde pour corriger dans la prochaine version
Peut-être que mbizon pourra nous dire s'il reste des optimisations à faire ou si on est déjà au taquet.
le bloc hardware n'est pas (encore) utilisé
-
Pas de problème, merci pour le retour ! :)