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

Haha

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".

Om man ska konstruera en ren spelmaskin så kan man diskutera interuppt för och nackdelar på en datamaskin. Dagens datorer används till mycket och användarens input ska inte ens ha högsta prioritet. I praktiken är användarens data så liten så det hade kvittat. Men det är en galen lösning att avbryta processon för att musen har flyttat sig.

Och dagen lösning med usb har ändå blivit såpass bra så att nästan ingen kör med ps/2 idag.

Exempel på processer som måste ha hög prioritet är seriell dataöverföring.

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.

Bra svar. Den erfarenhet jag har av interupts är microdatorer och då utan något os utan avbrott av min egen kodsnurror.

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.

Låter som om detta är en sådan utveckling som inte kommer till nytta men som bryter kompatibilitet och kräver att man köper en maskin med mer kraft för att klara av en simpel produkt, d.v.s. det vanliga: "vill Du ha denna så får Du byta ut den och den och den och sedan fungerar det" för att sälja mer.

Vad är vitsen med en hastighet på 8 kHz för en mus?

Varför går man inte tillbaks till rötterna och kör istället med avbrottshantering istället för pollning och då missar inte datorn några uppgifter ifrån musen. Kräver då enbart känsligare optik om man vill ha känsligare mus, inte högre förfrågningshastighet.

Typiskt modernt beteende med att försöka göra grejer snabbare(större/snabbare är bättre mantrat) för att man inte klarar av att lösa ett simpelt grundproblem.

Jag kör fortfarande med en MX518 på speldatorn och USB-adapter(den är bara en mekanisk adapter) till PS/2 och har inga problem med det eftersom musen har stöd för både USB och PS/2 protokollet(den använder det fysiska protokoll som den känner av att värden har).

Kanske utveckla en USB-port som kan köra med avbrottshantering om slaven har stöd för det?

Annars slå över till den mer påfrestande varianten som är pollningsbegäran. Och således kan man börja utveckla en krets(för att hålla ner komponentkostnaderna) för slavarna där USB avbrott och USB pollning är tillgängliga, ungefär som denna men den är för PS/2 och USB: https://investors.st.com/news-releases/news-release-details/s... http://www.4eplus.com/docc/vt5363.pdf

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 tror att skaparen fick problem när denna skulle gå längre än t.ex. PS/2 och vanlig seriell port då USB gav helt plötsligt stöd för flera enheter över en port(med hjälp av nav utav olika slag, både mjukvarumässigt men även via hårdvara), samt rent krasst så skulle avbrottshantering ha för hög "over-head" kostnad med tanke på att USB kan överföra stora mängder data vid samma tidsfönster, vilket skulle innebära onödigt många avbrott.

Det jag tänker mig är att man skulle kunnat ha haft två lägen i USB protokollet som slaven väljer själv(först en annonsering om vilken typ den föredrar primärt om värden saknar stöd för bägge) hur värden skall hantera avisering om inkommande data:

1 = Avbrott. Lämpligt för överföring utav liten mängd information men som är tidskritisk.
2 = Pollning. Lämplig för överföring utav stora mängder information men där latens är ett mindre problem(får ligga på applikationsprotokollet i så fall att lösa), t.ex. överföring av information till/från snabba lagringsenheter.

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.