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

Permalänk
Medlem
Skrivet av stgr:

Jag spelade en stor del quake 3 med en sådan här mus

Det gick görbra.

Haha

Permalänk
Skrivet av blue eyed devil:

Så en sån här 8 000 Hz mus skulle det på något sätt vara bättre än en Logitech g pro, som har bäst sensor i hela världen?

Har du någon najs benchmark som ställer hero 25k mot pmw 3370 eller varför är hero bäst? 😁

Permalänk
Medlem
Skrivet av lillaankan_i_dammen:

De skickar data i en frekvens i 100Hz. Men responstiden är snabbare då det går genom interrupts.

Om man går tillbaka till 80talet så kändes denna konstruktion vettig. Man körde entrådade applikationer som kunde låsa upp alla resurser, på något sätt måste man se till så att input från användaren för högsta prioritet. Att då lägga den som en interrupt när cpun kördes i 4MHz eller liknade kan verkas vettigt.

idag känns lösningen som att ha interrupts till processorn för att musen ha flyttat sig bara en lösning som en idiot skulle komma på att implementera.

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.

Permalänk
Medlem
Skrivet av Herr Kantarell:

Kanske ni var med också på tiden med de tidiga optiska mössen (125Hz) som skuttade när man drog musen snabbt?

Tror man även har fixat det med algoritmer på moderna möss med låg rate.

Frågan är om man har nytta av över 1000 på en mus dock

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

Permalänk
Medlem
Skrivet av Djhg2000:

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.

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.

Permalänk
Medlem

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

Permalänk
Medlem
Skrivet av bennyfax:

Skillnaden var också att med Logitech kunde man dra en spikrak linje horisontellt men det är något som försvunnit från många av dagens möss verkar det som.

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.

Permalänk
Medlem
Skrivet av lillaankan_i_dammen:

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.

Tror inte riktigt du förstår hur interrupt förhåller sig till polling. En modern CPU med någon av de stora operativsystemen hanterar redan massor med interrupt, till exempel för nätverk, diskar, klocka, grafik, etc. Att köra ett interrupt för mus och tangentbord är en högst försumbar ökning i antal interrupt.

Interrupt gör precis tvärt om mot vad du verkar försöka återspegla; det är inte som att CPUn hänger kvar och pollar buffern från SATA-controllern medan disken varvar upp. CPUn säger åt SATA-controllern att generera ett interrupt när disken har levererat sektorn som efterfrågades, och fortsätter räkna vektorer till komprimeringen i videon du kollar på så länge. Polling å andra sidan betyder att CPUn med något tidsintervall behöver sluta göra något annat, fråga igen om det finns nytt data, vänta på att det kommer ett svar, och sedan återuppta vad den höll på med till nästa pollning. Till saken hör också att så gott som all pollning är implementerade med timerinterrupt, det finns nämligen ingen bra anledning att polla klockan.

Interrupt låter alltså huvudprocessorn arbeta vidare medan andra processorer arbetar med sina specialiserade uppgifter, i exemplet ovan kommer SATA-controllern att fråga diskens processor efter en sektor och i sin tur leverera ett interrupt när disken sektorn är läst. Vidare kommer antagligen diskens processor att säga till en ytterligare motorstyrningsprocessor att börja varva upp disken och leverera ett interrupt när skivorna har nått arbetsvarvtalet. På det sättet kan diskens processor fortsätta leverera data som finns i sin cache, till SATA-controllern som under tiden kan prata med andra diskar anslutna på andra portar, och till sist till huvudprocessorn som arbetar med videodekomprimering.

Om det istället hade varit ett pollat system hade CPUn kontinuerligt behövt fråga SATA-controllern om det fanns nytt data, som hade behövt polla diskens processor för att se om sektorn var läst än, som hade behövt polla motorstyrningsprocessorn för att se om skivorna hade varvat upp än. Under varje pollning kan ingen av komponenterna göra något annat medan de väntar på ett svar. Dessutom hade även 8 kHz varit plågsamt långsamt för diskaccess, tänk dig att bara kunna läsa 8000 sektorer per sekund.

Som referens kan en första generationens Intel X25-E (som går över SATA 1) leverera ca 35000 IOPS vid läsning. Hade alla delar varit pollade hade det inte varit mycket tid kvar för annat på den datorn.

Permalänk
Medlem
Skrivet av Djhg2000:

Tror inte riktigt du förstår hur interrupt förhåller sig till polling. En modern CPU med någon av de stora operativsystemen hanterar redan massor med interrupt, till exempel för nätverk, diskar, klocka, grafik, etc. Att köra ett interrupt för mus och tangentbord är en högst försumbar ökning i antal interrupt.

Interrupt gör precis tvärt om mot vad du verkar försöka återspegla; det är inte som att CPUn hänger kvar och pollar buffern från SATA-controllern medan disken varvar upp. CPUn säger åt SATA-controllern att generera ett interrupt när disken har levererat sektorn som efterfrågades, och fortsätter räkna vektorer till komprimeringen i videon du kollar på så länge. Polling å andra sidan betyder att CPUn med något tidsintervall behöver sluta göra något annat, fråga igen om det finns nytt data, vänta på att det kommer ett svar, och sedan återuppta vad den höll på med till nästa pollning. Till saken hör också att så gott som all pollning är implementerade med timerinterrupt, det finns nämligen ingen bra anledning att polla klockan.

Interrupt låter alltså huvudprocessorn arbeta vidare medan andra processorer arbetar med sina specialiserade uppgifter, i exemplet ovan kommer SATA-controllern att fråga diskens processor efter en sektor och i sin tur leverera ett interrupt när disken sektorn är läst. Vidare kommer antagligen diskens processor att säga till en ytterligare motorstyrningsprocessor att börja varva upp disken och leverera ett interrupt när skivorna har nått arbetsvarvtalet. På det sättet kan diskens processor fortsätta leverera data som finns i sin cache, till SATA-controllern som under tiden kan prata med andra diskar anslutna på andra portar, och till sist till huvudprocessorn som arbetar med videodekomprimering.

Om det istället hade varit ett pollat system hade CPUn kontinuerligt behövt fråga SATA-controllern om det fanns nytt data, som hade behövt polla diskens processor för att se om sektorn var läst än, som hade behövt polla motorstyrningsprocessorn för att se om skivorna hade varvat upp än. Under varje pollning kan ingen av komponenterna göra något annat medan de väntar på ett svar. Dessutom hade även 8 kHz varit plågsamt långsamt för diskaccess, tänk dig att bara kunna läsa 8000 sektorer per sekund.

Som referens kan en första generationens Intel X25-E (som går över SATA 1) leverera ca 35000 IOPS vid läsning. Hade alla delar varit pollade hade det inte varit mycket tid kvar för annat på den datorn.

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

Permalänk
Medlem
Skrivet av lillaankan_i_dammen:

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!

Permalänk
Medlem
Skrivet av Pepsin:

En människas reaktionstid på visuellt stimuli ligger på ca. 180-200 ms. Tveksamt om bråkdelar av millisekunder spelar någon roll i sammanhanget.

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.

Permalänk
Medlem
Skrivet av Lordsqueak:

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.

Permalänk
Medlem

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

Permalänk
Medlem

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

Permalänk
Medlem
Skrivet av Veni:

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.

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.

Permalänk
Medlem
Skrivet av jolu:

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.

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

Permalänk
Medlem
Skrivet av Findecanor:

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.

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.

Permalänk
Medlem
Skrivet av Lordsqueak:

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

stavning
Permalänk
Medlem

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

Permalänk
Medlem
Skrivet av jolu:

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

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.

Permalänk
Medlem
Skrivet av Veni:

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.

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.

Permalänk
Medlem

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.