Inleiding
versie #020105.1 Release
versie #030105.2 cl_cmdrate bijgewerkt, smallband bijgewerkt, copy paste code toegevoegd, speedtest voor luilakken
Deze guide is gemaakt voor CS 1.6 en CSS naar aanleiding van recent onderzoek naar packet sizes m.b.v. Ethereal en de Netcode verandering die HL2 met zich meebracht.
Ping Guide
rate
Dit is je downloadsnelheid in bytes/sec. Telenet en ADSL hebben zo'n hoge downloadsnelheden dat ze de maximum toegestane rate overschrijden. Dat wil zeggen dat je rate op 20000.
Om je rate precies te bepalen kan je hetvolgende doen:
Je bepaalt je download snelheid in bytes/sec. Dat kan je doen m.b.v. een snelheidstest, of als je de exacte waarde al weet van je ISP is dat natuurlijk beter.
Als je je downloadsnelheid van je ISP hebt, is dat de geadverteerde waarde en dus niet realistisch/representatief voor je echte downloadsnelheid. Die zal eerder rond 90% van die door de ISP bepaalde maximumsnelheid liggen.
Om van bits naar bytes te gaan deel je door 8 (want 8 bits is 1 byte).
Om van kilobits naar bytes te gaan moet je delen door 8 en dan nog eens door 1024 (want 1 kilobit = 1024 bits).
Code:
[Formule]
rate (geadv.downloadsnelheid.in.bytes/s)*9/10
of
rate (getestte.downloadsnelheid.in.bytes/s)
[ADSL/Telenet]
rate 20000
[Smallband]
rate 4000
Er is echter nog een kleine opmerking hierover, zie verder.
cl_rate
Je upload snelheid in bytes/sec. Met de recente verhogingen van upload snelheid overtroeven Telenet en ADSL weeral het maximum van Half-Life: 20000.
Cl_rate op 20000 zetten dan maar? Zo simpel is het niet. Half-Life blijkt deze cvar te locken op 9999 of 10000 elke mapchange. Dit is te laag. Je zou om deze lock tegen te werken een autoexec.cfg moeten maken met daarin cl_rate 20000.
De formules om cl_rate precies te bepalen zijn gelijkaardig aan die van rate.
Code:
[Formule]
cl_rate (geadv.uploadsnelheid.in.bytes/s)*9/10
of
cl_rate (getestte.uploadsnelheid.in.bytes/s)
[ADSL/Telenet]
cl_rate 20000
[Smallband]
cl_rate 3400
cl_updaterate
Het aantal packets of updates per seconde die jij van de server aanvraagt. Je kan er maar evenveel per seconde aanvragen als je kan downloaden in 1 seconde uiteraard. Je zou ook minder kunnen aanvragen dan dat je in 1 seconde kan aanvragen maar dan benut je niet je volledige downloadsnelheid, die bepaald werd door rate.
Ik heb onlangs nog onderzoek gedaan naar de grootte van de packets die je ontvangt als client. Deze zijn maximaal 360 bytes in grote vuurgevechten. Het is ook daar dat je het minste latency wilt hebben natuurlijk. Dus hoeveel packetten van 360 bytes kan je ontvangen met een download snelheid van 20000 bytes per seconde?
cl_updaterate = 20000/360 = 55.55...
Dit getal ronden we af naar beneden omdat je ten eerste geen halve packets kan aanvragen en ten tweede als je naar boven zou afronden dan zou je rate in principe moeten stijgen maar deze zit al tegen het plafond van 20000.
cl_cmdrate
Het aantal packets per seconde die je stuurt naar de server om jou status te updaten. Je kan maar zoveel packets sturen per seconde als je uploadsnelheid toelaat. Deze formules zijn dus gelijkaardig aan die van cl_updaterate (theoretisch), alleen dat de grootste packets die je stuurt maar 180 bytes zijn.
De maximum waarde voor cl_cmdrate is 100.
Code:
[Formule]
cl_cmdrate naarbenedenafronden(cl_rate/180)
[ADSL/Telenet]
cl_cmdrate 100
[Smallband]
cl_cmdrate 18
Copy Paste Code
In een notendop zijn dit de "beste" rates:
Code:
[ADSL/Telenet]
rate 20000
cl_rate 20000
cl_updaterate 100
cl_cmdrate 100
Smallband
Ik heb voor deze berekeningen gerekend dat de packets die toekomen gemiddeld dubbel zo groot zijn als degene die verstuurd worden door de client. Smallband heeft geshared 64 kbit/sec geadverteerd, neem daar 90%, deel door 8 en vermenigvuldig met 1024 en je krijgt een realistische waarde van je gesharede bandbreedte in bytes/s.
Ik nam 2/3 daarvan als downloadsnelheid (rate) omdat je toekomende packets dus dubbel zo groot zijn. Een derde blijft dus over voor je eigen status te updaten (cl_rate en cl_cmdrate).
Met versie #020105.2 heb ik het omgedraaid: aangezien cl_updaterate maximum 10 keer per seconde een packet van maximum 360 bytes vraagt, moet de rate niet meer zijn dan 4000 (ipv 4900). Daardoor is er meer bandbreedte vrij voor cl_cmdrate. Die kan nu ingesteld worden op 18.
sv_maxrate
Dit is de rate die de server je als maximum rate oplegt. Vroeger moest je afhankelijk hiervan eigenlijk je eigen cl_updaterate opnieuw berekenen met elke server, omdat deze afhangt van je rate, en krijgt afhankelijk van de server een nieuw plafond (sv_maxrate). Stel dat je rate op 20000 staat, en de server zet sv_maxrate op 10000, dan wil dat zeggen dat je rate niet 20000 maar eigenlijk 10000 is. Je cl_updaterate was vroeger afhankelijk van je rate dus moest je die opnieuw berekenen.
Nu geldt dat dus niet meer, ik weet niet echt waarom, zie mijn "theorie" boven voor meer info.
Toevoegingen
Als iemand me meer kan weten te zeggen over deze misterieuze update voor cl_updaterate, aarzel dan niet.
De meeste van deze formules etc. worden (nog) *niet* gebruikt door HLTooLz, maar zullen waarschijnlijk wel in SteamTooLz geimplementeerd worden, maar ik laat jullie er nu al van genieten
.
Opmerking: Ik gebruikte bij elke test net_graph 3 om mijn ping te testen aangezien scoreboard ping niet representatief genoeg was (het veranderde nauwelijks bij wijzigingen van de instellingen).