विंडोज टीसीपी विंडो स्केलिंग हिटिंग पठार बहुत जल्दी

50

परिदृश्य: हमारे पास कई विंडोज क्लाइंट नियमित रूप से बड़ी फ़ाइलों (FTP / SVN / HTTP PUT / SCP) को लिनक्स सर्वरों पर अपलोड कर रहे हैं जो ~ 100-160ms दूर हैं। हमारे पास कार्यालय में 1Gbit / s सिंक्रोनस बैंडविड्थ है और सर्वर या तो AWS उदाहरण हैं या शारीरिक रूप से US DC में होस्ट किए गए हैं।

प्रारंभिक रिपोर्ट यह थी कि एक नए सर्वर उदाहरण पर अपलोड किए जाने की तुलना में बहुत धीमी थी। यह परीक्षण में और कई स्थानों से बाहर है; क्लाइंट अपने विंडोज सिस्टम से होस्ट को स्थिर 2-5Mbit / s देख रहे थे।

मैं iperf -sAWS के उदाहरण पर टूट गया और फिर कार्यालय में एक विंडोज क्लाइंट से:

iperf -c 1.2.3.4

[  5] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 55185
[  5]  0.0-10.0 sec  6.55 MBytes  5.48 Mbits/sec

iperf -w1M -c 1.2.3.4

[  4] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 55239
[  4]  0.0-18.3 sec   196 MBytes  89.6 Mbits/sec

उत्तरार्द्ध का आंकड़ा बाद के परीक्षणों पर काफी भिन्न हो सकता है, (AWS के Vagaries) लेकिन आमतौर पर 70 और 130Mbit / s के बीच होता है जो हमारी आवश्यकताओं के लिए पर्याप्त से अधिक है। Wiresharking सत्र, मैं देख सकता हूँ:

  • iperf -c विंडोज SYN - विंडो 64kb, स्केल 1 - लिनक्स SYN, ACK: विंडो 14kb, स्केल: 9 (* 512) डिफ़ॉल्ट 64kb विंडो के साथ iperf विंडो स्केलिंग
  • iperf -c -w1M विंडोज SYN - विंडोज 64kb, स्केल 1 - लिनक्स SYN, ACK: विंडो 14kb, स्केल: 9 डिफ़ॉल्ट 1MB विंडो के साथ iperf विंडो स्केलिंग

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

इसके विपरीत, एक ही नेटवर्क पर एक लिनक्स क्लाइंट से एक सीधा, iperf -c(सिस्टम डिफ़ॉल्ट 85kb का उपयोग करके) मुझे देता है:

[  5] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 33263
[  5]  0.0-10.8 sec   142 MBytes   110 Mbits/sec

किसी भी मजबूर के बिना, यह उम्मीद के अनुरूप है। यह हस्तक्षेप करने वाले हॉप्स या हमारे स्थानीय स्विच / राउटर में कुछ नहीं हो सकता है और विंडोज 7 और 8 क्लाइंट को समान रूप से प्रभावित करता है। मैंने ऑटो-ट्यूनिंग पर बहुत सारे गाइड पढ़े हैं, लेकिन ये आमतौर पर खराब भयानक होम नेटवर्किंग किट के आसपास काम करने के लिए स्केलिंग को अक्षम करने के बारे में हैं।

क्या कोई मुझे बता सकता है कि यहां क्या हो रहा है और मुझे इसे ठीक करने का एक तरीका देना है? (अधिमानतः कुछ मैं जीपीओ के माध्यम से रजिस्ट्री में चिपका सकता हूं।)

टिप्पणियाँ

प्रश्न में AWS लिनक्स उदाहरण में निम्नलिखित कर्नेल सेटिंग्स लागू हैं sysctl.conf:

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 1048576
net.core.wmem_default = 1048576
net.ipv4.tcp_rmem = 4096 1048576 16777216
net.ipv4.tcp_wmem = 4096 1048576 16777216

मैंने किसी अन्य संभावित अड़चन को दूर करने और हटाने के लिए सर्वर के अंत में dd if=/dev/zero | ncपुनर्निर्देशन का उपयोग किया है , लेकिन परिणाम बहुत समान हैं। ऊपर दिए गए iperf परीक्षणों के रूप में उसी तरह से टेस्ट (साइगविन, नेटिव विंडोज, लिनक्स) पैमाने पर टेस्ट किए जाते हैं।/dev/nulliperfncftp

संपादित करें

मैंने यहाँ एक और सुसंगत बात बताई है जो प्रासंगिक हो सकती है: यहाँ छवि विवरण दर्ज करें

यह 1MB कैप्चर का पहला सेकेंड है, जिसे ज़ूम इन किया गया है। आप विंडो स्टार्ट होने के बाद स्लो स्टार्ट एक्शन देख सकते हैं और बफर बड़ा हो जाता है। वहाँ तो ~ 0.2s के इस छोटे से पठार बिल्कुल बिंदु पर है कि डिफ़ॉल्ट विंडो iperf परीक्षण हमेशा के लिए बाहर समतल है। यह एक निश्चित रूप से बहुत चक्करदार ऊंचाइयों को बढ़ाता है, लेकिन यह उत्सुक है कि स्केलिंग में यह ठहराव है (ऐसा करने से पहले मान 1022bytes * 512 = 523264) हैं।

अपडेट - 30 जून।

विभिन्न प्रतिक्रियाओं के बाद:

  • CTCP सक्षम करना - इससे कोई फर्क नहीं पड़ता; विंडो स्केलिंग समान है। (यदि मैं इसे सही ढंग से समझता हूं, तो यह सेटिंग उस दर को बढ़ा देती है जिस पर भीड़ की खिड़की अधिकतम आकार के बजाय बढ़ जाती है)
  • टीसीपी टाइमस्टैम्प को सक्षम करना। - यहां भी कोई बदलाव नहीं।
  • नागल का एल्गोरिथ्म - जो समझ में आता है और कम से कम इसका मतलब है कि मैं शायद ग्राफ़ में उस विशेष ब्लिप्स को समस्या के किसी भी संकेत के रूप में अनदेखा कर सकता हूं।
  • pcap फाइलें: जिप फाइल यहां उपलब्ध है: https://www.dropbox.com/s/104qdysmk01lnf6/iperf-pcaps-10s-Win%2BLinux-2014-06-30.zip (bwwiste के साथ अनाम, ~ 150MB तक अर्क) तुलना के लिए प्रत्येक OS क्लाइंट से एक)

अपडेट 2 - 30 जून

ओ, इसलिए काइल सुझाव पर निम्नलिखित, मैंने ctcp और अक्षम चिमनी ऑफ़लोडिंग सक्षम किया है: टीसीपी ग्लोबल पैरामीटर्स

----------------------------------------------
Receive-Side Scaling State          : enabled
Chimney Offload State               : disabled
NetDMA State                        : enabled
Direct Cache Acess (DCA)            : disabled
Receive Window Auto-Tuning Level    : normal
Add-On Congestion Control Provider  : ctcp
ECN Capability                      : disabled
RFC 1323 Timestamps                 : enabled
Initial RTO                         : 3000
Non Sack Rtt Resiliency             : disabled

लेकिन दुख की बात है कि थ्रूपुट में कोई बदलाव नहीं हुआ।

मेरे पास यहां कारण / प्रभाव का सवाल है, हालांकि: रेखांकन क्लाइंट के सर्वर में ACWs में निर्धारित RWIN मान के हैं। विंडोज क्लाइंट्स के साथ, क्या मैं यह सोचने में सही हूं कि लिनक्स उस मूल्य को उस निम्न बिंदु से आगे नहीं बढ़ा रहा है क्योंकि क्लाइंट का सीमित सीडब्ल्यूआईएन उस बफर को भी भरने से रोकता है? क्या कोई और कारण हो सकता है कि लिनक्स कृत्रिम रूप से RWIN को सीमित कर रहा है?

नोट: मैंने ईसीएन को इसके नरक के लिए चालू करने की कोशिश की है; लेकिन कोई बदलाव नहीं।

अपडेट ३ - ३१ जून।

हेयुरेटिक्स और RWIN ऑटोट्यूनिंग को अक्षम करने के बाद कोई परिवर्तन नहीं। ने सॉफ्टवेयर के साथ नवीनतम (12.10.28.0) इंटेल नेटवर्क ड्राइवरों को अपडेट किया है जो कि फंक्शनलियोएनलिटी ट्विकस वाइडेविस मैनेजर टैब को उजागर करता है। कार्ड एक 82579V चिपसेट ऑन-बोर्ड एनआईसी है - (मैं रियलटेक या अन्य विक्रेताओं के साथ ग्राहकों से कुछ और परीक्षण करने जा रहा हूं)

एक पल के लिए एनआईसी पर ध्यान केंद्रित करते हुए, मैंने निम्नलिखित की कोशिश की है (ज्यादातर सिर्फ असंभव अपराधियों को सत्तारूढ़ करना):

  • बफ़र्स को 256 से 2k तक बढ़ाएं और बफ़र्स को 512 से 2k तक प्रसारित करें (दोनों अब अधिकतम पर) - कोई परिवर्तन नहीं
  • अक्षम सभी आईपी / टीसीपी / यूडीपी चेकसम ऑफलोडिंग। - कोई परिवर्तन नहीं होता है।
  • विकलांग बड़े भेजें बोझ - नाडा।
  • IPv6, QoS शेड्यूल करना बंद कर दिया - Nowt।

अपडेट 3 - जुलाई 3

लिनक्स सर्वर पक्ष को खत्म करने की कोशिश कर रहा है, मैंने एक सर्वर 2012R2 उदाहरण शुरू किया और iperf(cygwin बाइनरी) और NTttcp का उपयोग करके परीक्षणों को दोहराया ।

साथ iperf, मैं स्पष्ट रूप से निर्दिष्ट किया था -w1mपर दोनों से पहले कनेक्शन परे ~ 5Mbit / एस पैमाने पर होता पक्षों। (संयोग से, मुझे चेक किया जा सकता है और 91ms विलंबता पर ~ 5Mbit की BDP लगभग ठीक 64kb है। सीमा को सीमित करें ...)

Ntttcp बायनेरिज़ ने अब ऐसी सीमा दिखाई। ntttcpr -m 1,0,1.2.3.5सर्वर और ntttcp -s -m 1,0,1.2.3.5 -t 10क्लाइंट पर उपयोग करके , मैं बहुत बेहतर थ्रूपुट देख सकता हूं:

Copyright Version 5.28
Network activity progressing...


Thread  Time(s) Throughput(KB/s) Avg B / Compl
======  ======= ================ =============
     0    9.990         8155.355     65536.000

#####  Totals:  #####

   Bytes(MEG)    realtime(s) Avg Frame Size Throughput(MB/s)
================ =========== ============== ================
       79.562500      10.001       1442.556            7.955

Throughput(Buffers/s) Cycles/Byte       Buffers
===================== =========== =============
              127.287     308.256      1273.000

DPCs(count/s) Pkts(num/DPC)   Intr(count/s) Pkts(num/intr)
============= ============= =============== ==============
     1868.713         0.785        9336.366          0.157

Packets Sent Packets Received Retransmits Errors Avg. CPU %
============ ================ =========== ====== ==========
       57833            14664           0      0      9.476

8MB / s इसे उन स्तरों पर रखता है जो मुझे स्पष्ट रूप से बड़ी खिड़कियों के साथ मिल रहे थे iperf। विचित्र रूप से, हालांकि, 1273 बफ़र्स में 80MB = 64kB बफर फिर से। एक और वायरशर्क सर्वर से एक अच्छा, परिवर्तनशील आरडब्ल्यूआईएन दिखा रहा है (स्केल फैक्टर 256) जिसे ग्राहक पूरा करता है; तो शायद ntttcp भेजें विंडो को गलत बता रहा है।

अद्यतन 4 - जुलाई 3

@ Karyhead के अनुरोध पर, मैंने कुछ और परीक्षण किए हैं और कुछ और कैप्चर किए हैं, यहां: https://www.dropbox.com/s/dtlvy1vi46x75it/iperf%2Bntttcp%2Bftp-pcaps-2014-07-03.zip

  • दो से अधिक iperfs, दोनों विंडोज से एक ही लिनक्स सर्वर से पहले (1.2.3.4): एक 128k सॉकेट आकार और डिफ़ॉल्ट 64k विंडो के साथ (एक बार फिर ~ 5Mbit / s तक सीमित) और एक 1MB सेंड विंडो और डिफ़ॉल्ट 8k सॉकेट के साथ। आकार। (तराजू अधिक)
  • ntttcpसर्वर 2012R2 EC2 उदाहरण (1.2.3.5) में समान विंडोज क्लाइंट से एक ट्रेस। यहाँ, थ्रूपुट तराजू अच्छी तरह से। नोट: NTttcp पोर्ट 6001 पर परीक्षण कनेक्शन खोलने से पहले कुछ अजीब करता है। यकीन नहीं होता कि वहां क्या हो रहा है।
  • एक एफ़टीपी डेटा ट्रेस, /dev/urandomसिग्विन का उपयोग करके समरूप लिनक्स होस्ट (1.2.3.6) के पास 20MB अपलोड करना ncftp। फिर से मर्यादा है। Windows Filezilla का उपयोग करके पैटर्न बहुत समान है।

iperfबफर लंबाई बदलने से समय अनुक्रम ग्राफ (बहुत अधिक ऊर्ध्वाधर खंड) में अपेक्षित अंतर पड़ता है, लेकिन वास्तविक थ्रूपुट अपरिवर्तित होता है।

windows  networking  tcp 
— SmallClanger
स्रोत
11
एक अच्छी तरह से शोध की गई समस्या का एक दुर्लभ उदाहरण जो प्रलेखन में स्पष्ट रूप से नहीं है। अच्छा - चलो उम्मीद करते हैं कि कोई व्यक्ति एक समाधान ढूंढता है (क्योंकि किसी तरह मुझे लगता है कि मैं भी इसका उपयोग कर सकता हूं)।
— टॉमटॉम
2
RFC 1323 टाइमस्टैम्प को चालू करने का प्रयास करें क्योंकि वे विंडोज में डिफ़ॉल्ट रूप से अक्षम हैं जबकि लिनक्स ने उन्हें डिफ़ॉल्ट रूप से सक्षम किया है)। netsh int tcp set global timestamps=enabled
— ब्रायन
3
200 एमएस विलंब शायद कार्रवाई में नागल एल्गोरिथ्म है। जैसा कि किसी विशेष कनेक्शन पर टीसीपी द्वारा डेटा प्राप्त किया जाता है, यह केवल तभी पावती भेजता है, जब निम्न में से कोई एक सत्य हो: प्राप्त पिछले खंड के लिए कोई पावती नहीं भेजी गई थी; एक खंड प्राप्त होता है, लेकिन उस कनेक्शन के लिए 200 मिलीसेकंड के भीतर कोई अन्य खंड नहीं आता है।
— ग्रेग आस्क्यू
2
कहीं धीमी गति से भेजने वालों में से कुछ पैकेट कैप्चर करने का कोई मौका?
— काइल ब्रान्ड
मैंने अपने ओपी को इन परीक्षणों और प्रतिनिधि कैप्चर फ़ाइलों के लिंक के परिणामों के साथ अपडेट किया है।
— स्मॉलक्लैंगर

जवाबों:

15

क्या आपने अपने विंडोज 7/8 क्लाइंट्स में कंपाउंड टीसीपी (CTCP) को सक्षम करने की कोशिश की है।

कृपया पढ़ें:

हाई-बीडीपी ट्रांसमिशन के लिए प्रेषक-साइड प्रदर्शन बढ़ाना

http://technet.microsoft.com/en-us/magazine/2007.01.cableguy.aspx

...

ये एल्गोरिदम छोटे बीडीपी के लिए अच्छी तरह से काम करते हैं और छोटे को खिड़की के आकार मिलते हैं। हालाँकि, जब आपके पास एक बड़ी प्राप्त विंडो आकार और बड़े बीडीपी के साथ एक टीसीपी कनेक्शन होता है , जैसे कि 100ms राउंड-ट्रिप समय के साथ उच्च गति वाले WAN लिंक पर स्थित दो सर्वरों के बीच डेटा की प्रतिकृति , ये एल्गोरिदम सेंड विंडो नहीं बढ़ाते हैं काफी तेजी से पूरी तरह से कनेक्शन की बैंडविड्थ का उपयोग करने के लिए ।

इन स्थितियों में टीसीपी कनेक्शन की बैंडविड्थ का बेहतर उपयोग करने के लिए, नेक्स्ट जनरेशन टीसीपी / आईपी स्टैक में कंपाउंड टीसीपी (सीटीपीसी) शामिल है। CTCP बड़े प्राप्त विंडो आकार और BDPs के साथ कनेक्शन के लिए अधिक आक्रामक तरीके से भेजें विंडो को बढ़ाता है । CTCP विलंब भिन्नताओं और नुकसानों की निगरानी करके इस प्रकार के कनेक्शनों पर थ्रूपुट को अधिकतम करने का प्रयास करता है। इसके अलावा, CTCP सुनिश्चित करता है कि इसका व्यवहार अन्य TCP कनेक्शन को नकारात्मक रूप से प्रभावित न करे।

...

Windows Server 2008 चलाने वाले कंप्यूटरों में डिफ़ॉल्ट रूप से CTCP सक्षम है और Windows Vista चलाने वाले कंप्यूटरों में डिफ़ॉल्ट रूप से अक्षम है। आप netsh interface tcp set global congestionprovider=ctcpकमांड के साथ CTCP सक्षम कर सकते हैं । आप CTCP को netsh interface tcp set global congestionprovider=noneकमांड से निष्क्रिय कर सकते हैं ।

6/30/2014 को संपादित करें

देखना है कि क्या CTCP वास्तव में "चालू" है

> netsh int tcp show global

अर्थात

यहाँ छवि विवरण दर्ज करें

PO ने कहा:

यदि मैं यह सही ढंग से समझ, इस सेटिंग दर से बढ़ जाती है जो भीड़ खिड़की बल्कि अधिकतम आकार की तुलना में बढ़े हुए है वहां पहुंच सकते हैं

CTCP आक्रामक तरीके से भेजें विंडो को बढ़ाता है

http://technet.microsoft.com/en-us/library/bb878127.aspx

यौगिक टीसीपी

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

ये एल्गोरिदम लैन मीडिया स्पीड और छोटे टीसीपी विंडो आकार के लिए अच्छी तरह से काम करते हैं। हालाँकि, जब आपके पास एक बड़े प्राप्त विंडो आकार और एक बड़े बैंडविड्थ-विलंब उत्पाद (उच्च बैंडविड्थ और उच्च विलंब) के साथ एक टीसीपी कनेक्शन होता है, जैसे कि 100 एमएस राउंड ट्रिप के साथ उच्च गति वाले WAN लिंक पर स्थित दो सर्वरों के बीच डेटा की नकल करना समय, इन एल्गोरिदम तेजी से भेज खिड़की नहीं बढ़ाता पूरी तरह से कनेक्शन की बैंडविड्थ का उपयोग करने के लिए। उदाहरण के लिए, प्रति सेकंड 1 गीगाबिट (Gbps) WAN लिंक पर 100 ms राउंड ट्रिप टाइम (RTT) के साथ, सेंड विंडो के लिए शुरुआत में एक घंटे तक का समय लग सकता है , जिससे रिसीवर द्वारा विज्ञापित की जा रही बड़ी विंडो साइज़ में वृद्धि हो सकती है। खो जाने वाले खंडों को पुनर्प्राप्त करने के लिए ।

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

Microsoft में आंतरिक रूप से किए गए परीक्षण में, 50ms RTT के साथ 1 Gbps कनेक्शन के लिए बड़े फ़ाइल बैकअप समय को लगभग आधा कर दिया गया था। एक बड़े बैंडविड्थ देरी उत्पाद के साथ कनेक्शन में और भी बेहतर प्रदर्शन हो सकता है। सीटीसीपी और रिसीव विंडो ऑटो-ट्यूनिंग बढ़ी हुई उपयोग के लिए एक साथ काम करते हैं और बड़े बैंडविड्थ-देरी उत्पाद कनेक्शन के लिए पर्याप्त प्रदर्शन लाभ प्राप्त कर सकते हैं।

— थपथपाना
स्रोत
3
इस उत्तर के पूरक के रूप में, सर्वर 2012 / Win8.1 में Powershell समकक्ष पैरामीटर के Set-NetTCPSettingसाथ है -CongestionProvider... जो CCTP, DCTCP और डिफ़ॉल्ट को स्वीकार करता है। विंडोज क्लाइंट और सर्वर विभिन्न डिफॉल्ट कंजेशन प्रोवाइडर्स का उपयोग करते हैं। Technet.microsoft.com/en-us/library/hh826132.aspx
— रेयान रीज़
मैं देख रहा हूं कि आप क्या कर रहे हैं, लेकिन यह लागू नहीं होता है। इसकी खातिर, मैंने 30 मिनट चलाए iperfऔर विंडो अभी भी ~ 520kb से आगे नहीं बढ़ पाई। कुछ और CWND को सीमित कर रहा है इससे पहले कि यह आक्रामक एल्गोरिदम कोई लाभ दिखा सके।
— स्मॉल क्लैन्जर
एक पुरानी (पहले से तय) विस्टा बग है जिसने इस तरह की समस्याओं को गैर-एचटीएमएल प्रोटोकॉल प्रसारित करते समय प्रस्तुत किया है। क्या आपकी समस्या एचटीएमएल द्वारा उसी फ़ाइल को स्थानांतरित करते समय ठीक वैसी ही दिखती है या एफ़टीपी द्वारा बताई गई है?
— पैट
@Pat - यह करता है। एसवीएन कमिट्स (एचटीटीपी और एचटीटीपीएस के माध्यम से) और एएफएस पर एफ़टीपी एक अन्य प्रणाली में भी उसी सीमा को प्रदर्शित करता है।
— स्मॉलक्लैंगर
कैसे विन ग्राहक फ़ायरवॉल के बारे में? आप पूरी तरह से बंद फ़ायरवॉल के साथ परीक्षण कर सकते हैं? यहाँ देखें: ask.wireshark.org/questions/2365/tcp-window-size-and-scaling
— Pat
12

समस्या को स्पष्ट करना:

टीसीपी में दो विंडो हैं:

  • प्राप्त विंडो: बफर में कितने बाइट्स बचे हैं। यह रिसीवर द्वारा लगाया गया फ्लो कंट्रोल है। आप वायरशेकर में प्राप्त विंडो का आकार देख सकते हैं क्योंकि यह टीसीपी हेडर के अंदर विंडो आकार और विंडोिंग स्केलिंग कारक से बना है। टीसीपी कनेक्शन के दोनों पक्ष अपनी प्राप्त विंडो को विज्ञापित करेंगे, लेकिन आम तौर पर आप जिस चीज की परवाह करते हैं वह डेटा का थोक प्राप्त करने वाला होता है। आपके मामले में, यह "सर्वर" है क्योंकि क्लाइंट सर्वर पर अपलोड कर रहा है
  • भीड़ खिड़की। यह प्रेषक द्वारा लगाया गया प्रवाह नियंत्रण है। यह ऑपरेटिंग सिस्टम द्वारा बनाए रखा जाता है और टीसीपी हेडर में नहीं दिखता है। यह दर को नियंत्रित करता है कि कितनी तेजी से डेटा भेजा जाएगा।

आपके द्वारा प्रदान की गई कैप्चर फ़ाइल में। हम देख सकते हैं कि प्राप्त बफर कभी बह निकला नहीं है:

यहाँ छवि विवरण दर्ज करें

मेरा विश्लेषण यह है कि प्रेषक पर्याप्त तेज़ी से नहीं भेज रहा है क्योंकि प्रेषक विंडो (उर्फ कंजेशन कंट्रोल विंडो) रिसीवर के RWIN को संतुष्ट करने के लिए पर्याप्त नहीं खोल रहा है। इसलिए संक्षेप में रिसीवर "मुझे और दे दो" कहता है, और जब विंडोज प्रेषक होता है तो यह पर्याप्त तेजी से नहीं भेज रहा है।

यह इस तथ्य से स्पष्ट है कि उपरोक्त ग्राफ में RWIN खुला रहता है, और .09 सेकंड के राउंड ट्रिप समय और ~ 500,000 बाइट्स के RWIN के साथ हम बैंडविड्थ देरी उत्पाद के अनुसार अधिकतम थ्रूपुट की उम्मीद कर सकते हैं (500000) /0.09) * 8 = ~ 42 Mbit / s (और आप लिनक्स पर कब्जा करने के लिए अपनी जीत में केवल ~ 5 के बारे में प्राप्त कर रहे हैं)।

इसे कैसे जोड़ेंगे?

मुझे नहीं पता। interface tcp set global congestionprovider=ctcpमुझे करने के लिए सही चीज़ लगती है क्योंकि इससे सेंड विंडो (जो कि कंजेशन विंडो के लिए एक और शब्द है) बढ़ जाएगी। आपने कहा था कि काम नहीं कर रहा है। तो बस यह सुनिश्चित करने के लिए:

  1. क्या आपने इसे सक्षम करने के बाद रिबूट किया?
  2. क्या चिमनी बंद है? अगर यह शायद एक प्रयोग के रूप में इसे बंद करने की कोशिश है। मुझे नहीं पता कि यह सक्षम होने पर वास्तव में क्या उतरा जाता है, लेकिन अगर भेजने वाली खिड़की को नियंत्रित करना उनमें से एक है, तो शायद यह सक्षम होने पर congestionprovider का कोई प्रभाव नहीं है ... मैं सिर्फ अनुमान लगा रहा हूं ...
  3. इसके अलावा, मुझे लगता है कि यह प्री विंडोज 7 हो सकता है, लेकिन आप HKEY_LOCAL_MACHINE-System-CurrentControletet-Services-AFD-Parameters में DefaultSendWindow और DefaultReceiveWindow नामक दो रजिस्ट्री कुंजियों के साथ जोड़ने और खेलने का प्रयास कर सकते हैं। अगर ये भी काम करते हैं, तो आप शायद इसे बीटीपी से बंद कर दें।
  4. अभी तक एक और अनुमान, बाहर की जाँच करने का प्रयास करें netsh interface tcp show heuristics। मुझे लगता है कि यह RWIN हो सकता है, लेकिन यह नहीं कहता है, इसलिए हो सकता है कि अक्षम करने / सक्षम करने के साथ खेलें क्योंकि यह भेजने की खिड़की को प्रभावित करता है।
  5. इसके अलावा, सुनिश्चित करें कि आपके ड्राइवर आपके परीक्षण क्लाइंट पर अद्यतित हैं। शायद कुछ टूट गया है।

मैं इन सभी प्रयोगों की कोशिश करूँगा कि आप ऑफ-लोडिंग सुविधाओं को बंद कर दें ताकि नेटवर्क ड्राइवर कुछ चीजों की रीराइटिंग / संशोधन कर सकें। TCP_OFFLOAD_STATE_DELEGATED struct कम से कम सूचित करते हैं कि CWnd बिकवाली कम से कम संभव है लगता है।

— काइल ब्रांड
स्रोत
2
मैंने आपके "उत्तर" की सूचना दी है क्योंकि तुम्हारा यह उत्तर नहीं है; मैंने तुरंत वोट डाला; अब मैं देख रहा हूँ कि कैसे "लोग" आपके "नो-उत्तर" को वोट कर रहे हैं ... वास्तव में बहुत मज़ेदार है
— Pat
1
@Pat: आप वोट नंबर क्लिक कर सकते हैं, अपवोट्स / डाउनवोट्स के टूटने को भी देख सकते हैं। वर्तमान में आपके उत्तर पर कोई डाउनवोट नहीं है। मेरा जवाब उसकी समस्या को हल नहीं करता है (लेकिन कोई जवाब अभी तक नहीं है), यह समस्या को समझाता है और स्थानीय करता है (उम्मीद है कि सही ढंग से!) जो समस्या निवारण में एक महत्वपूर्ण कदम है।
— काइल ब्रान्ड
@ काइल ब्रांट यदि आप स्वीकार करते हैं तो आप एक जवाब नहीं है मुझे आश्चर्य है कि यह "स्वचालित रूप से" बिना किसी और विचार के क्यों नहीं हटाया गया है ?? और आप गलत हैं; जैसे ही मैंने आपके "उत्तर" की सूचना दी, मुझे एक मत-मतान्तर (unupvote) "जैसे ही" मिला; अभी तक हटाया नहीं गया है। ऐसा लगता है कि आप यहां "विशेष" नियमों से खेलते हैं।
— पैट
1
@Pat यदि यह मदद करता है, तो काइल का गैर-उत्तर अविश्वसनीय रूप से मददगार रहा है। मुझे अब यह स्पष्ट रूप से पता है कि किस बफ़र को सीमित किया जा रहा है और मुझे लगता है कि परिणामस्वरूप मैं उचित समाधान के थोड़ा करीब हूं। कभी-कभी इस तरह के प्रश्न एक सहयोगात्मक प्रयास हो सकते हैं, जो थोड़े से विवेकपूर्ण संपादन के साथ उचित क्यू और उचित ए बन सकते हैं ।
— स्मॉलक्लैंगर
@SmallClanger पूरे सम्मान के साथ, SF में नियमों का एक सेट है, जिसका पालन केल ब्रांट सहित उसके सभी उपयोगकर्ताओं द्वारा किया जाना चाहिए; अगर उसका जवाब नहीं है, तो उसे मिटा दिया जाना चाहिए या टिप्पणी के रूप में स्थानांतरित कर दिया जाना चाहिए, भले ही उसके "मध्यस्थ" क्लब में कितने दोस्त हों।
— पैट
5

यहाँ @Pat और @Kyle द्वारा कुछ बेहतरीन जानकारी दी गई है। निश्चित रूप से टीसीपी प्राप्त करने और खिड़कियों को भेजने के @ काइल के विवरण पर ध्यान दें, मुझे लगता है कि उसके आसपास कुछ भ्रम हो गया है। आगे के मामलों को भ्रमित करने के लिए, iperf -wसेटिंग के साथ "TCP विंडो" शब्द का उपयोग करता है जो प्राप्त, भेजना या समग्र स्लाइडिंग विंडो के संबंध में अस्पष्ट शब्द की तरह है। यह वास्तव में क्या करता है सेट सॉकेट भेजने के लिए बफर -c(क्लाइंट) उदाहरण के लिए और सॉकेट बफर -s(सर्वर) उदाहरण पर प्राप्त करते हैं । इन src/tcp_window_size.c:

if ( !inSend ) {
    /* receive buffer -- set
     * note: results are verified after connect() or listen(),
     * since some OS's don't show the corrected value until then. */
    newTCPWin = inTCPWin;
    rc = setsockopt( inSock, SOL_SOCKET, SO_RCVBUF,
                     (char*) &newTCPWin, sizeof( newTCPWin ));
} else {
    /* send buffer -- set
     * note: results are verified after connect() or listen(),
     * since some OS's don't show the corrected value until then. */
    newTCPWin = inTCPWin;
    rc = setsockopt( inSock, SOL_SOCKET, SO_SNDBUF,
                     (char*) &newTCPWin, sizeof( newTCPWin ));
}

जैसा कि काइल का उल्लेख है, समस्या लिनक्स बॉक्स पर प्राप्त विंडो के साथ नहीं है, लेकिन प्रेषक पर्याप्त विंडो नहीं खोल रहा है। ऐसा नहीं है कि यह बहुत तेजी से नहीं खुलता है, यह सिर्फ 64k पर कैप करता है।

विंडोज 7 पर डिफ़ॉल्ट सॉकेट बफर का आकार 64k है। यहाँ MSDN पर थ्रूपुट के संबंध में सॉकेट बफर आकार के बारे में प्रलेखन क्या कहता है

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

ठीक है, ब्ला ब्ला ब्ला, अब हम यहाँ जाते हैं:

एक समय में एक अवरुद्ध या गैर-अवरुद्ध भेजने का अनुरोध करने वाले अनुप्रयोग आमतौर पर सभ्य थ्रूपुट को प्राप्त करने के लिए विनसॉक द्वारा आंतरिक भेजें बफरिंग पर भरोसा करते हैं। किसी दिए गए कनेक्शन के लिए भेजें बफर सीमा SO_SNDBUF सॉकेट विकल्प द्वारा नियंत्रित की जाती है। अवरुद्ध और गैर-अवरुद्ध भेजने की विधि के लिए, भेजें बफर सीमा निर्धारित करती है कि टीसीपी में कितना डेटा बकाया रखा गया है । यदि कनेक्शन के लिए आईएसबी मान भेजें बफर सीमा से बड़ा है, तो कनेक्शन पर प्राप्त थ्रूपुट इष्टतम नहीं होगा।

64k विंडो का उपयोग करके अपने सबसे हाल के iperf टेस्ट का औसत थ्रूपुट 5.8Mbps है। यह आँकड़े> Wireshark में सारांश है, जो सभी बिट्स को गिनता है। संभवतः, iperf टीसीपी डेटा थ्रूपुट की गिनती कर रहा है जो 5.7Mbps है। हम एफ़टीपी परीक्षण के साथ ही प्रदर्शन को देखते हैं, ~ 5.6 एमबीपीएस।

64k सेंड बफर और 91ms RTT के साथ सैद्धांतिक थ्रूपुट है .... 5.5Mbps। मेरे लिए पर्याप्त बंद करें।

यदि हम आपके 1MB विंडो iperf टेस्ट को देखते हैं, तो tput 88.2Mbps (सिर्फ TCP डेटा के लिए 86.2Mbps) है। 1MB विंडो के साथ सैद्धांतिक tput 87.9Mbps है। फिर, सरकारी काम के लिए पर्याप्त है।

यह प्रदर्शित करता है कि भेजने वाला सॉकेट बफर सीधे भेजने वाली विंडो को नियंत्रित करता है और दूसरी तरफ से प्राप्त विंडो के साथ युग्मित होता है, जो विवादास्पद को नियंत्रित करता है। विज्ञापित प्राप्त विंडो में कमरा है, इसलिए हम रिसीवर द्वारा सीमित नहीं हैं।

पकड़ो, इस ऑटोट्यूनिंग व्यवसाय के बारे में क्या? क्या विंडोज 7 अपने आप उस सामान को नहीं संभालता है? जैसा कि उल्लेख किया गया है, विंडोज प्राप्त विंडो के ऑटो-स्केलिंग को संभालता है, लेकिन यह डायनामिक रूप से सेंड बफर भी संभाल सकता है। आइए MSDN पृष्ठ पर वापस जाएं:

Windows 7 और Windows Server 2008 R2 पर TCP के लिए डायनेमिक सेंड बफ़रिंग जोड़ा गया था। जब तक कोई एप्लिकेशन SO_SNDBUF सॉकेट विकल्प को स्ट्रीम सॉकेट पर सेट नहीं करता है, तब तक टीसीपी के लिए डायनेमिक सेंक बफ़रिंग सक्षम है।

विकल्प SO_SNDBUFका उपयोग करते समय iperf उपयोग करता है -w, इसलिए डायनेमिक सेंक बफ़रिंग अक्षम हो जाएगा। हालाँकि, यदि आप उपयोग नहीं करते हैं -wतो यह उपयोग नहीं करता है SO_SNDBUF। डिफ़ॉल्ट रूप से डायनेमिक भेजें बफरिंग होनी चाहिए, लेकिन आप देख सकते हैं:

netsh winsock show autotuning

दस्तावेज़ कहता है कि आप इसे इसके साथ अक्षम कर सकते हैं:

netsh winsock set autotuning off

लेकिन यह मेरे लिए काम नहीं किया। मुझे एक रजिस्ट्री परिवर्तन करना था और इसे 0 पर सेट करना था:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters\DynamicSendBufferDisable

मुझे नहीं लगता कि यह अक्षम करने से मदद मिलेगी; यह सिर्फ एक FYI है।

जब रिसीव विंडो में बहुत सारे कमरे के साथ लिनक्स बॉक्स में डेटा भेजते हैं, तो डिफ़ॉल्ट 64k के ऊपर आपकी बफ़र स्केलिंग क्यों नहीं होती है? बड़ा सवाल है। लिनक्स कर्नेल में एक ऑटोट्यूनिंग टीसीपी स्टैक भी होता है। टी-दर्द और कान्ये की तरह एक ऑटोट्यून युगल को एक साथ करना, यह सिर्फ अच्छा नहीं लग सकता है। शायद उन दो ऑटोट्यूनिंग टीसीपी स्टैक के साथ कुछ समस्या है जो एक दूसरे से बात कर रहे हैं।

एक अन्य व्यक्ति को आपकी तरह ही एक समस्या थी और डिफ़ॉल्ट भेजने वाले बफ़र आकार को बढ़ाने के लिए रजिस्ट्री एडिट के साथ इसे ठीक करने में सक्षम था। दुर्भाग्य से, यह अब काम नहीं करता है, कम से कम यह मेरे लिए नहीं था जब मैंने इसे आज़माया।

इस बिंदु पर, मुझे लगता है कि यह स्पष्ट है कि सीमित कारक विंडोज होस्ट पर बफर का आकार है। यह देखते हुए कि यह गतिशील रूप से ठीक से नहीं बढ़ रहा है, एक लड़की को क्या करना है?

आप ऐसा कर सकते हैं:

  • उन अनुप्रयोगों का उपयोग करें जो आपको सेंड बफर यानी विंडो विकल्प सेट करने की अनुमति देते हैं
  • एक स्थानीय लिनक्स प्रॉक्सी का उपयोग करें
  • एक दूरस्थ विंडोज प्रॉक्सी का उपयोग करें?
  • Microsofhahahahahahaha के साथ एक मामला खोलें
  • बीयर

डिस्क्लेमर: मैंने इस पर शोध करने में कई घंटे बिताए हैं और यह मेरे ज्ञान और गूगल-फू के सर्वश्रेष्ठ के लिए सही है। लेकिन मैं अपनी माँ की कब्र पर शपथ नहीं लूंगा (वह अभी भी जीवित है)।

— karyhead
स्रोत
विलक्षण इनपुट; धन्यवाद। मैं iperf 2.0.4 का उपयोग कर रहा हूं, मैं सेटिंग्स के साथ प्रयोग करूंगा और अपने ओपी को कुछ नए कैप के साथ अपडेट करूंगा।
— स्मॉलक्लैंगर
ठीक है, मैंने अपने "उत्तर" को अधिक शोध और अपने हालिया परीक्षणों के आधार पर अपडेट किया है
— karyhead
धन्यवाद। कम से कम भाग में यह जानना अच्छा है कि मैं पागल नहीं हूं। मैंने XP / 2003 दिनों से कुछ ब्लॉग / थ्रेड्स पढ़े हैं जो उन रजिस्ट्री सेटिंग्स की सिफारिश करते हैं, लेकिन वे विस्टा / 2008 से पहले लिखे गए थे और मुझे पूरा यकीन है कि वे विस्टा में बाद में अनदेखा कर रहे हैं। मुझे लगता है कि मैं वास्तव में इस बारे में एमएस के साथ एक टिकट
— बढ़ाऊंगा
1
मेरे शोध में आया एक उपयोगी उपकरण SDK में tcpanalyzer.exe था ( microsoft.com/en-us/download/details.aspx?id=8279 )। यह एक ग्राफिकल नेटस्टैट है जिसे आप एक व्यक्तिगत कनेक्शन का चयन कर सकते हैं और टीसीपी आँकड़े जैसे आरटीटी, सीडब्ल्यूडी, रिट्रांसमिशन आदि प्राप्त कर सकते हैं। मैं सीडब्ल्यूडी को भेजने वाले बफर आकार से परे अच्छी तरह से खोलने के लिए प्राप्त कर सकता हूं, लेकिन विवाद नहीं बढ़ा और वायरशार्क सत्यापित नहीं हुआ। यह अभी भी बफर सीमित भेज रहा है।
— 15 अप्रैल को karyhead
1
मुझे "netsh" कमांड के बारे में 7/8 में विज्ञापित नहीं होने के बारे में कई मंचों पर टिप्पणियां मिली हैं, और लोगों को मैन्युअल रूप से संबंधित रजिस्ट्री प्रविष्टियों में प्रवेश करने के लिए मजबूर किया जा रहा है; मुझे आश्चर्य है कि अगर ऐसा कुछ CTCP विकल्प के साथ हो रहा है।
— पैट
4

एक बार जब आप टीसीपी स्टैक को ट्यून कर लेते हैं, तो आपके पास अभी भी विन्सेक परत में एक अड़चन हो सकती है। मैंने पाया है कि Winsock (रजिस्ट्री में एंकिलरी फंक्शन ड्राइवर) को कॉन्फ़िगर करना विंडोज 7 में अपलोड स्पीड (सर्वर पर डेटा को पुश करने) के लिए बहुत बड़ा अंतर है। माइक्रोसॉफ्ट ने टीसीपी ऑटोट्यूनिंग में नॉन-ब्लॉकिंग सॉकेट्स के लिए एक बग को स्वीकार किया है - बस ब्राउज़र का उपयोग सॉकेट की तरह ;-)

DefaultSendWindow के लिए DWORD कुंजी जोड़ें और इसे BDP या उच्चतर पर सेट करें। मैं 256000 का उपयोग कर रहा हूं।

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\AFD\Parameters\DefaultSendWindow

डाउनलोड के लिए Winsock सेटिंग बदलने से मदद मिल सकती है - DefaultReceiveWindow के लिए एक कुंजी जोड़ें।

आप क्लाइंट और सर्वर सॉकेट बफर आकार को समायोजित करने के लिए फिडलर प्रॉक्सी और कमांड का उपयोग करके विभिन्न सॉकेट स्तर सेटिंग्स के साथ प्रयोग कर सकते हैं:

prefs set fiddler.network.sockets.Server_SO_SNDBUF 65536 

fiddler.network.sockets.Client_SO_SNDBUF
fiddler.network.sockets.Client_SO_RCVBUF
fiddler.network.sockets.Server_SO_SNDBUF
fiddler.network.sockets.Server_SO_RCVBUF
— LeslieM
स्रोत
महान अतिरिक्त जानकारी। क्या आपके पास एमएस बग के लिए कोई संदर्भ लिंक है, किसी भी संयोग से?
— स्मॉलक्लैंगर
3

उत्तरों में सभी विश्लेषणों को पढ़ने के बाद, यह समस्या बहुत ज्यादा लगती है जैसे कि आप विंडोज 7/2008 आर 2 उर्फ ​​विंडोज 6.1 चला रहे होंगे

Windows 6.1 में नेटवर्किंग स्टैक (TCP / IP और Winsock) बुरी तरह से त्रुटिपूर्ण था और इसमें बग्स और प्रदर्शन समस्याओं की एक पूरी मेजबानी थी, जिसे Microsoft ने 6.1 की प्रारंभिक रिलीज के बाद से कई वर्षों के हॉटफ़िक्सिंग पर संबोधित किया था।

इन हॉटफ़िक्स को लागू करने का सबसे अच्छा तरीका मैन्युअल रूप से support.microsoft.com पर सभी संबंधित पृष्ठों के माध्यम से झारना है और मैन्युअल रूप से अनुरोध करते हैं और नेटवर्क स्टैक हॉटफिक्सेस के LDR संस्करण डाउनलोड करें (इनमें से कई दर्जनों हैं)।

प्रासंगिक हॉटफ़िक्स खोजने के लिए, आपको निम्नलिखित खोज क्वेरी के साथ www.bing.com का उपयोग करना होगा site:support.microsoft.com 6.1.7601 tcpip.sys

आपको यह भी समझने की आवश्यकता है कि विंडोज 6.1 में LDR / GDR हॉटफिक्स ट्रेनें कैसे काम करती हैं

मैं आमतौर पर विंडोज 6.1 के लिए एलडीआर फिक्स (न सिर्फ नेटवर्क स्टैक फिक्स) की अपनी सूची को बनाए रखने के लिए इस्तेमाल किया और फिर इन सुधारों को किसी भी विंडोज 6.1 सर्वर / क्लाइंट पर लागू किया जो मैं भर में आया था। नए LDR हॉटफिक्सेस की नियमित रूप से जाँच करना बहुत समय लेने वाला कार्य था।

सौभाग्य से, Microsoft ने नए OS संस्करणों के साथ LDR हॉटफिक्सेस के अभ्यास को रोक दिया है और बगफिक्स अब Microsoft से स्वचालित अपडेट सेवाओं के माध्यम से उपलब्ध हैं।

अद्यतन : Windows7SP1 में कई नेटवर्क बग का सिर्फ एक उदाहरण - https://support.microsoft.com/en-us/kb//7575585

अद्यतन 2 : यहाँ एक और हॉटफ़िक्स जोड़ा गया है जो SYN पैकेट के दूसरे रिट्रांसमिशन के बाद विंडो स्केलिंग को बाध्य करने के लिए एक netsh स्विच जोड़ता है (डिफ़ॉल्ट रूप से, विंडो स्केलिंग अक्षम होने के बाद 2 SYN पैकेटों को पुन: सबमिट कर दिया जाता है) https://support.microsoft.com/en-en हमें / केबी / 2780879

— क्रिस्टोफ़ वेगेनर
स्रोत
धन्यवाद क्रिस्टोफ़; इस पर कुछ बेहद दिलचस्प नए इनपुट और SYN-retransmission 'फीचर' बहुत ही अजीब है; मैं इसके पीछे डिज़ाइन लक्ष्य नहीं देख सकता। (क्रूड कंजेशन डिटेक्शन का कुछ प्रकार, शायद?)। सभी मूल परीक्षण Win7SP1 पर किए गए थे; हम जल्द ही Win10 को ट्राई कर रहे हैं, और यह देखने के लिए कि यह कितना किराया है, इसे फिर से चलाने के लिए मुझ पर है।
— स्मॉलक्लैंगर
विंडोज 10 की किस शाखा के साथ आप परीक्षण करेंगे? मुझे विंडोज 10 में नेटवर्क स्टैक के साथ अभी तक कोई अनुभव नहीं है।
— क्रिस्टोफ वेगेनर
एंटरप्राइज 1511 वह है जिसे हम लक्षित कर रहे हैं।
— स्मॉलक्लैंगर
समझा। विंडोज 10 के साथ शाखा पर निर्णय लेना काफी मुश्किल है क्योंकि बहुत सारे हैं। मैं पहले ही विंडोज 10 के साथ एक मुद्दे पर चल चुका हूं, जहां मैं एक विशेष सुविधा का उपयोग नहीं कर सका क्योंकि मैं एलटीएसबी शाखा में था। मेरी इच्छा है कि Microsoft ने कुल उपलब्ध शाखाओं की संख्या को कम कर दिया है और इसके बजाय उनके निर्माण में सुधारों और विशेषताओं को शामिल करने के बारे में उनके प्रलेखन में सुधार किया है ...
— क्रिस्टोफ़ वेगनर
1

मैं देख रहा हूं कि यह थोड़ी पुरानी पोस्ट है लेकिन यह दूसरों की मदद कर सकती है।

संक्षेप में आपको "विंडो ऑटो-ट्यूनिंग प्राप्त करें" सक्षम करना होगा:

netsh int tcp set global autotuninglevel=normal

CTCP का मतलब बिना सक्षम के ऊपर कुछ भी नहीं है।

यदि आप "प्राप्त विंडो ऑटो-ट्यूनिंग" को अक्षम करते हैं, तो आप 64KB पैकेट के आकार पर अटक जाएंगे जो लंबे आरटीटी के उच्च ब्रॉडबैंड कनेक्शनों पर नकारात्मक प्रभाव डालते हैं। आप "प्रतिबंधित" और "अत्यधिक अप्रतिबंधित" विकल्प के साथ भी प्रयोग कर सकते हैं।

बहुत अच्छा संदर्भ: https://www.duckware.com/blog/how-windows-is-killing-internet-download-speeds/index.html

— spricer
स्रोत
1

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

आखिरकार मेरे लिए यह तय हो गया कि मैं एएफडी सेवा की रजिस्ट्री में डिफ़ॉल्ट भेजें विंडो को संशोधित कर रहा हूं। समस्या afd.sys फ़ाइल से संबंधित लगती है। मैंने कई ग्राहकों का परीक्षण किया, कुछ ने धीमी अपलोड को प्रदर्शित किया, और कुछ ने नहीं, लेकिन सभी विंडोज 7 मशीन थे। धीमी गति से व्यवहार प्रदर्शित करने वाली मशीनों का एक ही संस्करण AFD.sys था। AFD.sys के कुछ संस्करणों के साथ कंप्यूटर के लिए रजिस्ट्री वर्कअराउंड की आवश्यकता है (क्षमा करें, संस्करण # याद नहीं है)।

\ CurrentControlSet \ HKLM सेवाएं \ AFD \ पैरामीटर

जोड़ें - DWORD - DefaultSendWindow

मूल्य - दशमलव - 1640960

वह मूल्य कुछ ऐसा था जो मुझे यहां मिला: https://helpdesk.egnyte.com/hc/en-us/articles/201638254-Upload-Speed-Slow-over-WebDAV-Windows-

मुझे लगता है कि उचित मूल्य का उपयोग करना चाहिए, आपको इसका उपयोग करके खुद की गणना करनी चाहिए:

जैसे। विज्ञापित अपलोड: 15 एमबीपीएस = 15,000 केबीपीएस

(15000/8) * 1024 = 1920000

जो मैं समझता हूं, क्लाइंट सॉफ़्टवेयर को आम तौर पर रजिस्ट्री में इस सेटिंग को ओवरराइड करना चाहिए, लेकिन यदि वे नहीं करते हैं, तो डिफ़ॉल्ट मान का उपयोग किया जाता है, और जाहिरा तौर पर डिफ़ॉल्ट मान AFD.sys फ़ाइल के कुछ संस्करणों में बहुत कम है।

मैंने देखा कि ज्यादातर MS उत्पादों में धीमे अपलोड की समस्या थी (IE, Mini-redirector (WebDAV), FTP with Windows Explorer, आदि ...) 3rd पार्टी सॉफ्टवेयर (उदा। Filezilla) का उपयोग करते समय मेरे पास समान धीमा-डाउन नहीं था। ।

AFD.sys सभी Winsock कनेक्शनों को प्रभावित करता है, इसलिए यह फिक्स FTP, HTTP, HTTPS, आदि पर लागू होना चाहिए ...

इसके अलावा, यह फिक्स कहीं और भी सूचीबद्ध किया गया था, इसलिए मैं इसका श्रेय नहीं लेना चाहता अगर यह किसी के लिए काम करता है, हालांकि इस धागे में इतनी जानकारी थी कि मुझे डर था कि यह चमक गया होगा।

— jjspierx
स्रोत
0

खैर, मैं खुद एक ऐसी स्थिति में आया हूं (मेरा सवाल यहां ), और अंत में मुझे टीसीपी स्केलिंग के आंकड़े को अक्षम करना था, मैन्युअल रूप से ऑटोट्यूनिंग प्रोफाइल सेट करना और सीटीपी को सक्षम करना था:

# disable heuristics
C:\Windows\system32>netsh interface tcp set heuristics wsh=disabled
Ok.

# enable receive-side scaling
C:\Windows\system32>netsh int tcp set global rss=enabled
Ok.

# manually set autotuning profile
C:\Windows\system32>netsh interface tcp set global autotuning=experimental
Ok. 

# set congestion provider
C:\Windows\system32>netsh interface tcp set global congestionprovider=ctcp
Ok.
— आंद्रे फर्नांडीस
स्रोत
0

मेरे पास टिप्पणी करने के लिए पर्याप्त बिंदु नहीं हैं, इसलिए मैं इसके बजाय एक "उत्तर" पोस्ट करूंगा। मुझे लगता है कि एक समान / समान समस्या प्रतीत होती है (सर्वरफ़ोल्ट प्रश्न यहाँ देखें )। मेरी (और शायद आपकी) समस्या विंडोज़ पर iperf क्लाइंट का बफर भेजना है। यह 64 KB से आगे नहीं बढ़ता है। विंडोज को बफर को गतिशील रूप से विकसित करने के लिए माना जाता है जब यह प्रक्रिया द्वारा स्पष्ट रूप से आकार नहीं देता है। लेकिन वह गतिशील विकास नहीं हो रहा है।

मुझे आपकी विंडो स्केलिंग ग्राफ़ के बारे में यकीन नहीं है, जो आपके "धीमे" विंडोज केस के लिए 500,000 बाइट्स तक खुलने वाली विंडो दिखाती है। मुझे उम्मीद है कि यह ग्राफ केवल ~ 64,000 बाइट के लिए खुला है जिसे देखते हुए आप 5 एमबीपीएस तक सीमित हैं।

— क्रिस स्टेंकविट्ज़
स्रोत
0

यह एक आकर्षक धागा है और वास्तव में उन मुद्दों से मेल खाता है जो मैंने लंबे वसा पाइप पर थ्रूपुट का परीक्षण करने के लिए Win7 / iperf का उपयोग किया है।

विंडोज 7 के लिए समाधान iperf सर्वर और क्लाइंट दोनों पर निम्न कमांड निष्पादित करना है।

netsh इंटरफ़ेस tcp सेट वैश्विक ऑटोट्यूनिंगलवेल = प्रायोगिक

एनबी: इससे पहले कि आप ऐसा करें, ऑटोट्यूनिंग की वर्तमान स्थिति को रिकॉर्ड करना सुनिश्चित करें:

netsh इंटरफ़ेस tcp वैश्विक दिखाता है

विंडो ऑटो-ट्यूनिंग स्तर प्राप्त करें: अक्षम

फिर पाइप के प्रत्येक छोर पर iperf सर्वर / क्लाइंट चलाएं।

अपने परीक्षणों के बाद ऑटोट्यूनिंग मान रीसेट करें:

netsh इंटरफ़ेस tcp सेट ग्लोबल ऑटोट्यूनिंगलवेल =

   autotuninglevel - One of the following values:
                     disabled: Fix the receive window at its default
                         value.
                     highlyrestricted: Allow the receive window to
                         grow beyond its default value, but do so
                         very conservatively.
                     restricted: Allow the receive window to grow
                         beyond its default value, but limit such
                         growth in some scenarios.
                     normal: Allow the receive window to grow to
                         accomodate almost all scenarios.
                     experimental: Allow the receive window to grow
                         to accomodate extreme scenarios.
— wicksee
स्रोत
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.