मार्गदर्शन

बफरब्लोट के हो?

बफरब्लोटमा नेटवर्क प्याकेट अत्यधिक लामो लाममा पर्खिन्छन्। अतिरिक्त ट्राफिक नभएको र लोड भएको अवस्थाको ढिलाइ तुलना गरेर परिवर्तनपछि गति पनि जाँच्नुहोस्।

बफरब्लोट भनेको प्याकेटको लाम अत्यधिक लामो रहिरहँदा पर्खाइ बढ्नु हो। छोटो समयका लागि बढेको डेटा सम्हाल्न बफर सामान्य र उपयोगी हुन्छ। तर ठूलो डाउनलोड वा अपलोडसँगै कल र खेलमा ढिलाइ बढेमा लामो लाम एउटा सम्भावित कारण हो। यस्तो लाम राउटर, मोडेम, नेटवर्कको अर्को भाग वा अन्तिम उपकरणमा हुन सक्छ। लोड हुँदा पिङ बढेको आधारमा कुनै एक उपकरणलाई दोष दिन मिल्दैन।

अतिरिक्त ट्राफिक नभएको र लोड भएको अवस्था तुलना गर्नुहोस्

एउटै उपकरण र परीक्षण गन्तव्य प्रयोग गर्नुहोस्। सम्भव भए Ethernet जोड्नुहोस्। आफ्ना ब्याकअप र ठूला ट्रान्सफर रोक्दै सुरुको पिङ वा लेटेन्सी टिप्नुहोस्। महत्त्वपूर्ण कलको समयमा परीक्षणका लागि थप लोड नदिनुहोस्।
पहिले डाउनलोड, त्यसपछि छुट्टै अपलोड चलाउनुहोस्। अतिरिक्त ट्राफिक नभएको र लोड भएको दुवै अवस्थाको ढिलाइ देखाउने परीक्षण प्रयोग गर्नुहोस्, वा नियन्त्रित ट्रान्सफरको समयमा पिङको उत्तर दिने एउटै गन्तव्यमा बारम्बार पिङ गर्नुहोस्। दुई दिशाका नतिजा छुट्टाछुट्टै राख्नुहोस्।
ट्रान्सफर रोक्दा ढिलाइ सुरुको स्तरमा फर्किन्छ कि हेर्नुहोस्। एउटै गन्तव्य र सेटिङमा दोहोर्‍याएर जाँच्नुहोस्। गति, ढिलाइको उतारचढाव र देखिएको प्याकेट हानि पनि टिप्नुहोस्।
उदाहरणका लागि 12 ms बाट 150 ms पुगेमा थप ढिलाइ 138 ms हुन्छ। यो गणनाको उदाहरण हो, सबै जडानको खराबी सीमा होइन। एउटा उच्चतम पिङ वा पिङको उत्तर नआउनु बफरब्लोटको प्रमाण होइन।

नतिजाले के पुष्टि गर्दैन

लोड दिँदा बारम्बार ढिलाइ बढ्ने र हटाउँदा घट्ने भए लामबारे थप जाँच गर्ने आधार मिल्छ। Wi-Fi को प्रतिस्पर्धा, उपकरणको प्रोसेसर, परीक्षण सर्भर र नेटवर्क मार्गले पनि नतिजा बदल्न सक्छन्। Ethernet ले स्थानीय Wi-Fi को प्रभाव हटाउँछ, तर दोष राउटर, मोडेम वा प्रदायकमध्ये कहाँ छ भन्ने तय गर्दैन। केही गति परीक्षणले लोड भएको अवस्थाको लेटेन्सी स्पष्ट रूपमा मापन गर्छन्। त्यसैले सबै गति परीक्षण अनुपयोगी भन्न मिल्दैन; विधि र गन्तव्य फरक हुँदा नतिजा फरक हुन सक्छ।

पहिले आफ्नै ट्राफिक र उपलब्ध सेटिङ हेर्नुहोस्

ठूला ब्याकअप र ट्रान्सफरलाई कल वा खेलको समयभन्दा बाहिर राख्नुहोस्। एपमा गति सीमा उपलब्ध भए अन्य ट्राफिकका लागि क्षमता बाँकी राखेर नतिजा तुलना गर्नुहोस्।
ढिलाइप्रति संवेदनशील उपकरणलाई Ethernet मा जाँच्नुहोस्। Wi-Fi कभरेजको समस्या छुट्टै सुधार्नुहोस्; केबल जोड्दा इन्टरनेट जडानको लाम आफैँ नियन्त्रण हुँदैन।
राउटरको सही मोडेल र हालको फर्मवेयरको आधिकारिक निर्देशिकामा SQM वा समान सुविधा हेर्नुहोस्। नयाँ उपकरण किन्नुअघि वास्तविक समर्थन र मापन गरिएको सीमा जाँच्नुहोस्।
समर्थित लाम व्यवस्थापन बदल्नुअघि पुरानो सेटिङ र मापन सुरक्षित राख्नुहोस्। निर्माताको निर्देशिका पालना गर्नुहोस्। कुनै एपलाई प्राथमिकता दिनु मात्रै सक्रिय लाम व्यवस्थापन भएको प्रमाण होइन।

SQM ले ट्राफिक दर नियन्त्रण, अलग प्रवाहको पालो व्यवस्थापन र सक्रिय लाम व्यवस्थापन जोड्न सक्छ। FQ-CoDel र CAKE समर्थित प्रणालीका उदाहरण हुन्, सबै राउटरका सुविधा होइनन्। स्थिर उपलब्ध क्षमताभन्दा केही कम सीमा राख्दा अनियन्त्रित लाम घट्न सक्छ, तर अधिकतम गति पनि घट्न सक्छ। उपयुक्त सीमा उपकरण र जडानमा निर्भर हुन्छ; सबैका लागि एउटै प्रतिशत ठीक हुँदैन। प्रोसेसरको सीमा र मोबाइल जडानको बदलिने क्षमता पनि विचार गर्नुहोस्। एकाइ जाँच्नुहोस्: 20 Mbps बराबर 20000 kbit/s हो; kbit/s लेखिएको ठाउँमा 20 राख्दा उही दर हुँदैन।

परिवर्तनपछि तुलना दोहोर्‍याउनुहोस्

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

अतिरिक्त ट्राफिक नभएको अवस्थामा पनि ढिलाइ उच्च छ वा एउटै सेवामा मात्र समस्या छ भने छुट्टै जाँच गर्नुहोस्। सहायता माग्दा समय, परीक्षण गन्तव्य, Ethernet वा Wi-Fi, लोडको दिशा, राउटर मोडेल र पहिले-पछिका नतिजा दिनुहोस्। एउटा ग्रेडका आधारमा मात्रै उपकरण नकिन्नुहोस्; आवश्यक सुविधा वा मापन गरिएको सीमा आधार हुनुपर्छ।