Estableix un pressupost de retard per al trànsit en temps real per VPN
Partiu del termini que l’aplicació ha de complir i mesureu el retard d’anada i el jitter en condicions declarades. Una mitjana sense llindar de retard no demostra res.
Les queixes sobre VPN en temps real necessiten un termini contra el qual fallar, i «baixa latència» no és cap termini. Decidiu què ha de lliurar la conversa o la sessió remota i, després, mesureu el camí contra aquest requisit en condicions declarades. Sense un llindar de paquets tardans, qualsevol resultat és discutible. L’assignació de sota és una decisió de disseny i existeix perquè el mesurament tingui alguna cosa a què respondre.
Escriviu el termini abans de tocar cap sonda
El termini ve de l’aplicació i dels seus usuaris, no de la pàgina de màrqueting d’un proveïdor. Una trucada de veu en directe, una sessió d’escriptori remot i una còpia de seguretat nocturna toleren temps d’espera completament diferents, i la fallada que importa sol ser la cua i no la mediana. Escriviu el número amb la càrrega de treball a què pertany.
Aleshores repartiu-lo. La captura i la paquetització consumeixen part del pressupost, l’enllaç d’accés i el túnel en consumeixen una altra part, el búfer de des-jitter del receptor reté paquets a propòsit i el processament de l’aplicació pren la resta. Anomenar aquestes etapes manté el xifratge del túnel en proporció en lloc de convertir-lo en el sospitós per defecte de cada paquet lent.
Finalment definiu el contracte de mesurament en quatre línies: extrems i direcció, forma del trànsit, condicions durant l’execució i el resultat que informareu. Una mostra d’un diumenge tranquil i una de dimarts carregat responen a preguntes diferents, així que digueu quina heu recollit. Si no podeu omplir les quatre línies, l’execució no està a punt per començar. Aquesta llista de comprovació és també el que fa comparables dos informes mesos després, quan ja ningú no recorda què més portava l’enllaç.
Repartiu el pressupost entre cada etapa
La taula és una ajuda de planificació, no dades recollides. Ompliu el propietari de cada fila abans de la primera sonda, perquè el propietari és qui truqueu quan aquella etapa supera la seva part.
| Stage | What it contributes | Who owns it |
|---|---|---|
| Capture and packetization | Encoder frame size, aggregation | Application owner |
| Tunnel and transit | Encryption, queueing, path length | Network owner |
| Receiver buffer | Deliberate waiting to absorb variation | Application owner |
| Application processing | Decode and render time | Application owner |
Dues files solen sorprendre la gent. El búfer del receptor no és cap defecte quan afegeix retard, perquè fa la feina per a la qual es va configurar. I la part del túnel sovint és més petita que la cua que té al davant, sobretot en un enllaç de pujada que se satura durant les càrregues.
Quan una etapa no té propietari, el pressupost és ficció. Assigneu-ne un abans de mesurar, o passareu la reunió següent discutint quin número és el dolent.
Mesureu el retard d’anada amb un rellotge honest
El retard d’anada és el número que importa al termini, i necessita rellotges sincronitzats als dos extrems. La mètrica de retard d’anada us exigeix informar del mètode de sincronització, la resolució i el desviament estimat al costat del resultat. Dos amfitrions no sincronitzats poden produir un número molt precís per a la quantitat equivocada.
Captureu uns quants cents de paquets en lloc d’un grapat i anoteu l’estat del rellotge al mateix temps:
$ ntpq -p
$ owping -c 300 -i 0.2 10.90.0.1
$ ping -c 200 -i 0.2 10.90.0.1 | tail -n 3El temps d’anada i tornada és un mesurament a part, no dos valors d’anada sumats. Dividir un RTT per la meitat assumeix camins simètrics i cues simètriques, i un túnel sobre un enllaç mòbil de pujada trenca aquestes dues suposicions habitualment. Informeu l’RTT com a RTT i manteniu-lo fora del pressupost d’anada.
Informeu de la cua i dels paquets tardans
Resumiu la distribució: mediana, percentil 95 i 99, pitjor cas, pèrdua i el nombre de paquets que van arribar més tard del que el termini permet. La mitjana és el menys útil d’aquests números per a una càrrega en temps real, perquè una mitjana suau pot amagar una cua que arruïna cada tercera trucada.
La variació del retard alimenta directament el búfer del receptor. Més búfer amaga la variació i afegeix espera, així que un flux pot semblar estable mentre supera el seu termini. Trieu una formulació de la variació, indiqueu l’interval sobre el qual heu mesurat i manteniu-la coherent entre execucions.
Repetiu l’execució amb trànsit creuat representatiu. Un camí que compleix el pressupost quan està inactiu i el incompleix durant una finestra de còpia de seguretat us ha dit una cosa útil sobre la planificació, que cap mesurament tranquil aïllat revelaria. Anoteu les condicions al costat del resultat, perquè el proper enginyer, si no, compararà dues mostres que mai no van ser comparables.
Accepteu el disseny quan la cua mesurada encaixi en el pressupost sota la càrrega de treball que realment executeu, i rebutgeu-lo amb l’etapa que s’ha excedit anomenada a l’informe.