मदत
पॅकेट हानी म्हणजे काय आणि कशी ओळखावी?
पॅकेट हानीमध्ये पाठवलेली पॅकेट गंतव्यावर पोहोचत नाहीत. उपकरणे, कनेक्शन आणि पुनरावृत्त चाचण्या तुलना करा; पिंगचे उत्तर नसणे एकट्याने दोष सिद्ध करत नाही.
पाठवलेले पॅकेट गंतव्यावर न पोहोचल्यास पॅकेट हानी होते. तुटक बोलणे, गेममधील अचानक उड्या किंवा थांबलेले ट्रान्सफर याला जुळू शकतात, पण उपकरण किंवा ॲपही कारण असू शकते. जलद डाउनलोड अधूनमधून होणारी हानी नाकारत नाही. VMAXCHECK थेट पॅकेट हानी मोजत नाही; वेग किंवा लेटन्सीने हे निदान निश्चित होत नाही.
नियंत्रित तुलनेपासून सुरू करा
- वेळ, कालावधी, ॲप आणि एकाच वेळी प्रभावित उपकरणे नोंदवा. ॲप नेटवर्क आकडे दाखवत असल्यास त्याच्या स्पष्टीकरणानुसार हानी आणि मोजण्याची दिशा लिहा.
- त्याच उपकरणावर थोड्या अंतराने Wi-Fi आणि Ethernet तुलना करा. सुरुवातीच्या मोजमापासाठी स्वतःचे मोठे ट्रान्सफर व बॅकअप थांबवा; सामान्य समस्या येण्याच्या परिस्थिती वेगळ्या पाहा.
- शांत वेळ आणि समस्या असताना त्याच लक्ष्य व सेटिंगसह पुन्हा करा. एक चांगली चाचणी अधूनमधून येणारी समस्या नाकारत नाही. फक्त संध्याकाळचा नमुना गर्दीचा पुरावा नाही.
- दुसरे उपकरण आणि सेवा तुलना करा. एक ॲप असल्यास सेवेची स्थितीही पाहा. Ethernet मधील सुधारणा बिनतारी मार्ग किंवा उपकरण तपासण्याचा संकेत आहे, Wi-Fi फ्रेम हरवल्याचा पुरावा नाही.
मर्यादित पिंग चाचण्या
Windows मध्ये ping /n 50 1.1.1.1 सार्वजनिक लक्ष्याला 50 ICMP इको विनंत्या पाठवते. उत्तर देणारे लक्ष्य वापरा; ते ॲपचे सर्व्हरच असेल असे नाही. नेटवर्क सेटिंगमधील स्थानिक राउटरचा पत्ता लक्ष्याच्या जागी घालूनही तपासा. निकाल वेगळे ठेवा: पाठवलेल्या विनंत्या, आलेली व न आलेली उत्तरे, येण्या-जाण्याचा वेळ. पुन्हा करताना संख्या, प्रतीक्षा मर्यादा, पॅकेट आकार व पत्ता कुटुंब समान ठेवा. फार लहान प्रतीक्षा मर्यादा किंवा वेगाने विनंत्यांचा पूर आणणारी चाचणी टाळा; न आलेल्या उत्तरांची प्रतीक्षा काही मिनिटे घेऊ शकते.
न आलेली उत्तरे काळजीपूर्वक समजून घ्या
- 50 विनंत्यांतील दोन उत्तरे नसणे म्हणजे या नमुन्यात 4% ICMP उत्तरे नसणे, सर्व ॲप ट्रॅफिकचा विश्वासार्ह हानी दर नाही. राउटर किंवा लक्ष्य ICMP मर्यादित किंवा बंद करू शकते. विनंती व उत्तर मार्गाच्या वेगळ्या भागांत हरवू शकतात.
- राउटरची उत्तरे नसण्यासोबत ॲप समस्या असल्यास आधी स्थानिक मार्ग तपासण्याचे कारण मिळते. जुळणारी लक्षणे नसताना राउटर शांत असणे कनेक्शन खराबीचा पुरावा नाही.
- राउटर उत्तर देत असताना अनेक इंटरनेट लक्ष्य व ॲप अयशस्वी असल्यास राउटरची इंटरनेट बाजू, कनेक्शन व पुढचा मार्ग तपासा. निकाल केवळ पुरवठादाराला दोषी ठरवत नाही.
- traceroute मधील तारे किंवा pathping मधील एका मधल्या टप्प्याची हानी फॉरवर्डिंग दोष सिद्ध करत नाही. अंतिम लक्ष्य, पुढचे टप्पे व ॲप तुलना करा: उपकरण स्वतःची उत्तरे मर्यादित करूनही इतर ट्रॅफिक पुढे पाठवू शकते.
विलंब आणि हानी वेगळे आहेत: मोठा पिंग हरवलेल्या पॅकेटची संख्या नाही. TCP न पोहोचलेला डेटा पुन्हा पाठवू शकते, ज्यामुळे प्रतीक्षा किंवा कमी वेग होऊ शकतो. UDP स्वतः पोहोचण्याची हमी देत नाही; ॲप स्वतःची पुनर्प्राप्ती जोडू शकते. परिणाम ॲप आणि एकेरी किंवा समूहातील हानीवर अवलंबून असतो. एक टक्केवारीचा आकडा सर्वांसाठी उत्तीर्ण सीमा नाही, आणि छोटी चांगली चाचणी दुसऱ्या मार्गांची किंवा नंतरच्या सत्रांची हमी देत नाही.
निकालानुसार बदला व पुन्हा तुलना करा
- फक्त बिनतारी समस्येत कव्हरेज आणि रेडिओ स्पर्धा पाहा. केबलवर योग्य चालणारी सुसंगत केबल किंवा पोर्टशी तुलना करा आणि उपकरण व ॲडाप्टरचे अधिकृत मार्गदर्शन पाहा. एका वेळी एक गोष्ट बदला.
- स्वतःच्या मोठ्या ट्रान्सफरसोबत समस्या असल्यास थांबवा, वेळ बदला किंवा मर्यादित करून तुलना करा. निर्मात्याने समर्थित रांग व्यवस्थापन गर्दीत मदत करू शकते, पण सर्व हानी दुरुस्त करत नाही.
- मार्गदर्शनानुसार पुन्हा सुरू करण्यापूर्वी राउटर घटना व मोजमाप जतन करा. यामुळे इतर वापरकर्ते व कॉल खंडित होतात; चाचणी आहे, कारणाचा पुरावा नाही. सुरुवातीला फॅक्टरी रीसेट किंवा संरक्षण बंद करू नका.
- बदलानंतर त्याच चाचण्या व ॲप पुन्हा वापरा. एका सेवेसाठी तिची स्थिती व मदत पाहा; अनेक उपकरणे व सेवांसाठी नेटवर्क पुरवठादाराला तुलना द्या.
मदतीसाठी वेळ, कालावधी, कनेक्शन, मॉडेल, लक्ष्य व सेटिंग, विनंत्या व न आलेल्या उत्तरांची संख्या, येण्या-जाण्याचा वेळ, उपकरणे, ॲप आणि Ethernet किंवा कमी लोडचा परिणाम द्या. लॉगमधून पासवर्ड, टोकन व खाजगी खात्याचे तपशील काढा. पुनरावृत्ती करता येणारी निरीक्षणे सर्वाधिक टक्केवारीच्या टप्प्याला दोष देणे किंवा एका चाचणीवर जलद प्लॅन घेण्यापेक्षा उपयोगी असतात.