आधा डुप्लेक्स में स्विचपोर्ट - डाउनलोड गति पीड़ित लेकिन अपलोड ठीक था

एक उपयोगकर्ता के पास इंटरनेट से डाउनलोड गति के साथ समस्याएं थीं। इंटरनेट का कनेक्शन 100 Mbit / s है। उपयोगकर्ता को 7 Mbit / s डाउनस्ट्रीम और लगभग 80 Mbit / s अपस्ट्रीम मिला।

मैंने अपने कंप्यूटर से परीक्षण किया और यह लगभग 70 Mbit / s डाउनस्ट्रीम और 80 Mbit / s अपस्ट्रीम में मिला। जाहिर है कि उपयोगकर्ताओं को पीसी को दोष देना था।

मैंने स्विच की जाँच की जो एक कैटलिस्ट 3560 है और वहाँ जैसा कि मुझे उम्मीद थी, पोर्ट आधे डुप्लेक्स में था। उपयोगकर्ता ने अपने पीसी को 100 / पूर्ण हार्ड कोडित किया था और पोर्ट ऑटो का उपयोग कर रहा था। फास्ट लिंक पल्स (एफएलपी) द्वारा गति का पता लगाया जाता है, लेकिन द्वैध को आधा होना चाहिए, इसलिए पोर्ट 100 या आधा का उपयोग कर रहा था। शो कंट्रोलर के साथ मैं टकराव और उम्मीद के मुताबिक देर से टकराव देख सकता था।

बैंडविड्थ का परीक्षण सिन साइट www.bredbandskollen.se के माध्यम से किया गया था। यह पहली बार विलंबता का परीक्षण करने के लिए टीसीपी का उपयोग करता है। फिर यह फ्लैश के माध्यम से एक सॉकेट खोलता है और कई HTTP GET (टीसीपी) करता है और डाउनस्ट्रीम बैंडविथ को लगभग 10 सेकंड के लिए मापता है। इसके बाद यह सर्वर पर चार HTTP पोस्ट करता है और 10 सेकंड के लिए ट्रैफ़िक भेजता है और अपस्ट्रीम बैंडविड्थ की गणना करता है।

मुझे पता है कि इस तरह की साइटें 100% सटीक नहीं हैं, लेकिन आमतौर पर वे कम से कम किसी तरह का संकेत दे सकते हैं यदि आप उस तरह की बैंडविड्थ प्राप्त करना चाहते हैं जो आपको चाहिए और यह सुनिश्चित करने के लिए चलाने के लिए एक आसान परीक्षण था उपयोगकर्ता और यहां गलती पर नेटवर्क नहीं।

केवल बहाव ही क्यों प्रभावित हुआ और अपस्ट्रीम नहीं?
क्या ये वास्तविक टकराव हैं? चूंकि केबल में अलग-अलग प्रसारण होते हैं और जोड़े प्राप्त होते हैं।

— डैनियल डिब
स्रोत

क्या 70/80 एकल परीक्षण या कई परीक्षणों के औसत पर आधारित हैं? अलग-अलग खिड़की के आकार को ध्यान में रखते हुए एक भी परीक्षण बहुत अस्पष्ट होगा।

— user2964971

यह एक द्वैध बेमेल के साथ पूरी तरह से सामान्य व्यवहार है।

केवल बहाव ही क्यों प्रभावित हुआ और अपस्ट्रीम नहीं?

चूंकि कंप्यूटर पूर्ण द्वैध मोड में काम कर रहा है, इसलिए यह CSMA-CD का उपयोग नहीं कर रहा है। इसका मतलब यह है कि यह जांच नहीं करता है कि माध्यम संचारित होने से पहले निष्क्रिय है या नहीं, न ही इसे टकराव के रूप में संचारित करते समय प्राप्त होने वाले किसी भी डेटा का अनुभव होगा। जैसे, कंप्यूटर से अपलोड अप्रभावित रहेगा।

इसके विपरीत, स्विच CSMA-CD का उपयोग कर रहा है और इसके प्रसारित होने से पहले माध्यम के निष्क्रिय होने की प्रतीक्षा करेगा। इसके अलावा, जब स्विच टकराव का पता लगाता है, तो यह तुरंत फ्रेम को प्रसारित करना बंद कर देता है और CSMA-CD टक्कर का पता लगाने की प्रक्रिया का अनुसरण करता है। इससे कंप्यूटर पर भेजे जाने वाले ट्रैफ़िक पर महत्वपूर्ण प्रदर्शन प्रभाव पड़ता है।

जब ट्रैफिक टीसीपी होता है, तो नकारात्मक प्रभाव कई गुना हो जाएगा क्योंकि किसी भी खोए हुए टीसीपी एसीके के कंप्यूटर पर जाने से एक टीसीपी पुन: प्रवेश होगा।

क्या ये वास्तविक टकराव हैं? चूंकि केबल में अलग-अलग प्रसारण होते हैं और जोड़े प्राप्त होते हैं।

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

चूंकि स्विच आधे डुप्लेक्स मोड में चल रहा है, यह ऐसे वातावरण में चल रहा है और किसी भी समय केवल संचारित या प्राप्त कर सकता है। किसी भी समय स्विच एक फ्रेम भेज रहा है और माध्यम पर अन्य ट्रैफ़िक का पता लगाता है (यानी कंप्यूटर, जो निष्क्रिय माध्यम की जाँच नहीं कर रहा है), इसे टकराव के रूप में माना जाता है और स्विच टकराव का पता लगाने की प्रक्रिया का पालन करेगा (जिसमें एक शामिल है समय की प्रतीक्षा करें या वापस बंद करें)।

जैसा कि कंप्यूटर इस तरह से काम नहीं कर रहा है (यानी यह भेजने के लिए डेटा होने पर स्वचालित रूप से संचारित होना शुरू हो जाता है), आप कई और टकरावों से खत्म हो जाते हैं, जितना कि आप एक ऐसे वातावरण में प्राप्त करेंगे जो पूरी तरह से आधे डुप्लेक्स उपकरणों से बना था।

संपादित करें: मैं इस सप्ताह के अंत में एक असंबंधित मामले की खोज करते हुए इन संदर्भों में आया था, जहां उन्हें झूठे टकराव के रूप में संदर्भित किया गया था । मैं इस दृष्टिकोण से असहमत हूं क्योंकि स्विच स्पष्ट रूप से उन्हें टकराव के रूप में देखता है और उन्हें इस तरह से संभालता है। बल्कि, मैं उनके बारे में अनावश्यक टकराव के बारे में सोचूंगा कि वे एक स्विच्ड नेटवर्क में मौजूद न हों।

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

— YLearn
स्रोत

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

— माइक पेनिंगटन

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

— रेमी लेटर्न्यू

@RemiLetourneau, स्पष्ट रूप से अगर बेमेल की दिशा को उलट दिया जाना था, तो प्रभाव भी उलट जाएगा। ऐसे मामले में आप मेरे उत्तर में कंप्यूटर / स्विच की शर्तों को स्वैप कर सकते हैं (जो ओपी के प्रश्न का उत्तर देने के लिए फ्रेम था)। मुझे यकीन नहीं है कि मैं आपकी सभी टिप्पणी का अनुसरण करता हूं।

— YLearn

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

— रेमी लेटर्न्यू 20

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

'sh नियंत्रकों' को किसी भी एक साथ RX और TX स्थिति को टकराव के रूप में रिपोर्ट करना चाहिए अगर आधे-द्वैध मोड में काम कर रहे हैं।

— औकाज़ ब्रोमिरस्की
स्रोत