Möss med 8 000 Hz uppdateringsfrekvens ställer höga krav på processorn

Så varför skulle det vara en dålig idé med interrupts nu? Moderna processorer är betydligt snabbare så den tid det tar att bearbeta ett interrupt har minskat, men samtidigt är det på något sätt bättre att den aktivt pollar musen betydligt oftare än den faktiskt flyttar på sig?

Polling är bara bra när det är kontinuerligt data som är intressant (temperatursensorer, effektförbrukning, etc.) eller om latensen i praktiken är okritisk (se om solen har gått upp mellan två förväntade klockslag).

Poängen med interrupt är just det faktum att processorn kan göra helt andra saker utan att bekymra sig om att kolla om något har ändrats, det är andra änden som säger till när det finns nytt data att läsa. CPUn spenderar alltså mycket mindre tid på att hantera input när det hanteras genom interrupt.

Worst case är att musen flyttar på sig kontinuerligt och då är du uppe på ingen skillnad alls i hantering av datat i sig och eventuell overhead från interrupthanteringen, men det senare beror väldigt mycket på hur interrupt är implementerade i processorn. Hursomhelst blir du helt av med aliasing till en polling rate och arbetar istället med tidskvanta som är väldigt nära en klockcykel i interruptlogiken, vilket betyder att latensen mellan att musen har nytt data och att CPUn börjar läsa det är extremt kort. Den praktiska skillnaden i latens är total utklassning.

Har svårt att tro att det är pollingraten som gör någon skillnad på om rörelsen "skuttar" eller inte. Det handlar nog bara om bättre sensorer och inte hur ofta man hämtar data från musen o fråga. Tror du har fel kring vilken funktion polling rate fyller. Du kan säkerligen köra en modern mus i 125 Hz polling rate utan "skutt".

Mitt Corsair K100 fick ny FW med 8000Hz.
Märker dock ingen skillnad i spel.

Jag hade en mus med angle-snapping på ett tidigare jobb. Det störde mig något otroligt när man rörde musen och den hamnade något fel från där jag pekade.
Jag märkte att jag började att göra extra runda rörelser för att musen inte skulle börja "korrigera" mina rörelser.

Då tycker jag du ska ta tillvara på tillfället och experimentera med interrupts nästa gång du kodar. Interrupts är svåra att börja med men när man har fått stil på dem är de riktigt trevliga. En av de första fallgroparna som är bättre att höra än att uppleva är att du behöver använda något som kallas "critical sections"; ibland gör man något som inte får avbrytas av interrupt och då vill du ha ett par macron för att snabbt kunna slå av och på interrupthanteringen i processorn.

På en PC sköter typiskt det underliggande operativsystemet interrupts och då syns inte problemet på samma sätt (interrupt i andra program döljs då genom att processorn gör en "context switch"), men om man råkar glömma bort att man har interrupt påslagna kan det bli spännande effekter i koden. Till exempel att variabler du arbetar på ändrar sig mellan två orelaterade instruktioner.

Ett typfall är när du i interruptrutinen uppdaterar en variabel från ett register med nytt värde, och processorn avbröts under en "read-modify-write"-operation på en av de modifierade variablerna. Variabelns innehåll kommer då att vara det modifierade gamla värdet istället för det nya värdet trots att interruptrutinen verkligen skrev det nya värdet i variabeln. Kom också ihåg att interrupt kan hända i interruptrutinen om du inte slår av dem, det är ett annat vanligt misstag när man börjar med interrupt.

Men var ändå inte rädd att försöka, för som sagt kan de vara riktigt trevliga, särskilt när man vill optimera energianvändning och hålla processorn i sleep så mycket det går (många typer av interrupt kan också väcka processorn ur lägen där den inte kan exekvera instruktioner).

Lycka till!

Reaktionstid har inget att göra med timing.
Visst spelar reaktionstid roll i ett spel, men det har inget att göra med när du klämmer av ett skott.
När det gäller timing så pratar vi om nån millisekund,,kanske. (har faktiskt ingen aning) Jag har själv upplevt skillnad på att gå från 120fps till 240fps, vilket är en skillnad på ca 4ms. Och det var en stor skillnad. Så vad en vältränad person kan uppnå bör ligga på millisekunden. Jag skulle gissa att man gjort undersökningar med musiker för att se hur "tajta" dom är, så det finns nog information om detta, även om jag inte vet vart.

När det gäller musik börjar man bli otajt efter ca 10 ms. 4-5 ms är helt ok.
Lägre än så är svårt att komma med alla ADDA, signalbehandlimg, mjukvara mm
Du kommer faktiskt över 10ms om du spelar gitarr och står några meter ifrån stärkaren.
Jag spelar själv trummo4 och är väldigt känslig för latency men tycker det funkar bra runt 5-7 ms.

Finns ett test hos LTT.com där de testar 8k musen vs vanlig 1k mus.
https://youtu.be/gOQNRvJbpmk

USB är utformat i grunden så att all kommunikation över bussen initieras av värddatorn.
Skulle man ändra protokollet för möss till att kommunikation initieras av musen så skulle det inte längre vara USB annat än i kontakten — och då skulle man mista andra egenskaper hos USB-protokollet.
T.ex. är USB flexibelt i att det tillåter en enhet att ha flera logiska "gränssnitt", så att den kan vara flera saker på en gång. Det finns t.ex. möss som också är tangentbord, som kan skicka macron eller t.om har numeriska tangentbord på sig — och dessa funkar med standard-protokollen utan några speciella drivrutiner. RGB-styrning ligger också på separata gränssnitt.

När värddatorn pollar så har musen rört sig sedan förra pollningen eller inte: och musen skickar "Ja, här är min rapport" eller så skickar den "Nej, jag har inget att rapportera".
Min erfarenhet ligger på enhets-sidan så jag har inte riktigt koll på hur PC-hårdvaran på värden funkar men teoretiskt så skulle varje "Nej" kunna hanteras i hårdvara på värddatorn utan att dra någon CPU, och ett interrupt triggas när det kommit in en rapport.
Alltså, detta skulle för CPU:n fungera på samma sätt som med ett protokoll där musen kontrollerat bussen.

Istället för att ändra protokollet i grunden så tycker jag att man ska uppdatera en detalj i USB HID ("Human Interface Device")-protokollet för möss:
Som det är nu så innehåller varje "rapport" relativa rörelser sedan den förra rapporten. Det innebär att USB HID-stacken måste tolka varje inkommande rapport.
Om en rapport istället innehöll wrappande räknare för X,Y-led och scrollhjul så skulle hårdvaran bara behöva spara den senaste rapporten, och CPU:n skulle bara behöva tolka denna allra färskaste rapport en gång per frame för uppdatering av muspekaren eller precis när ett spel frågar.
Dessutom så skulle det göra det enklare på musens sida att faktiskt uppnå minsta möjliga latency utan onödiga fördröjningar. Som det är nu så måste musens firmware skapa en relativ rapport och låta den ligga som den är i en hårdvaru-buffer tills värddatorn pollar (när det nu blir). Med räknare så skulle musens firmware kunna byta ut buffern atomiskt när som helst utan att behöva ha håll på om värddatorn hämtat den förra eller inte.

Googlade lite av nyfikenhet, om jag kunde hitta något. Och jag hittade en avhandling där dom lät personer kasta en boll, för att träffa en 20cm måltavla på 6-8 meters avstånd. Dom räknade ut att fönstret för att släppa bollen, för att den ska träffa sitt mål, var 1.2 ms. Om det stämmer, vilket låter troligt, så bör man kunna räkna med att en vältränad förmåga ligger runt millisekunden.
Fast sen kan man ju fråga hur ofta en person kan träffa målet. Det är ju lite skillnad jämfört med trummor, där man förväntar sig att en bra trummis ska klara av en jäkla massa slag i flera minuter.

Själv kan jag nog hålla med om att man börjar bli otajt vid 10ms ung. Dock så kan man märka av skillnad i input delay på nån millisekund. Jag spelar flipper på datorn, och är inkörd på 120hz, så när jag testade att låta spelet (fx2, var några år sen) få gå i 240hz så missade jag alla ramper, etc. enorm skillnad. Något som tog mig av överraskning, då jag egentligen testade 3D Vision settings. (8,33ms vs 4,33ms per frame)

Jag skulle gissa att en polling rate på 1000hz skulle räcka för de flesta, med tanke på det som nämnts. Men det är ju lite skillnad på att trycka på en knapp, och att kasta en boll. Det kanske finns de som kan bli tajtare än så om man tittar bland topp spelare. Så det kanske finns mening med att ha högre polling rates. Jag var skeptiskt till att 8khz skulle vara nån nytta, men efter ha lärt det som nämns ovanför, så tror jag nog att det finns elitspelare som kan ha nytta av detta. Vi får väl se i framtiden om någon lyckas träna upp sin tajming att bli så pass tajt. Med tanke på siffran 1.2ms för att kasta en boll på ett hyffsat enkelt mål, så tror jag att man kan komma under millisekunden. (sen hur ofta man kan upprepa samma kast är ju en annan femma, men klarar man 50/50 så är det ju klar fördel i spel.)

Jag gissar nu men kanske är synen känsligare än örat vad gäller fördröjningar. Ljus är ju betydligt snabbare än ljud. Till viss del kompenserar man ju som du säger för en fördröjning så länge den är någorlunda konstant.

Nu kanske jag missförstår exemplet med bollen men där införs ju en annan variabel i och med att måltavlan och/eller bollen rör sig. Då blir en kort fördröjning betydligt mer märkbar.

//J

Om man kollar Linus video så ser man att muspekaren rör sig med konstanta steg över skärmen. Han låter en robot köra musen och en superkamera filmar.
Det gör att hjärnan slipper kompensera för input lag, siktet kommer vara där hjärnan bestämt att det ska vara. Själv kan jag knappt träffa fiender på första skottet så dessa e-gamers reflexer i nivå med sparvhökar som jagar sparvar igenom snåriga buskage i 100 km/h är obegripligt. 360 noscope headshot haha

Jo, det är ju en stor skillnad på trycka på en knapp och att genomföra en arm rörelse som skall tajmas, Det blir ju många fler variabler som behöver stämma. mao, lite klurigare att allt klaffar. Så om man räknar på ett fönster på 1,2ms och betänker att det verkar rimligt att de flesta skulle kunna träna lite för att träffa ett 20cm mål (20cm högt, horizontellt, jag tolkar det som en bräda eller något liknande). Då verkar det ju rimligt att de flesta skulle kunna träna upp en förmåga att trycka på en knapp med ung samma tajming.
(Fördröjning är något man vänjer sig vid, och även stor dröjning är hanterbart, så länge den är konstant. Men det är kanske en annan diskussion. )
Vad jag försökte säga var hur som helst att det helt klart verkar som att 1000hz polling rate är något vi alla kan dra nytta av. (om vi inte har färdighet att göra det, så får vi iallfall möjligheten att träna upp den färdigheten.) Och att det verkar som att högre polling rates faktiskt är något man kan dra nytta av om man har den färdigheten. (förutsatt att det inte finns andra flaskhalsar.)

Jag är faktiskt lite förvånad att den där siffran (1,2ms) är så pass tajt, för något som verkar möjligt för de flesta att lära sig.

De flesta (alla vad jag vet) drar ju ner känsligheten på mössen.
Att köra över 800dpi i tex Fortnite gör att det är svårare att sikta eller följa någon med fint flyt.

Sedan även inne i spelet drar man ner sensitivity ännu mer
Därav man har en större musmatta.

Tror det råder viss förvirring i tråden med hur interupts fungerar.

Det finns många typer av interupts och jag är igen expert på dom men här är några exempel.

Många CPU'er 'ven den hederliga 6502 stödjer i alla fall 2 former av Interupt.

Den första många här verkar tänka på och det är att om CPU'n får en interupt så släpper den allt den pysslar med och går och servar interupten.

Men det är inte den typ av interupt ens användare av 6502 använder mest.

Istället fins det en annan form av interupt där processorn får reda på att nåt vill ha dess uppmärksamhet MEN processorn kan fortsätta göra det den pysslade med tills koden i princop säger, NU får du göra serva interuptsen.
Alltså kan man utan proble mskemalägga interupts och hantera dom när det passar för bästa optimering.

Det sissta ger mer effketivt implementering där maximalt med tid kan spenderas på program koden, en liten latenc, kan vara några till tiotals klock cyklar extra spenderas att exekviera programet som körs innan man går och servar interupten.

Detta är väldigt effektivt.

Den första typen av interupt jag nämde kan användas i kritiska senarion där interupten bums behöver servas, tex spara data till disk om tex batteriet i datorn rapporterar kritisk spännings nivå.

I dag används desutom inte fysiska interupts, alltså ledningsbanor på moderkortet utan mjukvarubaserade interupts, data skrivs till en minnesadress som triggar interupten.

Oavsett interupts används fortfarande och mer än någonsin. IBM XT hade 8 interupts alltså IRQ'er, AT modellen hade 16st.
I dag har datorerna hundratals interupts implementerade i mjukvara så interupts har inte gått nånstans, att din mus skulle ha en extra, samma för tangentbord i det stora hela är en droppe i havet.

Däremot att låta cpu kärnorna pola alltså fråga hårdvaran hela tiden om den har eller behöver data är ganska ineffektivt men med dagens snabb datorer märks kanske inte det så mycket.

Tar man lite äldre datorer, jag har en K6-2+ 500@600Mhz. Kör windows 9x men det fins drivers för Xbox360 kontrollen.
Det tar ungefär 25% av CPU'n cyklar att använda 360 controllern jämfört med en analog gamepad.
Så ja jag kör inte 360 kontrollen lägre för fps påverkan är allt för grov.

Och USB tangentbord/mus är ett stort no no av samma orsak.