Test de Ping și Pierderi de Pachete

Cum funcționează

1. Închide alte descărcări și streamuri. Alt dispozitiv sau aplicație care consumă bandă lățime în timpul testului va umfla artificial numărul de latență sub sarcină.
2. Preferă cablu Ethernet, sau stai aproape de router. Wi-Fi-ul adaugă propria lui latență și jitter peste ce face linia ta de internet — cablul elimină complet această variabilă.
3. Apasă Start și lasă fila în prim-plan. Browserele încetinesc filele din fundal, ceea ce ar strica măsurătoarea de care depinde acest test.
4. Urmărește întâi latența în repaus, apoi latența sub sarcină. Prima fază măsoară conexiunea în repaus; a doua pornește o descărcare în paralel cu aceleași sonde de latență, ca să vadă cât de mult încetinește cât timp e ocupată.
5. Citește contoarele de stabilitate, nu un procent de pierderi. Nu există unul — vezi mai jos de ce — dar numărul de sonde fără răspuns și câte au revenit neobișnuit de lent îți spun aproape același lucru.
6. Rulează-l din nou la oră de vârf. Latența și bufferbloat-ul sunt mai sensibile la ora din zi decât viteza brută — un rezultat de seară poate arăta semnificativ diferit de unul de după-amiază.

🇷🇴 De ce latența mică chiar contează în România — și de ce nu e o scuză locală

România are peering internațional excelent prin RoNIX (punctul de interconectare din București) și rute foarte directe către majoritatea serviciilor mari — Steam, Riot Games, Google, Cloudflare au toate prezență sau rute foarte bune către România. Asta înseamnă că o latență mare aici, spre deosebire de multe alte țări, e rareori „așa e internetul la noi" și aproape întotdeauna un semn concret de verificat.

• Fibra optică (FTTH) e răspândită chiar și în blocuri vechi din orașe mici, ceea ce înseamnă latență de bază foarte mică pe linia propriu-zisă la majoritatea abonaților.
• Providerii mari — Digi, Orange, Vodafone, Telekom — au toți conexiuni bune la punctele de schimb de trafic locale, deci ruta către servere din UE e de obicei scurtă.
• Scena de gaming competitiv și esports este activă în România, unde diferența dintre 15ms și 60ms chiar se simte în joc.

Ce măsoară de fapt acest test (și de ce „ping" e un pic impropriu într-un browser)

Comanda `ping` trimite un pachet ICMP brut și cronometrează răspunsul. O pagină web nu poate face asta — browserele nu au acces la ICMP sau la socket-uri brute, din același motiv pentru care o pagină web nu îți poate citi fișierele fără să ceară voie. Așa că acest test face cel mai apropiat lucru onest posibil: cronometrează o cerere HTTPS obișnuită către rețeaua Cloudflare și scade timpul de procesare raportat de server, rămânând doar cu drumul dus-întors prin rețea.

• E o măsurătoare reală, nu o simulare — doar prin HTTPS în loc de ICMP.
• De obicei citește cu câteva milisecunde mai mult decât un ping din terminal către aceeași destinație, pentru că un schimb HTTP securizat cu TLS costă puțin mai mult decât un simplu ecou ICMP, chiar și după scăderea timpului de procesare pe server.
• Măsoară drumul până la un punct Cloudflare, nu până la un server specific de joc sau de apeluri — tratează-l ca un indicator general al calității conexiunii, nu ca numărul exact pe care l-ai obține către o anumită destinație.

De ce nu există un procent de pierderi de pachete pe această pagină

Merită explicat direct, nu doar omis, pentru că lipsa acestui număr e o alegere deliberată, nu o funcție lipsă.

• TCP — protocolul din spatele oricărei cereri web obișnuite — retransmite automat și invizibil datele pierdute. Un pachet pierdut nu eșuează; pur și simplu ajunge mai târziu, după o reîncercare.
• Asta înseamnă că o pagină web care cronometrează cereri HTTP nu poate vedea, din principiu, un pachet pierdut ca pierdere — vede un răspuns lent, imposibil de deosebit la prima vedere de o congestie obișnuită.
• Un instrument care ar calcula „0% pierderi" din aceste date nu ar raporta o rată mică de pierderi — ar raporta că nu a putut detecta deloc pierderi, ceea ce e cu totul altceva de spus cuiva care are o conexiune instabilă.

Ce arătăm în schimb: câte sonde de latență nu au primit niciun răspuns într-un termen generos, și câte au revenit mult mai lent decât sonda tipică pe conexiunea ta — un semn că probabil a avut loc o retransmisie, chiar dacă nu poate fi numărată direct. Niciunul dintre cele două numere nu e pierdere. Ambele sunt cea mai apropiată dovadă pe care un browser o poate aduna cu adevărat.

Latență, jitter și cel mai defavorabil caz: ce înseamnă fiecare număr

Testul raportează trei numere înrudite, dar diferite, din faza de latență în repaus.

• Latență (ms): timpul tipic dus-întors — tehnic, mediana tuturor sondelor, care rezistă la a fi denaturată de o singură valoare extremă lentă, spre deosebire de o medie.
• Jitter (ms): cât de mult variază acel timp dus-întors de la o sondă la alta, nu cât de mare e în medie. O conexiune poate avea o latență medie decentă și totuși să se simtă sacadată la un apel dacă jitter-ul e mare.
• Cel mai defavorabil caz (ms): drumul dus-întors la percentila 95 — aproape de numărul pe care chiar l-ai observa într-un apel sau joc, pentru că un moment foarte lent iese mult mai mult în evidență decât cel tipic.

Bufferbloat: de ce conexiunea devine lentă exact când pornește o descărcare

Acesta e numărul pe care majoritatea testelor de viteză îl ignoră complet, și e adesea explicația reală pentru „conexiunea mea e bună până când altcineva începe să descarce ceva".

• Majoritatea routerelor și modemurilor — inclusiv cele oferite de provideri odată cu abonamentul — pun datele de ieșire într-un buffer de coadă înainte de a le trimite, o idee rezonabilă care merge prost când acel buffer e supradimensionat pentru conexiune.
• Când o descărcare sau un upload mare umple acel buffer, orice alt pachet — inclusiv sondele de latență ale acestui test, și orice pachet dintr-un apel sau joc — trebuie să aștepte la coadă în spatele lui.
• Rezultatul: latența care e bună când conexiunea e liberă poate sări de la 20ms la 300ms sau mai mult exact în momentul în care ceva saturează linia, apoi coboară la loc când se termină.

Notele merg de la A+ la F, în funcție de cât crește latența sub sarcină — A+ înseamnă câteva milisecunde abia observabile, F înseamnă sute de milisecunde, genul de vârf care face un apel să se întrerupă exact când telefonul pornește o copie de rezervă în cloud pe aceeași conexiune.

🇷🇴 Routerul de la provider poate fi vinovatul — și ai dreptul să-l schimbi

Mulți abonați din România folosesc routerul oferit de Digi, Orange, Vodafone sau Telekom odată cu abonamentul, iar unele dintre aceste routere gestionează prost coada de pachete — exact cauza bufferbloat-ului de mai sus. Conform regulamentului UE privind neutralitatea rețelei (Regulamentul 2015/2120, aplicabil direct și în România), ai dreptul să folosești propriul echipament terminal, atât timp cât respectă standardele tehnice — providerul nu îți poate condiționa serviciul de folosirea routerului lui.

• Dacă notele de bufferbloat sunt constant D sau F pe cablu, verifică mai întâi dacă routerul are o opțiune de „Smart Queue Management" (SQM) sau „QoS" activabilă din interfața de administrare.
• Un router propriu, mai recent, cu firmware care suportă `fq_codel` sau SQM, rezolvă adesea complet problema, chiar și pe aceeași linie și abonament.
• Dacă schimbi routerul, verifică întâi datele de autentificare PPPoE sau modul de conectare la rețeaua providerului — de obicei disponibile în contul tău online sau la cerere de la suport.

Ce înseamnă un număr bun, pe activități

Nu există un singur număr „bun" — ce contează depinde complet de ce faci pe conexiune.

• Apeluri vocale: confortabil sub aproximativ 200ms dus-întors, cu jitter mic.
• Apeluri video: latență sub 150ms și jitter sub 30ms se simte solid; o notă de bufferbloat C sau mai slabă e adesea cauza reală a unui apel care se întrerupe când altcineva e online în casă.
• Gaming online: sub 50ms cu jitter strâns e excelent pentru orice e competitiv; 50-100ms e suficient pentru majoritatea jocurilor casual.
• Cloud gaming: cel mai strict caz — sub 40ms cu jitter foarte mic, pentru că întregul cadru video face drumul dus-întors, nu doar o comandă.

De aceea testul arată direct un verdict pentru fiecare dintre aceste activități, în loc să te lase să interpretezi singur trei numere brute.

Când rezultatul chiar indică o problemă

Majoritatea rezultatelor slabe au una dintre explicațiile de mai sus. Un set mai mic de tipare chiar merită semnalat providerului.

• Notă de bufferbloat D sau F pe cablu, confirmată în mai multe rulări — adesea rezolvabilă de partea providerului cu management modern al cozii, dacă îl suportă.
• Latență în repaus constant peste 100ms către un punct Cloudflare apropiat, pe cablu, indiferent de ora din zi — indică o problemă de rutare sau congestie în amonte, nu ceva din casa ta.
• Un număr mare de sonde fără răspuns pe cablu, fără VPN activ — merită reprodus și raportat cu o captură de ecran, pentru că poate indica o problemă reală în rețeaua providerului.
• Numere bune la 3 dimineața, dar constant proaste în fiecare seară — congestie locală de rețea, un tipar concret de menționat providerului.

Întrebări frecvente