Új hozzászólás Aktív témák

• #14 sgteam aktív tag the8ball #13

  Új Válasz 2022-04-21 09:32:41 #14

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  sgteam

  aktív tag

  válasz the8ball #13 üzenetére

  

  Szeretem az állatokat de nem akarom megnevezni őket! :D

• #16 Chal addikt the8ball #15

  Új Válasz 2022-04-22 20:26:15 #16

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Chal

  addikt

  válasz the8ball #15 üzenetére

  Még a 10eFt-s aprós AP-k is sokkal többet kell hogy tudjanak ennél (persze 5Ghz azért legyen, ez alapfeltétel), kb. bármelyik jó a Quest2-höz, hiszen 200Mbit manapság semmi (kivéve persze ha még egy vagon kliens lóg rajta, akkor combosabb/jobb AP kell, de most nem erről van szó).

  Szóval a gond szerintem nálad sem az AP-nál volt/van, hanem a Windows ip stackjében. Amennyiben a túloldal nem egy stabil kábeles kapcsolat (a válaszidők nem konstansok és alacsonyak) teljesen képes behülyülni, köszönhetően a mindenféle autotuningos receive window size állítgatásnak, vagy éppen annak a hiányának! Sokat wiresharkoztam, több gépet is megnéztem itthon (3db asztali PC, laptopok), csak Windowsnál volt ilyen, Linux esetén 600-800Mbit-em volt wifi eszköz irányában, mindkét irányban (in/out), Windows-al ugyanez 80-160Mbit.

  Ez a legtöbb embernek fel sem tűnik egyébként, mert vezetéken lógó géppel ritkán forgalmaz wifi eszköz irányában, vagy ha igen, az a háttérben történik, és minimal forgalommal. Ha 1 évben egyszer mégis szembe jön erről egy progress bar egy sebességértékkel, akkor meg betudja átmeneti problémának (én is láttam már az Oculus előtt is itthon a jelenséget, de nem érdekelt).

  Javaslom a netsh tcp beállításainál körülnézni, nálam teljesen vegyes volt, hogy melyik gépen milyen paraméterek voltak itt, vélhetően a NIC-ek driverei, vagy egyéb Windows alkalmazások/patchek is gányolgatják ezt:

  netsh int tcp show global

  Sok esetben az autotuning ki volt kapcsolva (közvéleménykutatás alapján a VR topicban és ismerősi körben sokan voltak még ezzel így, pedig egy clean Windows install után ennek az a default állapota, hogy működik, azaz nem disabled).

  Default állapot:

  netsh int tcp set global autotuninglevel=normal

  Ha ezen túlmenően se jó, akkor tekergesd, nincs biztos módszer, méregetni kell, és próbálkozni.

  Nálam volt egy kis közjáték, ami bevitt a tesztek/mérések alatt még pluszban bevitt az erdőbe: nem tudom te mivel mérsz, de standard megoldás szokott lenni a iperf3. Na annak a hivatalos Windows buildje bugos, ezért nem tud nagyon 150-200M fölé menni (wifi végpont esetén a tcp autotuning hiába működik, az iperf nem növeli a receive window méretét). Persze ha akadozik az Alyx, akkor nálad nem ez van, hiszen ez csak a mérést befolyásolja. A nem hivatalos buildekben (pl.: link) javítva van egyébként a dolog.

  [ Szerkesztve ]

Új hozzászólás Aktív témák