CRC 오류는 깨진 방향의 받는 쪽에 쌓이므로 양쪽 끝을 모두 확인. 네트워크: 장비 포트의 CRC·입력 오류 카운터 확인, 광 신호 세기 점검(스위치의 광모듈 정보), 광커넥터 청소, 선·광모듈 교체. 서버 장비·OS: 서버 ethtool -S의 rx_crc_errors(드라이버마다 이름이 조금 다름) 확인, 광 신호 세기 점검(ethtool -m), 서버 쪽 선·NIC 교체.
외부 할 일
유저 집 구간이면 랜선·공유기 교체 안내, 통신사 회선 구간이면 통신사에 회선 점검 요청.
수치 감각
0.1% 손실도 게임 패킷 1,000개에 한 번입니다. 그 경로를 지나는 사람이 수십 명이면 몇 초마다 누군가 멈칫합니다. 비트 오류는 큰 패킷일수록 잘 걸립니다.
그래프에서는
일부만 높음 · 포트별 CRC 오류 수, 서버·포트별 재전송률
확인할 곳
링크 양쪽 끝의 CRC 카운터를 봄. 서버는 ethtool -S의 rx_crc_errors나 ip -s -s link의 crc, 스위치는 포트의 FCS 오류(dot3StatsFCSErrors)·입력 오류(ifInErrors). 광 링크면 ethtool -m과 스위치의 광모듈 정보로 수신 광 세기를 봄
이러면 맞음
한 포트의 CRC 오류가 시간대와 상관없이 꾸준히 늘고 그 포트를 지나는 서버·연결만 재전송률이 높음. 같은 종류의 다른 링크보다 수신 광 세기가 낮음
이러면 아님
CRC는 그대로인데 출력 폐기만 늘면 대기열 넘침(“송신 버스트로 얕은 버퍼 넘침”, “병목 대기열 넘침”). 한쪽의 늦은 충돌과 다른 쪽의 CRC가 함께 늘면 “듀플렉스 불일치”
확인 수단
인프라 도구로 확인(게임 코드 불필요)
출처
Interface statisticsLinux kernel rx_crc_errors는 받는 쪽 인터페이스가 CRC 오류로 센 패킷 수, ip -s -s link와 ethtool -S로 확인