कनेक्शन का परीक्षण करने के लिए ping google.com का उपयोग करना


11

चूंकि हमारे घर में इंटरनेट कनेक्शन समय-समय पर टूट जाता है, इसलिए मैंने थोड़ा सा प्रयोग किया:

पिछले दो महीने से, मेरी एक मशीन आधे घंटे के आधार पर google.com को पिंग कर रही है। एक माप में 50 पिंग होते हैं।

मैंने अब दिन के प्रत्येक घंटे के लिए खोए गए पैकेट के औसत प्रतिशत की गणना की: खोए हुए पैकेट का प्रतिशत

मेरे सवाल:

  1. क्या शाम को पीक डेस्टिनेशन के रूप में google.com को चुनने के कारण यह शिखर हो सकता है?
  2. क्या आप किसी अन्य गंतव्य का उपयोग करने की सलाह देंगे और कौन सा?
  3. क्या यह दर्शाता है कि मेरे संबंध में कुछ गड़बड़ है?
  4. यह मापने के लिए एक बेहतर रणनीति क्या होगी कि हमारे इंटरनेट कनेक्शन में समस्या कहां है? हमारा आईएसपी बताता है कि यह ठीक काम कर रहा है इसलिए मैं कुछ प्रमाण एकत्र करने की कोशिश करता हूं ...

सादर!

संपादित करें: मैं यह उल्लेख करना भूल गया कि मशीन सीधे राउटर (नो वाईफाई) से जुड़ी है। और राउटर को पिंग किया गया है, जिसमें कोई पैकेट नुकसान नहीं है।


"हमारे घर में इंटरनेट कनेक्शन समय-समय पर टूट जाता है" से आपका वास्तव में क्या तात्पर्य है? यदि "ब्रेक डाउन" का अर्थ है "काम करना बंद करें", पैकेट नुकसान को ट्रैक करना जब यह काम करता है तो आपको कुछ भी उपयोगी बताने की संभावना नहीं है।
इसहाक रैबिनोविच

यह सही है, लेकिन मेरी दिलचस्पी यह है कि यह कब टूटता है, और कितनी बार / कब तक
डिर्क

जवाबों:


10

दुर्भाग्य से आपने वास्तव में यह जानने के लिए पर्याप्त जानकारी नहीं दी है कि समस्या कहाँ है। यथासंभव सीमित जानकारी के साथ उत्तर देने के लिए:

  1. अगर मेरे अनुभव कुछ भी हो जाएं, तो Google को पिंग करना आम तौर पर काफी अच्छा दांव है, क्योंकि वे अपने नेटवर्क को जितना संभव हो उतनी तेजी से डिजाइन करते हैं। इसके अलावा, जैसा कि ICMP को प्राथमिकता दी जाती है, शाम की चोटी शायद एक महत्वपूर्ण अंतर नहीं बनाती है - विशेष रूप से पैकेट नुकसान के मामले में - जो मैं तर्क देता हूं कि 0 होना चाहिए।

  2. Google एक अच्छा गंतव्य है, लेकिन इस बारे में बेहतर विचार प्राप्त करने के लिए कि आप पर क्या चल रहा है, इसके अलावा अपने गेटवे को पिंग करने की कोशिश कर सकते हैं, और यदि वे इसकी अनुमति देते हैं, तो आपके प्रदाता DNS, मेल या वेब सर्वर। यह दिखाने में मदद करेगा कि पैकेट का नुकसान कहां तक ​​कम हो रहा है। वास्तविक रूप से हालांकि, पैकेट नुकसान के स्तर पर आप देख रहे हैं, एमटीआर (या WinMTR) को देखें और चल रहे हैं कि पैकेट के नुकसान का एक बेहतर विचार प्राप्त करने के लिए। ।

  3. विशेष रूप से, वाईफ़ाई आधारित नेटवर्क के लिए स्वीकार्य के शीर्ष अंत में 5% पैकेट का नुकसान होता है - यह मानते हुए कि आप अपने नेटवर्क पर संतृप्त नहीं हैं। दूसरी तरफ, मैं अपने फाइबर कनेक्शन पर लगभग 0.5% पैकेट के नुकसान से परेशान हूं - संदर्भ के एक बिंदु के रूप में, शिथिल रूप से बोलना, कम से कम 1% वीओआइपी के लिए ठीक है, ऊपर
    इतना नहीं। यदि आप Skype या Viber का उपयोग करने में सक्षम होने की उम्मीद करते हैं या आपके पास आपके कनेक्शन पर क्या है तो 5% पैकेट नुकसान ठीक नहीं है। केवल वेब ब्राउज़िंग के लिए यह पर्याप्त हो सकता है।

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

    एक ग्राहक के रूप में, मेरा आईएसपी मेरे ग्राफ़ को दूर करने में असमर्थ रहा है, जो कि पैकेट नुकसान की साजिश करता है (मैं इसे 250 पिंग्स के लिए करता हूं, एक बार 5 मिनट के अंतराल पर, उन पिंग्स के लिए न्यूनतम, औसत और अधिकतम विलंबता के साथ संयुक्त)। मेरे पास लिंक का मेरा उपयोग दिखाने वाले ग्राफ़ का एक सेट है, और स्थानीय (यानी मेरे बहुत करीब) को दिखाने वाले ग्राफ़ के सेट हैं, और दूसरे पीओपी के लिए वे कुछ सौ केएम की दूरी पर विशिष्ट ब्याज के मालिक हैं।

अन्य अवलोकन:

ऐसा लगता है कि दोपहर में आपकी विलंबता बढ़ जाती है - जिसका अर्थ है कि मैं देख रहा हूं कि पहली समस्या यह है कि क्या समस्या वाईफ़ाई है जब मेरे चारों ओर हर कोई इसका उपयोग कर रहा है। यह निर्णय लेने के बाद कि मैं कनेक्शन की देखरेख के बारे में अपने ISP से पूछताछ करना शुरू करूंगा।


आपके उत्तरों के लिए बहुत धन्यवाद। मशीन सीधे राउटर से जुड़ी होती है, और यह राउटर को भी पिंग कर देती है जो बिना किसी पैकेज लॉस के दिखाता है। MTR लगता है कि मैं क्या देख रहा था।
डिर्क

6

यह संभावना से कहीं अधिक लाइन के साथ भीड़ का परिणाम है। यह आपका राउटर हो सकता है लेकिन अधिक संभावना एक अपस्ट्रीम प्रदाता।

आप यह नहीं बताते हैं कि आप 50 पिंग्स कैसे कर रहे हैं, जैसे समय अंतराल, क्या आप एक के असफल होने / सफल होने से पहले प्रतीक्षा कर रहे हैं या एक साथ (फायर पिंगिंग) 50 से फायरिंग कर रहे हैं।

उच्च भीड़ की अवधि के दौरान ऐसा नुकसान मेरे अनुभव में असामान्य नहीं है। यह ICMP ट्रैफ़िक के लिए प्राथमिकता को कम कर सकता है, लेकिन सभी कनेक्शनों के समान प्रतिशत के लिए अधिक संभावना हो रही है - यह सिर्फ टीसीपी इनायत करेगा और पैकेट को फिर से व्यवस्थित करेगा ताकि आपको नोटिस करने की संभावना कम हो।

स्थिति का एक बेहतर चित्र प्राप्त करने के लिए मैं आपको निम्नलिखित को लागू करने का सुझाव दूंगा:

  1. अपने पिंग के बीच अंतराल बढ़ाएँ
  2. Google के लिए एक IP पता पिंग न कि डोमेन - google.com कई A रिकॉर्ड्स लौटाएगा और हो सकता है कि आप इसे जाने बिना अलग-अलग आईपी (और इसलिए अलग तरीके से रूटिंग) का उपयोग कर रहे हों
  3. प्रतिक्रिया करने के लिए औसत समय रिकॉर्ड करें; देखें कि क्या यह नुकसान के साथ संबंध रखता है - यदि ऐसा होता है तो आपको उच्च पिंग राउंडट्रिप बार और उच्च हानि दिखाई देती है तो यह भीड़ को इंगित करता है। आप इसके बजाय ट्रेसरआउट लॉग को स्टोर करके जांच कर सकते हैं और देख सकते हैं कि कहीं एक संभावित अड़चन है जहां आप अचानक बढ़े हुए समय को देख रहे हैं
  4. Google से अधिक पिंग करने का प्रयास करें। जब मैंने अतीत में नेटवर्क प्रदर्शन को बेंचमार्क किया है तो मैंने इसे 4 या 5 अच्छे एंड-पॉइंट्स (फिर से आईपी एड्रेस के साथ होस्टनाम नहीं) का उपयोग करके किया है ताकि आप केवल Google के नेटवर्क के भीतर जमाव या एक विशिष्ट समस्या को नियंत्रित कर सकें। अपने पूरे कनेक्शन पर सवाल उठाएं

2

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.