Sumy kontrolne: CC_BASE, CC_EXT, CC_DMI, strony CMIS

Każda specyfikacja zarządzania chroni swój blok danych identyfikacyjnych jedną lub kilkoma sumami kontrolnymi — pojedynczym bajtem, który pozwala hostowi wykryć uszkodzony albo połowicznie zapisany EEPROM, zanim zaufa jego zawartości. Ich obliczenie jest trywialne, a łatwo o nich zapomnieć: nieaktualna suma kontrolna po edycji to najczęstsza przyczyna, dla której świeżo zakodowany moduł jest zgłaszany jako invalid.

Algorytm

Wszystkie stosują tę samą regułę: zsumuj bajty objętego zakresu jako wartości 8-bitowe bez znaku i zachowaj młodsze 8 bitów sumy (suma modulo 256). Żadnego CRC, żadnego wielomianu.

sum = 0
for each byte b in range:
    sum = (sum + b) & 0xFF
checksum = sum

Przykład — pierwsze pięć bajtów SFP 10GBASE-SR: 03 04 07 10 00 → 3 + 4 + 7 + 16 + 0 = 30 = 1Eh. Kontynuuj do bajtu 62, a wynikiem będzie CC_BASE.

Gdzie mieszka każda suma kontrolna

Nie jest objęte żadną sumą kontrolną: obszary specyficzne dla producenta (SFP A0h 96–127, QSFP 224–255, CMIS 223–255), EEPROM użytkownika, bieżące wielkości mierzone i flagi, progi QSFP strony 03h oraz strony linii CMIS. Producenci mogą dodawać własne pola integralności w obszarze producenta — nie są one częścią specyfikacji.

Co robią z nimi hosty

Błąd sumy kontrolnej jest zgłaszany razem z danymi identyfikacyjnymi, więc moduł, który ma dodatkowo problem z polityką, pokazuje jeden komunikat maskujący drugi — najpierw sprawdź sumy kontrolne, to najtańsza poprawka. Mapa objawów: Indeks objawów.

Kiedy trzeba przeliczyć ponownie

• Po edycji czegokolwiek w objętych zakresach — nazwa producenta, numer katalogowy, numer seryjny, kod daty, kody zgodności, długość fali, długości, opcje, klasa mocy.
• Po zastosowaniu progów albo stałych kalibracji na SFP (CC_DMI).
• Po przywróceniu częściowego obrazu z innego modułu.
• Niepotrzebne przy zmianach w obszarze producenta, EEPROM użytkownika albo bajtach sterujących A2h.

Kolejność działań: edycja → przeliczenie każdej dotkniętej sumy kontrolnej → zapis → odczyt kontrolny → weryfikacja. Zapisanie bajtu sumy kontrolnej przed danymi, które obejmuje, zostawia okno, w którym utrata zasilania tworzy nieprawidłowy moduł.

Sumy kontrolne a blokady producenta

Poprawne sumy kontrolne są konieczne, ale niewystarczające. Restrykcyjna platforma sprawdza też blok producenta oraz, w zablokowanych konstrukcjach, zastrzeżoną sygnaturę w obszarze producenta, o której sumy kontrolne specyfikacji nic nie wiedzą. Poprawne CC_BASE przy odrzuconych danych identyfikacyjnych wygląda jak przypadek blokady producenta, a nie problem z sumą kontrolną — Blokada producenta, Pola producenta.

W CodingBox

CodingBox przelicza CC_BASE, CC_EXT, CC_DMI i sumy kontrolne stron CMIS automatycznie przy każdym zapisie i podświetla niezgodność podczas odczytu modułu — czerwone pole sumy kontrolnej na ekranie Check transceiver albo w EEPROM editor oznacza, że moduł był edytowany gdzie indziej bez poprawienia sumy, albo że EEPROM jest uszkodzony.

Gdzie każda suma kontrolna leży wśród sąsiednich bajtów: SFF-8472 A0h (63, 95), A2h (95), SFF-8636 górna (191, 223), CMIS górne strony (222, 255), XFP (191, 223).