SFF-8472 규격: 광모듈 DDM 인터페이스 상세 설명
SFF-8472 규격: 광모듈 DDM 인터페이스 상세 설명
SFF-8472는 SFP/SFP+/유사 플러그형 광모듈의 관리 인터페이스(Management Interface) 를 정의하는 업계 표준입니다. 실무에서 흔히 말하는 DDM/DDMI/DOM의 핵심 규격이 바로 이것입니다. 이 규격의 목적은 호스트(스위치, 라우터, 서버 NIC)가 모듈 내부 상태를 2-wire(I²C 유사) 버스로 읽고, 일부 제어 기능도 수행할 수 있게 만드는 것입니다. SNIA SFF-8472
쉽게 말하면, 예전 SFP가 “이 모듈이 누구냐”를 알려주는 정적 정보 위주였다면, SFF-8472는 거기에 “지금 몇 도인지, 전압은 정상인지, 레이저 바이어스는 얼마인지, TX/RX 광파워가 얼마인지” 같은 동적 진단 데이터를 추가한 규격입니다. 그래서 장애 분석, 열화 예측, 광 링크 마진 확인에 매우 중요합니다. SNIA SFF-8472 Optcore
출처: Optcore
1. SFF-8472의 위치: 기존 SFP ID 규격의 “확장판”
SFF-8472는 기존 GBIC/SFP Serial ID 모델을 그대로 유지하면서, 진단 기능을 확장한 규격입니다. 원래 SFP/GBIC 쪽에는 A0h 주소의 256바이트 메모리 맵이 있었고, 여기에는 벤더명, 파트넘버, 파장, 지원 규격 같은 정적 식별 정보가 들어 있었습니다. SFF-8472는 여기에 A2h 주소를 추가해서 동적 진단과 제어를 넣었습니다. 즉, A0h는 정적 정보, A2h는 진단/상태/제어 정보라고 이해하면 가장 쉽습니다. SNIA SFF-8472
이 설계의 중요한 장점은 하위 호환성입니다. 예전 장비는 여전히 A0h만 읽어도 모듈을 인식할 수 있고, 새 장비는 A2h까지 읽어서 DDM을 활용할 수 있습니다. 그래서 SFF-8472는 “기존 SFP 생태계를 깨지 않고 진단 기능을 확장한 규격”이라고 볼 수 있습니다. SNIA SFF-8472
2. 2-wire 인터페이스: 호스트와 모듈이 통신하는 방식
SFF-8472는 2-wire serial interface를 사용합니다. 실무적으로는 보통 I²C 계열 버스처럼 생각하면 됩니다. 호스트는 이 버스를 통해 모듈 EEPROM과 진단 레지스터를 읽습니다. SNIA SFF-8472
주요 장치 주소는 다음처럼 이해하면 됩니다. SNIA SFF-8472
주소 | 용도 | 성격 |
|---|---|---|
A0h | Base ID, Extended ID, Vendor data | 정적 식별 정보 |
A2h | Diagnostics, alarms, control/status | 동적 진단/상태/제어 |
즉, 호스트는 A0h로 “이게 어떤 모듈인지”를 알고, A2h로 “지금 이 모듈 상태가 어떤지”를 알게 됩니다. SNIA SFF-8472
3. 메모리 맵의 핵심 구조
A0h: 정적 ID 영역
A0h에는 모듈 타입, 커넥터, compliance code, nominal bitrate, wavelength, vendor name, vendor PN, revision, serial number 같은 식별 정보가 들어 있습니다. 이 영역은 전통적인 SFP ID 규격을 유지합니다. SNIA SFF-8472
A2h: 진단/제어 영역
A2h가 바로 SFF-8472의 핵심입니다. 이쪽에는 알람/워닝 임계값, 실시간 측정값, 상태 플래그, 소프트 제어 비트, 캘리브레이션 상수 등이 들어 있습니다. SNIA SFF-8472
실무적으로 자주 보는 A2h의 핵심 구역은 아래처럼 정리할 수 있습니다. SNIA SFF-8472
A2h 바이트 범위 | 내용 |
|---|---|
0–39 | Alarm / Warning Thresholds |
56–91 | External Calibration Constants |
96–105 | 실시간 진단값(온도, 전압, Bias, TX Power, RX Power) |
110 이후 | Status / Control bits, Flags 등 |
후기 리비전에서는 상위 메모리와 페이징 개념도 포함되며, 요약 기준으로 A2h 상위 128바이트 쪽은 page 선택을 통해 확장 정보를 담을 수 있습니다. 다만 현장 진단에서 가장 자주 쓰는 것은 여전히 하위 128바이트의 실시간 DDM 데이터입니다. SNIA SFF-8472
4. DDM/DOM의 5대 핵심 측정값
SFF-8472가 표준화한 대표 측정값은 아래 5가지입니다. 이것이 실무에서 DOM/DDM이라고 부르는 값의 본체입니다. SNIA SFF-8472 Optcore
항목 | 의미 | 실무 해석 |
|---|---|---|
Temperature | 모듈 내부 온도 | 과열, 냉각 불량, 열 스트레스 확인 |
Vcc | 공급 전압 | 전원 안정성 확인 |
TX Bias Current | 레이저 구동 전류 | 레이저 열화/보상 동작 추적 |
TX Optical Power | 송신 광출력 | 모듈 송신 상태 확인 |
RX Optical Power | 수신 광입력 | 광손실, 오염, 원격단 TX 상태 확인 |
이 다섯 가지가 중요한 이유는, 링크 장애를 전원 문제 / 열 문제 / 송신부 문제 / 광경로 문제로 분리해 볼 수 있게 해 주기 때문입니다. 예를 들어 TX Power가 낮으면 모듈 송신부 의심, RX Power만 낮으면 광섬유/커넥터/상대편 TX 의심처럼 해석할 수 있습니다. Optcore
5. 데이터 표현 방식: 단순 숫자가 아니라 “규격화된 포맷”
SFF-8472는 측정값을 16비트 필드로 보고합니다. 요약 기준으로 다음처럼 해석합니다. SNIA SFF-8472
Temperature: 16비트 signed 2’s complement, 보통 1/256 °C 분해능
Vcc: 16비트 unsigned, 보통 100 µV 단위
TX Bias: 16비트 unsigned, 보통 2 µA 단위
TX Power / RX Power: 16비트 unsigned, 보통 0.1 µW 단위 SNIA SFF-8472
이 말은, 호스트가 단순히 임의 포맷으로 읽는 것이 아니라, 규격이 정한 스케일과 해석식에 따라 값을 engineering unit으로 바꿔야 한다는 뜻입니다. SNIA SFF-8472
6. Internal Calibration vs External Calibration
이 부분이 SFF-8472에서 가장 자주 헷갈리는 포인트입니다. 규격은 두 가지 캘리브레이션 방식을 허용합니다. SNIA SFF-8472
내부 캘리브레이션(Internally Calibrated)
모듈이 내부에서 이미 보정된 값을 만들어서 호스트에 줍니다. 따라서 호스트는 거의 그대로 engineering unit으로 해석하면 됩니다. 가장 구현이 편한 방식입니다. SNIA SFF-8472
외부 캘리브레이션(Externally Calibrated)
모듈은 원시 A/D 값에 가까운 데이터를 내고, A2h의 calibration constants를 읽은 뒤 호스트가 보정식을 적용해야 합니다. 즉, 계산 책임이 호스트 쪽에 더 있습니다. SNIA SFF-8472
요약 기준으로 SFF-8472는 내부/외부 캘리브레이션 여부를 비트로 표시하고, 외부 캘리브레이션인 경우 A2h bytes 56–91의 slope/offset 계수를 사용하게 합니다. 실무적으로는 대부분 장비가 내부 캘리브레이션 모듈을 상대할 때가 많지만, 호스트 소프트웨어를 설계할 때는 둘 다 지원 가능성을 열어둬야 합니다. SNIA SFF-8472
7. 알람/워닝 구조: “숫자”만이 아니라 “판정 비트”도 표준화
SFF-8472는 단순히 실시간 값만 읽는 규격이 아닙니다. 각 항목에 대해 High Alarm / Low Alarm / High Warning / Low Warning 임계값을 정의합니다. 이 임계값은 보통 A2h bytes 0–39에 저장됩니다. SNIA SFF-8472
개념적으로는 다음과 같습니다. SNIA SFF-8472
구분 | 의미 |
|---|---|
High Alarm | 즉시 비정상 또는 규격 초과 수준 |
High Warning | 아직 동작 가능하지만 경계 상태 |
Low Warning | 하한 근접, 열화/이상 가능 |
Low Alarm | 확실한 저하/비정상 수준 |
그리고 실시간 측정값이 이 임계값을 넘으면, 모듈은 별도의 Alarm/Warning Flag bits를 세웁니다. 따라서 호스트는 매번 수치를 해석하지 않아도 **“어느 항목이 경고인지”**를 빠르게 판단할 수 있습니다. SNIA SFF-8472
8. 상태(Status)와 제어(Control): 단순 모니터링을 넘는 기능
SFF-8472는 관측만 하는 규격이 아니라, 일부 제어 비트도 정의합니다. 대표적인 것이 TX_DISABLE, TX_FAULT, RX_LOS, Rate Select입니다. SNIA SFF-8472
TX_DISABLE
송신 레이저를 끄는 기능입니다. 하드 핀으로도 존재하지만, SFF-8472는 소프트 비트 기반 제어도 정의합니다. 즉, 호스트는 핀만이 아니라 메모리 맵 제어 비트로도 송신 차단 여부를 제어할 수 있습니다. SNIA SFF-8472
TX_FAULT
모듈 송신부 이상 상태입니다. 레이저 바이어스 이상, 과온, 광출력 이상 등에서 Assert될 수 있습니다. SNIA SFF-8472
RX_LOS
수신광이 감지되지 않거나 부족한 상태입니다. 즉 “광이 안 들어온다”에 가까운 신호입니다. SNIA SFF-8472
Rate Select
모듈의 대역폭/속도 선택 동작과 관련된 기능입니다. 일부 구현에서는 하드 핀과 소프트 비트가 공존합니다. 규격은 이 둘의 관계도 정의합니다. SNIA SFF-8472
요약 자료 기준으로 A2h Byte 110 근처에 주요 soft control/status가 위치하고, TX_DISABLE, TX_FAULT, RX_LOS, Data_Not_Ready 같은 의미 있는 비트들이 존재합니다. SNIA SFF-8472
9. “실시간”이지만 완전 실시간은 아님: pseudo-real-time
SFF-8472는 진단 인터페이스를 real-time이 아니라 pseudo-real-time 성격으로 봅니다. 즉, 값이 계속 갱신되지만 ADC 샘플링과 내부 업데이트 주기가 있고, 호스트가 읽는 시점과 완전히 동기화된 것은 아닙니다. SNIA SFF-8472
이 때문에 규격은 다중 바이트 필드는 반드시 한 번의 2바이트 read sequence로 읽어 일관성을 보장하라고 요구합니다. 그렇지 않으면 MSB를 읽은 직후 내부 값이 갱신되고, LSB는 다음 샘플 값이 되어 찢어진 데이터(torn read) 가 될 수 있습니다. 이것은 실제 호스트 구현에서 매우 중요한 포인트입니다. SNIA SFF-8472
또한 Data_Not_Ready 비트가 있어, 모듈이 아직 진단값 준비가 끝나지 않았음을 알릴 수 있습니다. 전원 인가 직후 바로 DDM 값을 신뢰하면 안 되는 이유가 여기에 있습니다. SNIA SFF-8472
10. 호스트 구현 시 주의사항
호스트(스위치 OS, 서버 NIC 드라이버, 진단 소프트웨어)를 구현할 때는 다음을 꼭 고려해야 합니다. SNIA SFF-8472
10-1. 다중 바이트 읽기 일관성
온도/전압/광파워는 16비트이므로 MSB+LSB를 한 번에 읽어야 합니다. SNIA SFF-8472
10-2. 캘리브레이션 비트 확인
내부/외부 보정 여부를 먼저 확인하고, 외부 보정이면 slope/offset을 적용해야 합니다. SNIA SFF-8472
10-3. 체크섬 검증
A0h/A2h 일부 영역에는 체크섬이 있어 EEPROM 내용 무결성을 검증할 수 있습니다. 현장에서는 잘 안 보이지만, 펌웨어/진단 툴 구현에는 중요합니다. SNIA SFF-8472
10-4. 페이징 여부 확인
후기 리비전/특정 모듈은 상위 메모리 접근을 위해 paging 비트를 사용합니다. 따라서 호스트는 모듈이 실제로 paging을 구현했는지 확인해야 합니다. SNIA SFF-8472
10-5. 전원 인가 직후 신뢰성
모듈이 아직 안정화되지 않았을 수 있으므로 Data_Not_Ready나 초기화 지연을 고려해야 합니다. SNIA SFF-8472
11. 현장에서 SFF-8472 값은 어떻게 쓰이나
운영 측면에서 SFF-8472는 아래 같은 판단에 직접 쓰입니다. Optcore
Temperature 상승 → 냉각/환기/고온 랙 문제 점검
Vcc 흔들림 → 전원 품질, 브라운아웃, PSU 문제 의심
Bias Current 증가 → 레이저 열화 또는 보상 증가 가능성
TX Power 저하 → 모듈 송신부 이상 가능성
RX Power 저하 → 광커넥터 오염, 광손실 증가, 상대편 TX 문제 의심 Optcore
즉, SFF-8472는 “광모듈 상태 보기”를 넘어서 링크 장애의 책임 구간을 분리하는 표준 인터페이스입니다. Optcore
12. 자주 생기는 오해
“DOM 값은 무조건 절대 정확하다”
아닙니다. 규격은 포맷과 인터페이스를 표준화하지만, 측정 정확도는 모듈 구현 품질과 캘리브레이션 방식에 영향을 받습니다. 특히 RX Power는 구현 방식에 따라 average power/OMA 해석 차이가 있을 수 있습니다. SNIA SFF-8472 Optcore
“RX가 낮으면 무조건 모듈 불량이다”
아닙니다. RX Power는 광섬유, 패치패널, 스플라이스, 오염, 상대편 TX 등 외부 요인의 영향을 많이 받습니다. Optcore
“DDM은 완전 실시간이다”
아닙니다. SFF-8472는 pseudo-real-time 개념이므로, 샘플링/업데이트 타이밍과 데이터 coherency를 고려해야 합니다. SNIA SFF-8472
13. 핵심 정리
SFF-8472의 본질은 다음 한 문장으로 요약할 수 있습니다.
**“기존 SFP Serial ID(A0h)를 유지하면서, A2h에 실시간 진단·상태·제어 인터페이스를 추가한 표준”**입니다. 이 인터페이스 덕분에 호스트는 온도, 전압, TX Bias, TX Power, RX Power를 읽고, 경고/알람을 판정하며, 일부 소프트 제어까지 수행할 수 있습니다. SNIA SFF-8472
실무적으로는 SFF-8472를 이해하면, 스위치/서버에서 보이는 DOM/DDM 출력의 의미를 정확히 해석할 수 있고, 광 링크 장애를 모듈 문제 / 전원 문제 / 열 문제 / 광경로 문제로 나누어 볼 수 있게 됩니다. Optcore
참고 자료
공식 규격: SNIA SFF-8472 Rev.12.5a
해설 자료: Optcore DOM/DDM Tutorial
Linux ethtool -m 출력과 SFF-8472 바이트 필드의 대응 관계
아래는 Linux ethtool -m의 사람이 읽는 출력 필드가 SFF-8472 메모리 맵의 어느 바이트(A0h/A2h) 에 대응되는지 정리한 표입니다. 핵심은 다음 두 줄입니다.
A0h: 모듈의 정적 식별 정보
A2h: DDM/DOM 진단값, 임계값, 상태/제어 비트
ethtool -m은 플러그형 모듈의 EEPROM을 읽고, 드라이버/모듈이 지원하면 optical diagnostic 정보까지 디코드합니다. 또한 raw/hex, offset/page 기반 조회도 지원합니다. man7 ethtool
예시처럼 ethtool -m류 출력에는 Identifier, Vendor 정보, Laser bias current, Laser output power, Receiver optical power, Module temperature, Module voltage, 그리고 alarm/warning threshold가 표시됩니다. NVIDIA Documentation
1) 기본 대응 관계 요약
A0h = 식별/정적 정보, A2h = 진단/상태 정보
SFF-8472는 기존 SFP ID용 A0h 메모리 맵을 유지하면서, A2h에 DDM/DOM과 상태/제어를 추가합니다. Linux ethtool -m의 상단부는 보통 A0h를, 하단의 온도/전압/TX/RX/threshold 부분은 A2h를 디코드한 결과라고 보면 됩니다. SNIA SFF-8472
2) ethtool -m 상단 식별 정보 ↔ SFF-8472 A0h 바이트
| SFF-8472 위치 | 설명 |
|---|---|---|
Identifier | A0h byte 0 | 모듈 종류(SFP/SFP+/QSFP 계열 식별) |
Extended identifier | A0h byte 1 | 확장 식별자 |
Connector | A0h byte 2 | LC, RJ45 등 커넥터 타입 |
Transceiver codes | A0h bytes 3–10, 36, 62 | Ethernet/FC 등 compliance code |
Transceiver type | 주로 A0h bytes 3–10 해석 결과 | 예: 1000BASE-SX |
Encoding | A0h byte 11 | 8B/10B 등 |
BR, Nominal | A0h byte 12 | nominal bitrate |
Rate identifier | A0h byte 13 | rate select 관련 타입 |
Length (SMF, km) | A0h byte 14 | 단일모드 거리(km) |
Length (SMF) | A0h byte 15 | 단일모드 거리(100m 단위) |
Length (50um) | A0h byte 16 | MMF 50um 거리 |
Length (62.5um) | A0h byte 17 | MMF 62.5um 거리 |
Length (OM4 or Copper) | A0h byte 18 | OM4 또는 copper 관련 길이 |
Length (OM3) | A0h byte 19 | OM3 거리 |
Vendor name | A0h bytes 20–35 | ASCII vendor명 |
Vendor OUI | A0h bytes 37–39 | IEEE OUI |
Vendor PN | A0h bytes 40–55 | Part Number |
Vendor rev | A0h bytes 56–59 | Revision |
Vendor SN | A0h bytes 68–83 | Serial Number |
Date code | A0h bytes 84–91 | 제조일자 |
Optical diagnostics support / Diagnostic monitoring type | A0h byte 92 | 내부/외부 calibration, RX power 타입 등 |
Enhanced options | A0h byte 93 | soft control/status 지원 여부 |
SFF-8472 compliance | A0h byte 94 | SFF-8472 revision 표시 |
위 표는 ethtool -m이 사람이 읽기 좋게 보여주는 필드명이 실제로는 어떤 A0h 바이트를 해석한 것인지 대응시킨 것입니다. 특히 Optical diagnostics support 같은 항목은 단일 바이트 하나를 그대로 보여주는 게 아니라, A0h byte 92의 비트 의미를 ethtool이 문장 형태로 풀어준 것입니다. SNIA SFF-8472 NVIDIA Documentation
3) ethtool -m 실시간 DDM 값 ↔ SFF-8472 A2h 바이트
이 부분이 DOM/DDM의 핵심입니다.
| SFF-8472 위치 | 형식 |
|---|---|---|
Module temperature | A2h bytes 96–97 | 16-bit signed |
Module voltage | A2h bytes 98–99 | 16-bit unsigned |
Laser bias current | A2h bytes 100–101 | 16-bit unsigned |
Laser output power | A2h bytes 102–103 | 16-bit unsigned |
Receiver signal average optical power | A2h bytes 104–105 | 16-bit unsigned |
즉 ethtool -m에서 보이는
Module temperature
Module voltage
Laser bias current
Laser output power
Receiver signal average optical power
이 5개는 거의 그대로 A2h 96–105에 있는 SFF-8472 표준 진단 필드를 디코드한 결과입니다. SNIA SFF-8472 Optcore
4) ethtool -m threshold 표시 ↔ SFF-8472 A2h bytes 0–39
ethtool -m 하단에는 보통 각 항목별 high/low alarm, high/low warning threshold가 같이 출력됩니다. 이 값들은 SFF-8472에서 A2h 0–39에 정의됩니다. SNIA SFF-8472
항목별 threshold 위치
항목 | SFF-8472 위치 |
|---|---|
Temperature thresholds | A2h bytes 0–7 |
Voltage thresholds | A2h bytes 8–15 |
Bias current thresholds | A2h bytes 16–23 |
TX power thresholds | A2h bytes 24–31 |
RX power thresholds | A2h bytes 32–39 |
즉 ethtool -m에서 아래 같은 항목이 보이면:
Module temperature high alarm threshold
Module temperature low warning threshold
Module voltage high alarm threshold
Laser bias current low alarm threshold
Laser output power high warning threshold
Laser rx power low warning threshold
이들은 각각 위의 A2h threshold 바이트를 사람이 읽기 쉬운 형태로 풀어서 보여준 것입니다. NVIDIA Documentation SNIA SFF-8472
5) ethtool -m의 알람/워닝 상태 표시 ↔ SFF-8472 flag bits
threshold 값과 별개로, 현재 threshold를 넘었는지 아닌지를 나타내는 flag bit들도 있습니다. ethtool -m이 다음 같은 문구를 보여주는 경우가 여기에 해당합니다.
Laser bias current high alarm
Laser bias current low warning
Laser output power high alarm
Module temperature low alarm
Module voltage high warning
Laser rx power low warning
이런 항목들은 SFF-8472의 alarm/warning flag bits를 해석한 것입니다. 요약 도구 결과에서는 바이트 범위를 112–117 인근 flag 구조로 설명하고 있으며, threshold 자체는 bytes 0–39, 실시간 값은 bytes 96–105에 있습니다. 즉 ethtool -m은 **“현재값 + 기준값 + 초과 여부”**를 모두 조합해 보여주는 셈입니다. SNIA SFF-8472
6) 상태/제어 비트 ↔ A2h byte 110
이 부분은 ethtool -m이 항상 전부 예쁘게 보여주지는 않지만, SFF-8472 관점에서 매우 중요합니다.
기능 | 위치 | 의미 |
|---|---|---|
Data_Not_Ready | A2h byte 110 bit 0 | DDM 값 아직 준비 안 됨 |
RX_LOS | A2h byte 110 bit 1 | 수신 광손실 |
TX_FAULT | A2h byte 110 bit 2 | 송신부 fault |
Soft TX Disable | A2h byte 110 bit 6 | 소프트 TX disable |
TX Disable state | A2h byte 110 bit 7 | TX disabled 상태 |
즉 ethtool -m이나 다른 툴이 TX fault, RX LOS, data not ready 같은 상태를 출력한다면, 그 근원은 SFF-8472 기준으로 A2h byte 110의 상태 비트입니다. SNIA SFF-8472
7) 실제 ethtool -m 필드명 기준으로 묶어서 보기
아래는 현장에서 자주 보는 ethtool -m 출력명을 기준으로 어느 메모리 블록을 보는지 정리한 것입니다.
식별 정보 블록
Identifier → A0h 0
Extended identifier → A0h 1
Connector → A0h 2
Transceiver codes / type → A0h 3–10, 36, 62
Encoding → A0h 11
BR, Nominal → A0h 12
Rate identifier → A0h 13
Length fields → A0h 14–19
Vendor fields → A0h 20–59, 68–91
Diagnostics support / compliance → A0h 92–94
실시간 DDM 블록
Module temperature → A2h 96–97
Module voltage → A2h 98–99
Laser bias current → A2h 100–101
Laser output power → A2h 102–103
Receiver optical power → A2h 104–105
임계값 블록
Temp thresholds → A2h 0–7
Voltage thresholds → A2h 8–15
Bias thresholds → A2h 16–23
TX power thresholds → A2h 24–31
RX power thresholds → A2h 32–39
상태/제어 블록
Data_Not_Ready / RX_LOS / TX_FAULT / TX_DISABLE → A2h 110 비트 필드
8) raw/hex로 직접 확인하는 방법
ethtool -m은 사람이 읽기 좋은 출력 외에도 raw/hex와 offset/page 선택을 지원합니다. 즉, 필요하면 특정 바이트를 직접 읽어서 위 표와 대조할 수 있습니다. man7 ethtool
예를 들어:
Copysudo ethtool -m ens1f0 hex on
또는 특정 영역만:
Copysudo ethtool -m ens1f0 hex on offset 96 length 10
이렇게 하면 A2h의 실시간 진단값 블록을 직접 덤프해서 96–105 바이트가 temperature/Vcc/bias/TX/RX라는 사실을 바이트 수준으로 확인할 수 있습니다. page, bank, i2c 옵션도 지원됩니다. man7 ethtool
9) 중요한 주의점
1) ethtool -m은 “직접 바이트를 보여주는 툴”이 아니라 “디코더”
즉 출력 필드명은 SFF-8472의 개별 바이트/비트를 사람이 읽기 좋게 조합한 결과입니다. 그래서 Transceiver type 같은 항목은 단일 바이트 하나가 아니라 여러 compliance code 바이트의 조합 해석일 수 있습니다. SNIA SFF-8472
2) 드라이버/모듈 지원이 필요
공식 매뉴얼도 ethtool -m은 driver and module support가 있어야 optical diagnostics를 읽고 디코드한다고 명시합니다. man7 ethtool
3) 멀티바이트 값은 한 덩어리로 읽어야 함
SFF-8472는 16비트 진단값을 정의하므로, host는 coherency를 위해 멀티바이트 값을 올바르게 읽어야 합니다. SNIA SFF-8472
10) 한눈에 보는 핵심 대응표
| SFF-8472 주소 |
|---|---|
모듈 식별 정보 | A0h |
Vendor / PN / SN / Date | A0h |
Diagnostics support / compliance | A0h 92–94 |
DDM 현재값 | A2h 96–105 |
DDM 임계값 | A2h 0–39 |
상태/제어 비트 | A2h 110 |
.