I2C üzerinden DDM polling script'i yazmak: hangi A2h byte'ları anlık değerleri, hangileri eşikleri tutuyor
Whitebox cihazlarımızdaki modüllerden sıcaklık, voltaj, bias ve optik gücü doğrudan çeken küçük bir poller yazıyorum, böylece link hata vermeye başladıktan sonra birinin göz kararı bakması yerine bir trend çizgimiz oluyor. NOS güzel değerler basıyor, ama alarm seviyelerinin karışık optikler arasında model başına elle yazmak yerine tutarlı olması için yanlarında vendor eşikleriyle birlikte ham sayıları istiyorum.
Ortam:
- Linux host, sade bir I2C mux arkasında modül kafesleri, bus 1
- üç vendor'dan karışık SFP, SFP+ ve SFP28 optikler
- sadece i2c-tools ile okuma, vendor SDK yok
Diagnostics sayfasını şöyle okuyorum:
# i2cdump -y 1 0x51ve emin olamadığım kısım da bu, taslak parser'ım:
temp = s16(a2[96:98]) / 256.0
vcc = u16(a2[98:100]) * 100e-6
bias = u16(a2[100:102]) * 2e-6Şimdiye kadar yaptıklarım:
- hesapladığım değerleri NOS'un bastığıyla karşılaştırdım: bazı modüllerde yakın, bazılarında açıkça sapmış
- SFF-8472'yi baştan sona okudum, ama eşik bloğunun nerede bittiğini ve kalibrasyon alanının nerede başladığını hâlâ güvenle söyleyemiyorum
- aynı modülü doğrudan bir bus üzerinde dump'layarak mux'ı eledim, aynı sayılar çıktı
Yani: A2h'nin gerçek haritası ne, eşikler nerede yaşıyor, gerçek zamanlı değerler nerede başlıyor, bir de o ham word'lere güvenmeden önce onlara bir şey yapmam gerektiğini söyleyen bir flag var mı?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 7
Açıkça sapan değerler hangileri, dördü birden mi yoksa sadece bias ve güçler mi? Bu genelde tüm cevabı belirler. Bir de aynı anda A0h'yi de dump'la ve byte 92'ye bak: modülün diagnostics raporlayıp raporlamadığını, bir de internal mi external mi kalibre edildiğini söyler. Filonun bir kısmı externally calibrated ise ve parser'ın herkese aynı şekilde davranıyorsa, uyumsuzluk beklenen bir davranıştır, aritmetiğindeki bir hata değil.
Tüm tepsi boyunca A0h byte 92'yi çektim ve tekdüze değil. Bazı modüller external calibration flag'i taşıyor, bazıları taşımıyor, NOS çıktısıyla uyuşmayanlar da tam olarak external olanlar. Sıcaklık ve voltaj her şeyde gürültü seviyesinde; sapan şey bias ve iki güç. Yani yanlış offset okumaktan çok bir adımı atlamışım gibi görünüyor. O alt kümedeki ham word'lerle gerçekte ne yapmam gerekiyor?
0x51'deki A2h, senin için önemli olan dört parçaya ayrılıyor:
Canlı bloktaki birimler: sıcaklık signed, LSB başına 1/256 C; voltaj LSB başına 100 uV; bias 2 uA; TX ve RX gücü 0.1 uW. Senin snippet'in bunları zaten doğru şekilde ölçekliyor, yani sorun offset'lerde değil.
Eksik parça, az önce bulduğun flag. Externally calibrated bir modülde 96-105'teki word'ler ham ADC çıktısı ve 56-95'teki sabitlerin bir anlam ifade etmeden önce uygulanması gerekiyor; internally calibrated bir modül bu işi senin için zaten yapmış. Bu dallanma, senin iki grubun arasındaki fark.
Bana güvenmek yerine karşılaştıracağın bir layout istersen, FreeBSD'nin sff8472.h header'ı ve py-sfp-eeprom, offset'leri alan alan açıkça yazıyor. Yine de alarmları buna asmadan önce vendor başına bir modülü güvendiğin bir değere karşı doğrulardım.
Eşik bloğunun neden ilginç yarı olduğunu eklemekte fayda var. 0-55'teki değerler canlı blokla aynı birimlerde, yani ölçekleme doğru olduğunda vendor'ın kendi alarm ve warning noktalarını bedavaya alıyorsun ve model başına limit uydurmak zorunda hiç kalmıyorsun. Tek başına bu bile, birinin güzel printer'ını parse etmek yerine A2h'yi doğrudan okumayı haklı çıkarıyor.
Bunu karışık bir tepside çalıştırmaktan pratik bir not: poll aralığını mütevazı tut. O sayfa sıradan bir I2C okuma ve modül kontrolcüsü hızlı değil. Ayrıca bir mux'ın arkasında oturan bir bus'ta her modülü her saniye dövmek, grafiklerinde tam olarak flapping optikler gibi görünen kısa okumalar toplamanın iyi bir yolu.
Bunu nasıl ifade ettiğine dikkat et, çünkü insanlar bunu "sabitleri her zaman uygula" diye okuyup sonra sayıları neden kötüleşti diye merak ediyor. 56-95'teki sabitler sadece A0h'deki byte 92 modülün externally calibrated olduğunu söylediğinde uygulanır. Bunları internally calibrated bir modülde çalıştırırsan gayet iyi okumaları saçmalığa çevirirsin, çünkü modül o işi zaten yapmış. Önce flag'i oku, ona göre dallan, parser'da iki yolu da tut ve iki hata modunu sonradan ayırt edebilmek için hangi modülün hangi yolu aldığını logla.
Sıcaklıkla da aynı sınıftan bir tuzak var: o signed. Onu unsigned parse edersen sıfırın altındaki her şey çılgınca yüksek bir sayı olarak geri döner, bu da seni ilk soğuk sabah page ettiğinde eğlenceli oluyor.
Benim tarafımdan bir güncelleme. A0h byte 92'ye göre dallandım ve sabitleri sadece modül external dediğinde uyguluyorum. Bias ve her iki güç artık karşılaştırabildiğim her modülde NOS'un bastığını takip ediyor, sıcaklık ve voltaj zaten hiç sorun olmamıştı. İki modül hâlâ diagnostics'i mevcut olarak raporluyor ama güvenmeyeceğim eşikler geri veriyor, o yüzden onlar için kendi limitlerime geri dönüyorum ve numara yapmak yerine modülü envanterde işaretliyorum. Her şeyi kapatılmış saymıyorum, ama yukarıdaki harita tam olarak eksik olan şeydi.
Bu production'a girmeden önce bir şey daha. Byte 110 aynı sayfada oturuyor ve status artı control, control yarısı da TX disable'ı içeriyor. Bir poller'ın A2h'ye yazmakla hiç işi olmamalı, ama kütüphanen herhangi bir yerde read-modify-write yapıyorsa, ya da canlı bir kutuda test ederken i2cset'i yanlış yazarsan, userspace'ten bir müşteri link'ini düşürebilirsin. Poller'da bus'ı read-only aç ve herhangi bir write yolunu bilerek çalıştırman gereken ayrı bir araçta tut.
Aynı byte sana TX fault ve RX LOS veriyor, ikisi de analog değerlerin yanında export etmeye değer. Makul bir RX gücünde oturan ama LOS assert edilmiş bir modül, sadece düşük okuyan bir modülden çok farklı bir hikaye anlatıyor.