VPN ద్వారా నిజ-సమయ ట్రాఫిక్ కోసం ఆలస్య బడ్జెట్ను సెట్ చేయండి
యాప్ చేరుకోవాల్సిన గడువు నుంచి ప్రారంభించి, పేర్కొన్న పరిస్థితుల్లో ఒక-దిశ ఆలస్యం మరియు జిట్టర్ను కొలవండి. ఆలస్య ప్యాకెట్లకు థ్రెషోల్డ్ లేని సగటు ఏమీ నిరూపించదు.
నిజ-సమయ VPN ఫిర్యాదులకు ఓడిపోవడానికి ఒక గడువు అవసరం, „తక్కువ ఆలస్యం“ అలాంటిది కాదు. సంభాషణ లేదా రిమోట్ సెషన్ ఏమి అందించాలో నిర్ణయించి, పేర్కొన్న పరిస్థితుల్లో ఆ అవసరానికి వ్యతిరేకంగా మార్గాన్ని కొలవండి. ఆలస్య ప్యాకెట్ థ్రెషోల్డ్ లేకుండా, ప్రతి ఫలితం వాదనాస్పదం. క్రింది కేటాయింపు ఒక డిజైన్ నిర్ణయం, కొలతకు సమాధానం చెప్పడానికి ఏదో ఉండాలనే ఉద్దేశంతో అది ఉంది.
ప్రోబ్ను తాకే ముందు గడువును రాయండి
గడువు అప్లికేషన్ నుంచి మరియు దాని వినియోగదారుల నుంచి వస్తుంది, విక్రేత మార్కెటింగ్ పేజీ నుంచి కాదు. ప్రత్యక్ష వాయిస్ కాల్, రిమోట్ డెస్క్టాప్ సెషన్ మరియు రాత్రి బ్యాకప్ పూర్తిగా భిన్నమైన నిరీక్షణ సమయాలను భరిస్తాయి, మరియు ముఖ్యమైన వైఫల్యం సాధారణంగా మధ్యస్థం కాదు, తోక. ఆ సంఖ్యను అది చెందిన పనిభారంతో పాటు రాయండి.
తర్వాత దాన్ని కేటాయించండి. క్యాప్చర్ మరియు ప్యాకెటైజేషన్ బడ్జెట్లో ఒక భాగం తీసుకుంటాయి, యాక్సెస్ లింక్ మరియు టన్నెల్ మరో భాగం తీసుకుంటాయి, రిసీవర్ జిట్టర్ బఫర్ ప్యాకెట్లను ఉద్దేశపూర్వకంగా నిలుపుతుంది, అప్లికేషన్ ప్రాసెసింగ్ మిగిలినది తీసుకుంటుంది. ఆ దశలకు పేరు పెట్టడం టన్నెల్ ఎన్క్రిప్షన్ను నిష్పత్తిలో ఉంచుతుంది, ప్రతి నెమ్మదైన ప్యాకెట్కు దాన్ని డిఫాల్ట్ అనుమానితుడిగా చేయకుండా.
చివరగా కొలత ఒప్పందాన్ని నాలుగు వరుసల్లో నిర్వచించండి: చివరలు మరియు దిశ, ట్రాఫిక్ రూపం, నిర్వహణ సమయంలో పరిస్థితులు, మరియు మీరు నివేదించే ఫలితం. ప్రశాంతమైన ఆదివారం నమూనా మరియు భారంగా ఉన్న మంగళవారం నమూనా వేర్వేరు ప్రశ్నలకు సమాధానం ఇస్తాయి, కాబట్టి మీరు ఏది సేకరించారో చెప్పండి. నాలుగు వరుసలను నింపలేకపోతే, నిర్వహణ ప్రారంభించడానికి సిద్ధంగా లేదు. ఆ జాబితా కూడా రెండు నివేదికలను నెలల తర్వాత పోల్చగలిగేలా చేస్తుంది, లింక్ ఇంకా ఏమి మోసిందో ఎవరికీ గుర్తులేనప్పుడు.
ప్రతి దశలో బడ్జెట్ను విభజించండి
పట్టిక ప్రణాళిక సహాయం, సేకరించిన డేటా కాదు. మొదటి ప్రోబ్కు ముందు ప్రతి వరుసకు యజమానిని నింపండి, ఎందుకంటే ఆ దశ తన వాటాను మించినప్పుడు మీరు కాల్ చేసేది యజమానినే.
| 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 |
రెండు వరుసలు సాధారణంగా ప్రజలను ఆశ్చర్యపరుస్తాయి. రిసీవర్ బఫర్ ఆలస్యాన్ని జోడించినప్పుడు అది లోపం కాదు, ఎందుకంటే అది ఉద్దేశించిన పనినే చేస్తోంది. మరియు టన్నెల్ వాటా తరచుగా దాని ముందున్న క్యూ కంటే చిన్నది, ముఖ్యంగా అప్లోడ్ల సమయంలో నిండిపోయే అప్లింక్లో.
ఒక దశకు యజమాని లేకపోతే, బడ్జెట్ కల్పన. కొలిచే ముందు ఒకరిని నియమించండి, లేదంటే తర్వాతి సమావేశాన్ని ఎవరి సంఖ్య తప్పు అని వాదించడంలో గడుపుతారు.
నిజాయితీ గడియారంతో ఒక-దిశ ఆలస్యాన్ని కొలవండి
ఒక-దిశ ఆలస్యం గడువు పట్టించుకునే సంఖ్య, దానికి రెండు చివరలా సమకాలీకరించిన గడియారాలు అవసరం. ఒక-దిశ ఆలస్య మెట్రిక్ ఫలితంతో పాటు సమకాలీకరణ పద్ధతి, రిజల్యూషన్ మరియు అంచనా వ్యత్యాసాన్ని నివేదించమని కోరుతుంది. సమకాలీకరించని రెండు హోస్ట్లు తప్పు పరిమాణానికి చాలా కచ్చితమైన సంఖ్యను ఇవ్వగలవు.
పిడికెడు బదులు కొన్ని వందల ప్యాకెట్లను సేకరించి, అదే సమయంలో గడియార స్థితిని నమోదు చేయండి:
$ ntpq -p
$ owping -c 300 -i 0.2 10.90.0.1
$ ping -c 200 -i 0.2 10.90.0.1 | tail -n 3
రౌండ్-ట్రిప్ సమయం ప్రత్యేక కొలత, రెండు ఒక-దిశ విలువలను కలిపినది కాదు. RTTని సగానికి తగ్గించడం సమరూప మార్గాలు మరియు సమరూప క్యూలను ఊహిస్తుంది, మొబైల్ అప్లింక్పై టన్నెల్ రెండు ఊహలను సాధారణంగా బద్దలు కొడుతుంది. RTTని RTTగానే నివేదించి, ఒక-దిశ బడ్జెట్కు బయట ఉంచండి.
తోక మరియు ఆలస్య ప్యాకెట్లను నివేదించండి
పంపిణీని సంగ్రహించండి: మధ్యస్థం, 95 మరియు 99వ శాతం, అత్యంత దురవస్థ, నష్టం, మరియు గడువు అనుమతించిన దానికంటే ఆలస్యంగా చేరిన ప్యాకెట్ల సంఖ్య. నిజ-సమయ పనిభారానికి ఆ సంఖ్యల్లో సగటు అతి తక్కువ ఉపయోగం, ఎందుకంటే మృదువైన సగటు ప్రతి మూడవ కాల్ను నాశనం చేసే తోకను దాచగలదు.
ఆలస్య భేదం నేరుగా రిసీవర్ బఫరింగ్లోకి వెళ్తుంది. ఎక్కువ బఫరింగ్ భేదాన్ని దాచి నిరీక్షణను జోడిస్తుంది, కాబట్టి ఒక స్ట్రీమ్ తన గడువును మించుతూనే స్థిరంగా కనిపించగలదు. భేద సూత్రాన్ని ఎంచుకోండి, మీరు కొలిచిన అంతరాన్ని చెప్పండి, మరియు దాన్ని నిర్వహణల మధ్య స్థిరంగా ఉంచండి.
ప్రాతినిధ్య క్రాస్-ట్రాఫిక్తో నిర్వహణను పునరావృతం చేయండి. ఖాళీగా ఉన్నప్పుడు బడ్జెట్ను చేరి బ్యాకప్ విండో సమయంలో దాన్ని కోల్పోయే మార్గం షెడ్యూలింగ్ గురించి ఉపయోగకరమైనది చెప్పింది, దాన్ని ఏ ఒక్క ప్రశాంత కొలత వెల్లడించదు. ఫలితం పక్కన పరిస్థితులను నమోదు చేయండి, లేదంటే తర్వాతి ఇంజనీర్ ఎప్పుడూ పోల్చలేని రెండు నమూనాలను పోలుస్తారు.
మీరు నిజంగా నడిపే పనిభారంలో కొలిచిన తోక బడ్జెట్లో సరిపోయినప్పుడు డిజైన్ను అంగీకరించండి, మించిన దశను నివేదికలో పేర్కొని తిరస్కరించండి.