I2C पर DDM polling को script करना: कौन से A2h bytes live values रखते हैं और कौन से thresholds
मैं एक छोटा सा poller लिख रहा हूँ जो हमारे whitebox boxes पर modules से सीधे temperature, voltage, bias और optical power खींचता है, ताकि किसी link के errors देना शुरू करने के बाद किसी के आँख से देखने की बजाय हमें एक trend line मिले। NOS सुंदर values print करता है, पर मुझे raw numbers चाहिए, साथ में vendor thresholds, ताकि alarm levels mixed optics में भी consistent रहें, हर model के लिए हाथ से लिखने की बजाय।
Setup:
- Linux host, module cages एक plain I2C mux के पीछे, bus 1
- तीन vendors के mixed SFP, SFP+ और SFP28 optics
- सिर्फ i2c-tools से पढ़ना, कोई vendor SDK नहीं
मैं diagnostics page इस तरह पढ़ता हूँ:
# i2cdump -y 1 0x51और यह मेरा draft parser है, जहाँ मुझे यकीन नहीं है:
temp = s16(a2[96:98]) / 256.0
vcc = u16(a2[98:100]) * 100e-6
bias = u16(a2[100:102]) * 2e-6मैं अब तक क्या कर चुका हूँ:
- अपनी computed values को NOS जो print करता है उससे compare किया: कुछ modules पर करीब, कुछ पर साफ तौर पर गलत
- SFF-8472 पूरा पढ़ा, पर अब भी confidently नहीं बता सकता कि threshold block कहाँ खत्म होता है और calibration area कहाँ शुरू होता है
- वही module direct bus पर dump करके mux को rule out किया, numbers वही रहे
तो: A2h का असली map क्या है, thresholds कहाँ रहते हैं, real-time values कहाँ से शुरू होती हैं, और कहीं कोई flag है जो बताए कि module मुझसे उन raw words पर भरोसा करने से पहले कुछ करने की उम्मीद रखता है?
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
कौन सी values साफ तौर पर गलत हैं, चारों या सिर्फ bias और powers? आमतौर पर यही पूरा जवाब तय कर देता है। साथ ही इसी दौरान A0h भी dump कर लो और byte 92 देखो: यह बताता है कि module diagnostics report करता भी है या नहीं, और यह internally या externally calibrated है। अगर आपकी fleet का हिस्सा externally calibrated है और आपका parser सबके साथ एक जैसा व्यवहार करता है, तो यह mismatch expected behaviour है, आपके arithmetic का bug नहीं।
पूरी tray पर A0h byte 92 खींचा और यह uniform नहीं है। कुछ modules external calibration flag करते हैं, कुछ नहीं, और जो NOS output से असहमत हैं वे ठीक external वाले ही हैं। Temperature और voltage सब पर noise के भीतर हैं; bias और दोनों powers ही drift करते हैं। तो लगता है मैं गलत offsets नहीं पढ़ रहा, बल्कि कोई step miss कर रहा हूँ। उस subset पर raw words के साथ मुझे असल में क्या करना है?
0x51 पर A2h चार हिस्सों में बँटता है जो आपके काम के हैं:
Live block में units: temperature signed, 1/256 C प्रति LSB; voltage 100 uV प्रति LSB; bias 2 uA; TX और RX power 0.1 uW। आपका snippet इन्हें पहले से सही scale करता है, तो offsets आपकी problem नहीं हैं।
जो हिस्सा missing है वह वही flag है जो आपने अभी ढूँढा। किसी externally calibrated module पर 96-105 के words raw ADC output होते हैं, और 56-95 वाले constants को लागू करना पड़ता है तब जाकर उनका कोई मतलब बनता है; internally calibrated module यह काम पहले ही आपके लिए कर चुका होता है। वही branch आपके दो groups के बीच का फर्क है।
अगर मेरी बात मान लेने की बजाय किसी layout से मिलाकर check करना चाहें, तो FreeBSD का sff8472.h header और py-sfp-eeprom दोनों offsets को field दर field साफ बताते हैं। फिर भी मैं इस पर alarms लटकाने से पहले हर vendor के एक module को किसी भरोसेमंद value से verify कर लूँगा।
यह जोड़ने लायक है कि threshold block दिलचस्प आधा हिस्सा क्यों है। 0-55 की values live block जैसी ही units में हैं, तो आपकी scaling सही होते ही आपको vendor के अपने alarm और warning points मुफ्त में मिल जाते हैं और हर model के लिए limits बनाने की ज़रूरत कभी नहीं पड़ती। सिर्फ यही बात A2h को सीधे पढ़ने को किसी और के pretty printer को parse करने से बेहतर ठहराती है।
एक mixed tray पर यह चलाने से एक practical बात: poll interval को हल्का रखो। वह page एक साधारण I2C read है और module का controller तेज़ नहीं है। एक mux के पीछे बैठे bus पर हर module को हर सेकंड ठोकना, ऐसी short reads इकट्ठा करने का अच्छा तरीका है जो आपके graphs में बिल्कुल flapping optics जैसी दिखेंगी।
इसे कैसे कहते हो इसका ध्यान रखो, क्योंकि लोग इसे "constants हमेशा apply करो" पढ़ लेते हैं और फिर सोचते हैं कि उनके numbers क्यों बिगड़ गए। 56-95 वाले constants तभी लागू होते हैं जब A0h का byte 92 कहे कि module externally calibrated है। इन्हें किसी internally calibrated module पर चलाओ तो बिल्कुल ठीक readings बकवास में बदल जाती हैं, क्योंकि वह काम module पहले ही कर चुका होता है। पहले flag पढ़ो, उस पर branch करो, parser में दोनों paths रखो और log करो कि किसी module ने कौन सा path लिया, ताकि बाद में दोनों failure modes को अलग बता सको।
Temperature के साथ भी वैसा ही जाल है: यह signed है। इसे unsigned parse करो तो zero से नीचे कुछ भी लौटकर एक बेतहाशा बड़ा number बनकर आता है, जो पहली ठंडी सुबह जब यह आपको page करे तब काफी मज़ेदार होता है।
मेरी तरफ से update। मैंने A0h के byte 92 पर branch किया और constants सिर्फ वहीं apply किए जहाँ module external कहता है। Bias और दोनों powers अब हर उस module पर NOS जो print करता है उसे track करते हैं जिससे मैं compare कर सका, और temperature और voltage तो शुरू से ही कोई problem नहीं थे। दो modules अब भी diagnostics को present report करते हैं पर ऐसे thresholds वापस देते हैं जिन पर मैं भरोसा नहीं करूँगा, तो उनके लिए मैं अपनी खुद की limits पर fall back करता हूँ और दिखावा करने की बजाय module को inventory में flag कर देता हूँ। पूरी बात को बंद तो नहीं कह रहा, पर ऊपर वाला map ठीक वही था जो मुझसे छूट रहा था।
यह production में जाने से पहले एक बात और। Byte 110 उसी page में है और status plus control है, और control वाले आधे हिस्से में TX disable शामिल है। किसी poller को A2h पर लिखने से कोई मतलब ही नहीं होना चाहिए, पर अगर आपकी library कहीं read-modify-write करती है, या आप किसी live box पर test करते वक्त i2cset में उंगली फिसला दें, तो userspace से किसी customer का link गिरा सकते हैं। Poller में bus को read-only खोलो और कोई भी write path किसी अलग tool में रखो जिसे जानबूझकर चलाना पड़े।
वही byte आपको TX fault और RX LOS देता है, और दोनों analogue values के साथ export करने लायक हैं। एक module जो sane RX power पर बैठा हो पर जिसका LOS asserted हो, वह उस module से बिल्कुल अलग कहानी बता रहा है जो सिर्फ low पढ़ता है।