કેબલને દોષ આપતા પહેલાં પેકેટ લોસ કેવી રીતે વાંચવો

લાંબી પિંગ શ્રેણી દરમિયાન બે ટકા લોસ એવા આંકડા જેવો લાગે છે જેના પર તમે કાર્ય કરી શકો, અને એવું ભાગ્યે જ હોય છે. તે કહેતું નથી કે જવાબો ક્યાં ખોવાયા, તેઓ એકસાથે ખોવાયા કે નહીં, અથવા કોઈ ચોક્કસ એપ્લિકેશને તે અંતરાલ કેવી રીતે અનુભવ્યું. એક મિનિટમાં સમાનરૂપે વહેંચાયેલો લોસ અને એક જ આદાનપ્રદાનમાં એકઠો થયેલો લોસ સમાન ટકાવારી માટે ઘણા જુદા પરિણામો આપે છે.

એક પર ભરોસો કરવાને બદલે ત્રણ માપની સરખામણી કરો: પ્રોબે શું જોયું, ઇન્ટરફેસ કાઉન્ટરોએ શું કર્યું અને એપ્લિકેશને ખરેખર શેની રાહ જોઈ.

પિંગ ટકાવારી ખરેખર શું માપે છે

ઇકો પ્રોબ એક પ્રોટોકોલની એક દિશાને એક પેકેટ કદ સાથે, તમે પસંદ કરેલા દરે ચકાસે છે. મોટા અપલોડને વહન કરતું ટનલ સાવ બીજું કાર્ય કરે છે, અને નાના પ્રોબ ફેંકી દેતી લિંક એ જ લિંક હોવી જરૂરી નથી જે ટ્રાન્સફરને નુકસાન પહોંચાડે છે. ટકાવારી સૌથી મહત્વપૂર્ણ સમયની માહિતી પણ કચડી નાખે છે, કારણ કે એક ઝાપટમાં ખોવાયેલા દસ જવાબો એક કલાકના અંતરે ખોવાયેલા દસ જવાબો સમાન નથી. તે તમને એ પણ કહી શકતું નથી કે ટનલની કઈ બાજુએ કંઈક ફેંક્યું.

પ્રોબનું પરિણામ માર્ગ વિશેના સંકેત તરીકે રાખો. પછી તેને ઉત્પન્ન કરનાર સમય અને સીમા શોધો.

કાઉન્ટર ડેલ્ટા સરખાવો, આજીવન કુલ નહીં

લક્ષણ દેખાયું તે વિન્ડો પહેલાં અને પછી, બંને અંત્યબિંદુઓ પર અને તમે નિયંત્રિત કરો તે દરેક સ્વિચ પોર્ટ પર સમયછાપવાળા વાંચન લો. ભૂલો, બાકાત અને લિંક-સ્થિતિના ફેરફારો સાથે ટ્રાફિકનું પ્રમાણ નોંધો, કારણ કે મહિનાઓ દરમિયાન એકઠું થયેલું બિન-શૂન્ય કુલ ઇતિહાસનું વર્ણન કરે છે, આ ઘટનાનું નહીં. સ્થગિતતા દરમિયાન ત્રણ જેટલું ખસેલું કાઉન્ટર ત્રણ હજાર દર્શાવતા અને કદી ન બદલાયેલા કાઉન્ટર કરતાં જુદું અવલોકન છે.

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

સ્વીકૃતિ ભૂલોને કારણે બાકાત થયેલા પેકેટો અને બીજા કારણોસર બાકાત થયેલા પેકેટો અલગ કાઉન્ટરોમાં રહે છે, અને આ તફાવત આગળની કાર્યવાહી બદલે છે. ભૂલ કાઉન્ટરો ભૌતિક અથવા ડ્રાઇવર સ્તર તરફ સંકેત કરે છે, જ્યારે કતારનું દબાણ અને નીતિ-બાકાત તેની ઉપર ક્યાંક સંકેત કરે છે. દિશા અને ઇન્ટરફેસનું નામ પણ સાચવો, કારણ કે અપલિંક પર સ્વીકૃતિ-ભૂલનો વધારો અને ટનલ પેકેટ કાઉન્ટર એકબીજાના બદલે વપરાઈ શકે નહીં.

જો ડ્રાઇવર વિગતવાર ભૌતિક કાઉન્ટરો બહાર કાઢે, તો તે એડાપ્ટરના દસ્તાવેજીકરણ દ્વારા વાંચો. બે ઉત્પાદકોમાં “drop” નામના દરેક ક્ષેત્રને એક જ અર્થ આપવો એ સામાન્ય હિસાબી વિચિત્રતાને હાર્ડવેર નિદાનમાં ફેરવવાનો રસ્તો છે.

ખોવાયેલો સેગમેન્ટ લાંબી રાહ કેવી રીતે બને છે

સેગમેન્ટ ખોવાયા પછી એપ્લિકેશન એક રાઉન્ડ ટ્રિપ કરતાં ઘણો વધુ સમય રાહ જોઈ શકે છે. TCP રાઉન્ડ-ટ્રિપ સમયનો અંદાજ કાઢે છે, તે અંદાજમાંથી પુનઃમોકલવાનો ટાઇમર ગણે છે અને જ્યારે પુનઃમોકલવું પણ નિષ્ફળ જાય ત્યારે પાછળ હટે છે, તેથી ખોટી ક્ષણે ખોવાયેલો એક જ સેગમેન્ટ વિનંતીને નોંધપાત્ર અંતરાલ સુધી થોભાવી શકે છે. આ માળખું RFC 6298 માં નિર્દિષ્ટ છે, અને તે સમજાવે છે કે નજીવો દેખાતો લોસ દર પણ કેમ અનુભવાય છે.

જો કે દરેક વિરામ પુનઃમોકલવાનો સમયસમાપ્તિ નથી. એ જ રાહ નામ-નિરાકરણ, ધીમા સર્વર અથવા નિષ્ફળતા પછી પોતાની વિનંતી ફરી અજમાવતી એપ્લિકેશનમાંથી આવી શકે છે. નિષ્ફળ ક્રિયાને પરિવહન અવલોકનો અને ટનલની પોતાની સત્ર ઘટનાઓ સાથે સંરેખિત કરીને તે કેસોને અલગ કરો. પુનઃકનેક્શન વિના ડેટા માર્ગ પર વિક્ષેપ નવા હેન્ડશેક અને ઓળખપત્રની આપલે કરતાં જુદી ઘટના છે.

જ્યાં કેપ્ચરની પરવાનગી છે ત્યાં તેને સાંકડું રાખો. તમારે જે જોઈએ છે તે એ છે કે અપેક્ષિત પેકેટો કે સ્વીકૃતિઓ ચોક્કસ સીમા પર અટકે છે કે નહીં, વ્યસ્ત ટ્રેસમાં ક્યાંક પુનઃમોકલવું અસ્તિત્વમાં છે તે હકીકત નહીં.

બીજાને ખસેડ્યા વિના એક સીમા બદલો

જો પુરાવા સ્થાનિક લિંક તરફ ઇશારો કરે, તો નિયંત્રિત સરખામણી તરીકે મંજૂર કેબલ કે પોર્ટ બદલો અને બાકી બધું અકબંધ રાખો. અંત્યબિંદુ, એપ્લિકેશન અને કાર્યભાર સરખાવી શકાય તેવા રાખો, અને દરેક પ્રયાસે બરાબર એક સીમા બદલો. વાયરવાળા લેપટોપની વાયરલેસ સાથે સરખામણી કરતી વખતે એક્ઝિટ અને પ્રોટોકોલ પણ બદલવાથી તમને એવું કંઈ મળતું નથી જે તમે આરોપી શકો.

સ્વચ્છ સ્થાનિક કાઉન્ટરો બાકીના માર્ગનું પ્રમાણપત્ર આપતા નથી. તેઓ તમે જુઓ છો તે ભાગને મર્યાદિત કરે છે, અને પ્રામાણિક અહેવાલ કહે છે કે કઈ સીમાઓ અવલોકાઈ અને કઈ નહીં. અંતે તમારે એવું નિવેદન જોઈએ છે કે એક હસ્તક્ષેપ થયો ત્યારે એક અવલોકન બદલાયું, ખરાબ કેબલ વિશેની વાત નહીં જે સાર્વત્રિક નિયમ સુધી ઊંચી કરવામાં આવી હોય.