Introducere
Deci, în cazul general, lagul poate fii cauzat de toate elementele internet-computer care interferează cu un joc normal. Exemple: „se misca in poze”, înghețarea imaginii, înghețarea obiectelor de joc. 

Cauzele lagului pot fi împărțite în:
1) Probleme la computerul jucătorului - jucătorul însuși le poate rezolva;
2) Probleme la canalul de comunicare între computerul jucătorului și server;
3) Probleme pe server.

Mai jos vom analiza toate acestea mai detaliat, dar mai întâi, o listă de termeni folosiți în articol.

Lista de definiții
HL, Half-Life - în articol este folosit ca nume al motorului (dar nu și jocul de Gordon Freeman!). Datele din articol sunt aplicabile tuturor modurilor create pe acest motor, inclusiv Counter-Strike.

Clientul este un program (Half-Life) care rulează pe computerul jucătorului, care comunică cu serverul și desenează o imagine a lumii jocului.

HLDS, Half-Life Dedicated Server - acesta este un program, de fapt o parte de server pentru Half-Life.

Server - Computerul pe care rulează hlds.

Cvar, aka CVar, aka Console Variable - o variabilă folosită în Half-Lfe care modifică orice parametri de joc. Poate fi schimbat de către utilizator din consolă (de unde și numele).

Cvarurile sunt folosite atât pe client, cât și în HLDS-uri. Cvar-urile care afectează doar backend-ul sunt prefixate sv_ ( exemple - sv_gravity, sv_clienttrace);

Cvar-urile numai pentru client sunt prefixate cu cl_ (cl_lw, cl_lc, cl_updaterate).

Material. Modul în care hlds controlează fluxul de date către clienți.
Transferul de date către hlds este controlat separat pentru fiecare client, pe baza a doi factori:

1) Numărul de pachete pe secundă transmise clientului, să numim această valoare updrate
2) Rata maximă de transfer către client, să numim această valoare cmrate .

Datele inițiale pentru determinarea ratei de actualizare sunt trei variabile - acesta este clientul cl_updaterate și serverul sv_maxupdaterate și sv_minupdaterate.

Algoritmul pentru determinarea ratei de actualizare poate fi scris după cum urmează:

actualizare := cl_updaterate;
dacă updaterate > sv_maxupdaterate atunci updaterate = sv_maxupdaterate;
dacă updaterate < sv_minupdaterate atunci updaterate = sv_minupdaterate;

Se poate observa că, implicit, updaterate este egală cu valoarea clientului. Cu toate acestea, nu trebuie să depășească valorile maxime și minime definite în hlds.

Iată câteva exemple pentru o mai bună înțelegere:

cl_updaterate = 30, sv_minupdaterate = 20, sv_maxupdaterate = 60. În acest caz, clientul va primi 30 de pachete pe secundă de la server, adică ceea ce a dorit clientul, a primit.

cl_updaterate = 100, sv_minupdaterate = 20, sv_maxupdaterate = 60. În acest caz, clientul va primi 60 de pachete pe secundă de la server, deoarece valoarea a atins pragul superior.

cl_updaterate =10, sv_minupdaterate =20,sv_maxupdaterate = 60. În acest caz, clientul va primi 20 de pachete pe secundă de la server, deoarece valoarea a atins pragul inferior.

Datele inițiale pentru cmrate sunt valorile ratei variabilei client și serverului sv_maxrate și sv_minrate . Algoritmul de determinare este exact același ca pentru updrate , adică în mod implicit cmrate = rate , totuși, dacă valoarea depășește sv_minrate sau sv_maxrate , atunci este limitată.

Material. Cum hlds formează pachetele. Ce este choke. (versiune simplificată)
Când HLDS funcționează, toate datele care ar trebui trimise către client sunt adăugate într-un buffer separat (este diferit pentru fiecare client) , unde așteaptă momentul când vine momentul să le trimită. Imediat ce a sosit momentul, datele încep să fie scrise în pachet.

Dimensiunea pachetului este limitată de cmrate pentru a nu supraîncărca lățimea de bandă alocată clientului. Dimensiunea maximă a pachetului asociată cu această limită poate fi calculată ca cmrate / updrate , adică rata maximă împărțită la numărul de pachete pe secundă.

Dar ce se întâmplă dacă serverul a generat mai multe date decât poate trimite? Apoi totul este simplu - doar datele care se încadrează în limita maximă sunt scrise în pachet, restul sunt lăsate să aștepte pentru următorul transfer. De asemenea, un mesaj de un octet svc_choke este adăugat la pachet , ceea ce indică faptul că hlds nu au putut trimite toate datele pe care le-a generat.

Da, aceste date vor veni la client în următorul pachet, dar vor veni cu întârziere. Și dacă coada de date de pe hlds crește și nu se termină niciodată, atunci pe client puteți observa o creștere atât de bolnavă a ping-ului, iar valoarea choke = 99 (o puteți vedea în net_graph 3) .

Un punct separat demn de remarcat este faptul că verificarea dimensiunii pachetului este efectuată numai dacă serverul rulează în modul Internet ( sv_lan 0). Cu sv_lan setat la 1, această verificare este dezactivată. Acesta poate fi motivul apariției decalajelor la schimbarea hld-urilor la sv_lan 0 cu sv_maxrate / sv_minrate neconfigurat .

Efectuăm diagnostice.
Deci, pentru a scăpa de lag, trebuie să cunoașteți cauza. Și ceea ce ne va ajuta să aflăm asta este un instrument foarte bun încorporat în hl numit net_graph , care afișează informații legate de transferul de date în timp real. Există 3 moduri de afișare, vom folosi primul ( net_graph1).

Pentru început, vom oferi o descriere a ceea ce este afișat în general acolo:

Primul chenar - fps, interval de desincronizare (în general - ping), valoare cl_updaterate

Al doilea chenar - informații despre datele de pe server: dimensiunea actuală a pachetului și viteza medie de descărcare

Al treilea chenar - informații despre datele către server: dimensiunea actuală a pachetului și viteza medie de încărcare

Al patrulea chenar - grafic al datelor de pe server. Fiecare punct este un pachet de intrare, înălțimea punctelor indică întârzierea (ping) , cu cât este mai mare punctul, cu atât este mai mare întârzierea. Punctele în sine pot fi de 3 culori:

verde - un pachet normal, sosit la timp, nu a zăbovit nicăieri

galben - un pachet cu un marcator de choke , ceea ce înseamnă că serverul nu a putut trimite toate datele din cauza rate

roșu - pachetul a fost pierdut pe Internet

Numărul de pachete loss (pachete pierdute) și choke poate fi văzut și în numere în modul net_graph 3. Valoarea afișată acolo trebuie înțeleasă după cum urmează - câte pachete din ultimele 100 au fost pierdute (loss) sau overflowed (choke).

Linia 5 - valoarea curentă a cl_cmdratre

Linia 6 - două grafice (deși este greu să le vezi acolo), dar sunt actualizate sincron, fiecare coloană corespunde unui cadru pe care clientul îl desenează.

Primul grafic- un pixel înalt în partea de jos. Conține puncte roșii. Ele marchează cadre în care pachetele cmd nu au fost trimise către server (se poate spune că este un analog de choke pentru client, adică clientul are date de trimis, dar nu le poate trimite, pentru ca momentul trimiterii nu a venit încă). Dacă pachetele sunt trimise la server după ce fiecare cadru este randat, grafica nu este vizibilă deloc.

Al doilea grafic este violet în partea de jos și roșu în partea de sus - arată nivelul de desincronizare a stării clientului și serverului. Dacă te uiți cu atenție, este un pieptene (ca acesta - //////). Gradul de desincronizare depinde de momentul în care a fost primit ultimul pachet de la server. Consecințe - cu un pachet nou primit, desincronizarea este minimă, iar cu o întârziere mare în pachetele de intrare, este maximă (graficul în acest caz se transformă într-o bară roșie în partea de sus)

Exemple, descrieri și soluții
Mai jos este un set de 6 capturi de ecran + descrieri pentru ele

Graficul 1
Simptome - se misca in poze, fps scăzut.

Motive: este timpul să aruncați hardware-ul pe , sau altceva mănâncă timpul procesorului (poate un antivirus, sau invers, un fel de virus).

Soluție: Găsiți și distrugeți obiectul folosind procesorul sau alergați la magazin pentru un computer nou.

Graficul 2
Pe graficul verde vedem puncte roșii - pierderi de pachete. Acesta nu este cel mai bun ecran de demonstrat, dar nu există nimic altceva, din păcate.

Simptomele sunt smucirea jucătorilor în timpul jocului, întârzierea împușcării sau alte acțiuni. Se manifestă mai ales bine atunci când se pierd mai multe pachete la rând.

Soluţie:Nu există o singură cale, deoarece motivul poate fi dincolo de controlul tău (poate că un administrator beat s-a împiedicat de cablu). Ceea ce se poate face este să reduceți tot ceea ce folosește rețeaua, în special torrentele și descărcările. Puteți încerca să colectați diagnostice ping/traceroute și să le trimiteți la suportul furnizorului.

Grafic 3
Și aici avem o blocare pe computerul clientului.

Simptome - o „înghețare” bruscă a jocului timp de 200-300 ms, după care o continuare normală. Pe netgraph, acesta este însoțit de un salt al diagramei verzi „sub tavan” (pe ecran puteți vedea două freeze cu un interval mic) , în timp ce nu există abateri pe diagrama de jos.

Cauze- legate în principal de drivere sau hardware. Înghețarea care se vede pe ecran a fost cauzată de comportamentul „inteligent” al hard diskului - după 5-6 secunde de inactivitate, acesta revine, iar când încerci să citești ceva, iar se blocheaza, în timp ce întregul sistem îngheață o vreme.

Soluții - încercați să puneți un sistem de operare curat și vedeți dacă vor fi freeze pe el. Dacă există - o problemă cu computerul, căutăm vinovatul prin înlocuirea secvențială a componentelor. Poate avea, de asemenea, un conflict hardware-hardware, sau un hardware-driver. În general, o singură soluție este dificil de găsit.

Graficul 4
Cea mai frecventă problemă acum este choke, îngălbenirea graficului, care ar trebui să fie verde ;)

Simptome- creșterea ping-ului cu un număr mare de jucători, sau pe hărți în care multe obiecte sunt vizibile în același timp, întârzieri de tragere, puteți vedea mișcarea altor jucători și obiecte în smucitură.

Cauză: Serverul generează mai multe date decât poate trimite.

Soluție: Trebuie să măriți viteza alocată clientului. Punem o rată mai mare (de exemplu, 50000) și vedem ce se întâmplă. Dacă galbenul a dispărut, vă puteți felicita pentru rezolvarea problemei. Dacă nu, încercăm să ajungem la administratorul serverului.

Dacă sunteți administrator, atunci setați un sv_maxrate mai mare în hlds (100000 de exemplu). De asemenea, puteți crește sv_minrate - acest lucru va ajuta jucătorii cu o configurație implicită(se pare că există o rată de 6000) pentru a evita choke și întârzierile.

Graficul 5
Aici am vedea un pieptene clar pe graficul de jos - asta înseamnă că clientul primește date la intervale de timp prea mari. În joc, poate fi exprimat printr-o ușoară creștere a ping-ului, o ușoară zvâcnire a obiectelor, jucătorilor.

Motive: cl_updaterate scăzut sau sv_maxupdaterate foarte scăzut pe partea de server. Se tratează prin creșterea valorilor acestor variabile. De asemenea, acest comportament poate fi cauzat de un FPS foarte scăzut al serverului (< 50).

Rezolvat prin eliberarea procesorului de pe server sau prin creșterea valorii sys_ticrate(dacă are o valoare mică, i e < 100). 

Graficul 6
Aici puteți vedea o înghețare pe partea serverului - a existat o pauză foarte lungă între procesarea cadrelor pe server. Pe net_graph, acesta este exprimat printr-un salt pe graficul inferior de desincronizare, în timp ce nu au existat probleme cu livrarea pachetelor (graficul superior este normal).

Există mai multe motive:
1) asociate de obicei cu o încărcare mare a discului pe server, atunci când hard disk-ul încearcă să citească ceva, există o întârziere.

2) poate apărea din cauza solicitărilor de blocare către un subd supraîncărcat. Soluție - treceți la non-blocking (threadded) requests, deși aici nu puteți face fără a rescrie codul pluginului.

3) prioritate scăzută acordată hlds. Dacă există un proces pe server cu o prioritate mult mai mare decât hlds, în timp ce acesta a încărcat întregul (tot) procesor, atunci hlds-ul se prajeste.