Viết script poll DDM qua I2C: byte nào trong A2h chứa giá trị thời gian thực, byte nào chứa ngưỡng
Mình đang viết một poller nhỏ để lấy nhiệt độ, điện áp, bias và công suất quang thẳng từ module trên các whitebox của bọn mình, để có đường trend thay vì ai đó ngồi nhìn link bằng mắt sau khi nó đã bắt đầu lỗi. NOS thì in ra giá trị đẹp, nhưng mình muốn số raw kèm ngưỡng của vendor ngay bên cạnh để mức alarm nhất quán giữa các loại quang khác nhau thay vì phải viết tay cho từng model.
Cấu hình:
- host Linux, cage module sau một mux I2C thường, bus 1
- quang SFP, SFP+ và SFP28 trộn lẫn từ ba vendor
- đọc bằng i2c-tools thôi, không dùng SDK của vendor
Mình đọc trang diagnostics thế này:
# i2cdump -y 1 0x51và đây là parser nháp của mình, chỗ mình không chắc:
temp = s16(a2[96:98]) / 256.0
vcc = u16(a2[98:100]) * 100e-6
bias = u16(a2[100:102]) * 2e-6Đã làm những gì:
- so giá trị mình tính ra với những gì NOS in: một số module gần khớp, số khác lệch rõ
- đọc qua SFF-8472, nhưng vẫn chưa dám chắc khối threshold kết thúc ở đâu và vùng calibration bắt đầu từ đâu
- loại trừ mux bằng cách dump cùng module trên bus trực tiếp, ra cùng số
Vậy: bản đồ thật của A2h là gì, threshold nằm ở đâu, giá trị thời gian thực bắt đầu từ đâu, và có flag nào báo cho mình biết module có yêu cầu làm gì đó với mấy word raw kia trước khi tin chúng không?
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
Giá trị nào lệch rõ, cả bốn hay chỉ bias với hai công suất? Cái này thường quyết định cả câu trả lời. Tiện thể dump luôn A0h và xem byte 92: nó cho biết module có report diagnostics hay không, và calibrate kiểu internal hay external. Nếu một phần fleet của bạn là external calibration mà parser lại xử lý mọi thứ như nhau thì lệch số là chuyện bình thường chứ không phải bug trong phép tính của bạn.
Đã kéo byte 92 của A0h trên cả tray và nó không đồng nhất. Một số module gắn cờ external calibration, số khác không, và những cái lệch khỏi output của NOS đúng là nhóm external. Nhiệt độ và điện áp thì nằm trong khoảng nhiễu trên tất cả; bias và hai công suất là thứ trôi. Nên có vẻ mình đang thiếu một bước chứ không phải đọc sai offset. Mình thực sự phải làm gì với mấy word raw ở nhóm đó?
A2h ở 0x51 chia thành bốn khối đáng quan tâm với bạn:
Đơn vị trong khối live: nhiệt độ có dấu, 1/256 C mỗi LSB; điện áp 100 uV mỗi LSB; bias 2 uA; TX và RX power 0.1 uW. Đoạn code của bạn đã scale đúng mấy cái đó rồi, nên offset không phải vấn đề của bạn.
Mảnh còn thiếu chính là cái flag bạn vừa tìm ra. Trên module external calibration, các word ở 96-105 là output ADC raw, và hằng số ở 56-95 phải được áp dụng vào thì mới có nghĩa; module internal calibration thì đã làm sẵn việc đó cho bạn rồi. Nhánh rẽ đó chính là khác biệt giữa hai nhóm của bạn.
Nếu muốn có layout để đối chiếu thay vì tin lời mình, header sff8472.h của FreeBSD và py-sfp-eeprom đều ghi rõ offset từng field một. Mình vẫn khuyên kiểm tra một module mỗi vendor với một giá trị bạn tin tưởng trước khi treo alarm lên đó.
Đáng nói thêm vì sao khối threshold là nửa thú vị hơn. Giá trị ở 0-55 cùng đơn vị với khối live, nên một khi scale đúng thì bạn có sẵn điểm alarm và warning của chính vendor mà không cần tự bịa giới hạn cho từng model. Chỉ riêng điều đó đã đủ lý do để đọc thẳng A2h thay vì parse cái pretty printer của ai đó.
Một lưu ý thực tế từ việc chạy cái này trên tray trộn lẫn: giữ poll interval vừa phải thôi. Trang đó là một lần đọc I2C bình thường và controller của module không nhanh. Dội mỗi module mỗi giây trên một bus lại còn nằm sau mux là cách hay để thu về những read ngắn trông y hệt quang đang chập chờn trên graph của bạn.
Cẩn thận cách diễn đạt chỗ đó, vì người ta sẽ đọc thành "lúc nào cũng áp hằng số vào" rồi thắc mắc sao số của họ lại tệ đi. Hằng số ở 56-95 chỉ áp dụng khi byte 92 trong A0h nói module là external calibration. Chạy chúng lên một module internal calibration thì bạn biến số đọc đang hoàn toàn tốt thành vô nghĩa, vì module đã làm việc đó rồi. Đọc flag trước, rẽ nhánh theo nó, giữ cả hai đường trong parser và log lại module nào đi đường nào để sau này còn phân biệt được hai kiểu lỗi.
Cùng loại bẫy với nhiệt độ: nó có dấu. Parse nó thành unsigned thì bất cứ giá trị nào dưới 0 sẽ trả về một con số cao vọt, khá là vui vào sáng lạnh đầu tiên khi nó page bạn dậy.
Cập nhật từ phía mình. Mình đã rẽ nhánh theo byte 92 của A0h và chỉ áp hằng số ở nơi module báo là external. Bias và cả hai công suất giờ khớp với những gì NOS in trên mọi module mình so sánh được, còn nhiệt độ với điện áp thì chưa bao giờ là vấn đề ngay từ đầu. Hai module vẫn báo có diagnostics nhưng trả về threshold mình không tin tưởng, nên với chúng mình quay về giới hạn tự đặt và gắn cờ module đó trong inventory thay vì giả vờ ổn. Chưa dám gọi là xong hẳn, nhưng cái bản đồ ở trên đúng là thứ mình đang thiếu.
Thêm một điều nữa trước khi đưa cái này lên production. Byte 110 nằm cùng trang và là status cộng control, nửa control có cả TX disable. Một poller không có lý do gì để ghi vào A2h cả, nhưng nếu thư viện của bạn có chỗ nào làm read-modify-write, hoặc bạn lỡ tay gõ nhầm i2cset lúc test trên máy đang chạy, bạn có thể làm rớt link của khách hàng từ userspace. Mở bus ở chế độ read-only trong poller và giữ mọi đường ghi trong một tool riêng phải chạy có chủ đích.
Cùng byte đó cho bạn TX fault và RX LOS, cả hai đều đáng export cạnh các giá trị analogue. Một module đang ở RX power hợp lý nhưng LOS bật lên đang kể một câu chuyện rất khác so với module chỉ đơn giản đọc thấp.