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

• #40586 HSM félisten gbors #40581

  Új Válasz 2019-05-05 13:33:50 #40586

  Ú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

  

  HSM

  félisten

  válasz gbors #40581 üzenetére

  Van amúgy egy szuperjó írás az input lag témájában, szerintem aktuális. [link]

  A probléma, hogy felhős játékoknál ezek a tényezők ugyanúgy számítanak, csak még hozzájuk jönnek újak, ráadásul ahogy írod, ami erősen RTT függőek is, ami azért baj, mert a "való életben" elég sokszor találkozni durván ingadozó RTT-vel, miközben adott esetben az átlag sávszélesség egész magas.

  Illetve szerintem a két képkockás buffer is az abszolút minimum, nem véletlen van pl. az összes videó streamelő szolgáltatáson 30s körüli buffer (még élő közvetítésnél is minimum 4-5s!!!), minden szempontból kímélőbb és megbízhatóbb, mint alacsony késleltetéssel realtime átvinni ugyanazt.

  A QoS esetében két óriási probléma van. Az egyik, hogy a teljes láncon, értsd, a user számítógépétől kezdve (nem elég, ha a streamelő alkalmazás tudja, minden másnak tudnia kellene) egészen a kiszolgáló szerverig mindennek kellően konfigurálva kell(ene) lennie ehhez, mégpedig úgy, hogy mindenki a te játékod priorizálja. Nekem pl. egyáltalán nem tűnik reálisnak, hogy nagy sávszélességű játékokat priorizáljanak, amikor tipikusan a kommunikáció (hang, videó, VOIP) szolgáltatások szoktak itt lenni, mivel a sávszélesség igényük mérsékelt, viszont a késleltetésre érzékenyek. Az nem reális alternatíva, hogy ilyen nagy fogyasztókat priorizáljunk, ráadásul ha megzabálták a szolgáltató sávszélességét, akkor már nem is tudsz priorizálni, mert nincs már miből adni.... A másik, ha ezek a kevéssé életszerű feltételek adottak is lesznek, még mindig az elérhető sávszélesség. Ha foglalt bárhol a csatorna, akár csak egy rövid torlódás idejére, már buktad a játékot. Pl. egy VOIP hívásnál ilyenkor van egy rövid kimaradás a hangban, de megoldod, vagy játékban is, de amikor a kép is elkezd durván bedöcögni, az azért nem túl szép játéknál.
  Szerintem ezeknél a Gbites neteknél is legfeljebb addig tudsz normális megoldást adni, amíg nem használják túl sokan egy adott területen, mert minél többen használják, annál rosszabb kiszolgálási garanciákat fogsz tudni adni.

  Amúgy az sem véletlen, hogy pl. egy BF4 szervernél, ha 10 feletti a pinged, már erősen érezni azt is. Még nem játszhatatlan, de nem olyan élmény, mint amikor alacsony késleltetésű rendszeren, minimum 60hz-es szerveren tolod, szűk 20ms pinggel....

  Ezért is írtam, biztos lesz ennek is szuper felhasználási területe, de kiváltani szvsz nem fogja a lokális PC-s/konzolos játékot.

  (#40582) -Solt-: Ezt egyébként meg tudom erősíteni. Nálam viszonyítási alap "csak" a 60Hz-es közönséges IPS monitorom, 8ms GTG panellel. Már azt erősen észrevenni, ha 80Hz-re tuningolom, de tovább megyek, valami miatt DP porton is csökken a késleltetése a DVI-hoz képest, és az is érzékelhető. Sőt, BF4 multiban régebben azt is érezni lehetett, ha a Mantle móddal toltam, ami kevesebb képkockát bufferelt be CPU-n, mint a DX11 mód. Itt alapvetően néhány ms difikről beszélünk, képzeld akkor el, mekkora difi lehet ennek a nagyon sokszora....

  (#40584) -Solt-: A monitor paneljének GTG válaszidejét szokták így jelölni.

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