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


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

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

मैंने तोड़ दिया iperf -s एक एडब्ल्यूएस उदाहरण पर और फिर से विंडोज कार्यालय में ग्राहक:

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

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

  • iperf -c विंडोज एसवाईएन - विंडो 64 केबी, स्केल 1 - लिनक्स एसईएन, एसीके: विंडो 14 केबी, स्केल: 9 (* 512) iperf window scaling with default 64kb Window
  • iperf -c -w1M विंडोज एसवाईएन - विंडोज 64 केबी, स्केल 1 - लिनक्स एसवाईएन, एसीके: विंडो 14 केबी, स्केल: 9 iperf window scaling with default 1MB Window

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

इसके विपरीत, एक ही नेटवर्क पर एक लिनक्स क्लाइंट से सीधे, 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 क्लाइंट समान रूप से प्रभावित होते हैं। मैंने ऑटो-ट्यूनिंग पर कई मार्गदर्शिकाएं पढ़ी हैं, लेकिन ये आम तौर पर खराब भयानक होम नेटवर्किंग किट के आसपास काम करने के लिए स्केलिंग को अक्षम करने के बारे में हैं।

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

टिप्पणियाँ

प्रश्न में एडब्ल्यूएस लिनक्स उदाहरण में निम्नलिखित कर्नेल सेटिंग्स लागू हैं 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 रीडायरेक्टिंग /dev/null सर्वर पर समाप्त होने के अंत में iperf और किसी अन्य संभावित बाधाओं को हटा दें, लेकिन परिणाम बहुत समान हैं। के साथ टेस्ट ncftp (सिगविन, मूल विंडोज़, लिनक्स) उसी तरह से स्केल करते हैं जैसे उपरोक्त आईपीआरएफ परीक्षण उनके संबंधित प्लेटफॉर्म पर।

संपादित करें

मैंने यहां एक और सुसंगत चीज देखी है जो प्रासंगिक हो सकती है: enter image description here

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

अपडेट - 30 जून।

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

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

अपडेट 2 - 30 जून

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

----------------------------------------------
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

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

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

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

अद्यतन 3 - 31 जून।

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

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

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

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

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

साथ में iperf, मुझे स्पष्ट रूप से निर्दिष्ट करना था -w1m पर दोनों कनेक्शन से पहले ~ 5 एमबी / एस से अधिक पैमाने पर होगा। (संयोग से, मुझे चेक किया जा सकता है और 9 5 एमबी अक्षांश पर ~ 5 एमबीटी का बीडीपी लगभग 64 केबी है। सीमा को स्पॉट करें ...)

एनटीटीसीपी बाइनरी ने अब इस तरह की सीमा दिखायी। का उपयोग करते हुए 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

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

4 - 3 जुलाई अपडेट करें

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

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

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


50
2018-06-26 09:31


मूल


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


जवाब:


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

कृपया पढ़ें:

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

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

...

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

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

...

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

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

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

> netsh int tcp show global

अर्थात।

enter image description here

पीओ ने कहा:

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

सीटीसीपी आक्रामक रूप से भेजने की खिड़की को बढ़ाता है

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

कंपाउंड टीसीपी

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

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

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

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


15
2018-06-29 10:03



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


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

टीसीपी में दो खिड़कियां हैं:

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

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

enter image description here

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

यह इस तथ्य से प्रमाणित है कि उपर्युक्त ग्राफ में आरडब्ल्यूआईएन खुला रहता है, और 0 9 सेकंड के राउंड ट्रिप समय और ~ 500,000 बाइट्स के आरडब्ल्यूआईएन के साथ हम बैंडविड्थ देरी उत्पाद के अनुसार अधिकतम थ्रूपुट की उम्मीद कर सकते हैं (500000 /0.0 9) * 8 = ~ 42 एमबीटी / एस (और आपको केवल लिनक्स कैप्चर करने के लिए जीत में ~ 5 मिल रहा है)।

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

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

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

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


12
2018-06-30 15:11



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


@Pat और @Kyle द्वारा यहां कुछ शानदार जानकारी दी गई है। निश्चित रूप से @ केली के लिए ध्यान देना व्याख्या टीसीपी प्राप्त करने और खिड़कियां भेजने के लिए, मुझे लगता है कि इसके आसपास कुछ भ्रम हो गया है। मामलों को और भ्रमित करने के लिए, आईपीआरएफ शब्द "टीसीपी विंडो" का उपयोग करता है -w सेटिंग, प्राप्त करने, भेजने, या समग्र स्लाइडिंग विंडो के संबंध में एक संदिग्ध शब्द है। वास्तव में यह क्या करता है सॉकेट भेजने बफर सेट करने के लिए -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

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

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

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

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

64k प्रेषक बफर और 91 एमएमएस आरटीटी के साथ सैद्धांतिक थ्रूपुट है .... 5.5 एमबीपीएस। मेरे लिए पर्याप्त बंद करो।

यदि हम आपकी 1 एमबी विंडो आईपीआरएफ परीक्षण देखते हैं, तो ट्यूब 88.2 एमबीपीएस (केवल टीसीपी डेटा के लिए 86.2 एमबीपीएस) है। 1 एमबी विंडो वाला सैद्धांतिक ट्यूट 87.9 एमबीपीएस है। फिर, सरकारी काम के लिए पर्याप्त बंद करो।

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

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

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

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

netsh winsock show autotuning

प्रलेखन का कहना है कि आप इसे अक्षम कर सकते हैं:

netsh winsock set autotuning off

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

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

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

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

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

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

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

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

अस्वीकरण: मैंने इस पर शोध करने में कई घंटे बिताए हैं और यह मेरे ज्ञान और Google-fu के सर्वोत्तम है। लेकिन मैं अपनी मां की कब्र पर कसम खाता नहीं हूं (वह अभी भी जीवित है)।


5
2017-07-03 08:24



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


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

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

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

डाउनलोड के लिए विंसॉक सेटिंग बदलने से मदद मिल सकती है - 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

4
2018-04-23 21:02



जानकारी का महान अतिरिक्त बिट। क्या आपके पास किसी भी मौके से एमएस बग के लिए एक संदर्भ लिंक है? - SmallClanger


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

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

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

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

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

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

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

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

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


3
2018-06-06 12:34



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


मुझे लगता है कि यह एक छोटी सी पुरानी पोस्ट है लेकिन यह दूसरों की मदद कर सकती है।

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

netsh int tcp set global autotuninglevel=normal

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

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

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


1
2018-02-23 15:51





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

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

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

जोड़ें - DWORD - DefaultSendWindow

मूल्य - दशमलव - 1640 9 60

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

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

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

(15000/8) * 1024 = 1 9 0000

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

मैंने देखा कि ज्यादातर एमएस उत्पादों में धीमी अपलोड की समस्या थी (आईई, मिनी-रीडायरेक्टर (वेबडीवीवी), विंडोज एक्सप्लोरर के माध्यम से एफ़टीपी, आदि ...) तीसरे पक्ष के सॉफ्टवेयर (उदा। फाइलज़िला) का उपयोग करते समय मेरे पास धीमी गति से धीमी गति नहीं थी ।

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

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


1
2017-07-16 20:11





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

# 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
2018-02-02 23:28





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

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


0
2017-08-24 23:22