Czy 1000Hz jest lepsze niż 500Hz u myszy?

Podwojenie częstotliwości odpytywania z 500Hz na 1000Hz skraca interwał raportowania z dwóch milisekund do jednej, dając jedno-milisekundową poprawę w jednym etapie znacznie dłuższego łańcucha latencji. W praktyce ten zysk jest nieodczuwalny obok interwału odświeżania wyświetlacza, czasu klatki GPU i ludzkiej szybkości reakcji, z których każdy jest o rząd wielkości większy. Wyższe odpytywanie pomaga tylko wtedy, gdy każde inne ogniwo jest już szybkie, co oznacza wyświetlacz o wysokiej częstotliwości odświeżania, utrzymane wysokie liczby klatek i niska latencja systemu w całym łańcuchu. Do pracy biurowej i gamingu okazjonalnego 500Hz jest funkcjonalnie identyczne, zużywając mniej czasu procesora i, w urządzeniach bezprzewodowych, mniej baterii — choć nowoczesne odbiorniki 2,4GHz obsługują 1000Hz, gdy tego chcesz.

W liczbach

Skok z 125 Hz do 1000 Hz usuwa około pięciu milisekund średniego czasu oczekiwania. Skok z 1000 Hz do 8000 Hz usuwa dodatkową pół milisekundy — a ta pół milisekundy jest ukryta w piętnastu milisekundach innych opóźnień, których mysz nie może skrócić.

Producenci myszy reklamują teraz 8000Hz odpytywania jako specyfikację wiodącą, z jasnym sugerowaniem, że wszystko niższe Cię ogranicza. Krok z 500Hz na 1000Hz jest autentycznie realny na papierze, ale konsekwencja na ekranie jest znacznie mniejsza, niż sugeruje podwojona liczba, a dążenie do wyższych częstotliwości niesie koszty, które materiały marketingowe pomijają. Oto rzetelne rozliczenie.

Co faktycznie opisuje częstotliwość odpytywania

Twoja mysz próbuje swoją pozycję i przesyła te dane do komputera ze stałą częstotliwością. Przy 500Hz raportuje co dwie milisekundy. Przy 1000Hz co jedną milisekundę. Przy 8000Hz co 0,125 milisekundy. Wyższa częstotliwość oznacza częstsze aktualizacje pozycji, a zatem potencjalnie mniej opóźnienia między ruchem ręki a reakcją kursora.

Rzeczonym słowem jest potencjalnie. Odpytywanie jest jednym etapem w potoku latencji i prawie nigdy nie jest najdłuższym.

Arytmetyka, którą wszyscy cytują, i kontekst, który pomijają

Różnica między 1000Hz a 500Hz to jedna milisekunda w interwale raportowania. To jest kompletna mierzalna przewaga na etapie odpytywania, a ponieważ ruch pojawia się w losowych momentach w obrębie interwału, średnia zrealizowana oszczędność to raczej pół milisekundy.

A teraz postaw to obok innych etapów tej samej potoku:

Jedna milisekunda zyskana przez podwojenie częstotliwości odpytywania jest błędem zaokrąglenia obok odświeżania wyświetlacza i renderowania klatek, a jest mniej więcej dwieście razy mniejsza niż Twój własny czas reakcji. Ta proporcjonalna zależność jest całym powodem, dla którego większość graczy autentycznie nie potrafi odróżnić 500Hz od 1000Hz w ślepym porównaniu, niezależnie od tego, co oczekuje odczuć.

Kiedy 1000Hz i wyżej autentycznie pomaga

Wyższe odpytywanie przynosi wartość tylko wtedy, gdy każde inne ogniwo w łańcuchu jest już szybkie. Konkretnie wymaga to:

• Wyświetlacza o wysokiej częstotliwości odświeżania, w zakresie 240Hz do 360Hz, aby ekran mógł faktycznie prezentować aktualizacje w interwałach poniżej czterech milisekund.
• Utrzymanych wysokich liczb klatek, istotnie powyżej trzystu, aby renderowane klatki istniały, by wypełnić te możliwości odświeżania.
• Niskiej latencji systemu w całym łańcuchu, włączając bezpośrednie połączenie USB, minimalne przetwarzanie w tle i brak nakładek w ścieżce wejścia.

W tym wąskim, celowo zoptymalizowanym oknie konkurencyjnym, niewielka liczba graczy potrafi wyciągnąć realną wartość z 1000Hz, a czasem z wyższych częstotliwości. Poza nim korzyść zapada w nieodczuwalność, ponieważ wąskie gardło po prostu przenosi się gdzie indziej, a dodatkowe raporty są łączone lub próbkowane, zanim wpłyną na cokolwiek widocznego.

Koszty podnoszenia dalej

Wyższe odpytywanie nie jest bezpłatne, a powyżej 1000Hz kompromisy stają się materialne:

Obciążenie procesora

Każdy raport przechodzi przez stos wejścia systemu operacyjnego i często silnik gry. Przy czterech do ośmiu tysięcy herców zużywa to mierzalny czas procesora, a na słabszych systemach wynikająca z tego redukcja liczby klatek może zwiększyć całkowitą latencję zamiast ją zmniejszyć.

Rozładowanie baterii

Myszy bezprzewodowe zużywa znacznie więcej energii przy podwyższonych częstotliwościach, a 8000Hz może drastycznie skrócić czas pracy między ładowaniami.

Raporty, które rzadko przekładają się na widoczny zysk

Mysz 8000Hz raportuje co 0,125 milisekundy, podczas gdy wyświetlacz 360Hz odświeża się co 2,8. Ponad dwadzieścia raportów dociera między kolejnymi klatkami, a dodatkowa granularność nie ma celu.

Częstotliwość odpytywania to nie celność ani DPI

Dwie uporczywe pomyłki zniekształcają decyzje zakupowe:

• DPI to czułość sensora, opisująca przemieszczenie kursora na cal fizycznego ruchu. Jest całkowicie niezależne od odpytywania i dostrojone dla komfortu, a nie latencji.
• Celność pochodzi z dokładności sensora, podłoża, chwytu i ćwiczeń. Mysz 1000Hz z sensorem wykazującym wygładzanie lub przyciąganie kątów będzie celować gorzej niż mysz 500Hz z czystą implementacją sensora.

Żadne z nich nie jest poprawiane przez specyfikację odpytywania, a producenci korzystają na niejednoznaczności.

Zweryfikuj, co faktycznie otrzymujesz

Skonfigurowana częstotliwość i dostarczona mogą się rozchodzić, ale przeglądarka nie może bezpośrednio odczytać sprzętowej częstotliwości odpytywania: zdarzenia myszy podlegają łączeniu przez przeglądarkę, harmonogramowaniu głównego wątku i obsłudze wejścia systemu operacyjnego, więc czas pomierzony w webie nie może udowodnić prawdziwego interwału raportowania USB. Do wiarygodnego pomiaru użyj dedykowanego natywnego narzędzia czytającego dane na poziomie USB lub oprogramowania producenta myszy. Wkładem narzędzia przeglądarkowego, takiego jak nasz tester myszy, może być gruba kontrola wzorca — niezwykle długie i konsekwentne przerwy między zarejestrowanymi aktualizacjami mogą sugerować, że ścieżka połączenia (współdzielony hub, nagłówek panelu przedniego lub marginalny kabel) dławi dostarczanie, co warto zweryfikować natywnym narzędziem. Podłącz bezpośrednio do portu USB 3.0 z tyłu płyty głównej i przetestuj ponownie, zanim uznasz mysz za wadliwą.

Rekomendowane ustawienia domyślne

• Przewodowa mysz gamingowa: 1000Hz. Bezpieczne, standardowe, bez istotnego mankamentu.
• Mysz bezprzewodowa: nowoczesne odbiorniki 2,4GHz obsługują 1000Hz, więc wybierz według priorytetu: 1000Hz, jeśli chcesz maksymalną responsywność, lub 500Hz, jeśli ważniejsza jest żywotność baterii — różnica w odczuciu jest nieodczuwalna dla większości użytkowników, a oszczędność baterii przy 500Hz jest realna.
• Setup konkurencyjny z wyświetlaczem o wysokiej częstotliwości odświeżania i wysokich liczbach klatek: wypróbuj 1000Hz do 2000Hz i oceń rzetelnie, czy Ty wykrywasz różnicę. Jeśli nie, zejdź z powrotem i odzyskaj zapas mocy procesora.
• Wszyscy inni, włączając całe użytkowanie produktywne: 500Hz jest całkowicie wystarczające. Pytanie nie zasługuje na dalszą uwagę.

Jak USB obsługuje raporty myszy na poziomie protokołu

Urządzenia USB komunikują się z hostem przez punkty końcowe, z których każdy jest skonfigurowany dla określonego typu transferu. Myszy używają transferów przerwających, których interwał odpytywania kontroler hosta planuje z skonfigurowaną częstotliwością — host rezerwuje te szczeliny czasowe, choć rzeczywista dostawa może nadal drgać pod obciążeniem systemu. Granularność czasu zależy od prędkości USB: urządzenie Full-Speed (typowe dla myszy) jest planowane w ramkach jednej milisekundy, podczas gdy urządzenie High-Speed używa mikroramek 125 mikrosekund. Mysz skonfigurowana na 1000Hz dostaje zatem szczelinę jednej milisekundy na połączeniu Full-Speed; dokładna semantyka interwału punktu końcowego różni się między Full-Speed a High-Speed, a rzeczywisty rytm raportowania zależy też od tego, jak deskryptor urządzenia deklaruje swój interwał.

Sam pakiet raportu jest definiowany przez deskryptor HID urządzenia, który deklaruje strukturę i rozmiar danych wysyłanych przez mysz. Standardowy raport zawiera bajt stanu przycisków, deltę X, deltę Y i opcjonalnie dane kółka oraz dodatkowych osi. Całkowity ładunek jest niewielki — zazwyczaj od ośmiu do szesnastu bajtów — co oznacza, że pasmo prawie nigdy nie jest ograniczeniem. Ograniczeniem jest timing: jak często host planuje transfer, jak szybko urządzenie może go wypełnić i jak szybko stos wejścia systemu operacyjnego potrafi go przetworzyć.

Na poziomie systemu operacyjnego każdy odebrany raport wyzwala przerwanie, które przechodzi przez stos sterownika USB, sterownik klasy HID i ostatecznie podsystem wejścia, który aktualizuje pozycję kursora lub przekazuje zdarzenie do aplikacji pierwszoplanowej. System operacyjny nie po prostu przekazuje każdego raportu do silnika gry; grupuje je, łączy lub przetwarza zgodnie z własnym projektem obsługi wejścia, co oznacza, że nie każdy raport koniecznie wpływa na renderowaną klatkę.

To zrozumienie na poziomie protokołu wyjaśnia kilka kwestii. Po pierwsze, częstotliwość odpytywania jest właściwością konfiguracji punktu końcowego USB, a nie sensora myszy — sensor może próbkować z własną częstotliwością niezależnie. Po drugie, kompatybilny host i urządzenie mogą planować raporty z skonfigurowanym interwałem, ale rzeczywisty rytm nadal zależy od deskryptora, firmware, połączenia i harmonogramowania systemu operacyjnego. Po trzecie, koszt przetwarzania jest realny i kumuluje się przy ekstremalnych częstotliwościach, co jest powodem, dla którego myszy 8000Hz mogą redukować wydajność gry zamiast ją poprawiać. Specyfikacja opisuje rytm planowania, a nie gwarancję poprawy percepcyjnej, a warstwy między kablem a ekranem każda wprowadza własną latencję, której częstotliwość odpytywania nie jest w stanie rozwiązać.

Dalszym subtelnością jest to, że planowanie kontrolera USB nie jest idealnie deterministyczne. Kontroler hosta zarządza wieloma urządzeniami współdzielącymi tę samą magistralę, a choć transfery przerwania mają gwarantowaną szczelinę, inny ruch na tym samym kontrolerze może wprowadzać jitter — drobne wahania w dokładnym momencie każdego transferu. Na dobrze skonfigurowanym systemie z myszą na dedykowanym kontrolerze ten jitter jest zaniedbywalny, często poniżej 0,1 milisekundy. Na systemie, gdzie mysz współdzieli kontroler z urządzeniami o dużym paśmie, jak pamięć zewnętrzna czy karty przechwytujące, rywalizacja o harmonogram może produkować okazjonalne opóźnienia, które są małe w ujęciu bezwzględnym, ale mierzalne precyzyjną instrumentacją. To jest jeden z powodów, dla których gracze konkurencyjni często podłączają swoją myszę do konkretnego portu USB rekomendowanego przez producenta płyty głównej, a nie do najbliższego dostępnego portu.

Aby zrozumieć, gdzie częstotliwość odpytywania znajduje się w całkowitym łańcuchu latencji, warto prześledzić pojedynczy ruch myszy przez każdy etap od fizycznego podłoża do widocznej zmiany kursora. Każdy etap wnosi czas, a odpytywanie to tylko jeden z nich.

Próbkowanie sensora. Sensor optyczny w Twojej myszy przechwytuje obrazy podłoża z wysoką wewnętrzną częstotliwością — często 12.000 do 16.000 klatek na sekundę — i porównuje kolejne klatki, by obliczyć ruch. Ten proces jest całkowicie wewnętrzny dla sensora i działa z własną częstotliwością, niezależną od częstotliwości odpytywania USB. Sensor produkuje deltę pozycji i przekazuje ją mikrokontrolerowi myszy.

Przetwarzanie mikrokontrolera. MCU odbiera deltę sensora, stosuje skonfigurowane przetwarzanie, takie jak przyciąganie kątów, wygładzanie lub przyspieszenie, i składa to w pakiet raportu USB. Ten etap dodaje niewielkie, ale niezerowe opóźnienie, zazwyczaj poniżej jednej milisekundy przy dobrze inżynirowanym firmware, ale może być dłuższe na urządzeniach z ciężkim przetwarzaniem DSP.

Transfer USB. To jest etap rządzony przez częstotliwość odpytywania. Przy 1000Hz złożony raport czeka na następny zaplanowany transfer przerwania, który następuje co milisekundę. Średnio raport czeka połowę tego interwału — 0,5 milisekundy — zanim zostanie przesłany do hosta. Przy 500Hz średni czas oczekiwania podwaja się do jednej milisekundy.

Stos wejścia systemu operacyjnego. Host odbiera raport, przetwarza go przez sterownik USB, sterownik klasy HID i podsystem wejścia. Pozycja kursora jest aktualizowana w kompozytorze systemu operacyjnego, a surowe zdarzenie wejścia jest przekazywane do gry. Ten etap trwa od jednej do trzech milisekund w zależności od systemu operacyjnego, wersji sterownika i obciążenia systemu.

Przetwarzanie silnika gry. Gra odbiera zdarzenie wejścia, stosuje własną logikę obsługi wejścia (która może obejmować skalowanie czułości, surowe wejście versus buforowane wejście i próbkowanie zależne od liczby klatek) i włącza ruch do następnej renderowanej klatki. Jeśli gra działa przy 60fps, każda klatka trwa 16,7 milisekundy, co oznacza, że ruch nie może pojawić się na ekranie, dopóki następna klatka nie zostanie wyrenderowana i przedstawiona wyświetlaczowi.

Prezentacja na wyświetlaczu. Renderowana klatka wędruje do monitora, który prezentuje ją z własnym interwałem odświeżania. Przy 144Hz klatka pojawia się na ekranie w ciągu 6,9 milisekundy od dotarcia do bufora wejściowego wyświetlacza.

Sumując typowe etapy: sensor (0,25ms) + MCU (0,5ms) + USB przy 1000Hz (0,5ms) + system operacyjny (2ms) + gra przy 60fps (średnio 8,3ms) + wyświetlacz przy 144Hz (3,5ms) = około 15 milisekund. Etap odpytywania USB wnosi mniej więcej 3% całości. Podwojenie go do 500Hz dodaje 0,5 milisekundy, zwiększając sumę do 15,5 milisekundy. Dlatego mierzona różnica między 500Hz a 1000Hz jest konsekwentnie poniżej jednej milisekundy — pozostałe 96% potoki jest niezmienione. Te liczby są ilustracyjne; rzeczywiste wartości zależą od konkretnego systemu operacyjnego, sterownika, gry i wyświetlacza.

Implikacja nie jest taka, że częstotliwość odpytywania jest irrelewantna, lecz że jest ostatnim komponentem do optymalizacji. Jeśli Twoja gra działa przy 60fps, podniesienie liczby klatek do 144fps usuwa około 4,9 milisekundy średniego oczekiwania na klatkę (16,7ms/2 minus 6,9ms/2) — mniej więcej dziesięć razy więcej niż oszczędność z podwojenia częstotliwości odpytywania. Jeśli Twój wyświetlacz działa przy 60Hz, upgrade do 144Hz usuwa średnio około 4,9 milisekundy (16,7ms/2 minus 6,9ms/2). Dokładne liczby zależą od tego, czy mierzysz średnie oczekiwanie, pełny czas klatki, czy latencję end-to-end, więc traktuj je jako ilustracyjne, a nie uniwersalne. Obie te zmiany produkują również widoczne poprawy w klarowności ruchu, których dostrojenie odpytywania nie jest w stanie sprostać. Dopiero gdy liczba klatek i częstotliwość odświeżania są już wysokie, udział częstotliwości odpytywania staje się proporcjonalnie większą częścią pozostałej latencji, a nawet wtedy pozostaje mały w ujęciu bezwzględnym.

Jedyna liczba

1000Hz jest autentycznie lepsze od 500Hz o dokładnie jedną milisekundę, co jest realną, ale prawie zawsze niewidzialną poprawą. Kieruj swój wysiłek optymalizacyjny najpierw na częstotliwość odświeżania wyświetlacza i utrzymaną liczbę klatek, ponieważ te etapy wnoszą opóźnienia o rząd wielkości większe, a dopiero potem rozważ, czy częstotliwość odpytywania cokolwiek przesuwa w tym, co potrafisz zauważyć. Traktuj 8000Hz jako osiągnięcie z specyfikacji, a nie odczuwalny upgrade, dopóki reszta potoki nie będzie w stanie skonsumować tej rozdzielczości.