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वाँ प्रतिशतक, सबसे खराब स्थिति, हानि, और उन पैकेटों की संख्या जो समय सीमा की अनुमति से देर से पहुँचे। रीयल-टाइम कार्यभार के लिए औसत इन संख्याओं में सबसे कम उपयोगी है, क्योंकि चिकना औसत ऐसी पूंछ छिपा सकता है जो हर तीसरी कॉल बिगाड़ देती है।
विलंब की भिन्नता सीधे प्राप्तकर्ता के बफ़र को खिलाती है। अधिक बफ़रिंग भिन्नता छिपाती है और प्रतीक्षा जोड़ती है, इसलिए स्ट्रीम अपनी समय सीमा पार करते हुए भी स्थिर दिख सकती है। भिन्नता के लिए एक सूत्र चुनें, जिस अंतराल पर आपने मापा उसे बताएं, और रनों के बीच उसे एक समान रखें।
प्रतिनिधि क्रॉस-ट्रैफ़िक के साथ रन दोहराएं। जो पथ निष्क्रिय रहने पर बजट पूरा करता है और बैकअप विंडो के दौरान उसे चूक जाता है, उसने आपको शेड्यूलिंग के बारे में कुछ उपयोगी बताया है, जो कोई भी अकेला शांत माप प्रकट नहीं करता। परिणाम के बगल में परिस्थितियाँ दर्ज करें, वरना अगला इंजीनियर ऐसे दो नमूनों की तुलना करेगा जो कभी तुलनीय नहीं थे।
डिज़ाइन तब स्वीकार करें जब मापी गई पूंछ उस कार्यभार के तहत बजट में फ़िट हो जिसे आप वास्तव में चलाते हैं, और रिपोर्ट में जिस चरण ने सीमा पार की उसका नाम देकर उसे अस्वीकार करें।