Độ trễ chuột, bàn phím và màn hình cộng dồn như thế nào?

Độ trễ thấp giúp thao tác của bạn được phản ánh lên màn hình sớm hơn. Nhưng con số “1ms” trên hộp chuột hoặc màn hình chỉ mô tả một phép đo cụ thể, không phải toàn bộ thời gian từ cú bấm đến hình ảnh.

Chuỗi phản hồi thường gồm xử lý trong thiết bị nhập, chuyển dữ liệu, game đọc input, CPU/GPU dựng khung, hàng đợi hiển thị và màn hình phát sáng. Muốn cộng đúng, phải dùng các đoạn đo không chồng lặp và có cùng điều kiện.

Phạm vi: bài giải thích kỹ thuật từ tài liệu công khai, không phải số đo của một bộ thiết bị cụ thể. Những phép tính chu kỳ là tính toán lý thuyết; ví dụ tổng độ trễ được ghi rõ là minh họa.

Phân biệt ba loại độ trễ trước khi so thông số

Ngay cả “click-to-photon” cũng cần đọc phương pháp: điểm bắt đầu là lúc công tắc đóng hay lúc phần mềm nhận sự kiện? Điểm kết thúc ở giữa màn hình hay gần cạnh dưới? Hai bài đo có ranh giới khác nhau không thể cộng hoặc so trực tiếp.

Phản xạ con người không có một quỹ cố định 231ms mà thiết bị phải chia nhau. Thời gian phản ứng phụ thuộc người, loại nhiệm vụ và cách đo. Độ trễ thiết bị là một phần khác trong vòng tương tác, không phải lời giải thích đầy đủ cho kết quả thi đấu.

Polling rate rút ngắn thời gian chờ, không mô tả toàn bộ chuột

Polling rate cho biết tần suất báo cáo danh nghĩa. Nếu sự kiện xuất hiện ngẫu nhiên so với chu kỳ và báo cáo đều, thời gian chờ đến lượt báo cáo tiếp theo có thể ước lượng trung bình bằng nửa chu kỳ.

Từ 1.000 lên 8.000Hz, riêng phần chờ trung bình lý tưởng giảm khoảng 0,4375ms. Đây không phải mức giảm click-to-photon được bảo đảm trên mọi hệ thống.

Thiết bị còn phải quét công tắc hoặc cảm biến, xử lý debounce, firmware và có thể truyền không dây trước khi gửi dữ liệu tới máy. Độ trễ chuyển động và độ trễ click cũng có thể khác nhau. Vì vậy, không nên xếp hạng toàn bộ chuột chỉ bằng polling rate.

Tài liệu USB của Microsoft giải thích nhịp interrupt endpoint phụ thuộc loại bus và trường bInterval. Ở high-speed, một microframe dài 0,125ms; không phải “125 microframe bằng 0,125ms”.^[1] Việc cắm vào cổng nhanh hơn cũng không tự biến thiết bị chỉ hỗ trợ 1.000Hz thành 8.000Hz.

Polling rất cao có thể làm tăng tải xử lý và không tương thích tốt với mọi game. Hãy thử frametime và độ ổn định trên máy của bạn, thay vì luôn chọn mức tối đa.

FPS và hàng đợi ảnh hưởng thời điểm game phản hồi

Game không nhất thiết chỉ đọc input đúng một lần cho mỗi lần màn hình quét. Cách lấy input, bước mô phỏng và render có thể chạy theo nhịp khác nhau. Tuy vậy, khung hình render thưa thường làm phản hồi hình ảnh cập nhật chậm hơn.

CPU có thể chuẩn bị trước công việc trong khi GPU xử lý khung trước. Một hàng đợi sâu có thể làm input trong khung sắp hiển thị đã cũ hơn. Nhưng không nên đếm số back buffer rồi nhân cứng với thời gian khung để ra độ trễ thật.

Microsoft có API đặt giới hạn số khung driver được phép xếp hàng, với giá trị mặc định và phạm vi riêng của API.^[2] Điều đó không chứng minh mọi game Windows luôn có đúng ba khung đang chờ.

Reflex là một ví dụ công nghệ đồng bộ đường ống CPU/GPU để render sát thời điểm cần thiết trong game hỗ trợ.^[3] Hiệu quả cụ thể phụ thuộc game và trạng thái giới hạn của hệ thống. Không có công tắc chung bảo đảm vừa tăng FPS vừa giảm độ trễ ở mọi máy.

Hz, GtG và độ nhòe màn hình là ba chuyện khác nhau

Hz mô tả số lần làm mới danh nghĩa mỗi giây. GtG mô tả thời gian chuyển giữa các mức xám theo điều kiện đo. MPRT mô tả đặc tính thời gian hiển thị liên quan đến độ rõ chuyển động, không phải cùng một đại lượng với GtG.

Vì vậy, màn hình ghi “1ms” cần nói rõ đó là phép đo nào, dùng overdrive hay đèn nền chớp ở chế độ nào và có đánh đổi về overshoot hoặc độ sáng hay không. Không thể lấy số 1ms đó thay cho toàn bộ input lag.

Ở mô hình quét tuần tự từ trên xuống, vùng dưới nhận dữ liệu muộn hơn vùng trên. Tuy nhiên, thời gian chênh cụ thể còn phụ thuộc timing, tốc độ scanout và cách màn hình xử lý, không phải lúc nào cũng chính xác bằng một chu kỳ quét. Điểm ảnh cũng chuyển màu dần khi từng hàng được cập nhật; màn hình không chờ quét xong toàn bộ khung mới bắt đầu đổi màu.

OLED thường có chuyển trạng thái nhanh, nhưng không đồng nghĩa mọi OLED có tổng input lag thấp hơn mọi LCD. Bộ xử lý, chế độ màn hình và cách đo vẫn cần được kiểm tra. Chỉ số độ rõ chuyển động cũng không thay thế phép đo độ trễ.

Cộng độ trễ thế nào để không đếm hai lần?

Về nguyên tắc, theo dõi cùng một sự kiện input và khung hình phản ánh sự kiện đó, rồi chia đường đi thành các khoảng không chồng lặp:

• Từ thao tác vật lý đến khi báo cáo input tới máy.

• Từ lúc máy nhận báo cáo đến khi game tạo xong nội dung hình ảnh tương ứng.

• Thời gian nội dung đó chờ được đưa ra đường hiển thị.

• Từ khi bắt đầu xuất khung đến khi dữ liệu tới vị trí điểm ảnh đang đo.

• Từ khi điểm ảnh nhận cập nhật đến ngưỡng sáng hoặc màu mà phép đo chọn.

Ví dụ hoàn toàn giả định: nếu năm khoảng không chồng lặp nói trên lần lượt là 2ms, 6ms, 3ms, 2ms và 1ms thì tổng là 14ms. Đây chỉ là minh họa phép cộng, không phải số đo hay dự báo cho thiết bị nào.

Nếu khoảng đầu tiên đã đo từ công tắc đến báo cáo USB, không cộng thêm polling một lần nữa. Nếu một bài đo màn hình đã bao gồm scanout và chuyển màu, cũng không cộng lại từng phần đó.

Không lấy độ trễ trung vị của một con chuột trong nghiên cứu này cộng với cực đại màn hình ở nghiên cứu khác rồi gọi đó là “khoảng trễ thật của PC gaming”. Các thiết bị, ranh giới và trạng thái hệ thống phải phù hợp. Chu kỳ còn có thể tương quan với nhau, nên cộng các cực đại rời rạc dễ tạo ra tình huống không đại diện.

Cách kiểm tra và thứ tự tối ưu hợp lý

• Kiểm tra miễn phí trước: màn hình đang chạy đúng Hz, game không bị khóa FPS ngoài ý muốn, không có tiến trình nền gây frametime tăng vọt.

• Tối ưu render: thử giảm các thiết lập đang làm GPU quá tải, sử dụng chế độ giảm độ trễ được game hỗ trợ và đo lại.

• Kiểm tra thiết bị nhập: xem polling thực tế và bài đo click/motion latency độc lập; không mặc định hub USB nào cũng gây trễ đáng kể.

• Đánh giá màn hình: xem input lag và response time ở đúng Hz/chế độ bạn dùng, không chỉ số tốt nhất trong quảng cáo.

• Nâng cấp theo phần chậm đã xác định: không có thứ tự duy nhất cho mọi bộ máy.

Nghiên cứu NVIDIA năm 2019 cho thấy hiệu năng trong các tác vụ thử có thể cải thiện khi tăng tần số quét và giảm độ trễ.^[4] Một nghiên cứu năm 2026 lại không tìm thấy khác biệt có ý nghĩa giữa 144Hz và 360Hz trong bài thử riêng của họ.^[5] Những kết quả này không tạo ra một ngưỡng chung mà trên đó mọi nâng cấp đều vô ích.

Video quay chậm bằng điện thoại có thể giúp so tương đối nếu bố trí cẩn thận, nhưng có sai số do tốc độ quay, rolling shutter, vị trí đo và mốc bắt đầu. Kết quả vài phần mili giây cần thiết bị cùng phương pháp phù hợp hơn. Xem hoặc bấm giờ một trận livestream không đo được click-to-photon của tuyển thủ hay của máy bạn.

Kết luận: độ trễ được cộng theo đường đi của cùng một sự kiện, không cộng tùy ý các số trên hộp. Hãy ưu tiên phép đo đầu cuối rõ ràng và tối ưu đúng đoạn đang chậm thay vì suy hiệu năng từ một con số “1ms”.

Nguồn tham khảo

Đối chiếu ngày 27/10/2026. Phép tính polling trong bảng là mô hình chu kỳ lý tưởng.

• Microsoft Learn — USB_ENDPOINT_DESCRIPTOR: bInterval và microframe.

• Microsoft Learn — IDXGIDevice1::SetMaximumFrameLatency: giới hạn hàng đợi của API cụ thể.

• NVIDIA Developer — Reflex.

• Kim và cộng sự, 2019 — Esports Arms Race: Latency and Refresh Rate for Competitive Gaming Tasks.

• Toth và cộng sự, 2026 — Monitor refresh rate impacts FPS video gamers’ perceptions of display ‘smoothness’ and target acquisition performance; tóm tắt của trường đại học.