Nếu gom yêu cầu tới tick sau mới xử lý, rồi kết quả lại đợi đến tick sau nữa mới gửi, khoảng cách tick bị cộng vào hai lần.
Vì sao Yêu cầu nhận được sẽ xử lý ở tick tiếp theo → Dẫn đến Kết quả xử lý cũng được gom lại gửi ở tick gửi tiếp theo → Trên màn hình Ping đường truyền thấp mà phản hồi luôn chậm đều khoảng 1,5 lần khoảng cách tick. Server 10 tick thì trung bình 0,15 giây, tệ nhất 0,2 giây
Phụ trách chính Phát triển server (Đội phát triển game)
Việc cần làm (Đội phát triển game)
Gửi phản hồi ngay trong tick xử lý, tăng tick rate, gửi ngay các phản hồi quan trọng.
Con số tham khảo
Server 10 tick có mỗi tick 100 ms, nên riêng việc chờ tick đã cộng thêm trung bình 150 ms, tệ nhất 200 ms. Nếu chỉ chờ một lần thì trung bình 50 ms.
Trên đồ thị
Luôn cao ngay từ đầu · Thời gian từ khi yêu cầu tới đến khi gửi phản hồi
Chỗ cần xem
Trong bản bắt gói phía server, khi tài khoản thử nghiệm lặp lại nhiều lần cùng một hành động (ví dụ dùng vật phẩm), đo khoảng cách giữa thời điểm gói yêu cầu tới và thời điểm gói phản hồi đi ra. Nếu có log server: xem thời điểm yêu cầu tới, số thứ tự tick xử lý, thời điểm gửi phản hồi
Đúng nếu
thời gian yêu cầu nằm trong server trung bình khoảng 1,5 lần, tối đa khoảng 2 lần khoảng cách tick, và không đổi bất kể RTT
Loại trừ nếu
thời gian yêu cầu nằm trong server trung bình quanh mức một nửa khoảng cách tick → chỉ chờ tick một lần. Dài hơn khoảng cách tick và lúc dài lúc ngắn → xem vượt tick budget
Cách kiểm tra
Kiểm tra bằng công cụ hạ tầng (không cần code game)
Nguồn
Peeking into VALORANT's NetcodeRiot Games Input tới phải chờ tối đa một tick cho tới ranh giới tick, rồi áp dụng và gửi đi lại tốn thêm một khung hình. Tick rate càng cao thì độ trễ này càng giảm