केबलला दोष देण्यापूर्वी पॅकेट लॉस कसा वाचावा

दीर्घ पिंग फेरीत दोन टक्के लॉस हा असा आकडा वाटतो ज्यावर तुम्ही कार्यवाही करू शकता, आणि तसे होणे दुर्मिळ आहे। तो उत्तरे कुठे हरवली, ती एकत्र हरवली का, किंवा एखाद्या विशिष्ट अनुप्रयोगाने तो अंतराल कसा अनुभवला हे सांगत नाही। एका मिनिटात समान रीतीने पसरलेला लॉस आणि एकाच देवघेवीत साचलेला लॉस एकाच टक्केवारीसाठी खूप वेगळे परिणाम देतात.

एकावर विश्वास ठेवण्याऐवजी तीन मोजमापांची तुलना करा: प्रोबने काय पाहिले, इंटरफेस काउंटरने काय केले आणि अनुप्रयोग प्रत्यक्षात कशाची वाट पाहत होता.

पिंग टक्केवारी प्रत्यक्षात काय मोजते

इको प्रोब एका प्रोटोकॉलची एक दिशा एका पॅकेट आकाराने, तुम्ही निवडलेल्या कोणत्याही दराने तपासतो। मोठे अपलोड वाहून नेणारी बोगदा पूर्णपणे दुसरेच काही करत असते, आणि लहान प्रोब टाकून देणारी लिंक हस्तांतरणाला हानी करणारी लिंक असेलच असे नाही। टक्केवारी सर्वात महत्त्वाची असलेली वेळेची माहितीही चिरडून टाकते, कारण एकाच झोकात हरवलेली दहा उत्तरे एका तासाच्या अंतराने हरवलेल्या दहा उत्तरांइतकी नसतात। बोगद्याची कोणती बाजू काही टाकून देत होती हेही ती सांगू शकत नाही.

प्रोबचा निकाल मार्गाबद्दलचा सुगावा म्हणून ठेवा। नंतर तो निर्माण करणारी वेळ आणि सीमा शोधा.

आयुष्यभराच्या बेरजा नाही, काउंटर फरकांची तुलना करा

लक्षण दिसलेल्या खिडकीपूर्वी आणि नंतर, दोन्ही टोकांवर आणि तुम्ही नियंत्रित करता त्या प्रत्येक स्विच पोर्टवर वेळ-मुद्रांकित वाचन घ्या। त्रुटी, टाकून दिलेले आणि लिंक-स्थितीतील बदलांसह रहदारीचे प्रमाण नोंदवा, कारण महिन्यांत साचलेली शून्येतर बेरीज हा हा प्रसंग नाही तर इतिहास वर्णन करते। थांब्याच्या वेळी तीनने हललेला काउंटर तीन हजार दाखवणाऱ्या आणि कधीही न बदललेल्या काउंटरपेक्षा वेगळे निरीक्षण आहे.

ip -s link show dev eth0
nstat -az TcpRetransSegs TcpExtTCPTimeouts
date -u +%Y-%m-%dT%H:%M:%SZ

स्वीकृती त्रुटींमुळे टाकून दिलेले पॅकेट आणि इतर कारणांमुळे टाकून दिलेले पॅकेट वेगवेगळ्या काउंटरमध्ये राहतात, आणि हा फरक पुढील पावलाला बदलतो। त्रुटी काउंटर भौतिक किंवा ड्रायव्हर थराकडे इशारा करतात, तर रांगेचा दाब आणि धोरण-टाकून देणे त्याच्यावर कुठेतरी इशारा करतात। दिशा आणि इंटरफेसचे नावही जपून ठेवा, कारण अपलिंकवरील स्वीकृती-त्रुटी वाढ आणि बोगदा पॅकेट काउंटर परस्पर बदलण्यायोग्य नाहीत.

जर ड्रायव्हर तपशीलवार भौतिक काउंटर उघड करत असेल, तर ते त्या अॅडाप्टरच्या दस्तऐवजातून वाचा। दोन उत्पादकांमध्ये “drop” नावाच्या प्रत्येक क्षेत्राला एकच अर्थ देणे म्हणजे सामान्य लेखाशास्त्रीय विचित्रता हार्डवेअर निदानात कशी बदलते याचा मार्ग.

हरवलेला विभाग दीर्घ प्रतीक्षा कसा बनतो

विभाग हरवल्यानंतर अनुप्रयोग एका फेरीपेक्षा खूप जास्त काळ थांबू शकतो। TCP प्रवासाचा वेळ अंदाजतो, त्या अंदाजातून पुनःप्रेषण टाइमर काढतो आणि पुनःप्रेषणही अयशस्वी झाल्यास मागे हटतो, त्यामुळे चुकीच्या क्षणी हरवलेला एकच विभाग विनंती लक्षणीय अंतरालासाठी थांबवू शकतो। ही यंत्रणा RFC 6298 मध्ये निर्दिष्ट आहे, आणि क्षुल्लक वाटणारा लॉस दर तरीही का जाणवतो हे ते स्पष्ट करते.

मात्र प्रत्येक खंड पुनःप्रेषण कालबाह्यता नाही। तीच प्रतीक्षा नाव-निराकरण, संथ सर्व्हर किंवा अपयशानंतर स्वतःची विनंती पुन्हा प्रयत्न करणाऱ्या अनुप्रयोगातून येऊ शकते। अपयशी क्रियेला वाहतूक निरीक्षणांशी आणि बोगद्याच्या स्वतःच्या सत्र घटनांशी जुळवून ती प्रकरणे वेगळी करा। पुनर्जोडणी न करता डेटा मार्गावरील व्यत्यय नव्या हस्तांदोलन आणि ओळखपत्रांच्या देवघेवीपेक्षा वेगळी घटना आहे.

जिथे कॅप्चरला परवानगी आहे तिथे ते अरुंद ठेवा। तुम्हाला हवे आहे की अपेक्षित पॅकेट किंवा पोच या विशिष्ट सीमेवर थांबतात का, व्यस्त ट्रेसमध्ये कुठेतरी पुनःप्रेषण आहे ही वस्तुस्थिती नाही.

इतरांना हलविल्याशिवाय एक सीमा बदला

जर पुरावे स्थानिक लिंककडे इशारा करत असतील, तर नियंत्रित तुलना म्हणून मंजूर केबल किंवा पोर्ट बदला आणि बाकी सर्व तसेच ठेवा। टोक, अनुप्रयोग आणि कामाचा भार तुलनीय ठेवा, आणि प्रत्येक प्रयत्नात नेमकी एक सीमा बदला। वायर्ड लॅपटॉपची वायरलेसशी तुलना करताना एक्झिट आणि प्रोटोकॉलही बदलल्यास तुम्हाला असे काही कळत नाही जे तुम्ही आरोपीत करू शकता.

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