ultraibolya írta:
Szervernek is van fps-e. Bár hogy mire kell azt nem tudom elképzelni.
Akkor ajánlom eme leírást
https://support.steampowered.com/kb_article.php?ref=5386-HMJI-5162&l=hungarian
Nagyjából a lényeg:
Server FPS ControlHLDS Servers render frames independently from the Client.
HLDS Servers use the CVAR sys_ticrate to control how many frames per second are rendered.
Why do you need to control this?
There are two good reasons for you to manage the server FPS. The number one reason is loading on your Server CPU. The higher the FPS the higher the load.
WHY HIGHER FPS?
The key reason to run higher FPS is the render time. At 1000FPS, the server is rendering one frame every 1 millisecond (ms). This means that the worst-case adder to the player ping is only 1ms, IE: the player gets more accurate data and can get it more often.
At 300FPS it's only 3ms which is perfectly acceptable, but at 100FPS it's 10ms, which is a significant percentage of a 100 ping (10%). A player with a 100 ping would actually be getting 110ms response time from the server. Many AMD systems will only run 60FPS without the ping booster which is 17ms.
This is still not too significant but it can change the feel and response time of your server for players.
Without the FPS Boost your server will use significantly less CPU but accuracy may suffer.
Megpróbálom érthetően elmagyarázni. Valamiért FPS, de tickrate-ről van szó, mivel a sys_tickrate beállítással tudod ezt meghatározni.
Na de.
A kommunikáció nagyjából a következőképp zajlik: (nem pontosan, de hogy értsd)
Idézet:
Kliens 1 > (adatcsomag [ami lehet kérés, válasz]) > Szerver > (adatcsomag [ami lehet kérés, válasz]) > Többi kliens
Azaz a kliens1 adatot küld a szervernek (pl. a kliens1 pozícióját), ami szétszórja ezt az adatot a Többi kliensnek. És ezt az adatot dolgozza fel/alakítja át a Többi kliens számítógépe látható/használható formára. A kliensek FPS értékei csak a képmegjelenítés számát jelöli másodpercenként és csak a saját erőforrása befolyásolja.
Azonban a szerver oldalán nem ezt jelenti. A szerveren a tickrate (sys_tickrate) beállítása határozza meg, hogy a szerver ezt az adatcsomagot milyen gyorsan állítsa össze, amit majd elküld. 100 FPS (tickrate) esetén 10ms, 1000 FPS esetén ennek tizede, 1 ms. Minél gyorsabban kell, hogy összeállítsa ezt az adatcsomagot, annál több erőforrást (CPU) használ fel a hosttól. És ez csak szerver oldalon történik. Azonban ez az idő kihatással van a szerver-kliens válaszidőre is. Mert minél gyorsabban összeállítja az elküldendő csomagot, annál gyorsabban el is küldheti azt, ezáltal a válaszidő csökken. Egyértelmű, ha minél lassabban dolgozik a gép, annál több idő telik el a kérés-válasz között.
Na de akkor ez hogy néz ki? Nézzük:
Háló!? Kliens1 kérdez valamit a szervertől?
Idézet:
Kliens1 > (kérés: háló?) > Szerver (x ms) // A kliens 1 elküldi a kérést a szervernek: háló?
Szerver (adatfeldolgozás y ms) // A szerver feldolgozza a kérést.
Szerver > (válasz: háló!) > Kliens1 (x+y ms) // A szerver válaszol, hogy itt van: háló!
Kliens1 (adatfeldolgozás y2 ms)
Kliens1 > (kérés: hogy vagy?) > Szerver (x2 ms)
Szerver (adatfeldolgozás y3 ms)
Szerver > (válasz: jól!) > Kliens1
Szerver (adatfeldolgozás y ms) // A szerver feldolgozza a kérést.
Szerver > (válasz: háló!) > Kliens1 (x+y ms) // A szerver válaszol, hogy itt van: háló!
Kliens1 (adatfeldolgozás y2 ms)
Kliens1 > (kérés: hogy vagy?) > Szerver (x2 ms)
Szerver (adatfeldolgozás y3 ms)
Szerver > (válasz: jól!) > Kliens1
És egy kicsit komplikáltabban, 3 szereplővel
Idézet:
// Kliens1 kérdezi a Szervertől, hol van Kliens 2?
Kliens1 > (kérés) > Szerver (x1 ms) // Kliens 1 elküldi a kérését a szervernek: Hol van Kliens2?
Szerver (adatfeldolgozás y1 ms) // A szerver feldolgozza a kérést
Szerver > (kérés) > Kliens2 (y1 + x2 ms) // A szervernek meg kell kérdeznie Kliens2-től: hol vagy?
Kliens2 > (adat) > Szerver (x3 ms) // Kliens2 válaszol szervernek: itt vagyok
Szerver (adatfeldolgozás y2 ms) // Szerver feldolgozza a választ, megfelel-e a kérésnek
Szerver > (válasz) > Kliens1 (y2 + x4 ms) // Szerver válaszol Kliens1-nek: Kliens 2 itt van.
Kliens1 > (kérés) > Szerver (x1 ms) // Kliens 1 elküldi a kérését a szervernek: Hol van Kliens2?
Szerver (adatfeldolgozás y1 ms) // A szerver feldolgozza a kérést
Szerver > (kérés) > Kliens2 (y1 + x2 ms) // A szervernek meg kell kérdeznie Kliens2-től: hol vagy?
Kliens2 > (adat) > Szerver (x3 ms) // Kliens2 válaszol szervernek: itt vagyok
Szerver (adatfeldolgozás y2 ms) // Szerver feldolgozza a választ, megfelel-e a kérésnek
Szerver > (válasz) > Kliens1 (y2 + x4 ms) // Szerver válaszol Kliens1-nek: Kliens 2 itt van.
Itt látható, hogy bizony a szerver oldali adatfeldolgozás, ami függ az tickrate-től, igen is nagyban befolyásolja a kliens-szerver válaszidejét is. A dokumentáció alapján a játékos pingjének majd 10%-át ez befolyásolhatja. Gyakorlatban jobban érezni ezt a 10%-ot.
Lehet jó a pinged, ha a szerver alig dolgozik, bizony a válasz is lassan fog megérkezni. Ha jó a pinged de lassú a szerver, akkor lesz szar a "hitbox". Nem is ott van az ellenfél addigra. Ha pedig jó a szerver, de nagy a pinged, ugyan az lesz az eredmény. Utóbbi a gyakoribb és inkább a hálózati adatforgalom a bajos (kecskeporn torrent)
Például, hogy lássuk, miért fontos az adatfeldolgozás sebessége: az egyik dproto-hoz talált exploit pont ezt használta ki: túlterhelte a szervert olyan kérésekkel, amit sokáig tartott feldolgoznia. De közben kapta a következő kérést is, aminek szintén nekilátott feldolgozni. De az előző választ sem küldte el, mert addigra nem maradt erőforrása a még beérkezett 4 kérés feldolgozására. Mindeközben már kapta az újabb kérést, amire már végképp nem maradt erőforrás válaszolni és mivel elfogyott az erőforrás, a szerver szívrohamot kapott és kiütötte magát.
Azonban ha átesel a ló túloldalára, az sem jó. Ha túlterhelt a CPU, kevesebb erőforrás marad a válasz feldolgozására, ami már növeli a válaszidőt is. Emiatt nem érdemes egy Pentium 4-es gépen 8 szervert futtatni.
Nem szégyen nyomni egy köszönöm gombot.