Scriptare il polling DDM via I2C: quali byte di A2h contengono i valori live e quali le soglie
Sto scrivendo un piccolo poller che tira giù temperatura, tensione, bias e potenza ottica direttamente dai moduli sulle nostre scatole whitebox, così otteniamo una linea di tendenza invece che qualcuno che controlla a occhio un link dopo che ha già iniziato a dare errori. Il NOS stampa valori belli pronti, ma voglio i numeri grezzi con le soglie del vendor accanto, così i livelli di allarme sono coerenti tra ottiche miste invece che scritti a mano per modello.
Configurazione:
- host Linux, cage dei moduli dietro un semplice mux I2C, bus 1
- ottiche SFP, SFP+ e SFP28 miste di tre vendor
- lettura solo con i2c-tools, nessun SDK del vendor
Leggo la pagina diagnostica così:
# i2cdump -y 1 0x51e questo è il mio parser in bozza, dove non sono sicuro:
temp = s16(a2[96:98]) / 256.0
vcc = u16(a2[98:100]) * 100e-6
bias = u16(a2[100:102]) * 2e-6Cosa ho già fatto:
- confrontato i miei valori calcolati con quello che stampa il NOS: vicini su alcuni moduli, chiaramente sballati su altri
- letto SFF-8472 da cima a fondo, ma non riesco ancora a dire con sicurezza dove finisce il blocco delle soglie e dove inizia l'area di calibrazione
- escluso il mux facendo il dump dello stesso modulo su un bus diretto, stessi numeri
Quindi: qual è la mappa reale di A2h, dove stanno le soglie, dove iniziano i valori in tempo reale, e c'è da qualche parte un flag che mi dice se il modulo si aspetta che io faccia qualcosa a quelle parole grezze prima di fidarmene?
Comments 7
Quali sono i valori chiaramente sballati, tutti e quattro o solo bias e le potenze? Di solito è quello che decide tutta la risposta. Fai anche il dump di A0h già che ci sei e guarda il byte 92: ti dice se il modulo riporta diagnostica del tutto, e se è calibrato internamente o esternamente. Se parte della tua flotta è calibrata esternamente e il tuo parser tratta tutti allo stesso modo, allora la discrepanza è comportamento atteso e non un bug nella tua aritmetica.
Ho tirato fuori il byte 92 di A0h su tutto il vassoio e non è uniforme. Alcuni moduli segnalano calibrazione esterna, altri no, e quelli che non concordano con l'output del NOS sono esattamente quelli esterni. Temperatura e tensione sono nel rumore su tutto; bias e le due potenze sono quello che deriva. Quindi sembra che mi manchi un passaggio piuttosto che stia leggendo gli offset sbagliati. Cosa devo effettivamente fare con le parole grezze su quel sottoinsieme?
A2h a 0x51 si scompone in quattro blocchi che ti interessano:
Unità nel blocco live: temperatura con segno, 1/256 C per LSB; tensione 100 uV per LSB; bias 2 uA; TX e RX power 0,1 uW. Il tuo snippet le scala già correttamente, quindi gli offset non sono il tuo problema.
Il pezzo mancante è il flag che hai appena trovato. Su un modulo calibrato esternamente le parole a 96-105 sono output ADC grezzo, e le costanti a 56-95 vanno applicate prima che significhino qualcosa; un modulo calibrato internamente l'ha già fatto per te. Quel ramo è la differenza tra i tuoi due gruppi.
Se vuoi un layout su cui verificare invece di fidarti della mia parola, l'header sff8472.h di FreeBSD e py-sfp-eeprom spiegano entrambi gli offset campo per campo. Io comunque verificherei un modulo per vendor contro un valore di cui ti fidi prima di appenderci allarmi.
Vale la pena aggiungere perché il blocco delle soglie è la metà interessante. I valori in 0-55 sono nelle stesse unità del blocco live, quindi una volta che la tua scalatura è giusta ottieni gratis i punti di allarme e warning del vendor stesso e non devi mai inventare limiti per modello. Solo questo giustifica leggere A2h direttamente invece di fare il parsing del pretty printer di qualcun altro.
Una nota pratica dal far girare questo su un vassoio misto: tieni l'intervallo di polling modesto. Quella pagina è una normale lettura I2C e il controller del modulo non è veloce. Martellare ogni modulo ogni secondo su un bus che sta anche dietro un mux è un buon modo per raccogliere letture corte che sembrano esattamente ottiche che sbattono nei tuoi grafici.
Attento a come lo formuli, perché la gente lo legge come "applica sempre le costanti" e poi si chiede perché i suoi numeri sono peggiorati. Le costanti a 56-95 si applicano solo quando il byte 92 in A0h dice che il modulo è calibrato esternamente. Falle girare su un modulo calibrato internamente e trasformi letture perfettamente buone in spazzatura, perché il modulo ha già fatto quel lavoro. Leggi prima il flag, ramifica su di esso, tieni entrambi i percorsi nel parser e logga quale percorso ha preso un dato modulo così puoi distinguere dopo i due modi di fallimento.
Stessa classe di trappola con la temperatura: è con segno. Fai il parsing come senza segno e qualsiasi cosa sotto zero torna come un numero folle, il che è divertente la prima mattina fredda che ti manda un alert.
Aggiornamento dal mio lato. Ho ramificato sul byte 92 di A0h e applico le costanti solo dove il modulo dice esterno. Bias ed entrambe le potenze ora seguono quello che stampa il NOS su ogni modulo contro cui ho potuto confrontare, e temperatura e tensione non sono mai state un problema fin dall'inizio. Due moduli riportano ancora diagnostica presente ma restituiscono soglie di cui non mi fiderei, quindi per quelli ripiego sui miei limiti e segnalo il modulo nell'inventario invece di fingere. Non dichiaro tutto chiuso, ma la mappa sopra era esattamente quello che mi mancava.
Un'altra cosa prima che questo vada in produzione. Il byte 110 sta nella stessa pagina ed è status più controllo, e la metà di controllo include TX disable. Un poller non ha nessun motivo per scrivere su A2h, ma se la tua libreria fa un read-modify-write da qualche parte, o sbagli a digitare i2cset mentre testi su una macchina live, puoi far cadere un link cliente dallo userspace. Apri il bus in sola lettura nel poller e tieni qualsiasi percorso di scrittura in uno strumento separato che devi far girare deliberatamente.
Lo stesso byte ti dà TX fault e RX LOS, ed entrambi vale la pena esportarli accanto ai valori analogici. Un modulo che sta a una RX power sana con LOS asserito ti sta raccontando una storia molto diversa da uno che semplicemente legge basso.