Auteur Sujet: GPON-ONU-34-20BI fonctionnel mais très lent...  (Lu 1377 fois)

0 Membres et 1 Invité sur ce sujet

Knight

  • Abonné Bell (Canada)
  • *
  • Messages: 3
GPON-ONU-34-20BI fonctionnel mais très lent...
« le: 01 octobre 2022 à 21:36:16 »
Bonjour!

Après des mois d'attente j'ai reçu mon GPON-ONU-34-20BI de chez FS...

Je lui ai donné le même numéro de série enregistré chez mon fournisseur. Il s'agit de la seule forme d'authentification qu'ils utilisent. J'avais fait la même chose avec un Nokia G-010S-A il y a de ça quelques mois.

Aves le Nokia G-010S-A, j'ai près du gigabit en téléchargement, un peu moins en téléversement.

Si je le remplace par le GPON-ONU-34-20BI, j'ai moins de 10Mbps dans les deux directions...

Est-ce que quelqu'un en connais la cause, configurer le GPON-ONU-34-20BI devrait être comparable au G-010S-A et j'ai suivi les instructions disponible ici à la lettre je crois.

J'ai essayé le GPON-ONU-34-20BI dans le même convertisseur de média que le G-010S-A ainsi que dans une carte Intel X520-DA2.

Le convertisseur de media n'est que gigabit, la X520-DA2 est 10Gbps et 1Gbps. Tel que prévu le GPON-ONU-34-20BI se synchronise à 1Gbps car ni l'un ni l'autre ne supporte 2.5Gbps (j’attends encore mon Hellotek 2.5Gbps).

La raison pour laquelle je veux passer du G-010S-A au GPON-ONU-34-20BI est que, même en applicant le correctif, le G-010S-A ne fonctionne pas partout (il est totalement instable avec ma X520-DA2...

Merci et bonne journée!

hwti

  • Abonné Orange Fibre
  • *
  • Messages: 2 237
  • Chambly (60)
GPON-ONU-34-20BI fonctionnel mais très lent...
« Réponse #1 le: 02 octobre 2022 à 03:27:38 »
Le "correctif" du G-010S-A, c'est le mod de la broche 6 ?


D'abord, il faudrait faire des tests iperf3 en UDP pour vérifier si le problème est bien dans les deux directions, ou si les pertes très importantes dans un sens pénalisent aussi l'autre en TCP.
Je donne l'exemple avec un serveur FR, mais ce serait mieux d'en avoir un plus proche :
 - iperf3 -c speedtest.milkywan.fr -p 9200 -u -b 500M -R
 - iperf3 -c speedtest.milkywan.fr -p 9200 -u -b 500M

hwti

  • Abonné Orange Fibre
  • *
  • Messages: 2 237
  • Chambly (60)
GPON-ONU-34-20BI fonctionnel mais très lent...
« Réponse #2 le: 02 octobre 2022 à 03:29:08 »
Pour ce qui est du comportement de l'ONT, s'il n'y a pas de problème de niveau de signal, peut-être qu'il y a des différences dans la gestion de traffic.
Je sais que certains ont des problèmes de débit avec le GPON-ONU-34-20BI, mais à priori c'est uniquement en upload (chez Bouygues par exemple).
Avec Bouygues, avec un DFP-34X-2C2 (Realtek), avec le OMCI_WAN_QOS_QUEUE_NUM=0 par défaut, les débits sont très faibles dans les deux sens, et avec 4 tout se passe bien.
Donc on peut avoir soit un OLT qui exige un nombre suffisant de files, ou alors un ONT qui bride très fortement quand l'OLT a poussé une configuration avec plus de files que ce qu'il y a de configuré.

Sur le G-010S-A, avec la fibre connectée, on peut faire :
omcli omciMgr redirect /dev/pts/0
omcli console displaymibs all
Ca va donner énormément d'informations.

Sur le GPON-ONU-34-20BI, c'est le mib file qui configure tout.
On peut soit regarder le mib file, déjà son nom donne des informations sur la configuration.
On peut également lancer "omcid -c", et utiliser les commandes :
 - help (si besoin)
 - md (mib_dump)
 - mda (mib_dump_all)
A voir ce que ça donne.

L'idée est d'essayer de comparer les différentes configurations qui pourraient être liées à la gestion des débits.
Ca peut aussi bien être ce que l'ONT expose, que ce que l'OLT configure.
Pour ça il faut regarder avec la spec OMCI.

Pour les capacités déclarées par l'ONT, le G-010S-A a :
 - dans ONTGpon, "Traffic Management:     0x02" (pour "Priority and rate controlled") à priori
 - dans ONT2Gpon, il y a "Total priority queue number" et "Total traffic scheduler number" (sur le GPON-ONU-34-20BI, ça dépend probablement du MIB file), et "QoS configuration flexibility"

Selon la spec, dans les valeurs intéressantes qui peuvent être lues et/ou positionnées par l'OLT, on a :
 - Circuit Pack (ME #6) (éventuellement)
 - GEM Port Network CTP (ME #268)
 - Priority Queue (ME #277)
 - Traffic Scheduler (ME #278)
 - Traffic Descriptor (ME #280)
Là c'est assez compliqué, on peut essayer de comparer les deux pour voir si sur le GPON-ONU-34-20BI il y aurait des "pointeurs" cassés ou des tables tronquées (si par exemple l'OLT demande trop de files par rapport à ce qui est supporté).

Knight

  • Abonné Bell (Canada)
  • *
  • Messages: 3
GPON-ONU-34-20BI fonctionnel mais très lent...
« Réponse #3 le: 04 octobre 2022 à 02:44:16 »
Bonjour!

Le "correctif" du G-010S-A, c'est le mod de la broche 6 ?

Oui...

réf: https://rsaxvc.net/blog/2020/8/15/Nokia_G-010S-A_Pin_6_Issue.html (un lien parmi tant d'autres...)

D'abord, il faudrait faire des tests iperf3 en UDP pour vérifier si le problème est bien dans les deux directions, ou si les pertes très importantes dans un sens pénalisent aussi l'autre en TCP.
Je donne l'exemple avec un serveur FR, mais ce serait mieux d'en avoir un plus proche :
 - iperf3 -c speedtest.milkywan.fr -p 9200 -u -b 500M -R
 - iperf3 -c speedtest.milkywan.fr -p 9200 -u -b 500M

Je vais tenter de faire ces tests en fin de semaine prochaine (il s'agit d'une fin de semaine de 3 jours ici...).

Pour le serveur, si je peux utiliser les mêmes que l'appli speedtest j'en utiliserai un de mon fournisseur Internet...

J'ai discuté avec quelqu'un qui a le même problème que moi avec un module différent (mais avec le même fournisseur Internet) et selon lui il s'agit d'un problème d'interprétation de la limite de vitesse possible...

Voici une traduction plus ou moins littérale de ses propos:

Citer
Ce que vous voyez est une incompatibilité entre les unités de vitesse maximale. L'OLT du fournisseur envoie l'information en Kbps alors que votre ONT l'interprète en Bps, créant un ralentissement de 125x (c-à-d 1000Mbps devient 8Mbps).

Il dit avoir constaté le même problème avec un G-010S-P (Nokia) et un MA5671 (Huawei)...

(Ce qui est pour le moins cocasse car je n'ai pas ce problème avec le G-010S-A, le petit frère du G-010S-P...)

Il suggère de trouver une manière de reconfigurer manuellement cette limite ou de trouver une manière de modifier le OMCID dans le logiciel embarqué ("firmware") pour reconnaître une vitesse maximale spécifiée en Kbps...

Est-ce possible avec le GPON-ONU-34-20BI?

Merci et bonne journée!
« Modifié: 04 octobre 2022 à 05:51:20 par Knight »

hwti

  • Abonné Orange Fibre
  • *
  • Messages: 2 237
  • Chambly (60)
GPON-ONU-34-20BI fonctionnel mais très lent...
« Réponse #4 le: 04 octobre 2022 à 07:01:37 »
Quelles sont les instabilités du G-010S-A avec la X520-DA2 ?

Pour le serveur, si je peux utiliser les mêmes que l'appli speedtest j'en utiliserai un de mon fournisseur Internet...
Speedtest et iperf3 c'est différent, certains serveurs font les deux, mais c'est loin d'être systématique.
Les serveurs iperf3 sont plus rares, encore plus en UDP.

J'ai discuté avec quelqu'un qui a le même problème que moi avec un module différent (mais avec le même fournisseur Internet) et selon lui il s'agit d'un problème d'interprétation de la limite de vitesse possible...

Voici une traduction plus ou moins littérale de ses propos:

Il dit avoir constaté le même problème avec un G-010S-P (Nokia) et un MA5671 (Huawei)...

(Ce qui est pour le moins cocasse car je n'ai pas ce problème avec le G-010S-A, le petit frère du G-010S-P...)

Il suggère de trouver une manière de reconfigurer manuellement cette limite ou de trouver une manière de modifier le OMCID dans le logiciel embarqué ("firmware") pour reconnaître une vitesse maximale spécifiée en Kbps...
C'est intéressant, il y a deux variantes de démon OMCI :
 - le omcid d'origine du SDK Lantiq (plus ou moins modifié selon les modèles) : MA5671A, GPON-ONU-34-20BI, G-010S-P (mais pas par défaut)
 - le omciMgr de Alcatel/Nokia : G-010S-A, G-010S-P

Le G-010S-P est plus ancien, donc le G-010S-A a peut-être des corrections qu'il n'a pas, notamment pour la compatibilité avec des OLT différents.

Modifier le binaire est difficile, il faut pouvoir identifier la partie de code responsable du traitement de la commande de configuration dont l'interprétation pose problème.
En revanche, on peut éventuellement faire croire à l'OLT qu'on ne supporte pas la limitation de débit, et peut-être donc s'en passer.

Knight

  • Abonné Bell (Canada)
  • *
  • Messages: 3
GPON-ONU-34-20BI fonctionnel mais très lent...
« Réponse #5 le: 26 octobre 2022 à 05:00:04 »
Désolé pour la réponse tardive, les dernières semaines ont été très mouvementées pour moi...

Je n'ai guère pu investiguer grand chose...

Quelles sont les instabilités du G-010S-A avec la X520-DA2 ?

En revanche les problèmes que j'avais ici j'en suis venu à bout...

Lorsque j'installais le G-010S-A dans la X520-DA2 mon pare-feu pfSense perdait toute connectivité à l'Internet (même avec la bonne configuration). Encore pire, et ça je n'ai pas pu l'expliquer, la connexion des autres cartes avec mon pfSense semblait instable...

Les cartes réseau sont toutes du Intel mais n'utilise pas le même pilote il m’apparaît donc impossible que le problème d'une carte réseau affecte de telle manière les autres. Il faut croire que ce problème créait une instabilité au niveau du système d'exploitation et c'est ce qui me donnait l'impression que les autres cartes réseau étaient en problème...

J'ai aussi tenter d'utiliser le G-010S-A dans un convertisseur de média 2.5Gbps et rien ne fonctionnait.

Je m'étais assuré de configurer le support 2.5Gbps à l'aide de "fw_setenv sgmii_mode 5"...

Tout était nickel quand le G-010S-A était dans un convertisseur de média 1Gbps toutefois, c'est le seul endroit où il fonctionnait correctement...

Je me suis rendu compte que c'est la version du logiciel embarqué ("firmware") que j'avais mis sur le G-010S-A qui causait ce problème...

La 3FE46398BGCB22 causait mes problèmes d'instabilité avec la X520-DA2 ainsi qu'avec le convertisseur de média 2.5Gbps (un Hellotek).

J'ai installé une version précédente (la 3FE47111BFHB32) est immédiatement tout à commencé à fonctionner...

Je me suis dit que je devrais trouver les coordonnées de la personne qui a publié ces logiciels embarqués ("firmware") sur GitHub et lui dire que ce serait probablement une bonne idée de mettre un avertissement au sujet de la version 3FE46398BGCB22...

Je crois que je l'ai trouvé, c'est vous...  ;D

(même code d'usager et intéressé par les même sujets...)

Je ne sais pas si c'est dû à une régression pour corriger un autre problème, si c'est parce qu'elle est personnalisée pour un autre fournisseur Internet que le mien, parce qu'elle n'est pas compatible avec la révision du G-010S-A que j'ai ou autre chose, une chose est sûre elle est très problématique dans le mauvais environnement...

Speedtest et iperf3 c'est différent, certains serveurs font les deux, mais c'est loin d'être systématique.
Les serveurs iperf3 sont plus rares, encore plus en UDP.

Ok, c'est donc loin d'être sûr que je pourrais utiliser un des serveurs de mon founisseur Internet...

C'est intéressant, il y a deux variantes de démon OMCI :
 - le omcid d'origine du SDK Lantiq (plus ou moins modifié selon les modèles) : MA5671A, GPON-ONU-34-20BI, G-010S-P (mais pas par défaut)
 - le omciMgr de Alcatel/Nokia : G-010S-A, G-010S-P

Le G-010S-P est plus ancien, donc le G-010S-A a peut-être des corrections qu'il n'a pas, notamment pour la compatibilité avec des OLT différents.

J'avais cru comprendre que certains d'entre-eux acceptait le logiciel embarqué ("firmware") d'un autre modèle, c'est vrai ou pas?

(Il serait trop simple de pouvoir utiliser le logiciel embarqué du G-010S-A sur le GPON-ONU-34-20BI...)

Savez-vous s'il existe des mises à jour du logiciel embarqué du GPON-ONU-34-20BI? Peut-être qu'une autre version aurait un meilleur comportement...

Modifier le binaire est difficile, il faut pouvoir identifier la partie de code responsable du traitement de la commande de configuration dont l'interprétation pose problème.

Ok, je comprend totalement, je suis programmeur... Je n'étais pas sûr si la personne avec qui j'avais discuté parlait d'un changement de configuration ou de décompiler et de modifier le logiciel embarqué ("firmware")...

En revanche, on peut éventuellement faire croire à l'OLT qu'on ne supporte pas la limitation de débit, et peut-être donc s'en passer.

Et quel serait les aspects pervers de faire ceci?

Je me demandais autre chose...

Savez-vous si les versions du logiciel, le type de module, etc... est communiqué à l'équipement de mon fournisseur?

Je n'ai changé que le numéro de série du GPON-ONU-34-20BI, se pourrait-il que si je changerais autre chose l'équipement du fournisseur Internet donnerait une réponse compatible avec le GPON-ONU-34-20BI?

(Un peu comme un navigateur qui communique son User-Agent à un site Internet et que celui-ci l'utilise pour donner une réponse compatible au navigateur?)

Merci beaucoup et bonne journée!
« Modifié: 26 octobre 2022 à 05:24:29 par Knight »

hwti

  • Abonné Orange Fibre
  • *
  • Messages: 2 237
  • Chambly (60)
GPON-ONU-34-20BI fonctionnel mais très lent...
« Réponse #6 le: 26 octobre 2022 à 11:51:16 »
Je me suis rendu compte que c'est la version du logiciel embarqué ("firmware") que j'avais mis sur le G-010S-A qui causait ce problème...

La 3FE46398BGCB22 causait mes problèmes d'instabilité avec la X520-DA2 ainsi qu'avec le convertisseur de média 2.5Gbps (un Hellotek).

J'ai installé une version précédente (la 3FE47111BFHB32) est immédiatement tout à commencé à fonctionner...
C'est la première fois que j'entends parler d'un problème comme ça, et en plus il est difficile à caractériser.
On pourrait comparer les paramètres du lien Ethernet ("onu lanpsg" 0 et autres), mais même s'ils étaient incorrects je ne vois pas comment ça pourrait perturber autre chose que le port dans lequel il est inséré.
La seule chose qui s'en approche, ce serait le problème des GPON-ONU-34-20BI qui font "planter" le bus I2C sur certains switchs/routeurs Mikrotik.
Mais pour perturber une autre carte, il faudrait que ça coincide avec un bug du driver ou du kernel (qui n'aimerait pas les données présentées en I2C, ou resterait bloqué pendant la lecture avec un mutex ou thread partagé entre les différentes cartes).
S'il n'y a pas de traces kernel de pfSense sur l'erreur, je ne sais pas trop comment avancer, à part tenter Linux par exemple (pour voir s'il y a le même type de problèmes avec le même firmware du le G-010S-A et la même X520-DA2).

J'avais cru comprendre que certains d'entre-eux acceptait le logiciel embarqué ("firmware") d'un autre modèle, c'est vrai ou pas?

(Il serait trop simple de pouvoir utiliser le logiciel embarqué du G-010S-A sur le GPON-ONU-34-20BI...)
Certains ont effectivement "converti" des ONT, le plus courant c'est MA5671A => Carlitoxx.
En principe, G-010S-P, MA5671A, Carlitoxx sont censés être quasiment identiques, et à priori le GPON-ONU-34-20BI aussi.
Le G-010S-A est légèrement différent, mais certaines personnes ont déjà tenté des cross-flash.
Mais il faut toujours faire attention à toujours bien utiliser les bonnes données de calibration ensuite, et en cas d'échec la récupération ne peut se faire qu'avec l'UART.

Mais si le 3FE47111BFHB32 fonctionne, autant utiliser le G-010S-A avec, que d'essayer de le flasher sur le GPON-ONU-34-20BI, non ?

Savez-vous s'il existe des mises à jour du logiciel embarqué du GPON-ONU-34-20BI? Peut-être qu'une autre version aurait un meilleur comportement...
Je ne sais pas, il faut demander au support FS.com, mais pour les autres personnes ayant eu des problèmes de débit cela n'a pas été très constructif...

Savez-vous si les versions du logiciel, le type de module, etc... est communiqué à l'équipement de mon fournisseur?

Je n'ai changé que le numéro de série du GPON-ONU-34-20BI, se pourrait-il que si je changerais autre chose l'équipement du fournisseur Internet donnerait une réponse compatible avec le GPON-ONU-34-20BI?

(Un peu comme un navigateur qui communique son User-Agent à un site Internet et que celui-ci l'utilise pour donner une réponse compatible au navigateur?)
Il y a beaucoup d'informations qui sont remontées.
Changer le numéro de série en masque une, puisque les 4 premières lettres correspondent normalement au fabricant (ALCL = Alcatel / Nokia pour le G-010S-A, ...).
Compte tenu de ce qui est fait côté ONT, et des comportements observés côté OLT, tout est envisageable en terme d'interopérabilité.
Un OLT peut essayer de s'adapter au modèle, à la marque, à certaines caractéristiques, voire au comportement dynamique de l'ONT.
Mais il peut aussi refuser de fonctionner face à un ONT inconnu, de manière plus ou moins évidente : erreur, reboot forcé, arrêt des échanges avant d'avoir tout configuré (VLAN, ...), ou configuration complète mais blocage silencieux du trafic...
Malheureusement c'est une boite noire pour nous, ça dépend de la marque et du modèle de l'OLT, et de son firmware et de sa configuration (qui peuvent être spécifiques au FAI).