Scripter le polling DDM par I2C : quels octets d'A2h portent les valeurs live et lesquels les seuils
J'écris un petit poller qui va chercher température, tension, bias et puissance optique directement sur les modules de nos boîtiers whitebox, pour avoir une courbe de tendance au lieu que quelqu'un regarde un lien à l'œil une fois qu'il a déjà commencé à faire des erreurs. Le NOS affiche de jolies valeurs, mais je veux les nombres bruts avec les seuils du vendeur à côté, pour que les niveaux d'alarme soient cohérents sur des optiques mixtes plutôt qu'écrits à la main modèle par modèle.
Banc :
- hôte Linux, cages de modules derrière un simple mux I2C, bus 1
- optiques SFP, SFP+ et SFP28 mixtes de trois vendeurs
- lecture avec i2c-tools uniquement, pas de SDK vendeur
Je lis la page de diagnostics comme ça :
# i2cdump -y 1 0x51et voici mon parseur en cours, là où je ne suis pas sûr :
temp = s16(a2[96:98]) / 256.0
vcc = u16(a2[98:100]) * 100e-6
bias = u16(a2[100:102]) * 2e-6Ce qui a déjà été fait :
- comparé mes valeurs calculées à ce qu'affiche le NOS : proche sur certains modules, clairement faux sur d'autres
- lu le SFF-8472, mais je ne peux toujours pas dire avec confiance où finit le bloc des seuils et où commence la zone de calibration
- écarté le mux en dumpant le même module sur un bus direct, mêmes chiffres
Donc : quelle est la carte réelle de A2h, où vivent les seuils, où commencent les valeurs temps réel, et y a-t-il un drapeau quelque part qui me dit si le module attend que je fasse quelque chose à ces mots bruts avant de leur faire confiance ?
Comments 7
Quelles valeurs sont clairement fausses, les quatre ou seulement le bias et les puissances ? Ça décide généralement de toute la réponse. Dumpe aussi A0h pendant que tu y es et regarde l'octet 92 : il te dit si le module rapporte des diagnostics du tout, et s'il est calibré en interne ou en externe. Si une partie de ton parc est calibrée en externe et que ton parseur traite tout le monde pareil, alors l'écart est un comportement attendu et pas un bug dans ton arithmétique.
J'ai extrait l'octet 92 d'A0h sur tout le plateau et ce n'est pas uniforme. Certains modules signalent une calibration externe, d'autres non, et ceux qui divergent de la sortie du NOS sont exactement les externes. Température et tension sont dans le bruit sur tout le monde ; bias et les deux puissances sont ce qui dérive. Donc on dirait qu'il me manque une étape plutôt que je lise les mauvais offsets. Qu'est-ce que je dois réellement faire avec les mots bruts sur ce sous-ensemble ?
A2h à 0x51 se découpe en quatre morceaux qui te concernent :
Unités dans le bloc live : température signée, 1/256 °C par LSB ; tension 100 µV par LSB ; bias 2 µA ; puissance TX et RX 0,1 µW. Ton extrait échelonne déjà ça correctement, donc les offsets ne sont pas ton problème.
La pièce manquante, c'est le drapeau que tu viens de trouver. Sur un module calibré en externe, les mots à 96-105 sont une sortie ADC brute, et les constantes à 56-95 doivent être appliquées avant que ça veuille dire quelque chose ; un module calibré en interne a déjà fait ce travail pour toi. Cette branche est la différence entre tes deux groupes.
Si tu veux une disposition à vérifier plutôt que de me croire sur parole, le header sff8472.h de FreeBSD et py-sfp-eeprom détaillent tous les deux les offsets champ par champ. Je vérifierais quand même un module par vendeur contre une valeur de confiance avant d'y accrocher des alarmes.
Ça vaut le coup d'ajouter pourquoi le bloc des seuils est la moitié intéressante. Les valeurs en 0-55 sont dans les mêmes unités que le bloc live, donc une fois que ton échelle est correcte, tu récupères gratuitement les points d'alarme et d'avertissement propres au vendeur et tu n'as jamais besoin d'inventer des limites par modèle. Ça seul justifie de lire A2h directement plutôt que de parser l'affichage joli de quelqu'un d'autre.
Une remarque pratique en faisant tourner ça sur un plateau mixte : garde un intervalle de polling modeste. Cette page est une simple lecture I2C et le contrôleur du module n'est pas rapide. Marteler chaque module chaque seconde sur un bus qui est aussi derrière un mux est un bon moyen de collecter des lectures courtes qui ressemblent exactement à des optiques qui flappent sur tes graphes.
Fais attention à la façon dont tu le formules, parce que les gens lisent ça comme « toujours appliquer les constantes » et se demandent ensuite pourquoi leurs chiffres ont empiré. Les constantes à 56-95 ne s'appliquent que quand l'octet 92 d'A0h dit que le module est calibré en externe. Passe-les sur un module calibré en interne et tu transformes des lectures parfaitement bonnes en n'importe quoi, parce que le module a déjà fait ce travail. Lis le drapeau d'abord, branche dessus, garde les deux chemins dans le parseur et logue quel chemin un module donné a pris pour pouvoir distinguer les deux modes de défaillance plus tard.
Même type de piège avec la température : elle est signée. Parse-la en non signé et tout ce qui est en dessous de zéro revient comme un nombre délirément élevé, ce qui est amusant le premier matin froid où ça te fait bipper.
Mise à jour de mon côté. J'ai branché sur l'octet 92 d'A0h et j'applique les constantes seulement quand le module dit externe. Le bias et les deux puissances suivent maintenant ce qu'affiche le NOS sur chaque module que j'ai pu comparer, et la température et la tension n'ont jamais été un problème de toute façon. Deux modules déclarent toujours des diagnostics présents mais rendent des seuils auxquels je ne ferais pas confiance, donc pour ceux-là je retombe sur mes propres limites et je marque le module dans l'inventaire plutôt que de faire semblant. Je ne dis pas que tout est clos, mais la carte ci-dessus était exactement ce qui me manquait.
Encore une chose avant que ça parte en production. L'octet 110 est sur la même page et c'est statut plus contrôle, et la moitié contrôle inclut TX disable. Un poller n'a rien à faire à écrire dans A2h, mais si ta bibliothèque fait un read-modify-write quelque part, ou que tu tapes de travers un i2cset en testant sur un boîtier en production, tu peux couper un lien client depuis l'espace utilisateur. Ouvre le bus en lecture seule dans le poller et garde tout chemin d'écriture dans un outil séparé que tu dois lancer délibérément.
Le même octet donne TX fault et RX LOS, et les deux valent le coup d'être exportés à côté des valeurs analogiques. Un module assis à une puissance RX saine avec LOS asserté te raconte une histoire très différente d'un module qui lit simplement bas.