Tần số polling chuột thực sự có nghĩa là gì?

Tần số polling, tính bằng hertz, mô tả số lần mỗi giây chuột báo cáo vị trí và trạng thái nút cho máy tính. Chuột 500Hz gửi năm trăm báo cáo mỗi giây, một báo cáo mỗi hai mili giây, còn chuột 1000Hz gửi một nghìn báo cáo mỗi một mili giây. Tần số cao hơn nghĩa là hệ điều hành nhận cập nhật vị trí thường xuyên hơn, có thể rút độ trễ giữa chuyển động tay và phản hồi tương ứng trên màn hình. Nó chỉ mô tả tần suất báo cáo và không nói gì về độ chính xác cảm biến, chất lượng theo dõi hay mức tinh tế chuột phát hiện chuyển động.

Chính xác 1000Hz nhanh hơn 500Hz bao nhiêu?

Khác biệt chính xác là một mili giây, và hiểu con số đó trong bối cảnh mới là vấn đề cốt lõi. Chuột 1000Hz báo cáo mỗi mili giây trong khi chuột 500Hz báo cáo mỗi hai mili giây, nên mức giảm tối đa ở giai đoạn polling là một mili giây, mức giảm trung bình bằng một nửa vì chuyển động xảy ra ngẫu nhiên trong khoảng. Đây là cải thiện đo được thật sự chứ không phải hư cấu marketing. Tuy vậy nó chỉ là một mắt xích trong chuỗi đã chứa tần số quét màn hình, render khung hình và phản ứng con người, mỗi thứ góp độ trễ lớn hơn nhiều.

Khác biệt giữa 1000Hz và 500Hz có nhận ra được trong game không?

Nhiều người chơi sẽ không nhận ra khác biệt một cách đáng tin ở lối chơi thường ngày. Ở 500Hz, khoảng báo cáo vốn đã là hai mili giây, còn 1000Hz chỉ rút thời gian chờ lập lịch trung bình xuống khoảng nửa mili giây. Khác biệt trở nên đáng kể hơn khi màn hình, tốc độ khung hình và đường đầu vào đã nhanh sẵn, nhưng mức cảm nhận tùy phần cứng, game, tốc độ di chuyển và độ nhạy của từng người. Hãy coi nó là một cài đặt đo được để thử nghiệm, không phải bản nâng cấp cảm nhận được bảo đảm, và hãy so sánh cả ảnh hưởng frame-time hay CPU.

Tần số polling cao hơn có gây vấn đề gì không?

Có hai chi phí thật. Thứ nhất, tải xử lý tăng vì mỗi báo cáo phải qua hệ điều hành, stack driver và thường cả engine game. Ở 2000Hz trở lên điều này đo được, và trên bộ xử lý yếu nó có thể kéo khung hình giảm nhẹ — trớ trêu thay lại tăng tổng độ trễ. Thứ hai, chuột không dây ngốn điện rõ hơn ở polling cao, rút ngắn pin giữa các lần sạc. Một số hệ thống cũ và vài triển khai USB trên mainboard cũng stutter ở tốc độ cực cao. 1000Hz thường an toàn trên đa số hệ thống hiện đại; vượt mức đó cần lý do chính đáng.

Nên dùng 1000Hz hay 500Hz cho shooter thi đấu?

Nếu bạn có hệ thống cao cấp và thi đấu nghiêm túc, 1000Hz vô hại và có thể mang lợi ích biên, không lý do tránh nó trên chuột có dây. Nếu setup điển hình — màn hình 144Hz hoặc thấp hơn, tốc độ khung hình vài trăm thấp — 500Hz thực sự không phân biệt được về cảm giác mà nhẹ nhàng hơn với tài nguyên hệ thống. Yếu tố quyết định lớn hơn nhiều tới cảm giác phản hồi của game là tần số quét màn hình và tốc độ khung hình duy trì, và tối ưu hai thứ đó sẽ cho kết quả mà điều chỉnh polling không sánh kịp.

Tần số polling có ảnh hưởng đến aim hay độ chính xác không?

Chỉ gián tiếp, và ở mức tối thiểu. Polling chi phối tần suất dữ liệu vị trí đến, không phải vị trí đó được đo chính xác thế nào ngay từ đầu. Chất lượng cảm biến, cài đặt DPI tương ứng độ nhạy của bạn và bề mặt di chuột đều ảnh hưởng độ chính xác theo dõi mạnh hơn nhiều. Một con chuột polling 1000Hz với cảm biến trung bình bị smoothing, angle snapping hay acceleration sẽ aim tệ hơn hẳn chuột 500Hz với cảm biến xuất sắc. Coi thông số polling như thước đo độ chính xác là lỗi mua sắm phổ biến mà chính nhà sản xuất khuyến khích qua cách nhấn mạnh marketing.

Polling 8000Hz có đáng trả tiền không?

Gần như không ai ở hiện tại. Chuột 8000Hz báo cáo mỗi 0,125 mili giây, nhưng chẳng thành phần nào trong hệ thống điển hình dùng nổi độ mịn đó. Màn hình 360Hz quét lại mỗi 2,8 mili giây, nên hơn hai mươi báo cáo đến giữa hai lần quét; hệ điều hành và engine game gộp hoặc lấy mẫu chúng theo nhịp riêng, nên độ mịn thừa hiếm khi thành lợi ích thấy được. Chi phí xử lý hoàn toàn thật, còn lợi ích vẫn nằm trên giấy ngoài phòng lab. Đó là cuộc đua thông số, không phải nâng cấp cảm nhận được cho công nghệ màn hình và render hiện tại.

Làm sao kiểm tra tần số polling chuột thực sự đạt được?

Trình duyệt không đọc được tần số polling phần cứng, và sự kiện chuột chịu gộp cùng lập lịch, nên tester web không chứng minh được khoảng báo cáo USB. Để có số đáng tin, hãy dùng công cụ native đọc dữ liệu cấp HID hoặc USB, như phần mềm nhà sản xuất hay tiện ích hệ thống. Tester trình duyệt hé lộ pattern thô: khoảng trống dài, đều giữa các cập nhật có thể gợi ý kết nối bị bóp, hub dùng chung hay hệ thống quá tải — đáng điều tra, không phải phép đo. Hãy kiểm tra đường kết nối (cổng mainboard hay hub) và driver trước khi kết luận lỗi thiết bị.

Chuột không dây có polling thấp hơn chuột có dây không?

Không với phần cứng thế hệ hiện tại. Các triển khai không dây hiện đại dùng receiver 2,4GHz chuyên dụng đạt đáng tin 1000Hz với độ trễ thực tế tương đương có dây, và nhiều người dùng không nhận ra khác biệt đáng tin trong dùng thường ngày, dù độ nhạy tùy phần cứng và tác vụ. Mười năm trước điều này không đúng, khi không dây còn mang phạt độ trễ thật, và tiếng xấu lỗi thời vẫn còn trong lời khuyên online. Cái giá thật của không dây hiện đại ở polling cao là pin chứ không phải độ phản hồi. Bluetooth là chuyện riêng và thường polling thấp xa receiver chuyên dụng.

USB hub có thể giảm tần số polling hiệu dụng không?

Nó có thể là một biến số, nhưng không phải lời giải thích thường gặp cho mọi vấn đề polling. Hub tải nặng hoặc hoạt động kém ổn định có thể gây vấn đề lập lịch, trong khi một kết nối USB 2.0 bình thường đã đủ băng thông cho chuột. Hãy cắm thẳng vào một cổng mainboard hoạt động tốt, so kết quả bằng tiện ích native, đồng thời kiểm tra firmware, driver, vị trí đặt receiver không dây và tải hệ thống. USB 3.x không phải yêu cầu bắt buộc cho báo cáo chuột thông thường, và kết quả khác trên một cổng khác không chứng minh hub là nguyên nhân duy nhất.

Tần số polling chuột: 1000Hz có tốt hơn 500Hz?

Tăng polling từ 500Hz lên 1000Hz rút khoảng báo cáo từ hai mili giây xuống một, và thời gian chờ lập lịch trung bình giảm khoảng nửa mili giây. Cải thiện đó chỉ tác động đến một giai đoạn trong pipeline đầu vào và có ý nghĩa nhất khi tần số quét màn hình, tốc độ khung hình và tốc độ xử lý đã nhanh sẵn. Với công việc văn phòng và gaming giải trí, 500Hz thường là đủ và còn giúp giảm tải xử lý hoặc tiết kiệm pin. Tester trên trình duyệt có thể hé lộ pattern thời điểm sự kiện, nhưng chỉ tiện ích native mới xác minh được tốc độ báo cáo USB thực sự.

Theo số liệu

Tốc độ polling	Khoảng thời gian báo cáo	Thời gian chờ lập lịch trung bình
125 Hz	8.0 ms	4.0 ms
500 Hz	2.0 ms	1.0 ms
1000 Hz	1.0 ms	0.5 ms
2000 Hz	0.5 ms	0.25 ms
4000 Hz	0.25 ms	0.125 ms
8000 Hz	0.125 ms	0.06 ms

Bước nhảy từ 125Hz lên 1000Hz cắt 3,5ms thời gian chờ lập lịch trung bình. Bước nhảy từ 1000Hz lên 8000Hz chỉ cắt khoảng 0,44ms. Đây là khác biệt tính ở giai đoạn polling, không phải phép đo đầu-cuối trên một con chuột hay hệ thống cụ thể.

Nhà sản xuất chuột nay quảng cáo polling 8000Hz như thông số chủ đạo, với ngụ ý rõ rằng bất cứ thứ gì thấp hơn đang kìm hãm bạn. Bước từ 500Hz lên 1000Hz trên giấy là có thật, nhưng hậu quả trên màn hình nhỏ hơn nhiều so với con số gấp đôi gợi ý, và theo đuổi tần số cao hơn còn mang những cái giá mà tài liệu marketing bỏ qua. Dưới đây là bài toán trung thực.

Tần số polling thực sự mô tả điều gì

Chuột của bạn lấy mẫu vị trí rồi truyền dữ liệu về máy tính ở tần số cố định. Ở 500Hz nó báo cáo mỗi hai mili giây. Ở 1000Hz, mỗi một mili giây. Ở 8000Hz, mỗi 0,125 mili giây. Tần số cao hơn nghĩa là cập nhật vị trí dày hơn, và do đó có thể giảm độ trễ giữa lúc tay bạn di chuyển và lúc con trỏ phản hồi. Từ khóa là có thể. Polling chỉ là một giai đoạn trong pipeline độ trễ, và gần như chưa bao giờ là giai đoạn dài nhất.

Phép tính ai cũng trích dẫn, và bối cảnh nó bỏ qua

Khác biệt giữa 1000Hz và 500Hz là một mili giây ở khoảng báo cáo. Đó là toàn bộ lợi ích đo được ở giai đoạn polling, và vì chuyển động xảy ra ở điểm ngẫu nhiên trong khoảng, mức tiết kiệm trung bình thực tế gần nửa mili giây. Bây giờ hãy đặt nó cạnh các giai đoạn khác của cùng pipeline:

Giai đoạn	Thời lượng điển hình
Khoảng polling ở 1000Hz	1ms
Khoảng polling ở 500Hz	2ms
Quét màn hình ở 144Hz	6,9ms
Quét màn hình ở 60Hz	16,7ms
Thời gian khung hình GPU ở 60fps	16,7ms
Phản ứng thị giác con người	~200ms (không phải độ trễ pipeline — một loại đo khác hẳn)
Một mili giây thu được từ việc tăng gấp đôi polling là sai số làm tròn bên cạnh tần số quét màn hình và render khung hình. Lưu ý rằng mức ~200ms phản ứng thị giác con người nêu trên thuộc loại phép đo hoàn toàn khác — đó là thời gian não bộ xử lý và phản ứng với kích thích thị giác, không phải độ trễ trong pipeline đầu vào — nên chia nó cho khoảng polling không phải một so sánh hợp lệ. Mối quan hệ tỷ lệ này chính là lý do nhiều người dùng không thể phân biệt đáng tin 500Hz với 1000Hz trong sử dụng thường ngày, dù độ nhạy thay đổi theo phần cứng, tác vụ và khác biệt từng người.

Khi nào 1000Hz trở lên thực sự hữu ích

Polling cao dễ phát huy nhất khi các mắt xích khác trong chuỗi đã nhanh sẵn. Ví dụ, điều đó có thể gồm:

Màn hình tần số cao, khoảng 240Hz đến 360Hz, để màn hình thực sự trình bày được các cập nhật dưới bốn mili giây.
Tốc độ khung hình cao duy trì, vượt xa tần số quét màn hình, để luôn có khung đã render lấp đầy các cơ hội quét đó.
Độ trễ hệ thống thấp xuyên suốt, gồm kết nối USB trực tiếp, xử lý nền tối thiểu và không có overlay nào trên đường đầu vào. Trong cửa sổ thi đấu hẹp, được tối ưu có chủ đích đó, một số người chơi khai thác được giá trị thật từ 1000Hz và thỉnh thoảng từ tần số cao hơn. Ngoài cửa sổ đó, lợi ích khó nhận ra hơn vì điểm nghẽn dịch chuyển sang nơi khác, và các báo cáo dư thừa có thể bị gộp hoặc lấy mẫu mất trước khi kịp ảnh hưởng đến bất cứ thứ gì nhìn thấy được.

Chi phí của việc tăng cao hơn nữa

Polling cao không miễn phí, và trên 1000Hz các đánh đổi trở nên đáng kể:

Tải xử lý

Mỗi báo cáo đi qua stack đầu vào của hệ điều hành và thường cả engine game. Ở bốn nghìn đến tám nghìn hertz, điều này ngốn thời gian xử lý đo được, và trên hệ thống yếu, tốc độ khung hình giảm theo có thể tăng tổng độ trễ thay vì giảm.

Hao pin

Chuột không dây nhìn chung tiêu thụ điện nhiều hơn ở tần số cao, và 8000Hz có thể rút ngắn đáng kể thời gian chạy giữa các lần sạc trên một số model.

Những báo cáo hiếm khi chuyển thành lợi ích nhìn thấy được

Chuột 8000Hz báo cáo mỗi 0,125 mili giây trong khi màn hình 360Hz quét lại mỗi 2,8. Hơn hai mươi báo cáo đến giữa hai khung liên tiếp; hệ điều hành và engine game gộp, gom hoặc lấy mẫu chúng theo nhịp riêng, nên độ mịn thừa không đến được một khung render một cách đáng tin.

Polling không phải chất lượng aim cũng không phải DPI

Hai nhầm lẫn dai dẳng bóp méo quyết định mua sắm:

DPI là độ nhạy cảm biến, mô tả quãng con trỏ đi mỗi inch chuyển động vật lý. Hoàn toàn độc lập với polling và được tinh chỉnh cho sự thoải mái chứ không phải độ trễ.
Chất lượng aim đến từ độ chính xác cảm biến, bề mặt, grip và luyện tập. Chuột 1000Hz với cảm biến bị smoothing hay angle snapping sẽ aim tệ hơn chuột 500Hz với triển khai cảm biến sạch. Cả hai đều không cải thiện nhờ thông số polling, và nhà sản xuất hưởng lợi từ sự mơ hồ đó.

Kiểm chứng những gì bạn thực sự nhận được

Tốc độ cấu hình và tốc độ thực tế có thể lệch nhau, nhưng trình duyệt không đọc được trực tiếp tần số polling phần cứng: sự kiện chuột chịu việc gộp của trình duyệt, lập lịch main-thread và xử lý đầu vào của hệ điều hành, nên timing kiểu web không chứng minh được khoảng báo cáo USB thật. Để đo đáng tin, hãy dùng tiện ích native chuyên dụng đọc dữ liệu cấp USB, hoặc phần mềm của hãng chuột. Điều công cụ trình duyệt như mouse tester của chúng tôi đóng góp được là kiểm tra pattern thô — các khoảng trống dài bất thường và đều đặn giữa các cập nhật ghi nhận được có thể gợi ý vấn đề kết nối, driver, receiver hay lập lịch đáng xác minh bằng công cụ native. Hãy cắm thẳng vào một cổng mainboard hoạt động tốt và test lại trước khi kết luận con chuột có lỗi.

Mức mặc định khuyến nghị

Chuột gaming có dây: 1000Hz là mặc định hợp lý trên đa số hệ thống hiện đại; hạ xuống nếu bạn thấy vấn đề CPU hoặc frame-time.
Chuột không dây: nhiều receiver 2,4GHz hiện đại hỗ trợ 1000Hz, nên chọn theo ưu tiên: 1000Hz nếu muốn khoảng báo cáo ngắn nhất, hoặc 500Hz nếu pin quan trọng hơn. Khác biệt về cảm giác khó nhận với nhiều người dùng, trong khi khoản tiết kiệm pin ở 500Hz là có thật.
Cấu hình thi đấu với màn hình tần số cao và tốc độ khung hình cao: thử 1000Hz đến 2000Hz và đánh giá trung thực xem bạn có nhận ra khác biệt không. Nếu không, hạ xuống và lấy lại dư địa xử lý.
Mọi người khác, gồm đa số công việc năng suất: 500Hz thường là đủ. Chỉ cần kiểm tra cài đặt khi đang xử lý một vấn đề cụ thể.

USB xử lý báo cáo chuột ở cấp giao thức thế nào

Hiểu điều gì xảy ra khi chuột báo cáo vị trí giúp giải thích vì sao polling có những đặc tính như ta thấy, và vì sao quan hệ giữa thông số và hiệu quả thực tế không đơn giản như marketing gợi ý. Thiết bị USB giao tiếp với host qua endpoint, mỗi endpoint được cấu hình cho một loại transfer cụ thể. Chuột dùng interrupt transfer, mà khoảng polling do host controller lập lịch theo tần số cấu hình — host dành sẵn các khe thời gian đó, dù việc giao hàng thực tế vẫn có thể jitter dưới tải hệ thống. Thiết bị đáp ứng với dữ liệu sẵn có của mình. Độ mịn thời gian phụ thuộc tốc độ USB: thiết bị Full-Speed (điển hình cho chuột) được lập lịch theo frame một mili giây, còn thiết bị High-Speed dùng microframe 125 micro giây. Chuột cấu hình 1000Hz vì thế nhận slot một mili giây trên kết nối Full-Speed; ngữ nghĩa interval của endpoint khác nhau giữa Full-Speed và High-Speed, và nhịp báo cáo thực tế còn phụ thuộc cách descriptor của thiết bị khai báo interval của nó. Gói báo cáo được định nghĩa bởi HID descriptor của thiết bị, nơi khai báo cấu trúc và kích cỡ dữ liệu chuột gửi. Báo cáo tiêu chuẩn chứa byte trạng thái nút, delta X, delta Y, và tùy chọn wheel cùng dữ liệu trục thêm. Tổng payload nhỏ — thường tám đến mười sáu byte — nghĩa là băng thông hiếm khi là ràng buộc chính. Ràng buộc nằm ở timing: host lập lịch transfer dày đến đâu, thiết bị lấp đầy nó nhanh đến đâu, và stack đầu vào của hệ điều hành xử lý nó nhanh đến đâu. Ở cấp hệ điều hành, mỗi báo cáo nhận được kích hoạt một interrupt lan truyền qua stack driver USB, HID class driver và cuối cùng là subsystem đầu vào, nơi cập nhật vị trí con trỏ hoặc chuyển tiếp sự kiện cho ứng dụng foreground. Mỗi lớp cộng một lượng nhỏ thời gian xử lý, và ở 8000Hz các lớp này cộng lại ngốn cycle CPU đo được — lý do polling cực cao có thể kéo giảm tốc độ khung hình trên bộ xử lý yếu. Hệ điều hành không đơn giản chuyển tiếp từng báo cáo cho engine game; nó gom, gộp hoặc xử lý theo thiết kế xử lý đầu vào riêng, nghĩa là không phải báo cáo nào cũng chắc chắn ảnh hưởng đến một khung render. Hiểu biết cấp giao thức này làm rõ vài điểm. Thứ nhất, polling là thuộc tính của cấu hình endpoint USB, không phải của cảm biến chuột — cảm biến tự lấy mẫu ở tần số riêng độc lập. Thứ hai, host và thiết bị tương thích có thể lập lịch báo cáo đúng khoảng cấu hình, nhưng nhịp thực tế vẫn phụ thuộc descriptor, firmware, kết nối và lập lịch của hệ điều hành. Thứ ba, chi phí xử lý tích lũy ở tần số cực cao và có thể kéo giảm hiệu năng game trên một số hệ thống. Thông số mô tả một nhịp lập lịch, không phải bảo đảm cải thiện cảm nhận, và các lớp giữa dây tín hiệu và màn hình mỗi lớp cộng thêm độ trễ mà polling không giải quyết được. Một điểm tinh tế nữa là lập lịch của USB controller không tuyệt đối deterministic. Host controller quản lý nhiều thiết bị chung một bus, và traffic khác có thể tạo biến thiên nhỏ về timing. Biến thiên lớn bao nhiêu phụ thuộc controller, driver, thiết bị kết nối và hệ điều hành, nên nên đo chứ không nên giả định. Cổng mainboard trực tiếp là mốc so sánh chẩn đoán hợp lý, nhưng USB 3.x không bắt buộc với chuột. Một mili giây là khác biệt khoảng tối đa giữa 500Hz và 1000Hz ở giai đoạn polling. Nó có thật và đo được, nhưng với nhiều người dùng khó nhận ra. Các giai đoạn khác của pipeline — thời gian khung hình GPU, xử lý hệ điều hành và tần số quét màn hình — có thể đóng góp nhiều hơn hẳn, và không cài đặt chuột nào rút ngắn được chúng. Nếu bạn có chuột gaming và màn hình tần số cao, 1000Hz là điểm khởi đầu hợp lý, nhưng hãy đánh giá tải CPU, frame time, pin và trải nghiệm của chính mình thay vì coi đó là yêu cầu phổ quát. Để hiểu polling nằm ở đâu trong chuỗi độ trễ tổng thể, hữu ích là truy vết một chuyển động chuột qua mọi giai đoạn, từ bề mặt vật lý đến khi con trỏ đổi hướng nhìn thấy được. Mỗi giai đoạn góp thời gian, và polling chỉ là một trong số đó. Lấy mẫu cảm biến. Cảm biến quang học trong chuột chụp ảnh bề mặt ở tốc độ nội bộ cao — thường 12.000 đến 16.000 khung mỗi giây — và so các khung liên tiếp để tính chuyển động. Quá trình này hoàn toàn nội bộ bên trong cảm biến, chạy theo tần số riêng độc lập với polling USB. Cảm biến tạo position delta và giao cho vi điều khiển của chuột. Xử lý vi điều khiển. MCU nhận delta từ cảm biến, áp các xử lý được cấu hình như angle snapping, smoothing hay acceleration, rồi đóng gói thành gói báo cáo USB. Giai đoạn này cộng một độ trễ nhỏ nhưng khác không — các mô hình minh họa cho thấy dưới một mili giây trên firmware được làm tốt, nhưng giá trị thực tùy thiết bị và có thể dài hơn trên máy có xử lý DSP nặng. Transfer USB. Đây là giai đoạn do polling chi phối. Ở 1000Hz, gói báo cáo chờ interrupt transfer được lập lịch kế tiếp, xảy ra mỗi một mili giây. Trung bình, báo cáo chờ nửa khoảng đó — 0,5 mili giây — trước khi truyền về host. Ở 500Hz, thời gian chờ trung bình tăng gấp lên một mili giây. Stack đầu vào hệ điều hành. Host nhận báo cáo, xử lý qua driver USB, HID class driver và subsystem đầu vào. Vị trí con trỏ được cập nhật trong compositor của hệ điều hành, và sự kiện input thô được chuyển tiếp cho game. Giai đoạn này thường được mô hình hóa ở mức một đến ba mili giây tùy hệ điều hành, phiên bản driver và tải hệ thống — hãy coi là khoảng minh họa, không phải phép đo của một hệ thống cụ thể. Xử lý engine game. Game nhận sự kiện đầu vào, áp logic xử lý riêng (có thể gồm scale độ nhạy, raw input so với buffered input, và lấy mẫu phụ thuộc tốc độ khung hình), rồi đưa chuyển động vào khung render kế tiếp. Nếu game chạy 60fps, mỗi khung mất 16,7 mili giây, nghĩa là chuyển động không thể xuất hiện trên màn hình cho tới khi khung kế tiếp được render và gửi xuống màn hình. Trình bày màn hình. Khung đã render đi tới monitor, nơi trình bày nó theo khoảng quét riêng. Ở 144Hz, khung xuất hiện trên màn hình trong vòng 6,9 mili giây sau khi đến buffer đầu vào của màn hình. Tổng các giai đoạn điển hình với thời gian chờ trung bình theo một mô hình minh họa (không phải phép đo của một chuột hay game cụ thể): cảm biến (~0,25ms) + MCU (~0,5ms) + USB ở 1000Hz (~0,5ms chờ trung bình) + OS (~2ms) + game ở 60fps (~8,3ms chờ khung trung bình) + màn hình ở 144Hz (~3,5ms chờ quét trung bình) ≈ khoảng 15 mili giây tổng. Trong mô hình này, giai đoạn polling USB đóng góp cỡ 3% tổng. Tăng gấp đôi khoảng lên 500Hz cộng thêm ~0,5 mili giây trung bình, đẩy tổng lên ~15,5 mili giây. Đó là lý do khác biệt đo được giữa 500Hz và 1000Hz luôn dưới một mili giây — phần còn lại của pipeline không đổi. Các con số này là mô hình minh họa, không phải phép đo của một chuột, hệ điều hành hay game cụ thể; giá trị thực phụ thuộc hoàn toàn vào phần cứng, driver và phần mềm của bạn. Hàm ý không phải polling vô nghĩa, mà nó là thành phần cuối cùng đáng tối ưu. Theo cùng mô hình chờ trung bình, nếu game của bạn chạy 60fps, nâng lên 144fps cắt khoảng 4,9 mili giây chờ khung trung bình (16,7ms/2 trừ 6,9ms/2) — gấp mười khoản tiết kiệm từ việc tăng gấp đôi polling. Nếu màn hình chạy 60Hz, nâng lên 144Hz cắt trung bình khoảng 4,9 mili giây (16,7ms/2 trừ 6,9ms/2). Con số chính xác phụ thuộc bạn đo chờ trung bình, full frame time hay độ trễ đầu-cuối, nên hãy coi chúng là minh họa chứ không phổ quát. Cả hai thay đổi đó còn tạo cải thiện nhìn thấy được về độ rõ chuyển động mà điều chỉnh polling không sánh nổi. Chỉ khi tốc độ khung hình và tần số quét đã cao, phần đóng góp của polling mới thành tỷ trọng lớn hơn trong độ trễ còn lại, và kể cả khi đó nó vẫn nhỏ về giá trị tuyệt đối.

Con số cần nhớ

1000Hz có thể rút khoảng ở giai đoạn polling tối đa một mili giây so với 500Hz — có thật nhưng thường khó nhận ra. Hãy tối ưu trực diện vào tần số quét màn hình và tốc độ khung hình duy trì trước, vì các giai đoạn đó có thể góp độ trễ lớn hơn hẳn, rồi mới đánh giá xem polling có đổi được gì bạn cảm nhận được không. Hãy coi 8000Hz là một lựa chọn báo cáo độ phân giải cao chứ không phải nâng cấp cảm nhận được bảo đảm, cho đến khi phần còn lại của pipeline tận dụng nổi nó.