यह टेस्ट बफरब्लोट को कैसे मापता है
बफरब्लोट एक क्षणिक विलंबता है जो नेटवर्क हार्डवेयर में अत्यधिक बफरिंग के कारण होती है जब कोई कनेक्शन सक्रिय रूप से संतृप्त होता है। निष्क्रिय परिस्थितियों में, पैकेट न्यूनतम देरी के साथ लाइन से गुजरते हैं। हालाँकि, जब बड़े डाउनलोड या अपलोड आपकी बैंडविड्थ को पूरी तरह भर देते हैं, तो अप्रबंधित हार्डवेयर बफर डेटा से भर जाते हैं, जिससे समय-महत्वपूर्ण पैकेटों को कतार में प्रतीक्षा करने के लिए मजबूर होना पड़ता है। यह परीक्षण लोड के तहत कितनी देरी बनती है यह मापने के लिए तीन अलग-अलग परिचालन चरणों में विलंबता को मापता है:
- निष्क्रिय बेसलाइन विलंबता: कोई भी बल्क ट्रांसफर शुरू होने से पहले इंजन 21 हल्के HTTP अनुरोध रिकॉर्ड करता है। यह शांत नेटवर्क स्थितियों में निकटतम एज सर्वर के लिए आपके भौतिक राउंड-ट्रिप पारगमन समय (निष्क्रिय पिंग) को स्थापित करता है।
- लोडेड डाउनलोड विलंबता: जबकि मल्टी-स्ट्रीम बल्क डाउनलोड ट्रांसफर डाउनस्ट्रीम बैंडविड्थ को संतृप्त करते हैं, इंजन आपके स्थानीय राउटर और आईएसपी डाउनस्ट्रीम नोड्स में कतार निर्माण को मापने के लिए लगभग हर 400 ms में छोटे राउंड-ट्रिप विलंबता जांच भेजता है।
- लोडेड अपलोड विलंबता: निरंतर बल्क अपलोड ट्रांसफर के दौरान, आपके स्थानीय ऑपरेटिंग सिस्टम, नेटवर्क इंटरफेस और होम राउटर अपस्ट्रीम बफर में पैकेट कतार का पता लगाने के लिए समान ~400 ms गति से जांच भेजी जाती है।
आपके सारांश में प्रदर्शित प्राथमिक बफरब्लोट स्कोर आपकी निष्क्रिय बेसलाइन की तुलना में डाउनलोड और अपलोड लोड स्थितियों के बीच उच्च वृद्धि का प्रतिनिधित्व करता है। सूत्र सीधा है: बफरब्लोट देरी = लोडेड लेटेंसी − निष्क्रिय लेटेंसी। व्यक्तिगत लोडेड मानों और उनके अलग-अलग अंतरों दोनों का निरीक्षण “टेस्ट विवरण” दराज के तहत किया जा सकता है।
विलंबता वृद्धि को समझना
| निष्क्रिय पिंग पर वृद्धि | व्यावहारिक अनुभव | गेमिंग, कॉल और स्ट्रीमिंग पर प्रभाव |
|---|---|---|
| 30 ms से कम | न्यूनतम / अच्छा | रीयल-टाइम वॉयस कॉल (Zoom, Teams, Discord) और प्रतिस्पर्धी मल्टीप्लेयर गेमिंग सुचारू और प्रतिक्रियाशील रहते हैं, भले ही अन्य घरेलू उपकरण बड़ी फ़ाइलें डाउनलोड कर रहे हों। |
| 30–100 ms | मध्यम कतार देरी | प्रतिक्रियाशीलता में ध्यान देने योग्य अंतराल। प्रारंभिक अनुरोध चरणों के दौरान वेब पेज झिझकते हैं, गेम हिट पंजीकरण में देरी महसूस होती है, और वीडियो कॉन्फ्रेंस प्रतिभागी कभी-कभार ऑडियो देरी के कारण एक-दूसरे पर बोलने लगते हैं। |
| 100 ms से अधिक | गंभीर बफरब्लोट | गंभीर कनेक्शन गिरावट। वॉयस कॉल में क्लिपिंग या रोबोटिक ऑडियो का अनुभव होता है, वीडियो मीटिंग्स हकलाती हैं, और ऑनलाइन गेम में गंभीर रबर-बैंडिंग, स्थानिक डीसिंक्रोनाइज़ेशन और डिस्कनेक्शन त्रुटियों का सामना करना पड़ता है जब भी कनेक्शन व्यस्त होता है। |
ये मूल्यांकन बैंड आधिकारिक नियामक मानक के बजाय व्यावहारिक नेटवर्किंग दिशानिर्देशों का प्रतिनिधित्व करते हैं। जबकि 20 ms का निष्क्रिय पिंग बिजली जैसा तेज़ लगता है, अपलोड के दौरान लोडेड पिंग का 350 ms तक बढ़ जाना यह दर्शाता है कि आपकी इंटरैक्टिव प्रतिक्रियाशीलता अस्थायी रूप से उपग्रह-स्तरीय देरी तक गिर जाती है।
बफरब्लोट बनाम पैकेट लॉस: केवल बैंडविड्थ लेटेंसी को ठीक करने में विफल क्यों होती है
एक आम गलतफहमी यह है कि उच्च बैंडविड्थ इंटरनेट प्लान खरीदने से इन-गेम अंतराल या कॉन्फ्रेंस कॉल ड्रॉप अपने आप ठीक हो जाएंगे। जबकि एक तेज़ प्लान फ़ाइल डाउनलोड की कुल अवधि को छोटा करता है, यह बैंडविड्थ के पूरी तरह व्यस्त होने पर बफर को ओवरफ्लो होने से नहीं रोकता है:
- FIFO बफर का उद्देश्य और दोष: हार्डवेयर निर्माताओं ने मूल रूप से अचानक डेटा उछाल को अवशोषित करने और पैकेट हानि को कम करने के लिए मॉडेम और आवासीय राउटर में बड़े फर्स्ट-इन-फर्स्ट-आउट (FIFO) मेमोरी बफर बनाए थे। हालाँकि, जब निरंतर ट्रैफ़िक लिंक को संतृप्त करता है, तो ये डंब बफर पूरी तरह से भर जाते हैं। एक छोटा 64-बाइट गेमिंग पैकेट या वीओआईपी ऑडियो नमूना तार तक पहुंचने से पहले हजारों कतारबद्ध 1,500-बाइट बल्क फ़ाइल पैकेटों के पीछे प्रतीक्षा करने के लिए मजबूर होता है।
- पैकेट ड्रॉप से पहले विलंबता स्पाइक: गंभीर बफरब्लोट परिदृश्यों में, पैकेट शुरू में खोते नहीं हैं—वे केवल सैकड़ों मिलीसेकंड तक विलंबित होते हैं। जब राउटर बफर अंततः 100% क्षमता तक पहुंच जाता है, तो यह टेल-ड्रॉप निष्पादित करना शुरू कर देता है (सभी आने वाले पैकेटों को त्यागना)। यह एक कैस्केडिंग विफलता पैदा करता है: अत्यधिक विलंबता स्पाइक्स के तुरंत बाद बर्स्ट पैकेट हानि और टीसीपी रीट्रांसमिशन तूफान आते हैं।
- असममित कनेक्शन सबसे पहले पीड़ित होते हैं: केबल (DOCSIS) और डीएसएल कनेक्शन आमतौर पर डाउनलोड की तुलना में काफी कम अपलोड बैंडविड्थ प्रदान करते हैं (उदाहरण के लिए, 300 Mbps डाउनलोड / 10 Mbps अपलोड)। चूंकि अपलोड क्षमता संकीर्ण होती है, इसलिए बैकग्राउंड क्लाउड बैकअप (iCloud, Google Photos, OneDrive), गेम क्लिप अपलोड या वीडियो स्ट्रीम अपस्ट्रीम लिंक को लगभग तुरंत संतृप्त कर देते हैं, जिससे बड़े पैमाने पर अपलोड बफरब्लोट शुरू हो जाता है।
बफरब्लोट को कैसे ठीक करें: स्मार्ट कतार प्रबंधन (SQM)
बफरब्लोट का सिद्ध, उद्योग-मानक समाधान आपके प्राथमिक होम राउटर पर लागू स्मार्ट कतार प्रबंधन (Smart Queue Management - SQM) है। पारंपरिक सेवा गुणवत्ता (QoS) सेटअप मैन्युअल पोर्ट नंबरों या पैकेट निरीक्षण नियमों पर निर्भर करते हैं जो अक्सर आधुनिक एन्क्रिप्टेड ट्रैफ़िक के साथ विफल हो जाते हैं। SQM स्थिर कतारों को गतिशील शेड्यूलिंग एल्गोरिदम के साथ बदलता है:
- उचित कतारबद्धता (Fair Queuing - FQ): एल्गोरिदम नेटवर्क ट्रैफ़िक को अलग-अलग प्रति-प्रवाह कतारों में विभाजित करते हैं। भारी, निरंतर डेटा स्ट्रीम (जैसे बड़ी फ़ाइल डाउनलोड या बिटटोरेंट) बैंडविड्थ जमा नहीं कर सकते हैं या हल्के, विलंबता-संवेदनशील प्रवाह (जैसे डीएनएस प्रश्न, गेम इनपुट और ज़ूम वॉयस पैकेट) को अवरुद्ध नहीं कर सकते हैं।
- सक्रिय कतार प्रबंधन (Active Queue Management - AQM): आधुनिक एल्गोरिदम जैसे fq_codel (RFC 8290) और CAKE लगातार उस समय को मापते हैं जो पैकेट कतार में बैठकर बिताते हैं। यदि कतार देरी अस्वीकार्य सीमा की ओर बढ़ने लगती है, तो एल्गोरिदम बफर के फूलने से पहले अपनी टीसीपी भेजने की दर को धीमा करने के लिए ट्रांसमिटिंग डिवाइस को संकेत देने के लिए सक्रिय रूप से अलग-अलग पैकेट छोड़ता है या चिह्नित करता है (स्पष्ट भीड़ अधिसूचना / ECN के माध्यम से)।
SQM को कॉन्फ़िगर करना और बाधा नियम
SQM को प्रभावी ढंग से सक्षम करने के लिए, आपके राउटर को प्राथमिक नेटवर्क अड़चन को नियंत्रित करना चाहिए। यदि आपके आईएसपी मॉडेम या ऑप्टिकल नेटवर्क टर्मिनल (ONT) के अंदर डेटा कतारबद्ध होता है, तो आपके राउटर के कतार एल्गोरिदम का ट्रैफ़िक देरी पर कोई नियंत्रण नहीं होता है:
- राउटर प्रबंधन तक पहुंचें: SQM, CAKE, fq_codel, या “Smart Queue” लेबल वाली सुविधाओं के लिए अपनी राउटर सेटिंग्स की जांच करें (OpenWrt, Ubiquiti UniFi, eero, GL.iNet और pfSense/OPNsense राउटर पर सामान्य)।
- लाइन दर बैंडविड्थ सीमाएं निर्धारित करें: अपनी लगातार सत्यापित डाउनलोड और अपलोड गति से लगभग 5% से 10% नीचे SQM बैंडविड्थ कैप कॉन्फ़िगर करें (आमतौर पर प्रावधानित थ्रूपुट का 90–95%)। उदाहरण के लिए, 300 Mbps डाउनलोड / 20 Mbps अपलोड कनेक्शन पर, SQM सीमा को 275 Mbps डाउनलोड और 18.5 Mbps अपलोड पर सेट करें।
- हेडरूम क्यों मायने रखता है: थ्रूपुट को थोड़ा कृत्रिम रूप से सीमित करके, आपका राउटर पथ में जानबूझकर बाधा बन जाता है। पैकेट आपके आईएसपी मॉडेम के बड़े बफर में जमा होने के बजाय राउटर की सक्रिय SQM मेमोरी के अंदर कतारबद्ध होते हैं।
- पुनः परीक्षण करें और बारीकी से ट्यून करें: सेटिंग्स लागू करने के तुरंत बाद इस बफरब्लोट परीक्षण को चलाएं। यदि लोडेड पिंग 30 ms से अधिक बढ़ा रहता है, तो कॉन्फ़िगर की गई बैंडविड्थ कैप को अतिरिक्त 2–3% कम करें जब तक कि लोडेड विलंबता आपकी निष्क्रिय बेसलाइन के साथ निकटता से संरेखित न हो जाए।
सच्चे बफरब्लोट से वाई-फाई जिटर को अलग करें
राउटर सेटिंग्स को संशोधित करने से पहले, सत्यापित करें कि क्या विलंबता स्पाइक्स लाइन की भीड़ से उत्पन्न होते हैं या स्थानीय वायरलेस हस्तक्षेप से। वाई-फाई चैनल विवाद, रेडियो रीट्रांसमिशन और पर्यावरणीय हस्तक्षेप का परिचय देता है जो बफरब्लोट की नकल कर सकते हैं। कैट 6 या कैट 6a ईथरनेट केबल का उपयोग करके अपने कंप्यूटर को सीधे अपने राउटर से कनेक्ट करें और बेसलाइन परीक्षण चलाएं। यदि लोडेड विलंबता केवल वाई-फाई पर बढ़ती है, तो मूल कारण अपस्ट्रीम बफरब्लोट के बजाय वायरलेस चैनल संतृप्ति या सिग्नल क्षीणन है।