बैंडविड्थ, थ्रूपुट, विलंबता और जिटर समझें

क्षमता, मापी गई स्थानांतरण दर, देरी और देरी का बदलाव अलग प्रश्नों के उत्तर हैं। बफ़रिंग के लिए एक संख्या को दोष देने से पहले पूरी नेटवर्क तुलना समझें।

संक्षेप में: बैंडविड्थ उपलब्ध या नाममात्र क्षमता की अवधारणा है; थ्रूपुट किसी खास परीक्षण में मापी गई उपयोगी दर है। विलंबता देरी है, जबकि जिटर बताई गई विधि के अंतर्गत देरी में बदलाव बताता है। पैकेट लॉस फिर अलग बात है। वीडियो इनमें से एक या कई से प्रभावित हो सकता है, इसलिए किसी संख्या का अर्थ निकालने से पहले विधि और रास्ता दर्ज करें।

हर मापदंड केवल आंशिक तस्वीर देता है। समान इकाई वाले दो परीक्षण भी अलग एंडपॉइंट, प्रोटोकॉल, दिशाएँ, अवधियाँ, रास्ते या ट्रैफ़िक परिस्थितियाँ माप सकते हैं।

बैंडविड्थ वास्तव में पहुँचे डेटा का परिणाम नहीं है

लोग अक्सर बैंडविड्थ को गति का संक्षिप्त नाम मानते हैं, लेकिन क्षमता का लेबल यह नहीं बताता कि किसी अवधि में ऐप का कितना डेटा पहुँचा। साझा लिंक, प्रोटोकॉल का अतिरिक्त डेटा, भीड़, रेडियो की परिस्थितियाँ, उपकरण की सीमाएँ और दूरस्थ एंडपॉइंट देखे गए थ्रूपुट को घटा सकते हैं।

इसलिए प्लान की दर, वाई-फ़ाई लिंक दर, ईथरनेट लेबल और ऐप का थ्रूपुट अलग मान हैं। किसी दूसरे से तुलना करने से पहले लिखें कि स्क्रीन कौन-सा मान दिखा रही है।

थ्रूपुट के लिए परीक्षण का संदर्भ चाहिए

थ्रूपुट मापी गई डेटा स्थानांतरण दर है। RFC 6349 TCP थ्रूपुट परीक्षण का ढाँचा बताता है और परीक्षण विधि पर ज़ोर देता है। परिणाम के साथ उसका एंडपॉइंट, दिशा, प्रोटोकॉल, अवधि, कनेक्शनों की संख्या, उपकरण, रास्ता और समय होना चाहिए।

घरेलू नेटवर्क की बुनियादी बातों का मार्गदर्शक (अंग्रेज़ी में) उपकरण से स्रोत तक का रास्ता दिखाता है। पास का परीक्षण सर्वर हर अधिकृत स्रोत के रास्ते को दोहराता नहीं है, और क्षणिक शिखर को ऐप के लगातार प्रदर्शन की तरह नहीं दिखाना चाहिए।

विलंबता लगने वाली देरी है

विलंबता बताती है कि डेटा या उत्तर को मापे गए रास्ते से जाने में कितना समय लगता है। RFC 7679 की विधि में एकतरफ़ा देरी के लिए घड़ियों का समकालिक होना और समय मापन की अनिश्चितता का हिसाब ज़रूरी है; कई उपभोक्ता उपकरण इसके बजाय आने-जाने की कुल देरी बताते हैं। ये परिणाम एक-दूसरे के स्थान पर इस्तेमाल नहीं किए जा सकते।

वीडियो शुरू होना, नियंत्रण, प्रमाणीकरण और सेगमेंट अनुरोध अलग कारणों से तुरंत प्रतिक्रिया वाले या धीमे लग सकते हैं। अधिक थ्रूपुट का परिणाम अपने-आप कम विलंबता नहीं बताता।

जिटर बदलाव है, केवल धीमापन नहीं

RFC 3393 पैकेट की देरी में बदलाव के मापदंड परिभाषित करता है। रोज़मर्रा के उपकरणों में “जिटर” अलग गणना, दिशा, अवधि या सांख्यिकीय मान इस्तेमाल कर सकता है। मानों की तुलना से पहले उपकरण की परिभाषा पढ़ें।

कनेक्शन का औसत थ्रूपुट पर्याप्त होकर भी पैकेट अनियमित रूप से आ सकते हैं, या देरी स्थिर होकर भी लगातार थ्रूपुट अपर्याप्त हो सकता है। लगातार 80 ms की आने-जाने की देरी और 20 तथा 140 ms के बीच बारी-बारी बदलती देरी का औसत समान हो सकता है, जबकि व्यवहार अलग होता है। यह उदाहरण बदलाव बताता है, जिटर का सूत्र या स्वीकार्य सीमा नहीं।

पैकेट लॉस एक और पहलू है

RFC 7680 स्पष्ट विधि के साथ एकतरफ़ा पैकेट लॉस मापदंड परिभाषित करता है। उपभोक्ता परिणाम इसके बजाय गायब उत्तरों से लॉस का अनुमान लगा सकते हैं, और कुछ उपकरण निदान वाले ट्रैफ़िक को कम प्राथमिकता दे सकते हैं। शून्य का परिणाम यह साबित नहीं करता कि ऐप का हर पैकेट पहुँचा; शून्य से अलग परिणाम में दोहराव और दायरा जाँचना ज़रूरी है।

अपने नोट में गायब पैकेट और देर से आए पैकेट अलग रखें। प्लेबैक रुकना दिखाई देने वाला लक्षण है, पैकेट स्तर का निदान नहीं।

मौलिक साक्ष्य: मापदंडों का शब्दकोश

हर मान के साथ इकाई लिखें और जहाँ निजता अनुमति दे वहाँ मूल परिणाम बचाएँ।

हल किया हुआ उदाहरण: तेज़ प्लान और अस्थिर शाम

ये शिक्षण के लिए काल्पनिक परिणाम हैं, Norva या किसी स्रोत का परीक्षण नहीं। किसी घर का प्लान 100 Mbps लेबल वाला है। उसी लैपटॉप को वाई-फ़ाई की उसी जगह पर, पास के उसी एंडपॉइंट के साथ, समान डाउनलोड सेटिंग से जाँचा जाता है; हर समय-खिड़की में 30 सेकंड के तीन परीक्षण होते हैं।

उचित अगला कदम लक्षण आने के समय दोहराना है; समर्थन मिलने पर वैकल्पिक रूप से केवल स्थानीय कनेक्शन को ईथरनेट में बदल सकते हैं। इसका अर्थ तुरंत तेज़ प्लान खरीदना नहीं है। 14 Mbps वाला नमूना भी यह स्थापित नहीं करता कि वीडियो चलना चाहिए या नहीं: संस्करण की वास्तविक ज़रूरतें, छोटी गिरावटें, स्रोत का रास्ता और बफ़रिंग व्यवहार अज्ञात हैं।

Mbps (मेगाबिट प्रति सेकंड) और MB/s (मेगाबाइट प्रति सेकंड) अलग रखें: मापन में अतिरिक्त डेटा की परिभाषा का हिसाब लगाने से पहले 8 Mbps बराबर 1 MB/s होता है। मिलीसेकंड समय बताते हैं, डेटा दर नहीं। इन इकाइयों की तुलना ऐसे नहीं की जा सकती जैसे बड़ा अंक हमेशा बेहतर कनेक्शन हो।

मापन का छोटा समूह बनाएँ

प्रभावित उपकरण को उसकी सामान्य जगह पर इस्तेमाल करें। कम व्यस्त समय में अंतराल देकर तीन नमूने और लक्षण वाले समय में तीन नमूने दर्ज करें। सुरक्षित और समर्थित होने पर एंडपॉइंट या परीक्षण सेटिंग बदले बिना एक वैकल्पिक स्थानीय लिंक पर दोहराएँ।

फिर सबसे अच्छा अंक चुनने के बजाय मध्यिका, सीमा और दोहराव की तुलना करें। एक साथ हो रहे अपलोड, मेश बदलाव, उपकरण की पावर स्थिति और मौसम केवल सीधे देखे जाने पर नोट करें; संयोग से हुई घटनाओं के आसपास कारण की कहानी न बनाएँ।

मापदंडों के मेल का अर्थ समझें

कम लगातार थ्रूपुट प्लेबैक बफ़र खाली कर सकता है। छोटी अवधि की औसत दर पर्याप्त दिखने पर भी देरी का बदलाव और लॉस डेटा वितरण बाधित कर सकते हैं। अधिक विलंबता लंबे स्थानांतरण को ज़रूरी नहीं सीमित करे, लेकिन अनुरोध-उत्तर क्रम धीमे कर सकती है। ऐप, परिवहन का व्यवहार, बफ़रिंग का डिज़ाइन और स्रोत दिखाई देने वाला प्रभाव तय करते हैं।

प्लेबैक चलता रहे लेकिन तस्वीर खराब दिखे, तो धुँधलेपन को धीमे नेटवर्क का प्रमाण मानने के बजाय तस्वीर की गुणवत्ता की तुलना देखें। Norva संगत अधिकृत स्रोत चलाता है; वह कैटलॉग नहीं देता और आपके राउटर, स्रोत के रास्ते या उसकी एन्कोडिंग को नियंत्रित नहीं करता।

अर्थ निकालने की आम गलतियाँ

बिट और बाइट की तुलना न करें, लिंक दर को थ्रूपुट न समझें, देरी के हर बदलाव को “पैकेट लॉस” न कहें और एक सर्वर के परिणाम को गारंटी न मानें। राउटर, उपकरण और स्रोत एक साथ बदलने के बाद ही मापने से बचें।

अक्सर पूछे जाने वाले प्रश्न

वीडियो के लिए कौन-सा मापदंड सबसे महत्त्वपूर्ण है?

कोई एक मापदंड हमेशा प्रमुख नहीं होता। संस्करण के डेटा पहुँचने का ढंग, रास्ता, उपकरण और लक्षण तय करते हैं कि कौन-से मापन प्रासंगिक हैं।

क्या थ्रूपुट प्लान के लेबल से अधिक हो सकता है?

लेबल, सेवा का प्रावधान, परीक्षण विधियाँ, इकाइयाँ और अतिरिक्त डेटा की परिभाषाएँ अलग होती हैं। अंतर को गलती मानने से पहले सत्यापित करें कि हर संख्या क्या बताती है।

क्या हर उपकरण जिटर एक ही तरह से मापता है?

नहीं। उपकरण का सूत्र, दिशा, जाँच संदेश का प्रकार, नमूना लेने की अवधि और बताया गया सांख्यिकीय मान जाँचें।

वीडियो स्ट्रीमिंग के लिए कितना जिटर स्वीकार्य है?

ऐसी कोई सार्वभौमिक मिलीसेकंड सीमा नहीं है जो वीडियो प्लेबैक को प्रमाणित करे। बफ़र किया हुआ ऑन-डिमांड वीडियो और परस्पर संवाद वाली कॉल देरी को अलग तरह से सहते हैं; उपकरण भी जिटर की गणना अलग करते हैं। उसी विधि से दोहराए गए परिणामों की तुलना वास्तविक लक्षण से करें। किसी एक ऐप या प्रोटोकॉल के लिए प्रकाशित सीमा Norva की सर्वव्यापी आवश्यकता नहीं बननी चाहिए।

अच्छा स्पीड टेस्ट आने के बाद भी वीडियो बफ़र क्यों होता है?

परीक्षण अलग सर्वर, रास्ता, स्थानांतरण ढंग या समय-खिड़की इस्तेमाल कर सकता है। वह छोटी बाधाएँ चूक सकता है और प्लेबैक स्रोत व उपकरण पर भी निर्भर है। अगला परीक्षण चुनने से पहले दर्ज करें कि देरी पहले फ़्रेम से पहले होती है या प्लेबैक के दौरान।