स्पीड टेस्ट के परिणाम कैसे पढ़ें
स्पीड टेस्ट का परिणाम चार मापों का एक स्नैपशॉट है — डाउनलोड गति, अपलोड गति, लेटेंसी और जिटर — जो आपके डिवाइस और किसी एक नज़दीकी टेस्ट सर्वर के बीच, एक क्षण में लिया जाता है, जबकि उस समय आपका कनेक्शन शायद किसी और काम में व्यस्त रहा हो। यह एक उपयोगी स्नैपशॉट है, लेकिन यह आपके इंटरनेट प्रदाता पर फैसला नहीं है, और यह एक अकेली संख्या भी नहीं है: कोई कनेक्शन तेज़ होकर भी भयानक महसूस हो सकता है, या कागज़ पर मामूली होकर भी इस्तेमाल में बिल्कुल सहज हो सकता है — यह इस पर निर्भर करता है कि चार संख्याओं में से कौन सी कमज़ोर है। यह लेख बताता है कि प्रत्येक संख्या क्या मापती है, ब्राउज़िंग, वीडियो कॉल, गेमिंग और 4K स्ट्रीमिंग के लिए क्या अच्छा माना जाता है, एक ही लाइन हर बार अलग परिणाम क्यों देती है, और परिणाम को ऐसे सबूत में कैसे बदलें जिस पर आपका प्रदाता वास्तव में कार्रवाई कर सके। आप इंटरनेट स्पीड टेस्ट में खुद परीक्षण चला सकते हैं, जो आपके ब्राउज़र में ही निकटतम Cloudflare एज तक आपके कनेक्शन को मापता है।
चार संख्याएँ, और प्रत्येक वास्तव में क्या मापती है
डाउनलोड गति एक दिशा में थ्रूपुट है: परीक्षण उत्तरोत्तर बड़ी डाउनलोड का उपयोग करके यह मापता है कि सर्वर से आपके डिवाइस तक प्रति सेकंड कितने मेगाबिट (Mbps) खींचे जा सके, और किसी एक शिखर के बजाय नमूनों का एक उच्च पर्सेंटाइल बताता है। अपलोड गति उलटी दिशा में वही माप है — आपका डिवाइस डेटा को बाहर कितनी तेज़ी से भेज सकता है — और यही वह संख्या है जो तय करती है कि कॉल में दूसरों को आपका वीडियो कैसा दिखेगा, बैकअप कितनी जल्दी पूरा होगा, और बड़ी फ़ाइल भेजने में कितना समय लगेगा। होम प्लान में ये दोनों अक्सर बहुत असमान होते हैं, और तेज़ डाउनलोड के साथ धीमा अपलोड प्लान की बनावट है, खराबी नहीं।
लेटेंसी, जिसे अक्सर पिंग कहा जाता है, एक छोटे अनुरोध के सर्वर तक जाने और वापस आने का समय है, जिसे मिलीसेकंड में मापा जाता है: यह किसी भी चीज़ के हिलने से पहले का इंतज़ार है, और यही तय करता है कि कनेक्शन फुर्तीला महसूस होता है या सुस्त। जिटर लगातार लेटेंसी मापों के बीच का उतार-चढ़ाव है — यानी वह देरी कितनी स्थिर है। 25 ms लेटेंसी और 3 ms जिटर वाला कनेक्शन चुस्त महसूस होता है; वही 25 ms औसत 40 ms जिटर के साथ अटकता हुआ महसूस होता है, क्योंकि वीडियो फ्रेम और वॉयस पैकेट असमान रूप से पहुँचते हैं। मोटे तौर पर: वेब ब्राउज़िंग लगभग 10 Mbps डाउनलोड और 100 ms से कम लेटेंसी पर आरामदायक है; ग्रुप वीडियो कॉल को प्रत्येक दिशा में लगभग 3–8 Mbps, 150 ms से कम लेटेंसी और 30 ms से कम जिटर चाहिए; ऑनलाइन गेमिंग को कच्ची गति की परवाह शायद ही होती है — 5–10 Mbps काफी है — लेकिन उसे 50 ms से कम लेटेंसी और 20 ms से कम जिटर चाहिए; और एक 4K स्ट्रीम को आमतौर पर लगभग 25 Mbps निरंतर डाउनलोड चाहिए। Mbps को 8 से विभाजित करें तो प्रति सेकंड मेगाबाइट (MB/s) मिलता है, वही इकाई जो आपके ब्राउज़र का डाउनलोड संकेतक उपयोग करता है।
एक ही लाइन हर बार अलग संख्या क्यों देती है
ब्राउज़र स्पीड टेस्ट सिर्फ आपके प्रदाता की लाइन नहीं, पूरा पथ मापता है: आपका डिवाइस, आपका Wi-Fi, आपका राउटर, एक्सचेंज तक की लाइन, आपके प्रदाता का नेटवर्क, और टेस्ट सर्वर तक का मार्ग। इनमें से कोई भी किसी दिए गए रन में अड़चन बन सकता है। तेज़ कनेक्शन पर सामान्य संदिग्ध Wi-Fi है — यह शायद ही कभी पूरी लाइन गति देता है, और दूरी, दीवारों और पड़ोसी नेटवर्क से खराब होता है — उसके बाद उसी कनेक्शन पर अन्य डिवाइस, बैकग्राउंड अपडेट और क्लाउड सिंक, व्यस्त मशीन पर ब्राउज़र स्वयं, और दिन का समय आते हैं: शाम, जब पूरा मोहल्ला वीडियो देख रहा होता है, साझा नेटवर्क का रश आवर है। सर्वर की दूरी भी मायने रखती है, इसीलिए यह परीक्षण किसी दूसरे महाद्वीप के सर्वर के बजाय निकटतम Cloudflare एज के खिलाफ मापता है।
तरीका भी अंतर की दूसरी परत जोड़ता है। परीक्षण फ़ाइल आकार में, एक स्ट्रीम खोलने या कई खोलने में, कौन सा पर्सेंटाइल बताने में, और टेस्ट सर्वर के आपके प्रदाता के नेटवर्क के अंदर (ऑन-नेट, छोटा पथ, चापलूसी भरी संख्याएँ) या बाहर (ऑफ़-नेट, असली ब्राउज़िंग के करीब) होने में भिन्न होते हैं। इंटरनेट गति की कोई एक मानक परिभाषा नहीं है, इसलिए अलग-अलग मापकों की संख्याएँ सीधे तुलनीय नहीं हैं — एक से 400 Mbps और दूसरे से 300 Mbps दोनों ही अलग-अलग चीज़ों के ईमानदार माप हो सकते हैं। एक अकेला धीमा रन न भीड़भाड़ साबित करता है, न थ्रॉटलिंग: केवल एक पैटर्न, जो कई दिनों तक एक ही तरीके से मापा गया हो, इनमें से किसी भी दावे का समर्थन कर सकता है।
परीक्षण ठीक दिखे लेकिन ऐप अटके — या इसका उल्टा — ऐसा क्यों होता है
स्पीड टेस्ट एक टेस्ट सर्वर तक का पथ मापता है। आपका वीडियो कॉल, गेम या स्ट्रीम अलग सर्वरों से जुड़ते हैं, अक्सर अलग शहरों में, अलग मार्गों से — और वे मार्ग भीड़भाड़ वाले हो सकते हैं जबकि परीक्षण पथ खाली हो, या इसका उल्टा भी हो सकता है। असली ऐप्स के लिए थ्रूपुट कहानी का केवल एक हिस्सा है: ऑनलाइन आप जो कुछ भी करते हैं वह ज़्यादातर छोटे ट्रांसफ़र होते हैं, और छोटे ट्रांसफ़र बैंडविड्थ से नहीं, लेटेंसी से सीमित होते हैं, क्योंकि हर राउंड ट्रिप में अधिक डेटा भेजने से पहले पुष्टि का इंतज़ार होता है। इसीलिए 500 Mbps कनेक्शन भी लेटेंसी अधिक होने पर पेज धीरे लोड कर सकता है, और 15 ms लेटेंसी वाला मामूली 50 Mbps कनेक्शन तुरंत महसूस हो सकता है। केवल खाली लेटेंसी भी पूरी कहानी नहीं बताती: लोड के तहत लेटेंसी — कनेक्शन व्यस्त होने पर देरी कितनी बढ़ती है — यही तय करती है कि डाउनलोड शुरू होने पर कॉल अटकेगा या नहीं।
इसलिए किसी अंतर को विरोधाभास नहीं, जानकारी मानें। यदि परीक्षण स्वस्थ है लेकिन एक ऐप नहीं है, तो समस्या शायद आपकी लाइन से परे है: उस ऐप के सर्वर, उन तक का मार्ग, या डिवाइस पर कुछ। दुनिया भर के कई स्थानों से उसी गंतव्य की जाँच, जैसा कि क्या यह डाउन है या सिर्फ मुझे ही ऐसा हो रहा है? में बताया गया है, स्थानीय समस्या को वैश्विक समस्या से अलग करती है। यदि सभी ऐप अटकते हैं जबकि परीक्षण ठीक दिखता है, तो देखें कि परीक्षण क्या नहीं मापता: लोड के तहत लेटेंसी, पैकेट लॉस, और अटकने के समय कनेक्शन का और क्या उपयोग कर रहा था। और यदि परीक्षण धीमा है लेकिन ऐप ठीक महसूस होते हैं, तो अजीब चीज़ परीक्षण पथ या वह क्षण हो सकता है, न कि आपका रोज़मर्रा का अनुभव।
ऐसा परीक्षण कैसे चलाएँ जिस पर आप वास्तव में भरोसा कर सकें
शुरू करने से पहले तय करें कि आप क्या परीक्षण कर रहे हैं। लाइन स्वयं को परखने के लिए, वायर्ड ईथरनेट कनेक्शन, एक डिवाइस, और कुछ और न चलाएँ: स्ट्रीमिंग बंद करें, क्लाउड सिंक और अपडेट रोकें, और ब्राउज़र के अन्य टैब बंद करें। किसी कमरे के Wi-Fi को परखने के लिए, उसी कमरे से, उसी डिवाइस पर परीक्षण करें जिसे आप वहाँ वास्तव में उपयोग करते हैं — लेकिन तब परिणाम कमरे का वर्णन करता है, लाइन का नहीं, और उसे अपने प्रदाता को लाइन गति के रूप में नहीं बताना चाहिए। परीक्षण कम से कम तीन बार चलाएँ और सर्वश्रेष्ठ नहीं, माध्यिका (median) लें; शाम के पीक सहित दिन के अलग-अलग समय पर परीक्षण करें; और जिन रनों की तुलना करना चाहते हैं उनके बीच परिस्थितियाँ समान रखें। एक अकेला परिणाम स्नैपशॉट है; तुलनीय परिणामों का समूह सबूत है।
संख्याओं के साथ परिस्थितियाँ भी दर्ज करें — वायर्ड या Wi-Fi, दिन का समय, और क्या चल रहा था — और यदि आप कोई मामला बना रहे हैं तो कई दिनों तक एक संक्षिप्त लॉग रखें। एक पूरा परीक्षण काफी डेटा ले जा सकता है, लगभग 200 MB तक, इसलिए मीटर वाले या सीमित कनेक्शन पर बार-बार परीक्षण से बचें। प्रत्येक परिणाम को उसके टाइमस्टैंप के साथ निर्यात या सहेजें; इस साइट का इंटरनेट स्पीड टेस्ट ठीक इसी उद्देश्य से CSV निर्यात देता है, ताकि एक सप्ताह की तुलनीय संख्याएँ प्रदाता को एक ही फ़ाइल में दिखाई जा सकें, बजाय याददाश्त से बहस करने के।
स्पीड टेस्ट आपको क्या नहीं बता सकता
स्पीड टेस्ट लक्षण बताता है, कारण नहीं। यह नहीं बता सकता कि पैकेट क्यों खो रहे हैं — कारण Wi-Fi हस्तक्षेप है, खराब केबल है, भीड़भाड़ वाला लिंक है, या खराब मॉडेम है — और यह बफ़रब्लोट, यानी लोड के तहत लेटेंसी का फूलना, नहीं माप सकता, जब तक कि वह कनेक्शन के संतृप्त होने पर विशेष रूप से लेटेंसी की जाँच न करे। यह एक रन से पथ को होम नेटवर्क और प्रदाता नेटवर्क में भी नहीं बाँट सकता: धीमा Wi-Fi परिणाम और धीमा लाइन परिणाम चारों संख्याओं में एक जैसे दिखते हैं, और केवल वायर्ड तुलना उन्हें अलग करती है। यह आपके होम नेटवर्क के अंदर बिल्कुल नहीं देख सकता — कौन सा डिवाइस बैंडविड्थ हड़प रहा है, राउटर ज़्यादा गर्म हो रहा है या नहीं, या पड़ोसी का नेटवर्क आपके Wi-Fi चैनल को दबा रहा है।
यह उन समस्याओं का निदान भी नहीं कर सकता जो कनेक्शन के बारे में नहीं हैं। कोई साइट जो आपके IP पते की खराब प्रतिष्ठा के कारण आपको ब्लॉक या सीमित करती है, परीक्षण कितना भी तेज़ हो, टूटी हुई महसूस होगी; यह प्रतिष्ठा की समस्या है, जिसे आपका IP पता फ़्लैग क्यों होता है में समझाया गया है, और कोई भी बैंडविड्थ इसे ठीक नहीं करती। न ही कोई परीक्षण जानबूझकर की गई थ्रॉटलिंग को सामान्य भीड़भाड़ से अलग कर सकता है — दोनों ही कम संख्या जैसे दिखते हैं — या बता सकता है कि धीमी साइट सबके लिए धीमी है या नहीं। ऐसे सवालों के लिए उपकरणों को मिलाएँ: वायर्ड की तुलना Wi-Fi से करें, ग्लोबल पिंग उपकरण से कई स्थानों से उसी गंतव्य का परीक्षण करें, और निष्कर्ष निकालने से पहले समय के साथ पैटर्न देखें।
अपने ISP को कब कॉल करें — और कौन सी संख्याएँ बताएँ
कॉल तब करें जब कोई पैटर्न बना रहे, न कि जब एक परिणाम निराश करे। असली शिकायत की सीमा कुछ इस तरह है: वायर्ड परीक्षण, एक से अधिक दिन, ऑफ़-पीक सहित अलग-अलग समय पर, लगातार आपके प्लान की गति से काफी नीचे — आधे से कम एक मज़बूत संकेत है — या लेटेंसी और जिटर जो वायर्ड पर तब भी ऊँचे बने रहें जब कनेक्शन का और कोई उपयोग न हो। कॉल करने से पहले राउटर को एक बार रीस्टार्ट करें और फिर से परीक्षण करें, ताकि वह चरण पहले ही हो चुका हो। सबसे दूर वाले बेडरूम के Wi-Fi परिणाम से शुरुआत न करें: सपोर्ट सबसे पहले वायर्ड परीक्षण माँगेगा, और Wi-Fi संख्याओं पर बनी शिकायत होम-नेटवर्क समस्या के रूप में दर्ज होगी।
वे संख्याएँ बताएँ जिन पर सपोर्ट कार्रवाई कर सके: आपके प्लान की गति, तारीखों और समय सहित कम से कम तीन वायर्ड परीक्षणों की माध्यिका, उन्हीं परीक्षणों की लेटेंसी और जिटर, और आपने क्या-क्या खारिज कर दिया — एक डिवाइस, कोई बैकग्राउंड ट्रैफ़िक नहीं, राउटर रीस्टार्ट हो चुका। बताएँ कि समस्या लगातार है या दिन के समय पर निर्भर है, क्योंकि केवल शाम की धीमापन साझा नेटवर्क की भीड़भाड़ की ओर इशारा करती है, जबकि पूरे दिन की धीमापन लाइन या उपकरण की ओर इशारा करती है। लाइन जाँच और टिकट नंबर माँगें, और अपने निर्यात किए गए परिणाम सहेजकर रखें: एक ही तरीके से कई दिनों तक जुटाई गई तुलनीय संख्याओं की शांत सूची को खारिज करना, गुस्से वाले एक स्क्रीनशॉट से कहीं कठिन है।