이중 틱 대기 Double tick quantization

원인 ID sy-double-tick · 주 담당 게임개발팀·서버 개발

요청을 다음 틱까지 모았다가 처리하고 결과도 그다음 틱에 보내면 틱 간격이 두 번 더해집니다.

왜 받은 요청은 다음 틱에서 처리 → 그러면 처리 결과도 다음 전송 틱에 모아서 보냄 → 화면에서는 회선 핑은 낮은데 반응이 틱 간격의 1.5배쯤 일정하게 늦음. 10틱 서버면 평균 0.15초, 최악 0.2초

증상: 입력 지연
요인: 지연
누가 겪나: 서버 전체
언제: 항상
담당: 주 담당 게임개발팀·서버 개발
게임개발팀 할 일: 처리한 틱에 바로 응답 보내기, 틱레이트 올리기, 중요한 응답은 즉시 전송.
수치 감각: 10틱 서버는 한 틱이 100ms라 틱 대기만으로 평균 150ms, 최악 200ms가 더해집니다. 한 번만 기다리면 평균 50ms입니다.
그래프에서는: 처음부터 늘 높음 · 요청 도착에서 응답 전송까지 시간
확인할 곳: 서버 쪽 패킷 캡처에서 시험 계정이 같은 행동(예: 아이템 사용)을 여러 번 할 때 요청 패킷이 도착한 시각과 그 응답 패킷이 나간 시각의 간격을 잼. 서버 로그가 있으면 요청 도착 시각, 처리한 틱 번호, 응답을 보낸 시각을 봄
이러면 맞음: 서버 안에서 걸린 시간이 평균 틱 간격의 1.5배, 최대 2배쯤이고 RTT와 상관없이 일정함
이러면 아님: 서버 안 시간이 평균 틱 간격의 절반 안팎이면 틱 대기는 한 번뿐. 틱 간격보다 들쭉날쭉 길면 틱 예산 초과를 봄
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처

Peeking into VALORANT's Netcode Riot Games
도착한 입력은 틱 경계까지 최대 한 틱을 기다리고 적용·전송에 다시 한 프레임이 듦. 틱레이트가 높을수록 줄어듦
VALORANT's 128-Tick Servers Riot Games
지연의 일부는 네트워크, 일부는 서버 틱레이트에서 옴
NetworkTime and ticks (Netcode for GameObjects 2.5) Unity
NetworkVariable 변경은 즉시 보내지 않고 네트워크 틱마다 모아 전송