मद्दत
प्याकेट हानि के हो र यसलाई कसरी चिन्ने?
प्याकेट हानिमा पठाइएका प्याकेट गन्तव्यमा पुग्दैनन्। उपकरण, जडान र दोहोरिएका परीक्षण तुलना गर्नुहोस्; पिङको उत्तर नआउनु मात्रै खराबीको प्रमाण होइन।
पठाइएको प्याकेट गन्तव्यमा नपुगे प्याकेट हानि हुन्छ। काटिने बोली, खेलमा अचानक उफ्रिने स्थिति वा रोकिएको ट्रान्सफर यससँग मिल्न सक्छ, तर उपकरण वा एपको समस्या पनि कारण हुन सक्छ। उच्च डाउनलोड गतिले बेलाबेला हुने हानि हटाउँदैन। 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 वा कम लोडको प्रभाव दिनुहोस्। लगबाट पासवर्ड, टोकन र निजी खाताका विवरण हटाउनुहोस्। दोहोरिने अवलोकन सबैभन्दा उच्च प्रतिशतको चरणलाई दोष दिने वा एक परीक्षणमा छिटो योजना किन्नेभन्दा उपयोगी हुन्छ।