Tutorial Privind Monitorizarea pe Internet și PingER la SLAC

Sursă originală: http://www.slac.stanford.edu/comp/net/wan-mon/tutorial.html

Les Cottrell , Warren Matthews și Connie Logg, creat în ianuarie 1996; Ultima actualizare: 1 decembrie 2014.

Pagina de start IEPM | PingER | Rapoarte detaliate PingER | Pinger Harta site – ului | Tutorial

Lucrul finanțat parțial de un grant DOE / MICS de lucru pe teren pentru monitorizarea performanței de la Internet la sfârșitul anului (IEPM) .

Conținutul Paginii Web

Introducere

Pentru a oferi o mai bună așteptare a performanței rețelei între site-urile cu care SLAC colaborează, în mai 1996 proiectul PingER (inițiat în ianuarie 1995) a monitorizat aproximativ 100 de gazde din întreaga lume de la SLAC. Din anul 2000, accentul se pune mai mult pe măsurarea divizării digitale. În prezent (aprilie 2007), există peste 35 de site-uri de monitorizare , peste 600 de site-uri aflate în deplasare fiind monitorizate în peste 150 de țări (care conțin peste 99% din populația mondială conectată la Internet) și peste 8000 de perechi de site-uri de la distanță. Mai multe detalii despre implementarea PingER pot fi găsite în PingER Deployment și există o hartă a site-urilor.

Mecanism

Mecanismul principal folosit este mecanismul Echo pentru Internet Control Message Protocol (ICMP) , cunoscut și sub denumirea de facilitatea Ping. Aceasta vă permite să trimiteți un pachet de lungime selectat de utilizator la un nod de la distanță și să îl trimiteți înapoi. În zilele noastre, de obicei vine pre-instalat pe aproape toate platformele, deci nu există nimic de instalat pe clienți. Serverul (de ex. Reponderul de ecou) rulează la o prioritate ridicată (de exemplu, în kernelul de pe Unix) și este mai probabil să ofere o bună măsură a performanței rețelei decât o aplicație de utilizator. Este foarte modest în cerințele de lățime de bandă a rețelei (~ 100 biți pe secundă per pereche de monitorizare-distanță-gazdă pentru modul în care o folosim).

Metodă de măsurare

În proiectul PingER, la fiecare 30 de minute cronde la un nod de monitorizare (Punct de măsurare – MP), pingem un set de noduri la distanță cu 11 ping-uri de câte 100 de octeți fiecare (inclusiv cele 8 octeți ICMP, dar nu și antetul IP). Ping-urile sunt separate de cel puțin o secundă și se folosește timpul de ping implicit de 20 de secunde. Primul ping este aruncat (se presupune că este lent din moment ce primește cache-urile etc.) (Martin Horneffer din “http://www.advanced.org/IPPM/archive.2/0246.html” a raportat că utilizarea UDP -echo pachete și un interval de sosire în jur de 12,5 secunde, primul pachet necesită aproximativ 20% mai mult timp pentru a reveni)). Valoarea minimă / medie / maximă RTT pentru fiecare set de 10 pings este înregistrată. Aceasta se repetă pentru zece ping-uri de 1000 octeți de date. Utilizarea a două mărimi de pachete ping ne permite să realizăm estimări ale ratelor de transfer ping și, de asemenea, la comportamente spot care diferă între pachetele mici și cele mari (de ex. limitare de rata). Vedea Pachete mari vs. mici , sincronizare măsurări ping pentru mai multe detalii. În general, RTT este proporțional cu l (unde l este lungimea pachetului) până la dimensiunea maximă a datagramului (de obicei 1472 octeți, inclusiv cei 8 bytes ICMP echo). Comportamentul dincolo de acest lucru este nedefinit (unele rețele fragmentează pachetele, altele le abandonează). Este disponibilă documentația privind scriptul de măsurare recomandat care rulează la fiecare loc de monitorizare. Timpii de răspuns ping sunt reprezentați grafic pentru fiecare jumătate de oră pentru fiecare nod. Acest lucru este folosit în principal pentru a trage cu probleme (de exemplu, vedeți dacă s-a înrăutățit dramatic în ultimele ore).

Setul de host-uri de la distanță pentru ping este furnizat de un fișier numit pinger.xml (pentru mai multe detalii, consultați documentația pinger2.pl ). Acest fișier conține două părți: gazde de baliză care sunt trase automat zilnic de la SLAC și sunt monitorizate de toți parlamentarii; alți gazde care prezintă un interes deosebit pentru administratorul MP. Gazdele Beacon (și gazdele particulare monitorizați de MP SLAC) sunt păstrați într-o bază de date Oracle conținând numele lor, adresa IP, site-ul, pseudonimul, locația, contactul etc. Lista Beacon (și lista anumitor gazde pentru SLAC) copia bazei de date, într-un format care simplifică accesul Perl pentru scripturile de analiză, este generată automat din baza de date pe bază zilnică.

Colectarea datelor

Arhitectura monitorizării include 3 componente:

  • Site-urile de monitorizare la distanță. Acestea oferă pur și simplu o gazdă pasivă la distanță, cu cerințele corespunzătoare .
  • Locul de monitorizare. De instrumente de monitorizare pinger trebuie să fie instalat și configurat pe o gazdă la fiecare dintre aceste site – uri. De asemenea, datele ping colectate trebuie să fie puse la dispoziția gazdei arhive prin HyperText Tansport Protocol (HTTP) (adică trebuie să existe un server Web care să furnizeze datele la cerere prin intermediul Web-ului). Există, de asemenea, instrumente PingER pentru a permite unui site de monitorizare să furnizeze analize pe termen scurt și rapoarte privind datele pe care le are în memoria cache locală.
  • Site-urile de arhivă și de analiză. Trebuie să existe cel puțin câte unul pentru fiecare proiect PingER. Site-urile de arhivare și de analiză pot fi situate la un singur site sau chiar într-o singură gazdă sau pot fi separate. Proiectul PingER are două astfel de site-uri, unul la NUST în Islamabad, Pakistan, celălalt la SLAC . Site-urile Bot sunt arhive și site-uri de analiză. Ele se completează reciproc prin furnizarea de redundanță. Proiectul XIWT a avut site-ul său de arhivă / monitorizare la CNRI .Site-urile de arhivare colectează informațiile, utilizând HTTP, de pe site-urile monitorului la intervale regulate și arhivează-le. Acestea furnizează datele arhivate sitului (site-urilor) de analiză care, la rândul lor, furnizează rapoarte care sunt disponibile pe Web.

Datele sunt colectate se adună în mod regulat ( de obicei zilnic) din nodurile de monitorizare de două gazde de arhivă, unul la SLAC altul la FNAL (HEPNRC), care stochează, analizează analiza , pregătirea și prin intermediul web face rapoarte disponibile pingtable privire la (a se vedea figura de mai jos).

Arhitectura PingER

Arhitectura PingER este ilustrată mai jos:

Gotchas

Este necesară o anumită atenție în selectarea nodului la ping (consultați Cerințele pentru gazdele WAN monitorizate ).

Am observat, de asemenea, diferite patologii cu diferite site-uri la distanță atunci când utilizați ping. Acestea sunt documentate în patologiile de măsurare PingER .

Calibrarea și contextul în care se măsoară valorile rotunjite sunt documentate în calibrarea și contextul PingER , iar câteva exemple de rezultate ale ping-ului atunci când sunt luate cu statistici ridicate și modul în care acestea se referă la rutare pot fi găsite în rezultatele ping de mare statistică .

Validare

Am validat utilizarea ping-ului demonstrând că măsurătorile făcute cu acesta se corelează cu răspunsul aplicației. Corelația dintre limitele inferioare ale răspunsurilor Web și ping este prezentată în figura de mai jos. Măsurătorile au fost efectuate pe 18 decembrie 1996, de la SLAC la aproximativ 1760 de locații identificate în cache-urile NLANR . Pentru mai multe detalii, a se vedea Efectele performanței Internetului în timpii de răspuns web , de Les Cottrell și John Halperin, nepublicate, ianuarie 1997.

Scatterul scatter de min HTTP GET vs min ping (30951 octeți)
Reziduuri pentru HTTP = 2 min răspuns Ping (37218 octeți)

Limita remarcabil de mică, văzută în jurul valorii de y = 2x, nu este surprinzătoare deoarece: o pantă de 2 corespunde HTTP GET-urilor care iau de două ori timpul ping; timpul minim de ping este aproximativ timpul de decolare; și o tranzacție minimă TCP implică două călătorii rotunde, o călătorie dus-întors pentru schimbul celui de-al doilea pentru a trimite cererea și pentru a primi răspunsul. Terminarea conexiunii se face în mod asincron și astfel nu apare în momentul respectiv. 
 
Limita inferioară poate fi de asemenea vizualizată prin afișarea distribuției reziduurilor între măsurători și linia y = 2 x (unde y = HTTP timpul de răspuns GET și x= Timp de răspuns minim ping). O astfel de distribuție este prezentată mai jos. Se observă o creștere abruptă a frecvenței măsurătorilor, pe măsură ce se atinge valoarea zero reziduală ( y = 2x ). Intervalul Quartier Interleu (IQR), intervalul rezidual dintre 25% și 75% din măsurători, este de aproximativ 220 msec și este indicat pe grafic de linia roșie. 

Un mod alternativ de a demonstra că ping-ul este legat de performanța Web este să arate că ping-ul poate fi folosit pentru a prezice care dintre serverele de Web replicate pentru a obține o pagină Web. Pentru mai multe informații, consultațiDynamic Server Selection pe Internet , de Mark E. Crovella și Robert L. Carter.

Firehunter Studiul de caz al Whitehouse Web Server a arătat că , deși răspunsul ping nu urmărește performanța web anormale bine, în acest caz , ping pierdere de pachete a facut o treaba mult mai bine.

Calitatea Internetului de evaluare a serviciilor de către Christian Huitema, oferă măsurători ale diferitelor componente care contribuie la răspunsul web. Aceste componente includ: RTT, viteza de transmisie, întârzierea DNS, întârzierea conexiunii, întârzierea serverului, întârzierea transmisiei. Aceasta arată că întârzierile dintre trimiterea comenzii URL GET și primirea primului octet al răspunsului este o estimare a întârzierii serverului (“în multe servere, deși nu neapărat toate, această întârziere corespunde cu timpul necesar pentru programarea solicitărilor de pagină , pregătiți pagina în memorie și începeți să trimiteți date) și reprezintă între 30 și 40% din durata tranzacției medii. Pentru a ușura acest lucru, probabil că aveți nevoie de mai multe servere puternice. Obținerea conexiunilor mai rapide ar ajuta în mod evident pe celelalte 60% din întârziere.

De asemenea, consultați secțiunea de mai jos cu privire la instrumentele bazate pe Non Ping pentru unele corelații ale performanței cu timpul de deplasare rotundă și pierderea pachetelor.

Ce măsuram

Utilizăm ping pentru a măsura timpul de răspuns (timpul de deplasare rotundă în milli-secunde (ms)), procentele pierderii de pachete, variabilitatea timpului de răspuns, atât pe termen scurt (scala de timp) și mai lungă, cât și lipsa accesibilității , adică nici un răspuns pentru o succesiune de ping-uri. Pentru o discuție și o definiție a disponibilității și a disponibilității, consultați Performanța Internetului: Analiza datelor și vizualizarea unei cărți albe a XIWT . De asemenea, înregistrăm informații cu privire la pachetele defecte și pachetele duplicate.

Cu datele măsurate, putem crea linii de bază pe termen lung pentru așteptările privind mijloacele / mediile și variabilitatea pentru timpul de răspuns , debitul și pierderea de pachete . Cu ajutorul acestor linii de bază putem stabili așteptări, furniza informații de planificare, facem extrapolări și căutăm excepții (de exemplu, timpul de răspuns de astăzi este mai mare de 3 abateri standard mai mari decât media pentru ultimele 50 de zile lucrătoare) și să ridice alertele.

Pierderi

Pierderea este o măsură bună a calității legăturii (în ceea ce privește ratele de pierdere a pachetelor) pentru multe aplicații bazate pe TCP. Pierderea este cauzată în mod obișnuit de congestionarea care, la rândul său, generează cozile (de exemplu în routere) și umple pachetele. Pierderea poate fi de asemenea cauzată de rețeaua furnizând o copie imperfectă a pachetului. Acest lucru este cauzat, de obicei, de erori de biți în legături sau în dispozitive de rețea. Paxson (a se vedea Dynamics Packet End-lto-end) din măsurătorile efectuate în 1994 și 1995 au concluzionat că majoritatea erorilor de corupție au provenit din legăturile T1, iar rata tipică a fost de 1 din 5000 de pachete. Aceasta corespunde unei rate de eroare bit pentru o medie de pachete de 300 de biți de aproximativ 1 din 12 milioane de biți. IP are o sumă de control de 16 biți, astfel încât probabilitatea de a nu detecta o eroare într-un pachet corupt este de 1 la 65536, sau 1 în aproximativ 300 de milioane de pachete. Un studiu mai recent despre Când CRC și TCP checksum nu sunt de acordpublicată în august 2000, indică faptul că, în ultimii doi ani, urme de pachete de Internet arată că 1 din 30.000 de pachete nu reușește să controleze TCP-ul, chiar și pe legăturile în care CRC-urile la nivel de legătură ar trebui să captureze toate erorile de la 1 la 4 miliarde. Aceste erori de control TCP sunt mai ridicate (de exemplu, ele pot fi cauzate de erori de magistrală în dispozitive sau calculatoare de rețea sau de erori de stack TCP) decât erorile la nivel de legătură care ar trebui să fie prinse de controalele CRC.

RTT

Timpul de răspuns sau Timpul rotunjit (RTT) atunci când este reprezentat grafic în raport cu mărimea pachetului poate da o idee despre rata de transfer ping (kilo Bytes / sec (KB / s)) Acest lucru devine din ce în ce mai dificil, mergând la link-uri de înaltă performanță, este relativ mic (de obicei <1500 de biți), iar rezoluția de sincronizare este limitată. RTT este legată de distanța dintre site-uri plus întârzierea la fiecare hamei de-a lungul căii dintre situri. Efectul distanței poate fi caracterizat prin viteza luminii din fibră și este dat de distanța / (0,6 * c) unde ceste viteza luminii (ITU în documentul G.144, tabelul A.1 recomandă un multiplicator de 0,005 msec / km sau 0,66c). Punând acest lucru împreună cu întârzierile hamei, RTT R este dat de:R = 2 * (distanța / (0,6 * c) + hamei * întârziere)unde factorul 2 este de la măsurarea timpilor de ieșire și de întoarcere pentru călătoria rotundă. Acest lucru este ilustrat în figura de mai jos, care arată răspunsul măsurat ping în funcție de distanța între 16 perechi de locații situate în SUA, Europa și Japonia (Bologna-Florența, Geneva-Lyon, Chicago-U din Notre Dame, Tokyo – Osaka, Hamburg-Dresda, Bologna-Lyon, Geneva-Mainz, Pittsburg-Cincinnatti, Geneva-Copenhaga, Chicago-Austin, Geneva-Lund, Chicago, San Francisco, Geneva-Osaka). Triunghiurile albastre sunt pentru RTT măsurat (în milisecunde), linia neagră este potrivită datelor, linia verde este pentru y = x (distanța) / (0.6 * c), iar punctele roșii se îndoaie în întârzierile hamei cu o întârziere / hop de aproximativ 2,25ms pentru fiecare direcție (adică punctele roșii sunt potrivite RTT teoretice). Am folosit Cât de departe este? pagina web pentru a obține distanțele dintre punctele importante de-a lungul fiecărui traseu. Un studiu mai recent, realizat de Mark Spiller în martie 2001, la aproximativ 10 universități din UC Berkeley a măsurat întârzierea ruterului de 500-700 de utilizări cu câteva vârfuri în gama de utilizări 800-900. 

rtt-predict.jpg (35216 bytes)

Lungimea căii rutiere (R km ) poate fi utilizată în locul distanței pentru anumite obiective de performanță a transferului în cadru (FTD). Dacă km este distanța de rulare aeriană dintre granițe, atunci lungimea traseului este calculată după cum urmează (acesta este același calcul ca cel descoperit în documentul ITU G.826).

  • dacă km <1000 km, atunci km = 1,5 * km
  • dacă 1000 km <= km <= 1200 km, atunci km = 1500 km
  • dacă km > 1200 km, atunci km = 1,25 * km

Această regulă nu se aplică dacă în traseu există un satelit. Dacă un satelit este prezent în orice porțiune a traseului, acelei porțiuni i se alocă un FTD fix de 320 ms. Valoarea de 320 msec ia în considerare factori precum unghiurile de vizualizare a stației terestre joase și codarea corecției de eroare înainte. Cele mai multe porțiuni care conțin un satelit nu sunt de așteptat să depășească 290 msec de întârziere. Dacă este un satelit geostaționar, atunci limita inferioară a orbitei geosinchimice se situează între 22.000 și 23.000 de mile, viteza luminii este de ~ 186.000 mile, se ridică și înapoi este de 45.000, iar călătoria este de 90.000 de mile, așa că ajungem acolo chiar la 500 de kilometri . 
Această RTT minimă alungită provocată de sateliții geo-staționare oferă o semnătură utilă pentru a identifica că traseul dintre monitor și țintă include un satelit geostationar. Un exemplu poate fi văzut în Figura 5 din Raportul 2011 – 2012 al Grupului de lucru pentru monitorizarea ICFA-SCIC . 
Întârzierile la fiecare hop sunt o funcție a 3 componente principale: viteza routerului, ratele de interconectare a interfeței și așteptarea în router. Primele două sunt constante pe perioade scurte (câteva zile). Astfel RTT-urile minime oferă o măsură a distanței / (0,6 * c) + hamei * (viteza interfeței / dimensiunea pachetului) + timpul minim de redirecționare a routerului). Acest număr ar trebui să fie o funcție liniară a mărimii pachetului. Efectele de așteptare ale routerului, pe de altă parte, depind de procesele de așteptare mai aleatoare și de traficul încrucișat și deci sunt mai variabile. Acest lucru este ilustrat în graficul MRTG de mai jos, care indică RTT minuscule (zona verde) foarte stabilă și RTT-urile maxime aleatorii (linii albastre) măsurate de la SLAC la Universitatea din Wisconsin, de la 25 februarie 2001 până la luni, 5 aprilie 2001. puțină blip în RTT în jurul valorii de marți, la jumătatea zilei, este probabil cauzată de o schimbare a traseului. 

Min și max RTT între SLAC și UWisc

Instrumente non-ping bazate pe

SLAC a fost, de asemenea, un sit Surveyor. Măsurătorile de întârziere ale unui observator (nu utilizează ICMP), folosind dispozitivele GPS (Global Positioning System) pentru sincronizarea timpului și monitorizările / gazdele dedicate. Amcomparat datele PingER și Surveyor pentru a compara și a contraface cele două metode și a verifica validitatea ecoului ICMP. O preocupare ridicată cu ICMP echo este posibilitatea ca furnizorii de servicii de Internet (ISP) să limiteze ICMP ecouși, prin urmare, să ducă la măsurători de pierdere a pachetelor invalide, pentru mai multe despre aceasta vezi secțiunea despre Gotchas de mai sus.

De asemenea, folosim instrumente mai complexe, cum ar fi FTP (pentru a măsura ratele de transfer în vrac) și traceroute (pentru a măsura căile și numărul de hamei). Cu toate acestea, pe lângă faptul că este mai dificil de configurat și automatizat, FTP este mai intruziv în rețea și mai dependent de încărcarea nodului final. Astfel, folosim FTP în principal într-un mod manual și pentru a obține o idee despre cât de bine funcționează testele ping (de ex. Corelațiile dintre FTP și Ping șicorelațiile dintre transferul FTP, Hops & Packet Loss ). De asemenea, am comparat previziunile PingER ale transferului cu măsurători NetPerf . O altă modalitate de corelare a măsurătorilor de transfer cu pierderi de pachete este prin modelarea TCP .

Calculând scorul mediu de opinie (MOS)

Industria de telecomunicații utilizează Scorul mediu de opinie (MOS) ca metric pentru calitatea vocii. Valorile MOS sunt: ​​1 = rău; 2 = slab; 3 = echitabil; 4 = bun; 5 = excelent. O gamă tipică pentru Voice over IP este de 3,5 până la 4,2 (veziVoIPtroubleshooter.com ). În realitate, chiar și o conexiune perfectă este influențată de algoritmii de compresie ai codecului, astfel încât cel mai mare scor pe care majoritatea codec-urilor îl poate obține este în intervalul de la 4,2 până la 4,4. Pentru G.711 cel mai bun este 4,4 (sau un factor R) (vezi Recomandarea ITU-T G.107, “Modelul E, un model computational pentru utilizarea in planificarea transmisiei”) de 94.3) si pentru G.729 care efectueaza compresia semnificativă este de 4,1 (sau un factor R de 84,3).

Există trei factori care influențează în mod semnificativ calitatea apelurilor: latență, pierderea pachetului, jitter. Alți factori includ tipul de codec, telefonul (analogic și digital), PBX etc.). Aratăm modul în care calculăm jitterul mai târziu în acest tutorial. Cele mai multe soluții bazate pe instrumente calculează ceea ce se numește o valoare “R” și apoi se aplică o formulă pentru a converti la un scor MOS. Facem același lucru. Acest calcul R la MOS este relativ standard (a se vedea, de exemplu, documentul temporar al sectorului de standardizare în telecomunicații XX-E WP 2/12pentru o nouă metodă). Scorul de valoare R este de la 0 la 100, unde un număr mai mare este mai bun. Valorile tipice R la MOS sunt: ​​R = 90-100 => MOS = 4.3-5.0 (foarte mulțumit), R = 80-90 => MOS = 4.0-4.3 (satisfăcut), R = 70-80 => MOS = 3.6 -4.0 (unele nemulțumiri), R = 60-70 => MOS = 3.1-3.6 (mai multă nemulțumire), R = 50-60 => MOS = 2.6-3.1 1,0-2,6 (nu este recomandat). Pentru a transforma latența, pierderea, jitterul la MOS, urmăm metoda lui Nessoft . Ei folosesc (în pseudo-cod):

# Acordați latența medie de călătorie rotundă (în milisecunde), adăugați 
# jitter în timpul călătoriei, dar dublează impactul la latență
# apoi adăugați 10 pentru latențe de protocol (în milisecunde).
Eficacitatea Latency = (Medie Latency + Jitter * 2 + 10)
#Efectuați o curbă de bază - deduceți 4 pentru valoarea R la 160ms de latență
#(dus-întors). Orice peste asta are o deducție mult mai agresivă.

dacă eficaceLatency <160 atunci
   R = 93,2 - (Latență efectivă / 40)
altfel
   R = 93,2 - (Latență efectivă - 120) / 10

# Acum, să deducem valorile 2.5 R per procentaj de pierdere de pachete (adică a
#loss de 5% va fi introdus ca 5).
R = R - (PacketLoss * 2,5)

#Convertați R într-o valoare MOS (aceasta este o formulă cunoscută)
dacă R <0 atunci
   MOS = 1
altfel
   MOS = 1 + (0,035) * R + (.000007) * R * (R-60) * (100-R)

De asemenea, vedeți următoarele pentru unele instrumente de măsurare și / sau explicații:

Calcularea contribuției rețelei la timpul de tranzacționare

UIT a prezentat o metodă de calculare a contribuției rețelei la timpul tranzacției în ITU-T Rec.G1040 “Contribuția rețelei la timpul tranzacției” . Contribuția depinde de RTT , probabilitatea de pierdere ( p ), timpul de retransmitere ( RTO ) și numărul de călătorii rotunde implicate ( n ) într-o tranzacție. Contribuția la rețea pentru timpul de transmisie ( NCTT ) este dată ca: 
Valoarea medie (NCTT) = (n * RTT) + (p * n * RTO)
Valorile tipice pentru n sunt 8, pentru RTO luăm 2,5 secunde, luăm probabilitatea RTT și a pierderii ( p ) din măsurătorile PingER.

Derivarea transferului TCP din măsurătorile ping

Comportamentul macroscopic al algoritmului de evitare a congestiei TCP de către Mathis, Semke, Mahdavi & Ott în Computer Communication Review, 27 (3), iulie 1997, oferă o formulă scurtă și utilă pentru limita superioară a ratei de transfer:Rata <(MSS / RTT) * (1 / sqrt (p))unde: 
Rata : este rata de transfer TCP 
MSS : este dimensiunea maximă a segmentului (fixată pentru fiecare cale de Internet, de obicei 1460 octeți) 
RTT : este timpul de plimbare rotundă (măsurat prin TCP) 
p : rata de pierdere a pachetelor. 
Strict vorbind, pierderile sunt pierderile TCP care nu sunt neapărat identice cu pierderile de ping (de exemplu, TCP standard provoacă pierderi ca parte a estimării congestiei). De asemenea, RTT-urile ping sunt diferite de modul în care TCP estimează RTT (a se vedea, de exemplu, Îmbunătățirea estimărilor timpului de rută-ieșire în Protocolul de transport fiabil ). Cu toate acestea, în special pentru link-uri de performanță mai scăzută, este un estimator rezonabil. 
Se poate folosi rata de eroare bit (BER)pentru a estima pierderile. Valorile tipice sunt BER = 10 ^ -9 (probabilitatea de pierdere a pachetului de ~ 0,001% pentru pachetele de 100 de biți) pentru o legătură electrică și 10 ^ -12 pentru o legătură optică (vezi CS244a: Introducere în rețelele de calculatoare – Universitatea Stanford ; 10 Gigabit Ethernet și interfața XAUI ). 
Dacă nu puteți măsura empiric p, începeți cu rata de eroare de așteptare (BER) pentru 1000BaseT, 10 ^ -10 pentru probabilitatea pierderii. Vedeți obiectivul de performanță a erorilor pentru 400GbE .

O formă îmbunătățită a ecuației de mai sus poate fi găsită în: Modelarea tranziției TCP: Un model simplu și validarea empirică a lui J. Padhye, V. Firoiu, D. Townsley și J. Kurose, în Proc. SIGCOMM Symp. Arhitecturile și protocoalele de comunicații Aug. 1998, pp. 304-314.

Rata = min (W max / RTT, 1 / (RTT / sqrt (2 * b * p / 3) + min (1, 3 * sqrt (3 * b * p / 8) * p))))unde: 
max : este dimensiunea maximă a ferestrei de congestie. 
b : este numărul de pachete confirmate de un ACK întârziat. Multe implementări ale receptorului TCP trimit un ACK cumulativ pentru două pachete consecutive primite (vezi W. Stevens, TCP / IP Illustrated, Vol.1 Protocoalele, Addison-Wesley, 1994), deci b este de obicei 2.

Comportamentul transferului ca o funcție a pierderii și RTT poate fi văzut prin analizarea Performanței față de RTT și a pierderii . Am folosit formula Mathis pentru a compara măsurătorile de transfer ale PingER și NetPerf .

Normalizarea fluxului derivat

Pentru a reduce efectul 1 / RTT în formula Mathis pentru viteza de producție derivată, normalizăm transferurile folosind 
norm_throughput = tranzit * min_RTT (regiune la distanță) / min_rtt (monitoring_region)

Directa de conectare

Aceasta este o metrică pentru a identifica direcționarea conexiunii de la 2 noduri la locații cunoscute. Valorile directoare aproape de una înseamnă că traseul dintre gazde urmează un traseu circular foarte mare. Valori mult mai mici decât 1 înseamnă calea este foarte indirectă. Derivarea coeficientului de directivitate Directivitatea bazată pe minimul RTT este dată aici .

RTD = distanța 
parcursă pe rută , RTD [km] = Directivitatea * min_RTT [msec] * 200 [km / msec
 ] 
Directivitatea permite întârzieri în echipamentul de rețea și indirectitatea rutei reale. 
D = distanța de 1 direcție 
Directivitate = D (km) / (min_RTT [msec] * 100 [km / msec])

  • Max ( Directivity ) = 1 = directe (cerc mare) și fără întârzieri în rețea
  • Directivitatea obținută din mini RTT este de obicei ~ 0,45
  • Valorile scăzute înseamnă în mod normal o rută foarte indirectă sau o conexiune prin satelit sau lentă (de exemplu, fără fir)
  • Directivitatea > 1 identifică probabil coordonatele nepotrivite pentru gazde.

În cazul traceroului vizual VTrace , diferența dintre distanța de la distanță și distanța între capăt poate oferi o estimare a Directivității . Distanța de la capăt la capăt este distanța mare dintre cerc și destinație, unde distanța totală a hameiului este suma distanțelor mari ale cercului între toate hamei consecutive. În acest caz, estimăm directiva ca (end_to_end_distance / total_hop_distance) .

Acces la date

Datele ping brute sunt accesibile publicului, consultați Accesarea datelor PingER pentru obținerea datelor și formatului. Datele rezumate sunt de asemenea disponibile de pe web în formatul Excel (.tsv) din fila Excel din rapoartele detaliate ale PingER .

Pingerea nodurilor colaboratorilor

Analiza și prezentarea datelorZilele zilniceTimpii de răspuns ping sunt reprezentați grafic pentru fiecare jumătate de oră pentru fiecare nod, de exemplu vezi complotul Smokeping dacă RTT și pierderea . Acest lucru este folosit în principal pentru a trage cu probleme (de exemplu, vedeți dacă s-a înrăutățit dramatic în ultimele ore).Plotte 3D ale nodului vs răspuns vs timpul zilei

Prin complotarea unui complot 3D al nodului versus timp în raport cu răspunsul, putem căuta corelații ale mai multor noduri care au performanțe slabe sau care nu pot fi atinse în același timp (poate din cauza unei cauze comune), sau un nod dat având un răspuns slab sau fiind inaccesibil pentru timp prelungit. În stânga este un exemplu care arată mai multe gazde (în negru), toate fiind inaccesibile în jurul orei 12.00.

Ultimele 180 de zile parcele:Graficele pe termen lung care indică timpul de răspuns, pierderea de pachete și lipsa de accesibilitate pentru ultimele 180 de zile pot indica, de asemenea, dacă un serviciu se înrăutățește (sau mai bine ).Lunar Ping Response & Pierdere medie care se întorc de ani de zile:

Tabelele medianilor lunare ale primei zile (7:00 – 19:00 în timpul zilei) 1000 de octeți de timp de răspuns ping și 100 de octeți pierderi de pachete ping ne permit să vedem datele care se întorc pe perioade mai lungi. Aceste date tabulare pot fi exportate în Excel și diagrame din performanța pierderilor de pachete ping pe termen lung.

Quiescent Network FrequencyAtunci când obținem un eșantion de pierdere a pachetelor zero (un eșantion se referă la un set de pings), ne referim la rețea ca fiind liniștită (sau ne-ocupată). Apoi, putem măsura frecvența procentuală a frecvenței reținerii rețelei. Un procentaj ridicat este o indicație a unei rețele bune (în stare de repaus sau fără încărcare). De exemplu, o rețea care este ocupată cu 8 ore de lucru pe săptămână și care este liniștită în alte momente ar avea un procent înconjurător de aproximativ 75% (total / ore săptămână – 5 săptămâni / săptămână * 8 ore / zi) / (total_hours / săptămână) . Acest mod de reprezentare a pierderii este similar în intenția metrică a telefonului pentru secundele fără erori. Frecvența Rețeaua de repaus
tabelul arată procentajul (frecvența) probelor (în cazul în care un eșantion este un set de 10 100 octeți ping) care au măsurat pierderea de pachete zero. Probele incluse în fiecare procent raportat sunt toate eșantioanele pentru fiecare amplasament pentru fiecare lună (adică de ordinul a 30 de zile * 48 (perioade de 30 de minute) sau aproximativ 1440 de probe) pe site / lună.Jitter , a se vedea, de asemenea , Jitter ,Variabilitatea pe termen scurt sau “jitterul” timpului de răspuns este foarte importantă pentru aplicațiile în timp real, cum ar fi telefonia. Navigarea pe Internet și poșta sunt destul de rezistente la jitter, dar orice tip de media streaming (voce, video, muzică) este destul de susceptibil la jitter. Jitter este un simptom că există o congestie sau nu este suficientă bandwidt pentru a gestiona traficul. Jitterul specifică lungimea tamponului de jitter pentru codec VoIP pentru a preveni supra-sau sub-flux. Un obiectiv ar putea fi specificarea faptului că 95% din variațiile întârzierii pachetelor ar trebui să se situeze în intervalul [-30msec, + 30msec].

O metodă necesită injectarea pachetelor la intervale regulate în rețea și măsurarea variabilității în timpul sosirii. IETF are o metrică de variație a intervalului de întârziere a pachetului IP pentru metrici de performanță IP (IPPM) (vezi șiRTP: Un protocol de transport pentru aplicații în timp real , RFC 2679 și RFC 5481

Măsurăm variabilitatea instantanee sau “jitter” în două moduri.

  1. Să măsurarea i-lea a round trip time (RTT) să fie i , atunci vom lua „bruiaj“ , ca fiind Inter segmențială Range (IQR) din distribuția frecvenței R . Vedeți SLAC <=> întârziere de întoarcere CERN pentru un exemplu de astfel de distribuție.
  2. În cea de-a doua metodă, extindem schița IETF la Metrica variației întârzierii pachetului de întârziere pentru IPPM , care este o metrică unidirecțională, la ping-uri bidirecționale. Luăm IQR a distribuției frecvenței dR , unde dR i = i -R i-1 . Rețineți că atunci când calculați dR , pachetele nu trebuie să fie adiacente. Vedeți variația de întârziere instantanee de întârziere a pachetelor CACC SLAC pentru un exemplu de astfel de distribuție.

Ambele distribuiri de mai sus pot fi considerate a fi non-Gaussian și de aceea folosim IQR în loc de abaterea standard ca măsură de “jitter”. De asemenea, consultați RFC 1889/3550.

Prin vizualizarea “jitterului” Ping între SLAC și CERN, DESY & FNAL se poate observa că cele două metode de calcul al jitterului se urmăresc bine (prima metodă este denumită IQR și cea de-a doua etichetă IPD din figură). Acestea variază în funcție de două ordine de mărime pe parcursul zilei. Jitterul dintre SLAC și FNAL este mult mai mic decât între SLAC și DESY sau CERN. Este, de asemenea, demn de remarcat faptul că CERN are un jitter mai mare în timpul zilei europene, în timp ce DESY are un jitter mai mare în timpul zilei americane.

De asemenea, am obținut o măsură a jitterului luând valoarea absolută dR , adică | dR | . Această metodă este denumită uneori “metoda de mișcare în mișcare” (vezi Designul și analiza statistică a experimentelor , Robert L. Mason, Richard F. Guest și James L. Hess, John Wiley & Sons, 1989). De asemenea, este utilizat în RFC 2598 ca definiție a jitterului ( RFC 1889 are o altă definiție a jitterului pentru utilizarea și calculul în timp real). A se vedea histograma domeniului în mișcarepentru un exemplu. În această figură, linia magenta este totalul cumulativ, linia albastră este o exponentail potrivită datelor, iar linia verde este o serie de putere care se potrivește cu datele. Rețineți că toate cele 3 diagrame din această secțiune despre jitter sunt reprezentări ale datelor identice.

Pentru a înțelege mai bine cerințele pentru VoIP și, în special, impactul aplicării măsurilor de calitate a serviciilor (QoS), am creat o platformă de testare VoIP între SLAC și LBNL. Un schematic brut este arătat la dreapta. Numai semicercul SLAC este arătat în schematică, capătul LBNL este similar. Un utilizator poate ridica telefonul conectat la PBX la capătul SLAC și poate apela un alt utilizator pe un telefon la LBNL prin gateway-ul routerului VoIP Cisco. Poarta codifică, comprimă etc. fluxul de voce în pachete IP (folosind standardul G.729), creând aproximativ 24kbps de trafic. Streamul VoIP include atât pachete TCP (pentru semnalizare) cât și pachete UDP. Conexiunea de la router-ul ESnet la cloud-ul ATM este un circuit virtual permanent (PVC) de 3,5 Mbps ATM. Cu nici un trafic concurente pe link, apelul se conectează și conversația se desfășoară în mod normal cu o calitate bună. Apoi injectam 4 Mbps de trafic pe Ethernet-ul comun de 10 Mbps pe care este conectat routerul VoIP. În acest stadiu, conexiunea VoIP este întreruptă și nu se pot face alte conexiuni. Apoi am folosit caracteristica Rata de Acces Committed Rate (RAC) a routerului Edge pentru a eticheta pachetele VoIP “prin setarea biților Behaviour HB (PHB). Router-ul ESnet este apoi setat să utilizeze caracteristica Weighted Fair Queuing (WFQ) pentru a accelera pachetele VoIP. În această configurație pot fi efectuate din nou conexiuni vocale, iar conversația este din nou de bună calitate. (CAR) pentru a eticheta pachetele VoIP “prin setarea biților de comportament Hop Hop (PHB). Router-ul ESnet este apoi setat să utilizeze caracteristica Weighted Fair Queuing (WFQ) pentru a accelera pachetele VoIP. În această configurație pot fi efectuate din nou conexiuni vocale, iar conversația este din nou de bună calitate. (CAR) pentru a eticheta pachetele VoIP “prin setarea biților de comportament Hop Hop (PHB). Router-ul ESnet este apoi setat să utilizeze caracteristica Weighted Fair Queuing (WFQ) pentru a accelera pachetele VoIP. În această configurație pot fi efectuate din nou conexiuni vocale, iar conversația este din nou de bună calitate.Previzibilitatea serviciilorO măsură a variabilității serviciului (sau a predictibilității ping ) poate fi obținută prin intermediul unei scheme de împrăștiere a variabilelor fără dimensiune rata medie zilnică de date ping / rata maximă de date ping față de succesul ping mediu / ping maxim (în cazul în care% succes = pachete totale – pachete pierdute) / Total Packets) . Aici rata de ping de date este definit ca (* octeți în pachete de ping 2) / timp de raspuns. Cel de-al doilea este de când pachetul trebuie să iasă și să se întoarcă. Un alt mod de a privi rapoartele este că numerele de lângă 1 indică faptul că performanța medie este aproape de cea mai bună performanță. Numerele care nu sunt aproape de 1 sunt cauzate în mod obișnuit de variații mari în timpul ping între orele de lucru și orele de lucru, a se vedea, de exemplu, răspunsul ping al UCD pentru 3 octombrie 1996 pentru un exemplu de variații diurne. Câteva exemple de parcele de predictibilitate ping pentru diferite părți ale Internetului măsurate de la SLAC pentru iulie 1995 și martie 1996 pot fi văzute mai jos.

DataToate gazdeleESnetAmerica de NordInternaţional
Iul ’95
Mar ’96

Se poate reduce mai mult această informație scatterplot prin trasarea succesului pachetului mediu de ping ping / succes ping ping maxim față de lunar ping thruput / maxim ping thruput pentru diferite luni pentru a vedea modificările. Un astfel de complot pentru câteva noduri N. americane pentru iulie 1995 și martie 1996 arată schimbări mari, în toate cazurile fiind în rău (mai multe puncte mai recente sunt mai degrabă la stânga jos a complotului).imprevizibilitateaSe poate calcula, de asemenea, distanța fiecărui punct de previzibilitate de la coordonat (1,1). Ne normalizăm la o valoare maximă de 1, împărțind distanța cu sqrt (2). Mă refer la acest lucru ca fiind imprevizibilitatea ping , deoarece oferă un procentaj indicator al impredictibilității performanței ping.accesibilitatePrivind datele ping pentru a identifica perioadele de 30 de minute în care nu s-au primit răspunsuri ping de la o anumită gazdă, se poate identifica când gazda a fost în jos. Folosind aceste informații se poate calcula ping unreachability = (# perioade cu Node jos / numărul total de perioade) , # Down periods, Mean Time between Failure (MTBF sau Mean Time To Failue MTTF)) și Mean Time to Repair (MTTR). Rețineți că MTBF = sample_time / ping_unreachability unde timpul de eșantionare al PingER este de 30 de minute. Accesibilitatea este foarte dependentă de gazda la distanță, de exemplu dacă gazda de la distanță este redenumită sau eliminată, gazda va apărea inaccesibilă, dar nu este nimic în neregulă cu rețeaua. Astfel, înainte de a utiliza aceste date pentru a furniza tendințe de rețea pe termen lung, datele ar trebui să fie epurate cu grijă pentru efecte non-rețea. Sunt disponibile exemple de disponibilitate ping și rapoarte în jos .

Se poate măsura, de asemenea, frecvența lungimilor de întrerupere utilizând sondele active și notând durata de timp pentru care sondele secvențiale nu trec prin.

Metoda ulterioară / care este uneori utilizată pentru a indica disponibilitatea unui circuit telefonic este secunde fără erori . Unele măsurători pot fi găsite în Secunde de eroare gratuite între SLAC, FNAL, CMU și CERN .

Există, de asemenea, un RFC IETF privind măsurarea conectivității și un document privind o taxonomie modernă de înaltă disponibilitate care ar putea fi utilă.Pachete de comandă în afara pachetuluiPingER folosește un algoritm foarte simplu pentru identificarea și raportarea pachetelor în afara comenzii. Pentru fiecare eșantion de 10 pachete, se dorește să se vadă dacă numerele de ordine ale răspunsurilor sunt primite în aceeași ordine în care au fost trimise cererile. Dacă nu este decât acel eșantion marcat ca având unul sau mai multe răspunsuri necorespunzătoare. Pentru un anumit interval (să zicem o lună), valoarea raportată pentru ou a ordinului este fracțiunea de eșantioane care au fost marcate cu răspunsuri ping necorespunzătoare. Deoarece pachetele de ping-uri sunt trimise la intervale de o secundă, este de așteptat ca fracțiunea din eșantioanele necorespunzătoare să fie foarte mică și poate fi utilă investigarea ori de câte ori nu este.Pachete duplicateRăspunsurile ping duplicate pot fi cauzate de:

  • Mai mult de o gazdă are aceeași adresă IP, astfel încât toate aceste gazde vor răspunde la solicitarea ecou ICMP.
  • Adresa IP pinged poate fi o adresă difuzată.
  • Gazda are mai multe stive TCP legate de un adaptor Ethernet (vezi http://www.doxpara.com/read.php/tcp_chorusing.html).
  • Un router crede că are două căi prin care poate ajunge la gazda finală și, probabil, în mod eronat, transmite cererile de ecou ICMP pe ambele rute, astfel încât gazda finală vede două solicitări de ecou și răspunde de două ori.
  • Există două sau mai multe căi (fără rute) către gazda de sfârșit și fiecare cerere este transmisă de mai multe căi.
  • O cutie NAT care funcționează necorespunzător.

Unele teste care pot ajuta includ:

  • Pingeți ruterul de-a lungul rutei pentru a vedea dacă oricare dintre ei răspunde cu dubluri.
  • Captați pachetele ping și căutați să vedeți dacă toate pachetele sunt returnate de pe aceeași adresă Ethernet.

O idee despre prvalența pachetelor duble ping vine de la măsurătorile PingER pe 31 martie 2012 la 703 de gazde în peste 600 de țări. Din aceste gazde 15 au răspuns cu ping-uri duplicate. Pentru 13 din cele 15 gazde a apărut pe ambele 100 și 1000 de octeți. Din 10 ping-uri trimis 6 gazde au avut 1 ping duplicat, 5 au avut 2 ping-uri duplicat, 2 au avut 4 ping duplicat, 1 a avut 3 pings duplicat și 1 returnat 12 ping-uri pentru fiecare ping trimis. Siturile gazdelor variază de la laboratoarele naționale (CERN, IHEP SU), țările dezvoltate (Israel), țările în curs de dezvoltare (Burkina Faso, Malawi, Mauritius, Sierra Leone, Swaziland, Zambia) și site-uri educaționale (SDSC). PingER raportează pur și simplu dacă există duplicate sau nu. O valoare utilă este de a raporta numărul de ping-uri primite / ping-uri trimise. Numărul primit poate depinde de opțiunile de comandă ping. O opțiune va trimite un număr dat de ping-uri până când nu primește acea mulțime de spate sau ori. O altă opțiune va trimite 10 ping-uri și așteptați (sau expirați) până când acestea vor fi primite. Deci, valoarea metrică poate depinde, de asemenea, de comanda ping.Combinarea tuturor măsurilor de pingSe poate compune un grafic al tuturor măsurilor de ping de mai sus (pierdere, răspuns, imposibilitate de accesare și imprevizibilitate) pentru a încerca și a arăta combinația de măsurători pentru un set de gazde pentru o anumită perioadă de timp. Parcela de mai jos pentru perioada 1-11 martie 1997 grupează gazdele în grupuri logice (ESnet, N. America West, …), iar în cadrul grupurilor se situează gazdele cu pierderi de pachete de% 100 octeți pentru SLAC prime time (7am – 7pm în zilele lucrătoare), de asemenea, arătat printr-o linie albastră este timpul de răspuns al timpului ping principal, iar negativul de ping% nereachabilitate și impredictibilitate. 

performanță ping mar96

În graficul de mai sus, timpul de pierdere și de răspuns este măsurat în timpul primei SLAC (7am – 7pm, în zilele lucrătoare), celelalte măsuri sunt pentru totdeauna.

  • Ratele pierderilor sunt reprezentate grafic ca bare deasupra axei y = 0 și sunt pentru pachete ping cu încărcătură de 100 de octeți. Linile orizontale sunt indicate la pierderile de pachete de 1%, 5% și 12% la limitele calităților de conectare definite mai sus.
  • Timpul de răspuns este reprezentat ca o linie albastră pe o axă a jurnalului, etichetat în dreapta și este timpul de deplasare rotundă pentru pachete de 1000 de bilete încărcate ping.
  • Neabordabilitatea gazdei este reprezentată grafic ca un graf de bare care se extinde negativ de la axa y = 0. O gazdă este considerată inaccesibilă la un interval de 30 de minute dacă nu răspunde niciunei dintre cele 21 de ping-uri făcute la acel interval de 30 de minute.
  • Imprevizibilitatea gazdei este reprezentată grafic în verde aici ca o valoare negativă, poate varia de la 0 (total imprevizibilă) la 1 (extrem de previzibilă) și este o măsură a variabilității timpului de răspuns al ping-ului și a pierderii în timpul fiecărei zile de 24 de ore. Acesta este definit în detaliu în Ping Imprevizibilitate .

Următoarele observații sunt de asemenea relevante:

  • Gazdele ESnet au, în general, pierderi de pachete bune (median 0,79%). Pierderile medii de pachete pentru celelalte grupuri variază de la aproximativ 4,5% (N. America de Est) la 7,7% (Internațional). În mod obișnuit, 25% -35% din gazdele din grupurile non-ESnet sunt în intervalul sărac până la rău.
  • Timpul de răspuns pentru gazdele ESnet este de aproximativ 50ms, pentru N. America Wes este de aproximativ 80ms, pentru N. America East aproximativ 150ms și pentru gazde internaționale în jur de 200ms.
  • Majoritatea problemelor de neatins sunt limitate la câțiva gazde, în special în grupul internațional (Dresda, Novosibirsk, Florența).
  • Imprevizibilitatea este cea mai pronunțată pentru câțiva gazde internaționale și urmărește aproximativ pierderea pachetului.

CalitatePentru a putea rezuma datele astfel încât semnificația să poată fi înțeleasă rapid, am încercat să caracterizăm calitatea performanței legăturilor. Unele rapoarte interesante sunt de mai jos:

Mai jos sunt câteva alte măsuri organizate după metrice.

Întârziere

Cea mai rară și mai valoroasă marfă este timpul. Studiile efectuate la sfârșitul anilor 1970 și începutul anilor 1980 de către Walt Doherty de la IBM și altele au arătat valoarea economică a timpului de răspuns rapid:

0-0.4sReactivitate interactivă de înaltă productivitate
0.4-2sRegim complet interactiv
2-12sRegim interactiv sporadic
12s-600sÎntrerupeți regimul de contact
600SModul de dozare

Pentru mai multe informații despre impactul timpilor de răspuns, consultați Psihologia interacțiunii om-calculator , Stuart K. Card, Thomas P. Moran și Allen Newell, ISBN 0-89859-243-7, publicat de Lawrence Erlbaum Associates (1983).

Există un prag în jur de 4-5, în cazul în care reclamațiile cresc rapid. Pentru unele aplicații Internet mai vechi există alte praguri, de exemplu pentru voce un prag pentru o întârziere de un mod apare la aproximativ 150ms (vezi Recomandarea ITU G.114 One-way time transmission , februarie 1996) – sub aceasta se pot obține apeluri de calitate, și dincolo de acest punct, întârzierea determină dificultăți pentru oamenii care încearcă să aibă o conversație și frustrare.

Pentru păstrarea timpului în muzică, cercetătorii de la Stanford au descoperit că valoarea optimă a latenței este de 11 milisecunde. Sub această întârziere și oamenii au tendința de a accelera. De peste această întârziere și au tendința de a încetini. După aproximativ 50 milisecunde (sau 70), performanțele au avut tendința de a se destrăma complet.

Urechea umană percepe sunetele ca fiind simultane numai dacă sunt auzite în decurs de 20 ms una de cealaltă, vezi http://www.mercurynews.com/News/ci_27039996/Music-at-the-speed-of-light-is-researchers-sunt poartă

Pentru măsurarea performanțelor multimedia în timp real (H.323), măsurarea și analiza performanței H.323 Traffic oferă o întârziere într-un singur mod (aproximativ un factor 2 pentru obținerea RTT), de: 0-150ms = Bună, 150-300ms = Acceptabilă și> 300ms = săraci.

SLA pentru one – way țintă latență rețea pentru Cisco TelePresence este sub 150 msec. Aceasta nu include latența indusă de codificare și decodare la punctele finale CTS.

Toate pachetele care cuprind un cadru de video trebuie să fie livrate la punctul final al TelePresence înainte ca tamponul de repetare să fie epuizat. În caz contrar, poate apărea o degradare a calității video. Obiectivul de vârf de vârf pentru vârf pentru Cisco TelePresence este sub 10 ms.

Lucrarea de pe Internet la viteza luminii oferă câteva exemple privind importanța reducerii RTT. Exemplele includ motoarele de căutare precum Google și Bing, vânzările Amazon și bursa de valori

Pentru controlul haptic in timp real si feedback – ul pentru operațiuni medicale, cercetătorii de la Stanford ( a se vedea Shah, A., Harris, D., & Gutierrez, D. (2002). “Performanța de Anatomie de la distanță și aplicații de formare chirurgicale în condiții de rețea diverse.” Lumea Conferința Multimedia Educațional, Hypermedia și Telecomunicații 2002 (1), 662-667 ) a constatat că o întârziere cu o singură cale de <= 80msec. era nevoie.

Harta Internet Vremea identifică la fel de rău orice legătură cu întârzieri de peste 300ms.

Pierderi

Pentru caracterizarea calității ne-am concentrat în special pe pierderile de pachete. Observațiile noastre au fost că mai mult de 4-6% conferințe video de pierdere a pachetelor devin iritante, iar vorbitorii de limbă non-nativă devin incapabili de a comunica. Apariția unor întârzieri prelungite de 4 secunde sau mai mult la o frecvență de 4-5% sau mai mult este, de asemenea, iritantă pentru activitățile interactive cum ar fi ferestrele telnet și X. De mai mult de 10-12% pierderi de pachete există un nivel inacceptabil de pierdere înapoi a pachetelor și perioade extrem de lungi de expirare, conexiunile încep să se rupă și videoconferințele sunt inutilizabile (a se vedea și Problema transmisiei inutile de pachete pentru multimedia prin internet , unde se spune la pagina 10, “concluzionăm că pentru acest flux video calitatea video este incomprehensibilă atunci când ratele de pierdere a pachetelor depășesc 12%” . Pe de altă parte, oficialii MSF (Multi Service Forum) au declarat ca urmare a testelor efectuate asupra rețelelor de generație următoare pentru testarea IPTV au arătat că o jumătate din 1% din pierderea pachetelor dintr-un flux video poate face calitatea video inacceptabilă până la sfârșit utilizatori “(a se vedea Computerworld, 29 octombrie 2008 ).

performanță ping mar96
ping pierderi praguri 1997

Inițial, nivelurile de calitate pentru pierderea pachetelor au fost stabilite la 0-1% = bune, 1-5% = acceptabile, 5-12% = slabe și mai mari de 12% = rele. 
 
 
Mai recent, am rafinat nivelurile la 0-0,1% excelente, 0,1-1% = bune, 1-2,5% = acceptabile, 2,5-5% = sărace, 5% -12% = foarte slabe și mai mari de 12% = rău. Modificarea pragurilor reflectă schimbările în accentul nostru, adică în 1995 am fost în primul rând preocupați de e-mail și ftp. Acest citat de la Vern Paxson rezumă preocuparea principală la momentul respectiv: înțelepciunea convențională printre cercetătorii TCP susține că o rată de pierdere de 5% are un efect negativ semnificativ asupra performanței TCP, deoarece va limita foarte mult dimensiunea ferestrei de congestie și, prin urmare, transfer, în timp ce 3% este adesea considerabil mai puțin gravă. Cu alte cuvinte, comportamentul complex al Internetului are ca rezultat o schimbare semnificativă atunci când pierderea de pachete urcă peste 3%. În anul 2000, am fost, de asemenea, preocupați de aplicațiile X-window, de performanța web și de videoconferințele în pachete. Până în 2005 am fost interesați de cerințele în timp real ale VoIP și începem să ne uităm la voce pe IP. Ca regulă, pierderea de pachete în VoIP (și VoFi) nu trebuie să depășească niciodată 1%, ceea ce înseamnă, în esență, că o singură voce săriți la fiecare trei minute. Algoritmii DSP pot compensa până la 30 ms de date lipsă; mai mult decât atât, și lipsa de audio va fi vizibil pentru ascultători. Analiza rețelei de automobile (ANX) stabilește pragul pentru rata de pierdere a pachetelor (a se vedea Metrici ANX / Auto Linx ) să fie mai mică de 0,1%.

Grupul de lucru ITU TIPHON (vezi Aspecte generale privind calitatea serviciului (QOS) , Raportul tehnic DTR / TIPHON-05001 V1.2.5 (1998-09)) a definit de asemenea <3% pierderi de pachete ca fiind bune,> 15% degradare și de 25% pentru degradarea slabă, pentru telefonia prin Internet. Este foarte greu să dai o singură valoare sub care pierderile de pachete dau o voce interactivă satisfăcătoare / acceptabilă / bună. Există multe alte variabile implicate: întârzierea, jitterul, blocarea pierderii de pachete (PLC), dacă pierderile sunt aleatoare sau sparte, algoritmul de compresie (compresia mai mare utilizează mai puțină lățime de bandă, dar există mai multă sensibilitate la pierderea pachetului, pierdute într-un singur pachet). A se vedea, de exemplu, Raportul privind primul eveniment de testare a calității vocale ETSI VoIP , 21-18 martie 2001, sau Prelucrarea vorbirii, transmisia și aspectele de calitate (STQ); Raport anonim de test din al doilea test al calității vorbelor 2002 ETSI TR 102 251 v1.1.1 (2003-10) sau al celui de-al treilea test ETSI privind calitatea vorbelor, Sumarul evenimentului, Calitatea conversației vocale pentru gateway-urile VoIP și telefonia IP .

Jonathan Rosenberg de la Universitatea Tehnică Lucent și Columbia în G.729 Recuperarea erorilor pentru telefonia prin Internet prezentată la Conferința VON 9/1997 a prezentat următorul tabel care arată relația dintre Scorul mediu de opinie (MOS) și pachetele consecutive pierdute.

Cadrele consecutive au fost pierdute12345
MOS4.23.22.42.11.7

Unde:

evaluareCalitatea vorbiriiNivelul de denaturare
5ExcelentImperceptibil
4BunDoar perceptibil, nu enervant
3echitabilPerceptibil, ușor enervant
2slabEnervant, dar nu înșelător
1NesatisfăcătorFoarte enervant, neplăcut

Dacă pachetele VoIP sunt distanțate de 20msec, atunci o pierdere de 10% (presupunând o repartizare aleatoare a pierderii) este echivalentă cu a vedea 2 cadre consecutive pierdute la fiecare 2 secunde, în timp ce o pierdere de 2,5% este echivalentă cu 2 cadre consecutive fiind pierdute 30 de secunde.

Așadar, am stabilit pierderea pachetului “Acceptabil” la <2,5%. Măsurarea și analiza performanței hârtiei pentru traficul H.323 oferă următoarele pentru VoIP (H.323): Pierdere = 0% -0,5% Bine, = 0,5% -1,5% Acceptabil și> 1,5% = Slab.

Pragurile de mai sus presupun o distribuire plată aleatorie a pachetelor. Cu toate acestea, deseori pierderile vin în explozii. Pentru a cuantifica pierderea consecutivă de pachete, am folosit, printre altele, probabilitatea de pierdere condiționată (CLP) definită în Caracterizarea întârzierii și pierderii de pachete end-to-end în Internet de către J. Bolot în Jurnalul rețelelor de mare viteză, vol. 2, nr. 3 pp 305-323 decembrie 1993 (este disponibil și pe web ). Practic, CLPeste probabilitatea că, dacă se pierde un pachet, se pierde și următorul pachet. Mai mult formal Conditional_loss_probability = Probabilitate (pierdere (pachet n + 1) = adevărată pierdere (pachet n) = adevărată). Printre cauzele unor astfel de explozii se numără timpul de convergență necesar după o schimbare de rutare (10s la 100s de secunde), pierderea și recuperarea sincronizării în rețeaua DSL (10-20 secunde) și reconfigurarea arborelui de pod (~ 30 secunde). Mai multe despre impactul pierderii de pachete explozive pot fi găsite în impactul calității vorbirii asupra pierderilor de pachete aleatoare / împrăștiate de către C. Dvorak, document intern ITU-T. Această lucrare arată că, în timp ce pentru pierderi aleatorii scăderea în MOS este liniară cu pierderea de pachete%, pentru pierderile de spargere căderea este mult mai rapidă. De asemenea, consultați Burstful pierderii pachetului . Scăderea în MOS este de la 5 la 3,25 pentru o modificare a pierderii de pachete de la 0 la 1% și apoi este liniară scăzută la un MOS de aproximativ 2,5 cu o pierdere de 5%.

Alte eforturi de monitorizare pot alege praguri diferite, probabil datorită faptului că sunt implicate în diferite aplicații. Pagina de trafic MCI etichetă link-uri ca verde dacă au pierderi de pachete <5%, roșu dacă> 10% și portocaliu între ele. În Raportul despre vremea pe Internet am colorat <6% pierdere ca verde și> 12% ca roșu, și altfel portocaliu. Deci, ambii sunt mai iertați decât noi sau cel puțin avem mai puțin granularitate. Gary Norton, în World Network Dec. 2000 (p. 40), spune: “Dacă sunt livrate mai mult de 98% din pachete, utilizatorii ar trebui să aibă un timp de răspuns ușor degradat, iar sesiunile nu ar trebui să se oprească”.

frecvență de calitate

Figura de mai jos prezintă distribuția frecvențelor pentru pierderea medie a pachetelor lunare pentru aproximativ 70 de site-uri văzute de SLAC între ianuarie 1995 și noiembrie 1997. 

Datorită cantității mari de predicție comprimată și compensată de mișcare utilizată de codecurile video TelePresence, chiar și o cantitate mică de pierderi de pachete poate duce la degradarea vizibilă a calității video. SLA pentru pachete țintă pierdere pentru Cisco TelePresence ar trebui să fie sub 0,05 procente în rețea.

Pentru controlul haptic în timp real și feedback-ul pentru operațiile medicale, cercetătorii de la Stanford au constatat că pierderea nu a fost un factor critic, iar pierderile de până la 10% ar putea fi tolerate.

Cu toate acestea, pentru transferul de date de înaltă performanță pe distanțe lungi (RTT înalte), așa cum se poate observa în articolul ESnet privind pierderea de pachete , pierderi de 0,0046% (pierdere de 1 pachet în 22000) pe legături de 10Gbps cu MTU setat la 9000Bytes impactul este mai mare cu MTU-urile implicite de 1500Bytes) conduc la factori de 10 reduceri ale debitului pentru RTT> 10msec.

jitter

Grupul de lucru ITU TIPHON (a se vedea raportul tehnic DTR / TIPHON-05001 V1.2.5 (1998-09) privind aspectele generale ale calității serviciului (QoS ) definește patru categorii de degradare a rețelei bazate pe bruiaj într-o singură direcție. Acestea sunt:

Categoria de degradareVârf de vârf
Perfect0 msec.
Bun75 msec.
Mediu125 msec.
slab225 msec.

Investigăm modul în care se pot raporta pragurile de bruiaj într-o singură direcție la măsurătorile de bruiaj ping (triplu sau bidirecțional). Am folosit Surveyor one way măsurătorile de întârziere ( a se vedea mai jos) si a masurat IQRs de unisens întârziere ( a => b și b => o , unde subscript a => b indică nodul de monitorizare este la un și monitorizează un nod la distanță la b ) și diferența de întârziere între pachete ( a => b și J b => a ). Apoi adăugăm cele două întârzieri cu o singură cale pentru timbrele echivalente de timp împreună și derivăm IQR-urile pentru întârzierea declanșării ( a <=> b ) și diferența de întârziere între pachete ( Jo <=> b ). Vizionând o comparație a bruiajului cu două și două căi se poate observa că distribuțiile nu sunt distribuite Gaussian (fiind mai clare și totuși cu cozi mai largi), bruiajul măsurat într-o singură direcție poate fi foarte diferit de cel măsurat în cealaltă direcție și că pentru aceasta cazul în care aproximarea de mai sus pentru călătoria dus-întors IQR funcționează destul de bine (cu acordul de două procente).

Navigarea pe internet și mesajele de poștă electronică sunt destul de rezistente la jitter, dar orice tip de media streaming (voce, video, muzică) este destul de susceptibilă la Jitter. Jitter este un simptom că există o congestie sau o bandă suficientă pentru a gestiona traficul.

Jitterul specifică lungimea tampoanelor de redare a codecului VoIP pentru a preveni supra-sau sub-flux. Un obiectiv ar putea fi specificarea faptului că 95% din variațiile întârzierii pachetelor ar trebui să se situeze în intervalul [-30msec, + 30msec].

Pentru măsurările de performanță în timp real (H.323), măsurarea performanței și analiza H.323 Traficul dă un singur mod: jitter = 0-20ms = Bună, jitter = 20-50ms = acceptabil,> 50ms = slab. Măsurăm bruiajul călătoriei rotunde, care este de aproximativ două ori jitterul pe o singură cale.

Pentru controlul haptic în timp real și feedback-ul pentru operațiile medicale, cercetătorii de la Stanford au descoperit că bruiajul era critic și că au fost necesare jigne de <1msec.

tranzitată

Cerințe de performanță (de la AT & T)

  • 768k – 1.5Mbps: partajarea fotografiilor, descărcarea de muzică, trimiterea prin e-mail, navigarea pe Internet.
  • 3.0Mbps – 6.0Mbps – streaming video, jocuri online, rețele de domiciliu.
  • > 6Mbps – găzduirea de site-uri web, vizionarea TV online, descărcarea de filme.

Iată câteva linii directoare:

  • Următoarele sunt de la Considerațiile de proiectare pentru teleprezenta Cisco pe o arhitectură PIN . Lățimea de bandă utilizată pentru fiecare punct final Cisco TelePresence variază în funcție de factorii care includ modelul implementat, rezoluția video dorită, interoperabilitatea cu sistemele de videoconferințe vechi și dacă este introdusă o intrare video auxiliară de mare viteză sau de joasă viteză pentru camera de documente sau pentru prezentarea diapozitivelor. De exemplu, atunci când se realizează cea mai bună rezoluție video de 1080p cu intrare video și interoperabilitate de mare viteză, cerința privind lățimea de bandă poate atinge 20,4 Mbps pentru un CTS-3000 și CTS-3000 sau 10,8 Mbps pentru un CTS-1000 și CTS-500 .
  • FCC Ghid de bandă largă

folosire

Utilizarea link-ului poate fi citită de la routere prin SNMP MIB-uri (presupunând că cineva are autorizația de a citi astfel de informații). “La o utilizare de aproximativ 90%, o rețea tipică va elimina 2% din pachete, dar aceasta variază. Legăturile de lățime de bandă redusă au o lățime mai mică pentru a gestiona exploziile, frecvent aruncând pachete la o utilizare de doar 80% … link-ul săptămânal. Iată un cod de culoare sugerat:

  • RED: Retrageți pachetul> 2%, nu implementați nicio aplicație nouă.
  • AMBER: Utilizare> 60%. Luați în considerare o actualizare de rețea.
  • VERDE: Utilizare <60%. Acceptabil pentru implementarea noilor aplicații. “

Încetinirea cu viteză mare , Gary Norton, Network Magazine, decembrie 2000. Cele de mai sus nu indică perioada în care se măsoară utilizarea. În altă parte, în articolul lui Norton, el spune că “Capacitatea rețelei … se calculează ca o medie a orelor de afaceri de peste 5 zile lucrătoare”.

“Teoria de așteptare sugerează că variația timpului de deplasare rotundă, o , variază proporțional cu 1 / (1-L) unde L este sarcina curentă a rețelei, 0 <= L <= 1. Dacă un Internet rulează la o capacitate de 50% ne așteptăm ca întârzierea de întoarcere să fluctueze cu un factor de + – 2o sau 4. Când sarcina atinge 80%, ne așteptăm la o variație de 10. ” Internetworking cu TCP / IP, principiu, protocoale și arhitectură , Douglas Comer, Prentice Hall. Acest lucru sugerează că se poate obține o măsură a utilizării prin analizarea variabilității RTT. Nu am validat această sugestie în acest moment.

accesibilitate

Cerința generică Bellcore 929 ( Măsurători fiabile și de calitate pentru sistemele de telecomunicații (RQMS) GR-929-CORE (Wireline), este utilizat în mod activ de către furnizori și furnizori de servicii ca bază pentru furnizarea rapoartelor furnizorilor privind performanța trimestrială măsurată în funcție de obiective. În fiecare an, în urma publicării celui mai recent număr al GR-929-CORE, astfel de obiective revizuite de performanță sunt implementate) indică faptul că miezul rețelei telefonice urmărește o disponibilitate de 99,999%, ceea ce se traduce la mai puțin de 5,3 minute de timp de nefuncționare an. După cum este scris, măsurarea nu include întreruperi mai scurte de 30 de secunde. Acest lucru este destinat comutatoarelor digitale actuale PSTN (cum ar fi Electronic Switching System 5 (5ESS) și Nortel DMS250), utilizând tehnologia ATM de astăzi. Este necesar un sistem public de comutare pentru a limita timpul total de întrerupere pe parcursul unei perioade de 40 de ani la mai puțin de două ore sau mai puțin de trei minute pe an, un număr echivalent cu o disponibilitate de 99. 99,943%. Odată cu convergența datelor și a vocii, aceasta înseamnă că rețelele de date care vor purta mai multe servicii, inclusiv vocea, trebuie să pornească de la o disponibilitate similară sau mai bună sau utilizatorii finali vor fi supărați și frustrați.

Nivelurile de disponibilitate sunt adesea incluse într-un acord privind nivelul serviciilor. Tabelul de mai jos (bazat pe sondajul Cahners In-Stat privind un eșantion de furnizori de servicii de aplicații (ASP)) arată nivelurile de disponibilitate oferite de ASP-uri și nivelurile alese de clienți.

Niveluri oferiteAleasă de client
Mai puțin de 99%26%19%
99% disponibilitate39%24%
Disponibilitate 99,9%24%15%
Disponibilitate 99,99%15%5%
Disponibilitate 99,999%18%5%
Mai mult de 99,999% disponibilitate13%15%
Nu știu13%18%
Media ponderată a disponibilității oferite99,5%99,4%

Pentru mai multe informații despre disponibilitate, vă rugăm să consultați: Cartea albă Cisco privind disponibilitatea permanentă pentru rețelele multiservice de transport pentru modul în care Cisco se străduiește să obțină o disponibilitate ridicată în rețelele de date; O taxonomie modernă de înaltă disponibilitate ; și documentul IETF RFC 2498: Metri IPPM pentru măsurarea conectivității .

Directivitate

Limitele teoretice ale Directivității sunt că trebuie să fie ≥ 0 și ≤ 1. O valoare de 1 indică faptul că traseul este un traseu de cerc mare și singura întârziere se datorează vitezei luminii din fibre sau electronilor din cupru. Valorile> 1 indică, de obicei, sursa sau destinația sau ambele au locații incorecte și astfel direcționarea este un diagnostic util pentru locațiile gazdă. Valorile tipice ale directivității între siturile de cercetare și cele de învățământ din SUA, Canada, Europa, Asia de Est și Australia / Noua Zeelandă variază de la 0,15 – 0,75, cu o valoare medie de aproximativ 0,4. Aceasta corespunde aproximativ 4 ori mai lent decât viteza luminii în vid. Valorile scăzute ale directivității înseamnă în mod obișnuit o rută foarte indirectă sau conexiune prin satelit sau lent (de exemplu, fără fir) 

Directivitatea internațională (983KB)

GrupareaDeoarece numărul de perechi de gazde monitorizate a crescut, devine din ce în ce mai necesar ca datele să fie agregate în grupuri care reprezintă zone de interes. Am găsit următoarele categorii de grupuri pentru a fi utile:

  • pe domenii (de exemplu, America de Nord, Europa de Vest, Japonia, Asia, țară, domeniu de nivel superior);
  • prin separarea perechilor gazdă (de exemplu, legăturile trans-oceanice, legăturile intercontinentale, punctele de acces la internet );
  • Rețeaua de servicii furnizor de rețea la care este conectat site-ul la distanță (de exemplu , ESnet , Internet 2 , DANTE …);
  • (de exemplu , XIWT , HENP , colaborarea cu experimente, cum ar fi BaBar , Laboratoarele naționale europene sau DOE, interesele programului ESnet , perfSONAR )
  • prin monitorizarea site-ului;
  • un site îndepărtat văzut de pe multe site-uri de monitorizare. Trebuie să putem selecta grupurile prin monitorizarea site-urilor și a site-urilor la distanță. De asemenea, avem nevoie de capacitatea de a include toți membrii unui grup, de a se alătura grupurilor și de a exclude membrii unui grup.

Unele exemple despre câte perechi de ~ 1100 de perechi de monitor-gazdă PingER au fost în grupurile de zone globale și grupurile de afinitate pot fi găsite în distribuțiile de grupuri de perechi PingER .

Istoricul răspunsurilor pentru grupuri de site-uri (39872 octeți)
Istoricul pierderilor pentru grupuri de site-uri (37966 octeți)

În același timp, este esențial să alegeți cu atenție site-urile și perechile gazdă cu atenție, astfel încât acestea să fie reprezentative pentru informațiile pe care se speră să le aflați. Prin urmare, am selectat un set de aproximativ 50 de “site-uri de baliză” care sunt monitorizate de toate site-urile de monitorizare și care sunt reprezentative pentru diferitele grupuri de afinitate de care suntem interesați. Un exemplu de grafic prezentând timpii de răspuns ping pentru grupurile de site- : 
  
Procentele afișate în dreapta legendei diagramei pierdute cu pachete sunt îmbunătățirile (reducerea pierderii de pachete) pe lună pentru ca linia de trend exponențială să se potrivească datelor de pierdere a pachetelor. Rețineți că îmbunătățirea cu 5% / lună echivalează cu o îmbunătățire de 44% / an (de exemplu, o pierdere de 10% ar scădea la 5,6% pe an).Măsurări pe o singură caleSLAC colaborează, de asemenea, la proiectul perfSONAR pentru a efectua măsurări de întârziere și pierdere într-o singură direcție între site-urile perfSONAR. Fiecare site perfSONAT are un punct de măsurare compus dintr-un calculator conectat la Internet cu un receptor GPS. Acest lucru permite ștampilarea precisă a timpului de sincronizare a pachetelor, ceea ce permite măsurătorile cu întârziere unică. Estimările de întârziere generate sunt mai detaliate decât cele ale PingER și clarifică asimetria pe căile de internet în cele două direcții. Pentru mai multe despre compararea celor două metode, consultați Comparația dintre PingER și Surveyor .

RIPE are, de asemenea, un proiect de testare a traficului pentru a efectua măsurători independente ale parametrilor de conectivitate, cum ar fi întârzierile și vectorii de rutare în Internet. O gazdă RIPE este instalată la SLAC.

Programul de măsurare activă NLANR (AMP) pentru participanții HPC are scopul de a îmbunătăți înțelegerea modului în care rețelele de performanță ridicată funcționează așa cum văd site-urile și utilizatorii participanți și de a ajuta la diagnosticarea problemelor atât pentru utilizatorii rețelei, cât și pentru furnizorii săi. Acestea instalează o mașină FreeBSD cu rafturi care se montează în locații și realizează măsurători ping active între mașinile lor, iar ping-urile sunt lansate la intervale de aproximativ 1 minut. O mașină AMP este instalată la SLAC.

Comparațiile mai detaliate ale Surveyor, RIPE, PingER și AMP pot fi găsite la Compararea anumitor proiecte Internet Active End-to-End Measurement Performance .

SLAC este, de asemenea, un site NIMI (Infrastructură națională de măsurare a internetului). Acest proiect poate fi considerat ca fiind complementar proiectului Surveyor, prin faptul că acesta (NIMI) se concentrează mai mult pe asigurarea infrastructurii pentru a sprijini numeroase metodologii de măsurare, cum ar fi ping-urile într-o singură direcție, TReno, traceroute, PingER etc.

Universitatea Waikato din Noua Zeelandă desfășoară, de asemenea, gazde Linux, fiecare având un receptor GPS și efectuând măsurători cu întârziere într-un singur mod. Pentru mai multe detalii, consultați pagina de constatări de întârziere a lui Waikato . Spre deosebire de proiectele AMP, RIPE și Surveyor, proiectul Waikato realizează măsurători pasive ale traficului normal între perechi existente, folosind semnăturile de pachete bazate pe CRC pentru a identifica pachetele înregistrate la cele două capete.

Intepatura pe bază de TCP instrument de măsurare a rețelei este capabil să măsoare în mod activ pierderea de pachete atât înainte și căile între perechile de gazde inversă. Are avantajul de a nu necesita un GPS și de a nu fi supus limitării sau blocării ratei ICMP (conform unui studiu ISI ~ 61% din gazdele de pe Internet nu răspund la ping-uri), cu toate acestea nu necesită o mică modificare a kernel-ului .

Dacă este cunoscută întârzierea unică ( D ) pentru ambele direcții ale unei perechi de noduri de internet ( a, b ), întârzierea R poate fi calculată după cum urmează: 
R = D a => b + D b => a
unde a => b este întârzierea unică măsurată de la nodul a la nodul b și invers. 
Cele doua modalitate de pierdere de pachete P poate fi derivată de la un singur sens pierderile ( p ) după cum urmează: 
P = p a => b + p b => a – p a => b * p b => o
unde a => b este pierderea unui pachet de la nodul a la b și invers.Există câteva RFC-uri IETF legate de măsurarea întârzierii și pierderii într- o singură direcție , precum și de o metrică întârziere de întoarcere .

traceroute

Un alt instrument foarte puternic pentru diagnosticarea problemelor de rețea este traceroute . Acest lucru permite identificarea numărului de hamei într-un loc izolat și cât de bine funcționează traseul.

John MacAllister de la Oxford a elaborat statistici de monitorizare a traseului traseului pe baza utilităților standard traceroute și ping. Statisticile au fost colectate la intervale regulate pentru perioade de 24 de ore și au furnizat informații despre configurația de rutare, calitatea traseului și stabilitatea traseului.

TRIUMF are, de asemenea, un foarte frumos instrument Traceroute Map care arată o hartă a rutelor de la TRIUMF către multe alte site-uri. Încercăm să oferim o simplificare a acestor hărți pentru a utiliza mai degrabă sistemele autonome (AS) decât router-ele.

Se poate calcula , de asemenea, viteza de transmitere a FTP versus numărul de melodii traceroute , precum și răspunsul ping și pierderea pachetelor pentru a căuta corelații.

Există multe site-uri care rulează serverele traceroute ( este disponibil codul sursă (în Perl)) care ajută la depanarea și la înțelegerea topologiei internetului.

Unele site-uri oferă acces la utilitare de rețea, cum ar fi nslookup, pentru a permite unui utilizator să afle mai multe despre un anumit nod. Câteva exemple sunt SLAC și TRIUMF .

Impactul rutei asupra performanței de la Internet la sfârșit

Glosar

  • DSCP Servicii Differentiate CodePoint. Codul de servicii diferențiat este de 6 biți în câmpul antet IP care sunt folosite pentru a selecta comportamentul per-hop al unui pachet. Cele 6 biți pentru DSCP și 2 biți neutilizate sunt destinate să înlocuiască definițiile existente ale octetului TOS IPv4, a se vedea RFC 2474 pentru mai multe detalii.
  • Unitatea de transfer maximă MTU . Unitatea de transfer maximă este cea mai mare dimensiune a datagramei IP care poate fi transferată utilizând o conexiune de date specifică.
  • Dimensiunea maximă a segmentului MSS . MTU-40.
  • QBSS QBone Scavenger Services. QBone Scavenger Services este o clasă suplimentară de servicii cu cele mai bune eforturi. O cantitate mică de capacitate a rețelei este alocată (într-un mod ne-rigid) pentru acest serviciu; atunci când capacitatea de efort maxim de efort implicit este subutilizată, QBSS se poate extinde pentru a consuma capacitatea neutilizată.
  • Fereastra de primire (Rwin) Dimensiunea buffer-ului TCP, numărul de pachete pe care mașina dvs. le va trimite fără a primi un ACK.

Informatii suplimentare


cron Un cronjob numește scripturile corespunzătoare. La SLAC acest cronjob este în pinger@pinger.slac.stanford.edu/.trs/crontab. Pentru PingER1 scriptul este numit timeping.pl, pentru PingER2 se numește pinger2.pl . La SLAC, scripturile PingER sunt toate în Perl și dacă nu se specifică altfel în calea / afs / slac / package / netmon / pinger / 
gather Datele sunt adunate la SLAC de scriptul getdata.pl care utilizează Lynx pentru a obține datele de la CGI ping_data.pl scriptul la fiecare locmonitorizare. Getdata.pl se numește zilnic pentru a aduna datele pe site-ul de arhivare SLAC. Se cheamă din același cronjob ca și callping.pl (vezi mai sus). 
analizăInformații despre lanțul de analiză a scripturilor pot fi găsite în: “Restaurarea datelor istorice” care explică întregul lanț de analiză. 
pingtable Mecanismul principal de raportare este prin intermediul scriptului pingtable.pl pe care la SLAC este stocat în calea CGI PingER / afs / slac / g / www / cgi-wrap-bin / net / offsite_mon / pinghistory /.138 Vizualizări De Pagină07 Februarie – 07 MartieFeedback | Probleme de raportare ] 
Cottrell