Umenet skapar IRL-lagg med Oculus Rift

Permalänk
Medlem

när han släppte den kläckta ägget rakt ner på diskbänken, I lost it hahaha

Visa signatur

Ryzen 5 1600, Gigabyte 1070, MSI B350M MORTAR, Crucial 16GB, Samsung EVO 500GB, Define Mini C, Corsair RM550x (╯°□°)╯​︵ ┻━┻

Permalänk
Medlem

Haha fy fan va bra!

Visa signatur

Console: Xbox Series X TV: Samsung Q70T 4K 120HZ Headset: Turtle Beach Stealth 700 Gen 2

Permalänk
Medlem

haha fick lite tårar

Visa signatur

#1: Z370N ITX | i7 8700k | GTX 1080 | 32GiB
#2: P8Z77-M pro | i7 3770k | GTX 1050ti | 16GiB

Server: Z370-G | i5 8600T | 64GiB | UnRAID 6.9.2 | 130TB
Smartphone: Samsung Z Flip 5 | Android 13 | Shure SE535

Permalänk
Medlem
Skrivet av Användarnamnqwer:

Jävligt kul grej att göra, lite i samma stil som third-person-view när du kör VR-glasögon och kamera på en ställning snett ovanifrån. =P

Men, det är ju töntigt att företag gör reklam för 100/1000mbit osv osv och gör säger att du slipper lagg, vilket inte har ett dyft med överföringskapacitet att göra... Men det är ju omöjligt att garantera lagg-fritt eftersom det beror på andra sidan och allt emellan.

Faktum är att överföringshastigheten har en hel del med lagget att göra... Utan att gå allt för noga in på saker kan man säga att lagget beror på ett gäng olika faktorer, t.ex fysiskt avstånd (ultimata begränsningen då ingen signal kan gå fortare än ljusets hastighet), routningsberäkningar på vägen och tiden det tar att "få ut" ett nätverkspaket på linan.
Det sistnämnda är DIREKT beroende av länkens hastighet, och kan således minskas med högre hastigheter. Beroende på hur din nätverkssituation ser ut så kan detta vara en stor eller liten del av den totala fördröjningen. Dock så finns det, precis som du nämnde så finns det många faktorer som oftast kan vara större, men länkhastighetens inverkan är ändå inte försumbar.

Visa signatur

Case: Fractal Design Arc MoBo: Asus SaberTooth P67 B3 CPU: Intel Core i5 2500k @4.5 GHz Cooler: Noctua NH-D14 GFX: Asus Geforce GTX 690 RAM: 16 GB Corsair Vengeance 1600 MHz SSD: Intel 320 series 160GB HDD: WD Caviar Green 2 TB PSU: Corsair TXV2 650W Monitor: LG IPS231P Accessories: Steelseries Sensei ¤ MS Sidewinder X4 ¤ Steelseries Siberia V2

Permalänk
Skrivet av Svj0hn:

Faktum är att överföringshastigheten har en hel del med lagget att göra... Utan att gå allt för noga in på saker kan man säga att lagget beror på ett gäng olika faktorer, t.ex fysiskt avstånd (ultimata begränsningen då ingen signal kan gå fortare än ljusets hastighet), routningsberäkningar på vägen och tiden det tar att "få ut" ett nätverkspaket på linan.
Det sistnämnda är DIREKT beroende av länkens hastighet, och kan således minskas med högre hastigheter. Beroende på hur din nätverkssituation ser ut så kan detta vara en stor eller liten del av den totala fördröjningen. Dock så finns det, precis som du nämnde så finns det många faktorer som oftast kan vara större, men länkhastighetens inverkan är ändå inte försumbar.

Jag skulle nog istället säga att det beroendet är rätt försumbart i det allra flesta fall. Om din lina har en lägre tillgänglig kapacitet (bps) än vad du behöver överföra (dvs du har lägre "effektiv hastighet") så kommer det inte att lagg'a, då kommer den inte kunna upprätthålla överföringen alls, och du kommer t.ex. behöva buffra en video innan du kollar på den, eftersom du kommer hamna längre och längre efter hela tiden. Lagg, eller latency som väl är den mer "tekniska termen", är precis som reklamen exemplifierar en konstant fördröjning i signalen, där alltså inte kapaciteten i nätverket är bristande, utan tiden det tar att ta sig från punkt 1 till 2 i nätverket, vilket som du mycket riktigt säger beror på många saker, den största vanligtvis routingpunkter i nätverket. Tiden att "få ut" ett paket på linan som du säger är inte direkt relevant så länge kapaciteten på linan överstiger överföringens kapacitetsbehov, det är bara om kapaciteten inte är tillräcklig som du få ett kö-problem där det tar tid att få ut paketet på linan, självklart inräknat overhead osv.

För att ta det mest okomplicerade exemplet, men som ändå funkar: på 90-talet när iaf jag lirade quake på kvällarna kunde man sitta på ett modem med 256kbps och lira med 20ms latency, nu med 100mbit är det ändå väldigt ovanligt att ha under 20ms latency i ett spel.

Permalänk
Medlem
Skrivet av Användarnamnqwer:

Jag skulle nog istället säga att det beroendet är rätt försumbart i det allra flesta fall. Om din lina har en lägre tillgänglig kapacitet (bps) än vad du behöver överföra (dvs du har lägre "effektiv hastighet") så kommer det inte att lagg'a, då kommer den inte kunna upprätthålla överföringen alls, och du kommer t.ex. behöva buffra en video innan du kollar på den, eftersom du kommer hamna längre och längre efter hela tiden. Lagg, eller latency som väl är den mer "tekniska termen", är precis som reklamen exemplifierar en konstant fördröjning i signalen, där alltså inte kapaciteten i nätverket är bristande, utan tiden det tar att ta sig från punkt 1 till 2 i nätverket, vilket som du mycket riktigt säger beror på många saker, den största vanligtvis routingpunkter i nätverket. Tiden att "få ut" ett paket på linan som du säger är inte direkt relevant så länge kapaciteten på linan överstiger överföringens kapacitetsbehov, det är bara om kapaciteten inte är tillräcklig som du få ett kö-problem där det tar tid att få ut paketet på linan, självklart inräknat overhead osv.

För att ta det mest okomplicerade exemplet, men som ändå funkar: på 90-talet när iaf jag lirade quake på kvällarna kunde man sitta på ett modem med 256kbps och lira med 20ms latency, nu med 100mbit är det ändå väldigt ovanligt att ha under 20ms latency i ett spel.

Nej, det jag pratar om är något helt annat än kö-problematiken. Jag tänker mig en typisk spel-situation där någon sitter på en relativt snabb uppkoppling (>1 Mbit/s) och använder bara en liten bit. Begränsas alltså inte av total kapacitet.

Tiden det tar att lägga ett nätverkspaket på linan är t = [packet size]/[bit rate].

En vanlig storlek på nätverkspaket är 1500 Bytes = 8*1500 = 12000 bit.

Tiden det tar att lägga ut detta paket på tråden för olika typiska hastigheter blir således:

1000 Mbit/s: 0.012 ms
100 Mbit/s: 0.12 ms
30 Mbit/s: 0.4 ms
10 Mbit/s: 1.2 ms
1 Mbit/s: 12 ms

Detta är inte beroende av hur mycket trafik du skickar, utan detta är en fördröjning som uppkommer även i fall då ett enda paket skickas.

Siffrorna kan verka små, men tänk då på att denna fördröjning uppkommer vid varje passerad nod i nätverksstrukturen (Din dator -> Din router -> nån router i byggnaden -> osv), då alla routrar osv alltid måste ta emot hela paketet innan det kan börja skickas iväg.

Precis som jag sa tidigare är detta en liten, men fortfarande inte försumbar del att din totala latency, eller "packet delivery time". På långa avstånd kommer utbredningshastigheten att spela större roll, men i geografiskt närliggande nätverk är denna s.k. "transmission time" en signifikant del av din latency.

Sen försöker jag absolut inte påstå att man kan eliminera latency helt genom att bara höja hastigheten (vilket reklamen kanske antyder).

Sen om man befinner sig i en sån situation att någon nätverksnod är överbelastad på vägen och köer osv uppstår så spelar det ju knappast någon roll hur snabb uppkoppling man själv har, och jag tycker personligen inte att det är motiverat att gå från 100 till 1000 Mbit/s av ovanstående anledning.

Finns mer att läsa på http://en.wikipedia.org/wiki/Transmission_time

P.S. Denna delay går att komma runt (gjordes nog flitigt under 56k-eran) genom att skicka informationen i väldigt små paket. Ett 1500 Byte-paket tar över 200ms (per hopp) att överföra med 56k-teknik, så i de fallen gör man sig en tjänst att skicka mindre information i taget om latency är viktigt.

Visa signatur

Case: Fractal Design Arc MoBo: Asus SaberTooth P67 B3 CPU: Intel Core i5 2500k @4.5 GHz Cooler: Noctua NH-D14 GFX: Asus Geforce GTX 690 RAM: 16 GB Corsair Vengeance 1600 MHz SSD: Intel 320 series 160GB HDD: WD Caviar Green 2 TB PSU: Corsair TXV2 650W Monitor: LG IPS231P Accessories: Steelseries Sensei ¤ MS Sidewinder X4 ¤ Steelseries Siberia V2

Permalänk
Skrivet av Svj0hn:

Nej, det jag pratar om är något helt annat än kö-problematiken. Jag tänker mig en typisk spel-situation där någon sitter på en relativt snabb uppkoppling (>1 Mbit/s) och använder bara en liten bit. Begränsas alltså inte av total kapacitet.
Tiden det tar att lägga ett nätverkspaket på linan är t = [packet size]/[bit rate].
[...]

Ok, det är rätt uppenbart att vi inte talar om samma sak här, så det är inte så konstigt att vi inte håller med. Jag förstår såklart vad du menar med ovan, grejen är att du definierar nog latency som något väldigt mycket bredare begrepp. Latency, enligt mig, i ett system är fördröjningen i överföringen av signalen och inte fördröjningen i meddelandet som överförs med den signalen. Om man så vill; hur lång tid tar det från att en del i systemet ger en signal tills det att den nått mottagaren. Dvs. tiden från att avsändaren skickar en bit till att mottagaren får den bit'en, utan att blanda in vad som överförs.

Visst påverkar paketstorleken hur snabbt meddelandet kan utvinnas, men det ligger utanför termen latency, just eftersom det är beroende av meddelandet som skickas. I den definitionen blir man beroende av vilket meddelande som överförs, och alltså blir begreppet latency egentligen helt omöjligt att definiera mellan olika system, eftersom du samtidigt måste definiera meddelandet. Säg att du laddar ner en film, helt lagligt såklart, den är 1GB och du har 10MB/s effektiv överföring, då tar det alltså 100s innan du har filen och kan titta på hela filmen, men du har inte 100s latency i överföringen.

Permalänk
Medlem
Skrivet av Användarnamnqwer:

För att ta det mest okomplicerade exemplet, men som ändå funkar: på 90-talet när iaf jag lirade quake på kvällarna kunde man sitta på ett modem med 256kbps och lira med 20ms latency, nu med 100mbit är det ändå väldigt ovanligt att ha under 20ms latency i ett spel.

CS beta 6.4 var fullt spebart med modem och man låg på 40-80ms

"Lanade" man låg man på ca 20ms om man hadde en bra dator.

Q3 låg ofta ner mot 6ms på lan.

Ligger på 20-40 på TF2 I dag med fiber.

Ångrar att jag inte provmätte skillnaden i leverantörens nät när jag bytte från ADSL till fiber.
Grejjen är den att pingen skenade i väg för minsta lilla övrig trafik när jag körde ADSL.

Visa signatur

GA-Z97P-D3 | i5-4690K | 8Gb DDR3 | Gigabyte GTX 1050Ti | Samsung 850EVO 250Gb
Kylare: CPU: CM TX3 EVO3 | PSU: Silver Power SP-S460FL (Passiv)
Lur: OnePlus Nord | NAS: Synology 211j + Ett antal Hemmabygge

Permalänk
Medlem

Låg fps = Spelet rör sig långsammare till en viss gräns då det kan börja hacka, dvs att de känns som att de händer rörelser efter en viss sekund.
hög ms = Ju högre MS desto längre tid för datorn från kommunikationen att reagera, om din ms kanske höjs med 450 ms i ett par sekunder kan känslan vara liknande detta exempel: vilket kan vara ifall du exempelvis spelar ett first person spel och du plötsligt flyger fram 2 steg sedan så stannar allt igen sen flyger du återigen fram 2 steg.

Visa signatur

Stationär: RTX 4090 OC ASUS | Ryzen 9 5950X | G.Skill Trident Z NEO 3600mhz 32GB | Arctic Liquid Freezer III 360 | Corsair HX1000i | Asus Rog Strix X570-F Gaming | Samsung 990 PRO 2TB | Samsung 980 PRO 2TB | Fractal Design North XL

Jobbdator: MacBook Pro 16" i7 6C, 16GB ram DDR4, AMD Radeon Pro 5300M 4GB

Permalänk
Medlem

Kan väl passa på att slinka in med att Umenet är ingen bredbandsleverantör, de är nätägare. Umenet är ett stadsnät.

Permalänk
Medlem

Jag diggar blicken vid 2:28.

Slutsatsen är lite konstig; "Lag är jobbigt, kräv bandbredd"...

Permalänk
Medlem
Skrivet av Användarnamnqwer:

Ok, det är rätt uppenbart att vi inte talar om samma sak här, så det är inte så konstigt att vi inte håller med. Jag förstår såklart vad du menar med ovan, grejen är att du definierar nog latency som något väldigt mycket bredare begrepp. Latency, enligt mig, i ett system är fördröjningen i överföringen av signalen och inte fördröjningen i meddelandet som överförs med den signalen. Om man så vill; hur lång tid tar det från att en del i systemet ger en signal tills det att den nått mottagaren. Dvs. tiden från att avsändaren skickar en bit till att mottagaren får den bit'en, utan att blanda in vad som överförs.

Visst påverkar paketstorleken hur snabbt meddelandet kan utvinnas, men det ligger utanför termen latency, just eftersom det är beroende av meddelandet som skickas. I den definitionen blir man beroende av vilket meddelande som överförs, och alltså blir begreppet latency egentligen helt omöjligt att definiera mellan olika system, eftersom du samtidigt måste definiera meddelandet. Säg att du laddar ner en film, helt lagligt såklart, den är 1GB och du har 10MB/s effektiv överföring, då tar det alltså 100s innan du har filen och kan titta på hela filmen, men du har inte 100s latency i överföringen.

Nej, jag menar inte alls att man väntar på hela meddelandet... Men data över nätverk skickas alltid i paket, och storleken på ett paket påverkar fördröjningen i överföringen (för varje steg i närverksstrukturen) beroende på överföringshastigheten. Detta gäller oavsett om du laddar ner en stor fil eller skickar någon form av kontinuerlig data (som vid onlinespel etc.).

Jag definerar latency precis som du, men man måste trots allt räkna tiden från att första biten i ett nätverkspaket börjar skickas till att den sista biten tas emot (paketet kommer hur som helst inte att lämnas över till applikationen som körs innan det är komplett).

Sen påverkar, som du säger, överföringstiden av totala storleken på t.ex den fil man ska skicka, men det är nåt helt annat än vad jag pratar om.

Visa signatur

Case: Fractal Design Arc MoBo: Asus SaberTooth P67 B3 CPU: Intel Core i5 2500k @4.5 GHz Cooler: Noctua NH-D14 GFX: Asus Geforce GTX 690 RAM: 16 GB Corsair Vengeance 1600 MHz SSD: Intel 320 series 160GB HDD: WD Caviar Green 2 TB PSU: Corsair TXV2 650W Monitor: LG IPS231P Accessories: Steelseries Sensei ¤ MS Sidewinder X4 ¤ Steelseries Siberia V2

Permalänk
Skrivet av Svj0hn:

Nej, jag menar inte alls att man väntar på hela meddelandet... Men data över nätverk skickas alltid i paket, och storleken på ett paket påverkar fördröjningen i överföringen (för varje steg i närverksstrukturen) beroende på överföringshastigheten. Detta gäller oavsett om du laddar ner en stor fil eller skickar någon form av kontinuerlig data (som vid onlinespel etc.).

Jag definerar latency precis som du, men man måste trots allt räkna tiden från att första biten i ett nätverkspaket börjar skickas till att den sista biten tas emot (paketet kommer hur som helst inte att lämnas över till applikationen som körs innan det är komplett).

Sen påverkar, som du säger, överföringstiden av totala storleken på t.ex den fil man ska skicka, men det är nåt helt annat än vad jag pratar om.

Precis, latency definieras exkl vad som överförs, eftersom du redan två gånger nu förklarat hur storleken på paketen påverkar en sådan fördröjning och alltså inte är applicerbart. Du kan ha 64KB i paketstorlek under TCP om du vill, vilket skulle ge väldigt hög latency om du mätte inkl det. Det är precis därför man inte räknar in det i termen latency. Så, om vi talar latency så talar vi inte om vilken implementation av informationsöverföring du väljer att sen köra på det nätverket. Latency är fördröjningen i nätverket, det du snackar om är fördröjningen i protokollet du väljer att använda för att överföra och alltså helt utanför det man pratar om när man pratar om latency. Du får ursäkta att jag kände mig tvungen att tala klarspråk.

Permalänk
Medlem
Skrivet av aMp:

Det var ganska kreativt, men det känns sjukt tillgjort - speciellt när killen failar att hälla smet i pannan eller få i ägget i bunken.

Om du tittar på live feeden från kameran längst ner i det högra hörnet så ser du att han får freeze lags vid dessa tillfällen

Visa signatur

⚙️ Ryzen 5800X | G.Skill TridentZ 3866MHz CL14 | ASUS TUF 6900XT
🖥️ Samsung Odyssey G8 OLED ⌨️ Keychron Q4 60% 🖱️ Glorious Series One Pro
🎧 RME ADI-2-DAC FS | Focal Clear MG Pro | Sony MDR-Z7M2
📺 LG 65" GX OLED | Dynaudio Xeo 4

Permalänk
Medlem
Skrivet av Användarnamnqwer:

Precis, latency definieras exkl vad som överförs, eftersom du redan två gånger nu förklarat hur storleken på paketen påverkar en sådan fördröjning och alltså inte är applicerbart. Du kan ha 64KB i paketstorlek under TCP om du vill, vilket skulle ge väldigt hög latency om du mätte inkl det. Det är precis därför man inte räknar in det i termen latency. Så, om vi talar latency så talar vi inte om vilken implementation av informationsöverföring du väljer att sen köra på det nätverket. Latency är fördröjningen i nätverket, det du snackar om är fördröjningen i protokollet du väljer att använda för att överföra och alltså helt utanför det man pratar om när man pratar om latency. Du får ursäkta att jag kände mig tvungen att tala klarspråk.

Oavsett vilket begrepp man vill lägga det under så kommer ju alltså överföringshastigheten från din internetleverantör (det som diskussionen och filmen handlar om) att påverka fördröjningen. Även om du skickar minsta möjliga paketstorlek (med tanke på headers m.m.) så kommer det att påverka.

Vet inte om det finns någon officiell definition på hur "latency" mäts, men jag tror att i de flesta fall där det diskuteras (t.ex i spel) mäts det från när applikationen lämnar information till sin socket till det att den tar emot svaret (tvåvägs) alternativ till att den når fram till mottagaren (envägs). Denna tid kommer att minska om du har en snabbare länk. Vilket protokoll du använder kommer att påverka hur mycket detta påverkar, ja, men det finns alltid där.

Jag ser din poäng i att man gärna vill ha en definition som inte är beroende av vilken applikation som körs och vilket transport/nätverksprotokoll som används. I synnerhet om man snor ihop något själv som kan använda nåt annat än TPC/UDP...

Dock står jag fast vid att man vid användning av en given nätverksapplikation kommer att se en minskad fördröjning från skickad signal till svar om man har en snabbare uppkoppling (som vi kommit överens om tidigare är detta inte enda faktorn och oftast inte den största, men faktum kvarstår). Jag är fullt medveten om att den delen av fördröjningen som går att minska på det sättet är beroende på vilket applikations/transportprotokoll som körs, men den finns alltid där så länge man skickar informationen i form av paket. Därav inte sagt att det är en fördröjning "i protokollet", utan det är en fördröjning i nätverket, vars storlek är beroende av protokollet (skillnad!).

Lämnar diskussionen nu, jag tror vi båda har fått fram våra ståndpunkter... Börjar mer handla om definitioner på ord än vad som faktiskt händer, vilket vi verkar ganska överens om

Visa signatur

Case: Fractal Design Arc MoBo: Asus SaberTooth P67 B3 CPU: Intel Core i5 2500k @4.5 GHz Cooler: Noctua NH-D14 GFX: Asus Geforce GTX 690 RAM: 16 GB Corsair Vengeance 1600 MHz SSD: Intel 320 series 160GB HDD: WD Caviar Green 2 TB PSU: Corsair TXV2 650W Monitor: LG IPS231P Accessories: Steelseries Sensei ¤ MS Sidewinder X4 ¤ Steelseries Siberia V2

Permalänk
Skrivet av Svj0hn:

Oavsett vilket begrepp man vill lägga det under så kommer ju alltså överföringshastigheten från din internetleverantör (det som diskussionen och filmen handlar om) att påverka fördröjningen. Även om du skickar minsta möjliga paketstorlek (med tanke på headers m.m.) så kommer det att påverka.

Vet inte om det finns någon officiell definition på hur "latency" mäts, men jag tror att i de flesta fall där det diskuteras (t.ex i spel) mäts det från när applikationen lämnar information till sin socket till det att den tar emot svaret (tvåvägs) alternativ till att den når fram till mottagaren (envägs). Denna tid kommer att minska om du har en snabbare länk. Vilket protokoll du använder kommer att påverka hur mycket detta påverkar, ja, men det finns alltid där.

Jag ser din poäng i att man gärna vill ha en definition som inte är beroende av vilken applikation som körs och vilket transport/nätverksprotokoll som används. I synnerhet om man snor ihop något själv som kan använda nåt annat än TPC/UDP...

Dock står jag fast vid att man vid användning av en given nätverksapplikation kommer att se en minskad fördröjning från skickad signal till svar om man har en snabbare uppkoppling (som vi kommit överens om tidigare är detta inte enda faktorn och oftast inte den största, men faktum kvarstår). Jag är fullt medveten om att den delen av fördröjningen som går att minska på det sättet är beroende på vilket applikations/transportprotokoll som körs, men den finns alltid där så länge man skickar informationen i form av paket. Därav inte sagt att det är en fördröjning "i protokollet", utan det är en fördröjning i nätverket, vars storlek är beroende av protokollet (skillnad!).

Lämnar diskussionen nu, jag tror vi båda har fått fram våra ståndpunkter... Börjar mer handla om definitioner på ord än vad som faktiskt händer, vilket vi verkar ganska överens om

Tror bara det finns en sak att säga.
http://bit.ly/1t3HLYV