Automatizando polling de DDM via I2C: quais bytes de A2h guardam os valores ao vivo e quais os limiares
Estou escrevendo um poller pequeno que puxa temperatura, tensão, bias e potência óptica direto dos módulos nas nossas caixas whitebox, para termos uma linha de tendência em vez de alguém olhando o link de olho depois que ele já começou a dar erro. O NOS imprime valores bonitinhos, mas eu quero os números brutos com os limiares do fabricante do lado, para os níveis de alarme ficarem consistentes entre ópticos misturados em vez de escritos à mão por modelo.
Bancada:
- host Linux, cages de módulo atrás de um mux I2C simples, bus 1
- ópticos SFP, SFP+ e SFP28 misturados de três fabricantes
- leitura só com i2c-tools, sem SDK de fabricante
Eu leio a página de diagnóstico assim:
# i2cdump -y 1 0x51e esse é o meu parser rascunho, que é onde estou inseguro:
temp = s16(a2[96:98]) / 256.0
vcc = u16(a2[98:100]) * 100e-6
bias = u16(a2[100:102]) * 2e-6O que já fiz:
- comparei meus valores calculados com o que o NOS imprime: próximo em alguns módulos, claramente errado em outros
- li a SFF-8472 inteira, mas ainda não consigo dizer com confiança onde termina o bloco de limiares e onde começa a área de calibração
- descartei o mux fazendo dump do mesmo módulo num bus direto, mesmos números
Então: qual é o mapa real do A2h, onde ficam os limiares, onde começam os valores em tempo real, e existe alguma flag em algum lugar que me diga se o módulo espera que eu faça alguma coisa com essas palavras brutas antes de confiar nelas?
Comments 7
Quais valores são os que estão claramente errados, os quatro ou só bias e as potências? Isso normalmente decide a resposta toda. Aproveite e dê um dump no A0h também, e olhe o byte 92: ele diz se o módulo reporta diagnóstico ou não, e se é calibrado interna ou externamente. Se parte da sua frota é calibrada externamente e o seu parser trata todo mundo do mesmo jeito, então a discrepância é um comportamento esperado, não um bug na sua aritmética.
Puxei o byte 92 do A0h em toda a bandeja e não é uniforme. Alguns módulos sinalizam calibração externa, outros não, e os que discordam da saída do NOS são exatamente os externos. Temperatura e tensão estão dentro do ruído em tudo; bias e as duas potências são o que varia. Então parece que estou perdendo um passo, não lendo os offsets errados. O que eu realmente preciso fazer com as palavras brutas nesse subconjunto?
O A2h em 0x51 se divide em quatro blocos que importam para você:
Unidades no bloco ao vivo: temperatura com sinal, 1/256 C por LSB; tensão 100 uV por LSB; bias 2 uA; TX e RX power 0.1 uW. O seu trecho já escala isso corretamente, então offsets não são o seu problema.
A peça que falta é a flag que você acabou de achar. Num módulo calibrado externamente, as palavras em 96-105 são saída bruta do ADC, e as constantes em 56-95 precisam ser aplicadas antes de significarem alguma coisa; um módulo calibrado internamente já fez isso por você. Esse desvio é a diferença entre os seus dois grupos.
Se você quiser um layout para conferir em vez de confiar só na minha palavra, tanto o header sff8472.h do FreeBSD quanto o py-sfp-eeprom detalham os offsets campo por campo. Eu ainda assim verificaria um módulo por fabricante contra um valor em que você confia antes de pendurar alarmes nisso.
Vale acrescentar por que o bloco de limiares é a metade interessante. Os valores em 0-55 estão nas mesmas unidades do bloco ao vivo, então assim que a sua escala está certa você ganha de graça os próprios pontos de alarme e aviso do fabricante e nunca precisa inventar limites por modelo. Só isso já justifica ler o A2h diretamente em vez de fazer parsing do pretty printer de alguém.
Uma nota prática de rodar isso numa bandeja mista: mantenha o intervalo de polling modesto. Essa página é uma leitura I2C comum e o controlador do módulo não é rápido. Bater em cada módulo a cada segundo num bus que também fica atrás de um mux é uma boa forma de coletar leituras curtas que parecem exatamente ópticos oscilando nos seus gráficos.
Cuidado com como você fala isso, porque as pessoas leem como "sempre aplique as constantes" e depois ficam pensando por que os números pioraram. As constantes em 56-95 só se aplicam quando o byte 92 no A0h diz que o módulo é calibrado externamente. Rode elas num módulo calibrado internamente e você transforma leituras perfeitamente boas em besteira, porque o módulo já fez esse trabalho. Leia a flag primeiro, decida o caminho com base nela, mantenha os dois caminhos no parser e registre qual caminho um dado módulo seguiu, para você conseguir distinguir os dois modos de falha depois.
Mesma classe de armadilha com temperatura: ela tem sinal. Faça o parse como sem sinal e qualquer coisa abaixo de zero volta como um número absurdamente alto, o que é divertido na primeira manhã fria em que isso te chama no pager.
Atualização do meu lado. Decidi o caminho com base no byte 92 do A0h e aplico as constantes só onde o módulo diz externo. Bias e as duas potências agora acompanham o que o NOS imprime em todo módulo contra o qual eu consegui comparar, e temperatura e tensão nunca foram um problema, para começar. Dois módulos ainda reportam diagnóstico como presente, mas devolvem limiares em que eu não confiaria, então para esses eu caio de volta nos meus próprios limites e sinalizo o módulo no inventário em vez de fingir. Não estou chamando isso de encerrado, mas o mapa acima era exatamente o que estava faltando para mim.
Mais uma coisa antes disso ir para produção. O byte 110 fica na mesma página e é status mais controle, e a metade de controle inclui TX disable. Um poller não tem nenhum motivo para escrever no A2h, mas se a sua biblioteca faz um read-modify-write em algum lugar, ou você erra o dedo no i2cset enquanto testa numa caixa em produção, você pode derrubar o link de um cliente a partir do userspace. Abra o bus como somente leitura no poller e mantenha qualquer caminho de escrita numa ferramenta separada que você precisa rodar deliberadamente.
O mesmo byte te dá TX fault e RX LOS, e os dois valem a pena exportar ao lado dos valores analógicos. Um módulo parado num RX power sensato com LOS ativado está te contando uma história bem diferente de um que simplesmente lê baixo.