Fare Polling Hızı: 1000Hz Gerçekten 500Hz'den Daha mı İyi?

Polling hızını 500Hz'den 1000Hz'e çıkarmak rapor aralığını iki milisaniyeden bire indirir ve ortalama zamanlama beklemesini kabaca yarım milisaniye kısaltır. Bu iyileşme giriş boru hattının yalnızca tek bir aşamasını etkiler ve ekran yenilemesi, kare hızı ile işleme zaten hızlıyken en çok işe yarar. Ofis işi ve sıradan oyun için 500Hz genellikle fazlasıyla yeterlidir ve işlemci yükünü ya da kablosuz modda batarya kullanımını azaltabilir. Tarayıcı tabanlı bir testçi olay zamanlama örüntülerini ortaya çıkarabilir; ama USB rapor hızının kendisini yalnızca yerel bir yardımcı program doğrulayabilir.

Rakamlarla

125 Hz’den 1000 Hz’e geçiş, ortalama zamanlama beklemesinden 3,5ms kaldırır. 1000 Hz’den 8000 Hz’e geçiş yaklaşık 0,44ms kaldırır. Bunlar hesaplanmış polling aşaması farklarıdır; belirli bir farenin ya da sistemin uçtan uca ölçümleri değildir.

Fare üreticileri artık 8000Hz polling’i manşet özelliği olarak tanıtıyor; ima açıkça şudur: daha düşük her şey sizi geri tutuyor. 500Hz’den 1000Hz’e adım kâğıt üzerinde gerçektir; ama ekrandaki sonucu ikiye katlanan sayının önerdiğinden belirgin biçimde küçüktür ve daha yüksek hızların peşine düşmek, pazarlama malzemesinin atladığı maliyetler taşır. İşte dürüst hesap.

Polling hızı gerçekte neyi açıklar

Fareniz konumunu örnekler ve bu veriyi sabit bir frekansta bilgisayara iletir. 500Hz’de her iki milisaniyede bir, 1000Hz’de her milisaniyede bir, 8000Hz’de her 0,125 milisaniyede bir bildirim yapar. Daha yüksek bir hız daha sık konum güncellemesi demektir; dolayısıyla elinizin hareketi ile imlecin yanıt vermesi arasındaki gecikmenin potansiyel olarak azalması demektir.

İşin anahtar sözcüğü potansiyel olarak. Polling, gecikme boru hattındaki bir aşamadır ve neredeyse hiçbir zaman en uzun olanı değildir.

Herkesin alıntıladığı aritmetik ve atladığı bağlam

1000Hz ile 500Hz arasındaki fark, rapor aralığında bir milisaniyedir. Polling aşamasındaki ölçülebilir avantajın tamamı budur; hareket aralığın rastgele bir noktasında gerçekleştiği için ortalama gerçekleşen tasarruf yarım milisaniyeye yakındır.

Şimdi bunu aynı boru hattının diğer aşamalarının yanına koyun:

Polling hızını ikiye katlayarak kazanılan bir milisaniye, ekran yenileme ve kare render yanında bir yuvarlama hatasıdır. Yukarıda listelenen ~200ms’lik insan görsel tepkisinin tümüyle başka bir ölçüm kategorisi olduğuna dikkat edin — bu, beynin görsel uyaranı işlemesi ve yanıtlaması süresidir, giriş boru hattındaki bir gecikme değil; dolayısıyla onu polling aralığına bölmek geçerli bir karşılaştırma değildir. Bu orantısal ilişki, birçok kullanıcının sıradan kullanımda 500Hz ile 1000Hz’i güvenilir biçimde ayırt edememesinin tüm nedenidir; duyarlılık donanıma, göreve ve bireysel farklılıklara göre değişse de.

1000Hz ve üzeri ne zaman gerçekten yardımcı olur

Daha yüksek polling, zincirdeki diğer halkalar zaten hızlıyken en çok işe yarar. Örneğin şu durumlar buna dahil olabilir:

• Ekranın dört milisaniyenin altındaki aralıklarla güncelleme sunabilmesi için 240Hz ila 360Hz aralığında yüksek yenilemeli bir ekran.
• Render edilen karelerin bu yenileme fırsatlarını dolduracak şekilde var olması için, ekran yenilemesinin belirgin üzerinde sürdürülen yüksek kare hızları.
• Doğrudan USB bağlantısı, en aza indirilmiş arka plan işlemesi ve giriş yolunda overlay olmaması dahil, uçtan uca düşük sistem gecikmesi.

Bu dar, kasıtlı olarak optimize edilmiş rekabetçi pencerenin içinde bazı oyuncular 1000Hz’den, ara sıra daha yüksek hızlardan gerçek değer çıkarabilir. Pencerenin dışında faydayı fark etmek zordur; çünkü darboğaz başka yere kayar ve ek raporlar, görünür hiçbir şeyi etkilemeden önce birleştirilebilir ya da örneklenebilir.

Daha da yükseltmenin maliyetleri

Daha yüksek polling bedava değildir; 1000Hz’in ötesinde takaslar somutlaşır:

İşlemci yükü

Her rapor işletim sisteminin giriş yığınından ve çoğu zaman oyun motorundan geçer. Dört bin ila sekiz bin hertz aralığında bu ölçülebilir işlemci süresi tüketir; zayıf sistemlerde ortaya çıkan kare hızı düşüşü toplam gecikmeyi azaltmak yerine artırabilir.

Batarya tüketimi

Kablosuz fareler yükseltilmiş hızlarda genellikle daha fazla güç tüketir; 8000Hz bazı modellerde şarjlar arası çalışma süresini ciddi biçimde kısaltabilir.

Görünür faydaya nadiren dönüşen raporlar

8000Hz bir fare her 0,125 milisaniyede bildirim yapar; 360Hz bir ekran ise her 2,8 milisaniyede yenilenir. Ardışık kareler arasında yirmiden fazla rapor gelir; işletim sistemi ve oyun motoru bunları kendi ritimlerinde birleştirir, toplu işler ya da örnekler, dolayısıyla ek incelik bir render edilmiş kareye güvenilir biçimde ulaşmaz.

Polling hızı ne nişan kalitesidir ne DPI

Satın alma kararlarını bozan iki inatçı karışıklık:

• DPI sensör hassasiyetidir; fiziksel hareketin inç başına imleç yolunu açıklar. Polling’den tümüyle bağımsızdır ve gecikme için değil konfor için ayarlanır.
• Nişan kalitesi sensör doğruluğundan, yüzeyden, tutuştan ve pratikten doğar. Yumuşatma ya da açı kilitleme sergileyen sensörlü 1000Hz bir fare, temiz sensör uygulamalı 500Hz fareden daha kötü nişan alır.

İkisi de polling özelliğiyle iyileşmez; belirsizlikten kazanan ise üreticilerdir.

Gerçekte ne aldığınızı doğrulayın

Ayarlanan hız ile ulaşılan hız ayrışabilir; ama bir tarayıcı donanım polling hızını doğrudan okuyamaz: fare olayları tarayıcı birleştirmesine, ana iş parçacığı zamanlamasına ve işletim sisteminin giriş işlemesine tabidir; bu yüzden web tabanlı zamanlama gerçek USB rapor aralığını kanıtlayamaz. Güvenilir bir ölçüm için USB düzeyinde veri okuyan özel bir yerel yardımcı program ya da fare üreticinizin yazılımını kullanın. Fare testimiz gibi bir tarayıcı aracının katkısı kaba bir örüntü kontrolüdür — kaydedilen güncellemeler arasındaki alışılmadık derecede uzun ve tutarlı boşluklar, yerel bir araçla doğrulanmaya değer bir bağlantı, sürücü, alıcı ya da zamanlama sorununa işaret edebilir. Fareyi suçlamadan önce bilinen iyi bir anakart portuna doğrudan bağlayın ve yeniden test edin.

Önerilen varsayılanlar

• Kablolu oyun faresi: 1000Hz çoğu modern sistemde makul bir varsayılandır; işlemci ya da kare süresi sorunu görürseniz düşürün.
• Kablosuz fare: birçok modern 2.4GHz alıcı 1000Hz destekler; önceliğe göre seçin: en kısa rapor aralığını istiyorsanız 1000Hz, batarya ömrü daha önemliyse 500Hz. His farkını birçok kullanıcı zor algılar; 500Hz’deki batarya tasarrufu ise gerçek olabilir.
• Yüksek yenilemeli ekran ve yüksek kare hızlı rekabetçi sistem: 1000Hz ila 2000Hz deneyin ve sizin bir fark algılayıp algılamadığınızı dürüstçe değerlendirin. Algılamıyorsanız geri düşürün ve işlemci payını geri kazanın.
• Çoğu verimlilik kullanımı dahil diğer herkes: 500Hz genellikle yeterlidir. Ayarı yalnızca belirli bir sorunun üstünde çalışırken doğrulayın.

USB fare raporlarını protokol düzeyinde nasıl ele alır

USB cihazları ana bilgisayarla endpoint’ler üzerinden haberleşir; her endpoint belirli bir transfer tipi için yapılandırılır. Fareler interrupt transferlerini kullanır; bunların polling aralığını ana bilgisayar denetleyicisi yapılandırılan frekansta planlar — ana bilgisayar bu zaman dilimlerini ayırır, ama gerçek dünyada teslimat sistem yükü altında yine de titreyebilir (jitter). Cihaz elindeki hazır veriyle yanıt verir. Zaman inceliği USB hızına bağlıdır: Full-Speed bir cihaz (fareler için tipik) birer milisaniyelik frame’lere göre planlanırken High-Speed bir cihaz 125 mikrosaniyelik microframe’leri kullanır. 1000Hz’e yapılandırılmış bir fare bu nedenle Full-Speed bağlantıda bir milisaniyelik dilim alır; endpoint aralığı semantiği Full-Speed ile High-Speed arasında farklılık gösterir ve gerçek rapor ritmi ayrıca cihazın tanımlayıcısının aralığı nasıl bildirdiğine bağlıdır.

Rapor paketinin kendisini cihazın HID tanımlayıcısı tanımlar; bu tanımlayıcı, farenin gönderdiği verinin yapısını ve boyutunu bildirir. Standart bir raporda düğme durumu baytı, bir X deltası, bir Y deltası ve isteğe bağlı olarak tekerlek ile ek eksen verileri bulunur. Toplam yük küçüktür — tipik olarak sekiz ila on altı bayt — bu da bant genişliğinin neredeyse hiçbir zaman birincil kısıt olmadığı anlamına gelir. Kısıt zamanlamadır: ana bilgisayarın transferi ne sıklıkla planladığı, cihazın onu ne kadar hızlı doldurabildiği ve işletim sisteminin giriş yığınının ne kadar hızlı işleyebildiği.

İşletim sistemi düzeyinde alınan her rapor, USB sürücü yığınından, HID sınıf sürücüsünden ve sonunda imleç konumunu güncelleyen ya da olayı ön plandaki uygulamaya ileten giriş alt sistemine yayılan bir interrupt tetikler. İşletim sistemi her raporu olduğu gibi oyun motoruna iletmez; kendi giriş işleme tasarımına göre bunları toplar, birleştirir ya da işler; yani her rapor mutlaka bir render edilmiş kareyi etkilemek zorunda değildir.

Bu protokol düzeyindeki anlayış birkaç noktayı netleştirir. Birincisi, polling hızı USB endpoint yapılandırmasının özelliğidir, fare sensörünün değil — sensör kendi hızında bağımsız örnekleyebilir. İkincisi, uyumlu bir ana bilgisayar ve cihaz raporları yapılandırılan aralıkta planlayabilir; ama gerçek ritim yine de tanımlayıcıya, aygıt yazılımına, bağlantıya ve işletim sistemi zamanlamasına bağlıdır. Üçüncüsü, işleme maliyeti aşırı hızlarda birikir ve bazı sistemlerde oyun performansını düşürebilir. Özellik bir planlama ritmini tanımlar; algısal iyileşme garantisi değildir. Kablodan ekrana kadar katmanların her biri, polling hızının çözemediği bir gecikme ekler.

Daha ince bir nokta: USB denetleyici zamanlaması kusursuz deterministik değildir. Ana bilgisayar denetleyicisi aynı veri yolunu paylaşan birden çok cihazı yönetir ve diğer trafik küçük zamanlama sapmaları yaratabilir. Sapmanın boyutu denetleyiciye, sürücülere, bağlı cihazlara ve işletim sistemine bağlıdır; o yüzden varsayılmaz, ölçülür. Doğrudan anakart portu makul bir teşhis karşılaştırmasıdır; ama bir fare için USB 3.x doğal olarak gerekli değildir.

Polling aşamasında 500Hz ile 1000Hz arasındaki azami aralık farkı bir milisaniyedir. Gerçek ve ölçülebilirdir; ama birçok kullanıcı için fark edilmesi zordur. Boru hattının diğer aşamaları — GPU kare süresi, işletim sistemi işlemesi ve ekran yenilemesi — çok daha fazla katkıda bulunabilir ve hiçbir fare ayarı onları kısaltamaz. Oyun faresi ve yüksek yenilemeli monitörünüz varsa 1000Hz makul bir başlangıç noktasıdır; ama onu evrensel bir gereklilik saymak yerine işlemci yükünü, kare süresini, batarya kullanımını ve kendi deneyiminizi değerlendirin.

Polling hızının genel gecikme zincirinde nerede durduğunu anlamak için, tek bir fare hareketini fiziksel yüzeyden görünür imleç değişimine kadar her aşamadan izlemek yardımcı olur. Her aşama süre katar; polling bunlardan yalnızca biridir.

Sensör örnekleme. Farenizdeki optik sensör yüzeyin görüntülerini yüksek bir iç hızda — çoğunlukla saniyede 12.000 ila 16.000 kare — yakalar ve ardışık kareleri karşılaştırarak hareketi hesaplar. Bu süreç tümüyle sensörün içindedir ve USB polling hızından bağımsız kendi frekansında çalışır. Sensör bir konum deltası üretir ve farenin mikrodenetleyicisine devreder.

Mikrodenetleyici işlemesi. MCU sensör deltasını alır; açı kilitleme, yumuşatma ya da ivmelenme gibi yapılandırılmış işlemeleri uygular ve bir USB rapor paketi hâline getirir. Bu aşama küçük ama sıfır olmayan bir gecikme ekler — temsili modeller iyi mühendisliklenmiş aygıt yazılımında bir milisaniyenin altını gösterir; gerçek değerler cihaza göre değişir ve ağır DSP işlemeli cihazlarda daha uzun olabilir.

USB transferi. Polling hızının yönettiği aşama budur. 1000Hz’de hazırlanan rapor, her milisaniyede gerçekleşen bir sonraki planlı interrupt transferini bekler. Ortalama olarak rapor, ana bilgisayara iletilmeden önce aralığın yarısı — 0,5 milisaniye — bekler. 500Hz’de ortalama bekleme ikiye katlanır ve bir milisaniye olur.

İşletim sistemi giriş yığını. Ana bilgisayar raporu alır; USB sürücüsünden, HID sınıf sürücüsünden ve giriş alt sisteminden geçirir. İmleç konumu işletim sistemi compositor’ında güncellenir, ham giriş olayı oyuna iletilir. Bu aşama işletim sistemine, sürücü sürümüne ve sistem yüküne göre yaygın biçimde bir ila üç milisaniye modellenir — bunu temsili bir aralık olarak görün, belirli bir sistemin ölçümü olarak değil.

Oyun motoru işlemesi. Oyun giriş olayını alır; kendi giriş işlemesi mantığını (hassasiyet ölçekleme, ham giriş ve tamponlu giriş farkı, kare hızına bağlı örnekleme dahil) uygular ve hareketi bir sonraki render edilecek kareye katar. Oyun 60fps çalışıyorsa her kare 16,7 milisaniye sürer; yani hareket, bir sonraki kare render edilip ekrana sunulana kadar ekranda görünemez.

Ekran sunumu. Render edilen kare monitöre gider ve monitör onu kendi yenileme aralığında sunar. 144Hz’de kare, ekranın giriş tamponuna vardıktan sonra 6,9 milisaniye içinde ekranda görünür.

Temsili bir modelle (belirli bir farenin ya da oyunun ölçümü değil) tipik aşamaları ortalama beklemeleriyle toplayın: sensör (~0,25ms) + MCU (~0,5ms) + 1000Hz USB (~0,5ms ortalama bekleme) + OS (~2ms) + 60fps oyun (~8,3ms ortalama kare beklemesi) + 144Hz ekran (~3,5ms ortalama yenileme beklemesi) ≈ toplam kabaca 15 milisaniye. Bu modelde USB polling aşaması toplamın kabaca %3’üne katkıda bulunur. Aralığı 500Hz’e çıkarmak ortalama ~0,5 milisaniye ekler ve toplamı ~15,5 milisaniyeye taşır. Ölçülen 500Hz–1000Hz farkının tutarlı biçimde bir milisaniyenin altında kalmasının nedeni budur — boru hattının geri kalanı değişmez. Bu rakamlar temsili bir modeldir; belirli bir fare, işletim sistemi ya da oyunun ölçümü değildir. Gerçek değerler tamamen sizin donanımınıza, sürücülerinize ve yazılımınıza bağlıdır.

Sonuç, polling hızının önemsiz olduğu değil, optimize edilecek son bileşen olduğudur. Aynı ortalama bekleme modeliyle oyununuz 60fps çalışıyorsa kare hızını 144fps’e çıkarmak ortalama kare beklemesinden yaklaşık 4,9 milisaniye kaldırır (16,7ms/2 eksi 6,9ms/2) — polling hızını ikiye katlamanın sağladığının kabaca on katı. Ekranınız 60Hz çalışıyorsa 144Hz’e geçmek ortalama yine yaklaşık 4,9 milisaniye kaldırır (16,7ms/2 eksi 6,9ms/2). Kesin sayılar ortalama bekleme mi, tam kare süresi mi yoksa uçtan uca gecikme mi ölçtüğünüze bağlıdır; o yüzden bunları evrensel değil temsili sayın. Bu iki değişiklik ayrıca polling ayarlarının asla erişemeyeceği hareket netliği iyileşmeleri üretir. Yalnızca kare hızı ve yenileme hızı zaten yüksekken polling hızının katkısı kalan gecikme içinde oransal olarak büyür; o zaman bile mutlak terimlerde küçüktür.

Hatırlanacak tek sayı

1000Hz, 500Hz’e kıyasla polling aşaması aralığını en fazla bir milisaniye kısaltabilir; bu gerçektir ama çoğu zaman fark edilmesi zordur. Önce optimizasyonu ekran yenileme hızı ve sürdürülen kare hızına yöneltin; çünkü bu aşamalar çok daha büyük gecikmeler katabilir. Sonra polling hızının algılayabildiğiniz bir şeyi değiştirip değiştirmediğini değerlendirin. Boru hattının geri kalanı bu çözünürlüğü kullanabilene dek 8000Hz’i garantili hissedilen bir yükseltme değil, yüksek çözünürlüklü bir raporlama seçeneği olarak görün.