উইন্ডোজ টিসিপি উইন্ডো স্কেলিং হিটিং মালভূমি খুব তাড়াতাড়ি

Question

পরিস্থিতি: আমাদের বেশিরভাগ উইন্ডোজ ক্লায়েন্ট নিয়মিত বড় বড় ফাইলগুলি (এফটিপি / এসভিএন / এইচটিটিপি পুট / এসসিপি) লিনাক্স সার্ভারগুলিতে ~ 100-160 মিটার দূরে আপলোড করে। আমাদের অফিসে 1 জিবি / এস সিঙ্ক্রোনাস ব্যান্ডউইথ এবং সার্ভারগুলি হয় এডাব্লুএস উদাহরণস্বরূপ বা ইউএস ডিসিগুলিতে শারীরিকভাবে হোস্ট করা হয়।

প্রাথমিক প্রতিবেদনটি ছিল যে কোনও নতুন সার্ভারের দৃষ্টান্তে আপলোডগুলি তার চেয়ে ধীর গতিতে ছিল। এটি পরীক্ষায় এবং একাধিক অবস্থান থেকে বেরিয়ে আসে; ক্লায়েন্টরা তাদের উইন্ডোজ সিস্টেম থেকে হোস্টের কাছে 2-5Mbit / s স্থিতিশীল দেখছিল।

আমি 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০ থেকে ১৩০ এমবিট / সে এর মধ্যে থাকে যা আমাদের প্রয়োজনের জন্য যথেষ্ট বেশি। ওয়্যারশার্কিং সেশন, আমি দেখতে পাচ্ছি:

• iperf -c উইন্ডোজ এসওয়াইএন - উইন্ডো 64 কেবি, স্কেল 1 - লিনাক্স এসওয়াইএন, এসিকে: উইন্ডো 14 কেবি, স্কেল: 9 (* 512)
• iperf -c -w1M উইন্ডোজ এসওয়াইএন - উইন্ডোজ 64 কেবি, স্কেল 1 - লিনাক্স এসওয়াইএন, এসি: উইন্ডো 14 কেবি, স্কেল: 9

স্পষ্টতই লিঙ্কটি এই হাই থ্রুপুটটি বজায় রাখতে পারে, তবে এর কোনও ব্যবহার করতে আমার উইন্ডো আকার নির্ধারণ করতে হবে, যা বিশ্বের বেশিরভাগ বাস্তব অ্যাপ্লিকেশন আমাকে করতে দেয় না। টিসিপি হ্যান্ডশেকগুলি প্রতিটি ক্ষেত্রে একই সূচনা পয়েন্টগুলি ব্যবহার করে তবে বাধ্যতামূলকভাবে একটি স্কেল করে

বিপরীতে, একই নেটওয়ার্কের একটি লিনাক্স ক্লায়েন্ট থেকে একটি সোজা, 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 ক্লায়েন্টকে একইভাবে প্রভাবিত করে বলে মনে হচ্ছে। আমি অটো-টিউনিং সম্পর্কে প্রচুর গাইড পড়েছি, তবে এগুলি সাধারণত খারাপ ভয়ঙ্কর হোম নেটওয়ার্কিং কিটের চারপাশে কাজ করার জন্য পুরোপুরি স্কেলিং অক্ষম করার বিষয়ে।

কেউ কি আমাকে বলতে পারে যে এখানে কী হচ্ছে এবং আমাকে এটি ঠিক করার একটি উপায় দিতে পারেন? (জিপিওর মাধ্যমে আমি রেজিস্ট্রিটিতে থাকতে পারি fe

নোট

প্রশ্নে থাকা এডাব্লুএস লিনাক্স উদাহরণটিতে নিম্নলিখিত কার্নেল সেটিংস প্রয়োগ করা হয়েছে 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পুনঃনির্দেশ ব্যবহার করেছি , তবে ফলাফলগুলি একই রকম। সঙ্গে টেস্ট (Cygwin, নেটিভ উইন্ডোজ, লিনাক্স) তাদের নিজ নিজ প্ল্যাটফর্মের উপর উপরে iperf পরীক্ষা যতটা একই ভাবে স্কেল।/dev/nulliperfncftp

সম্পাদন করা

আমি এখানে আরও একটি সামঞ্জস্যপূর্ণ জিনিস খুঁজে পেয়েছি যা প্রাসঙ্গিক হতে পারে:

এটি 1 এমবি ক্যাপচারের প্রথম দ্বিতীয়টি, জুম ইন। আপনি উইন্ডোটি স্কেল করে দেওয়ার সাথে সাথে বাফারটি আরও বড় হয়ে যাওয়ার সাথে আপনি ধীর গতিতে কর্ম দেখতে পাবেন । ডিফল্ট উইন্ডো আইপিএফ পরীক্ষা চিরতরে স্থিত হয়ে যায় ঠিক এমন সময়ে point 0.2 এর এই ছোট মালভূমিটি রয়েছে's অবশ্যই এটি একটি ডিজাইর উচ্চতা পর্যন্ত স্কেল করে তবে এটি কৌতূহল যে এটি করার আগে স্কেলিংয়ে এই বিরতি রয়েছে (মানগুলি 1022bytes * 512 = 523264) এর আগে এটি করা যায়।

আপডেট - 30 শে জুন।

বিভিন্ন প্রতিক্রিয়া অনুসরণ করা:

• সিটিসিপি সক্ষম করা - এটি কোনও পার্থক্য করে না; উইন্ডো স্কেলিং অভিন্ন। (যদি আমি এটি সঠিকভাবে বুঝতে পারি তবে এই সেটিংটি কনজেশন উইন্ডোটি সর্বাধিক আকারের চেয়ে বেশি আকারে বাড়ানোর চেয়ে বাড়িয়ে তোলে)
• টিসিপি টাইমস্ট্যাম্পগুলি সক্ষম করা। - এখানেও কোনও পরিবর্তন নেই।
• নাগলের অ্যালগরিদম - এটি উপলব্ধি করে এবং কমপক্ষে এর অর্থ হ'ল আমি গ্রাফের সেই নির্দিষ্ট ব্লিপগুলি সমস্যার কোনও ইঙ্গিত হিসাবে সম্ভবত উপেক্ষা করতে পারি।
• পিসিপি ফাইলগুলি: জিপ ফাইলটি এখানে উপলভ্য: https://www.DPboxbox.com/s/104qdysmk01lnf6/iperf-pcaps-10s- Win%2BLinux-2014-06-30.zip (বিটউইস্টের সাথে বেনামে,, 150MB তে এক্সট্রাক্ট তুলনার জন্য প্রতিটি ওএস ক্লায়েন্ট থেকে একটি)

আপডেট 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

তবে দুঃখের বিষয়, থ্রুপুটটিতে কোনও পরিবর্তন হয়নি।

যদিও এখানে আমার কোনও কারণ / প্রভাবের প্রশ্ন রয়েছে: গ্রাফটি ক্লায়েন্টের কাছে সার্ভারের ACK- তে থাকা RWIN মানের। উইন্ডোজ ক্লায়েন্টগুলির সাথে, আমি কি এই ভেবে সঠিকভাবে বুঝতে পারি যে লিনাক্স এই নিম্ন পয়েন্টের বাইরে এই মানটি স্কেল করছে না কারণ ক্লায়েন্টের সীমিত সিডব্লিন এমনকি সেই বাফারটি পূরণ হতে বাধা দেয়? আরও কিছু কারণ থাকতে পারে যে লিনাক্স কৃত্রিমভাবে আরডব্লিনকে সীমাবদ্ধ করছে?

দ্রষ্টব্য: আমি ইসিএন এর নরকের জন্য চালু করার চেষ্টা করেছি; কিন্তু কোন পরিবর্তন নেই।

আপডেট 3 - 31 জুন।

হিউরিস্টিক্স এবং আরডব্লিউআইএন স্বয়ংক্রিয়তা অক্ষম করার পরে কোনও পরিবর্তন হয়নি ফান্টিটিওনালিটি টুইটগুলি ভাইয়েডিস ম্যানেজার ট্যাবগুলি উন্মোচিত করে এমন সফ্টওয়্যার দিয়ে ইন্টেল নেটওয়ার্ক ড্রাইভারগুলিকে সর্বশেষ (12.10.28.0) এ আপডেট করেছে। কার্ডটি একটি 82579 ভি চিপসেট অন-বোর্ড এনআইসি - (আমি রিয়েলটেক বা অন্যান্য বিক্রেতাদের সাথে ক্লায়েন্টদের কাছ থেকে আরও কিছু পরীক্ষা করতে যাচ্ছি)

এক মুহুর্তের জন্য এনআইসির প্রতি দৃষ্টি নিবদ্ধ রেখে, আমি নিম্নলিখিতগুলি চেষ্টা করেছি (বেশিরভাগ ক্ষেত্রে কেবল সম্ভাব্য দোষীদের খারিজ করা):

• বাফার গ্রহণ 256 থেকে 2 কে করুন এবং বাফারগুলি 512 থেকে 2 ক-তে প্রেরণ করুন (এখন উভয়ই সর্বাধিক) - কোনও পরিবর্তন নেই
• সমস্ত আইপি / টিসিপি / ইউডিপি চেকসাম অফলোডিং অক্ষম করে। - পরিবর্তন নেই.
• অক্ষম বৃহত প্রেরণ অফলোড - নাদা।
• আইপিভি 6 বন্ধ হয়েছে, কিউএস শিডিউলিং - এখন t

আপডেট 3 - 3 জুলাই

লিনাক্স সার্ভারের দিকটি সরিয়ে দেওয়ার চেষ্টা করে, আমি একটি সার্ভার 2012R2 ইনস্ট্যান্স শুরু করেছি এবং iperf(সাইগউইন বাইনারি) এবং এনটিটিসিপি ব্যবহার করে পরীক্ষার পুনরাবৃত্তি করেছি ।

সাথে iperf, সংযোগটি M 5Mbit / s ছাড়িয়ে যাওয়ার আগে আমাকে উভয় পক্ষের স্পষ্টভাবে উল্লেখ করতে -w1mহয়েছিল । (ঘটনাক্রমে, আমার পরীক্ষা করা যেতে পারে এবং 91 মাইলের বিলম্বিত সময়ে 5 মিলিয়ন ডলার বিডিপি প্রায় সুনির্দিষ্টভাবে 64kb k সীমাটি স্পট করুন ...)

এনটিটিসিপি বাইনারিগুলি এখন এই জাতীয় সীমাবদ্ধতা দেখিয়েছে। 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 কেবি বাফার। আরও একটি ওয়্যারশার্ক সার্ভার থেকে ফিরে আসা একটি ভাল, পরিবর্তনশীল RWIN দেখায় (স্কেল ফ্যাক্টর 256) যা ক্লায়েন্টটি পূরণ করছে বলে মনে হয়; সুতরাং সম্ভবত এনটিটিসিপি প্রেরণ উইন্ডোটির ভুল তথ্য সরবরাহ করছে।

আপডেট 4 - 3 রা জুলাই

@ ক্যারিহেডের অনুরোধে, আমি আরও কিছু পরীক্ষা করেছি এবং আরও কয়েকটি ক্যাপচার তৈরি করেছি, এখানে: https://www.roidbox.com/s/dtlvy1vi46x75it/iperf%2Bntttcp%2Bftp-pcaps-2014-07-03.zip

• iperfউইন্ডোজ থেকে পূর্বের মতো একই লিনাক্স সার্ভারে আরও দুটি এস (1.2.3.4): একটি 128 কে সকেটের আকার এবং ডিফল্ট 64k উইন্ডো (আবার again 5Mbit / s এর মধ্যে সীমাবদ্ধ) এবং 1MB সহ একটি উইন্ডো এবং ডিফল্ট 8kb সকেট পাঠান আকার। (স্কেল বেশি)
• ntttcpএকই উইন্ডোজ ক্লায়েন্ট থেকে একটি সার্ভার 2012R2 ইসি 2 উদাহরণে (1.2.3.5) একটি ট্রেস। এখানে, থ্রুপুট ভাল স্কেল। দ্রষ্টব্য: এনটিটিসিপি পরীক্ষার সংযোগটি খোলার আগে 6001 পোর্টে অদ্ভুত কিছু করে। নিশ্চিত যে সেখানে কি ঘটছে।
• একটি এফটিপি তথ্য অনুসন্ধান করে, /dev/urandomসাইগউইন ব্যবহার করে কাছের অভিন্ন লিঙ্কস হোস্টে (1.2.3.6) 20MB আপলোড করে ncftp। আবার সীমাও আছে। উইন্ডোজ ফাইলজিলা ব্যবহার করে প্যাটার্নটি একই রকম।

iperfবাফার দৈর্ঘ্য পরিবর্তন সময়ের সিক্যুয়েন্স গ্রাফের (অনেক বেশি উল্লম্ব বিভাগ) প্রত্যাশিত পার্থক্য তৈরি করে, তবে প্রকৃত থ্রুপুটটি অপরিবর্তিত।

Comments

একটি ভাল গবেষিত সমস্যার একটি বিরল উদাহরণ যা ডকুমেন্টেশনে স্পষ্টতই নয়। সুন্দর - আসুন আশা করি যে কেউ সমাধান পেয়েছে (কারণ আমি মনে করি যে আমিও এটি ব্যবহার করতে পারি)।

— টমটম

আরএফসি 1323 টাইমস্ট্যাম্পগুলি চালু করার চেষ্টা করুন কারণ তারা উইন্ডোজে ডিফল্টরূপে অক্ষম থাকে এবং লিনাক্স সেগুলি ডিফল্টরূপে সক্ষম করে থাকে)। netsh int tcp set global timestamps=enabled

— ব্রায়ান

200 এমএস দেরিটি সম্ভবত নাগলে অ্যালগরিদম কার্যকর। যেহেতু কোনও নির্দিষ্ট সংযোগে টিসিপি দ্বারা ডেটা প্রাপ্ত হয়, এটি নিম্নলিখিত শর্তগুলির সত্য হলেই এটি একটি স্বীকৃতি ফেরত পাঠায়: পূর্ববর্তী বিভাগটির জন্য কোনও স্বীকৃতি প্রেরণ করা হয়নি; একটি বিভাগটি প্রাপ্ত হয়েছে, তবে অন্য সংযোগটি 200 মিলিসেকেন্ডের মধ্যে সেই সংযোগের জন্য আসে না।

— গ্রেগ অ্যাস্কিউ

ধীরে ধীরে প্রেরকের কোথাও কোথাও কোনও প্যাকেট ক্যাপচার রাখার কোনও সুযোগ?

— কাইল ব্র্যান্ড্ট

আমি এই পরীক্ষাগুলির ফলাফল এবং প্রতিনিধি ক্যাপচার ফাইলগুলির লিঙ্কগুলি সহ আমার ওপি আপডেট করেছি।

— স্মলক্ল্যাঞ্জার

Answer 1

আপনি কি আপনার উইন্ডোজ 7/8 ক্লায়েন্টগুলিতে যৌগিক টিসিপি (সিটিসিপি) সক্ষম করার চেষ্টা করেছেন ?

দয়া করে পড়ুন:

উচ্চ-বিডিপি ট্রান্সমিশনের জন্য প্রেরক-সাইড পারফরম্যান্স বাড়ানো

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

...

এই অ্যালগোরিদমগুলি ছোট বিডিপি এবং আরও ছোট উইন্ডো আকারের জন্য ভাল কাজ করে । তবে, যখন আপনি একটি বড় রিসিভ উইন্ডো আকার এবং একটি বৃহত বিডিপি , যেমন একটি 100-মিমি রাউন্ড ট্রিপ সময়ের সাথে উচ্চ-গতির WAN লিঙ্ক জুড়ে দুটি সার্ভারের মধ্যে ডেটা প্রতিরূপের সাথে টিসিপি সংযোগ থাকে, তখন এই অ্যালগরিদমগুলি প্রেরণ উইন্ডোটি বাড়ায় না সংযোগটির ব্যান্ডউইথকে পুরোপুরিভাবে ব্যবহার করতে যথেষ্ট দ্রুত ।

এই পরিস্থিতিতে টিসিপি সংযোগগুলির ব্যান্ডউইথকে আরও ভালভাবে ব্যবহার করতে, পরবর্তী জেনারেশন টিসিপি / আইপি স্ট্যাকের মধ্যে যৌগিক টিসিপি (সিটিসিপি) অন্তর্ভুক্ত রয়েছে। বৃহত্তর রিসিভ উইন্ডো আকার এবং বিডিপি সহ সংযোগের জন্য সিটিসিপি আরও আক্রমণাত্মকভাবে প্রেরণ উইন্ডো বৃদ্ধি করে । সিটিসিপি বিলম্বের বিভিন্নতা এবং লোকসান পর্যবেক্ষণ করে এই ধরণের সংযোগগুলিতে সর্বাধিক আউটপুট দেওয়ার চেষ্টা করে। এছাড়াও, সিটিসিপি নিশ্চিত করে যে এর আচরণটি অন্য টিসিপি সংযোগগুলিকে নেতিবাচকভাবে প্রভাবিত করে না।

...

উইন্ডোজ সার্ভার 2008 চলমান কম্পিউটারগুলিতে সিটিসিপি ডিফল্টরূপে সক্ষম হয় এবং উইন্ডোজ ভিস্তা চালিত কম্পিউটারগুলিতে ডিফল্টরূপে অক্ষম থাকে। আপনি netsh interface tcp set global congestionprovider=ctcpকমান্ড দিয়ে সিটিসিপি সক্ষম করতে পারবেন । আপনি netsh interface tcp set global congestionprovider=noneকমান্ড দিয়ে সিটিসিপি অক্ষম করতে পারেন ।

6/30/2014 সম্পাদনা করুন

সিটিসিপি সত্যিই "চালু" আছে কিনা তা দেখতে

> netsh int tcp show global

অর্থাত

পিও বলেছেন:

যদি আমি এটি সঠিকভাবে বুঝতে পারি তবে এই সেটিংটি কনজেশন উইন্ডোটি যে পরিমাণে পৌঁছতে পারে তার চেয়ে বড় আকার বাড়িয়ে তুলবে

সিটিসিপি আগ্রাসীভাবে প্রেরণ উইন্ডোটি বাড়িয়ে তোলে

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

যৌগিক টিসিপি

বিদ্যমান অ্যালগরিদমগুলি যে কোনও প্রেরণকারী টিসিপি পিয়ারকে নেটওয়ার্ককে কাটিয়ে উঠতে বাধা দেয় তারা ধীর সূচনা এবং যানজট এড়ানো হিসাবে পরিচিত। প্রারম্ভিকভাবে সংযোগের ডেটা প্রেরণ করার সময় এবং হারিয়ে যাওয়া বিভাগ থেকে পুনরুদ্ধার করার সময় প্রেরক উইন্ডো নামে পরিচিত প্রেরক পাঠাতে পারে এমন বিভাগগুলির পরিমাণ এই অ্যালগরিদমগুলি বাড়িয়ে তোলে। আস্তে আস্তে প্রাপ্ত প্রতিটি স্বীকৃতি বিভাগ (উইন্ডোজ এক্সপি এবং উইন্ডোজ সার্ভার 2003-এ টিসিপির জন্য) বা স্বীকৃত প্রতিটি বিভাগের জন্য (উইন্ডোজ ভিস্তা এবং উইন্ডোজ সার্ভার ২০০৮-এর টিসিপির জন্য) প্রেরণ উইন্ডোটিকে একটি সম্পূর্ণ টিসিপি বিভাগ দ্বারা বৃদ্ধি করে। কনজেশন এড়ানোর জন্য প্রেরিত উইন্ডোটি প্রতিটি পূর্ণ উইন্ডোটির জন্য একক টিসিপি বিভাগ দ্বারা প্রেরণ করা যায় যা স্বীকৃত।

এই অ্যালগরিদমগুলি ল্যান মিডিয়া গতি এবং ছোট টিসিপি উইন্ডো আকারের জন্য ভাল কাজ করে। তবে, যখন আপনি একটি বড় রিসিভ উইন্ডো আকার এবং একটি বৃহত ব্যান্ডউইথ-বিলম্ব পণ্য (উচ্চ ব্যান্ডউইথ এবং উচ্চ বিলম্ব) এর সাথে টিসিপি সংযোগ স্থাপন করেন, যেমন একটি 100 এমএস রাউন্ড ট্রিপ সহ একটি উচ্চ-গতির WAN লিঙ্ক জুড়ে অবস্থিত দুটি সার্ভারের মধ্যে তথ্য প্রতিলিপি করা সময়, এই অ্যালগোরিদম সংযোগের ব্যান্ডউইদথকে পুরোপুরিভাবে ব্যবহার করতে পর্যাপ্ত প্রেরণ উইন্ডোকে বাড়ায় না। উদাহরণস্বরূপ, প্রতি সেকেন্ডে একটি 1 গিগাবিট (জিবিপিএস) 100 MS রাউন্ড ট্রিপ সময় (RTT) সঙ্গে লিংক WAN উপর, এটা করতে পারেন আপ এক ঘন্টার নিতে এর জন্য পাঠানো জানালা প্রাথমিকভাবে বৃদ্ধি রিসিভার দ্বারা বিজ্ঞাপিত হওয়ার জন্য বড় উইন্ডোর আকার এবং হারিয়ে যাওয়া বিভাগগুলি থাকলে পুনরুদ্ধার করতে।

এই পরিস্থিতিতে টিসিপি সংযোগগুলির ব্যান্ডউইথকে আরও ভালভাবে ব্যবহার করতে , পরবর্তী জেনারেশন টিসিপি / আইপি স্ট্যাকের মধ্যে যৌগিক টিসিপি (সিটিসিপি) অন্তর্ভুক্ত রয়েছে । বৃহত্তর রিসিভ উইন্ডো আকার এবং বৃহত ব্যান্ডউইথ-বিলম্ব পণ্যগুলির সাথে সংযোগের জন্য সিটিসিপি আরও আগ্রাসীভাবে প্রেরণ উইন্ডো বৃদ্ধি করে। সিটিসিপি বিলম্বের বিভিন্নতা এবং লোকসান পর্যবেক্ষণ করে এই ধরণের সংযোগগুলিতে সর্বাধিক আউটপুট দেওয়ার চেষ্টা করে । সিটিসিপি এটিও নিশ্চিত করে যে এর আচরণটি অন্যান্য টিসিপি সংযোগগুলিকে নেতিবাচকভাবে প্রভাবিত করে না।

মাইক্রোসফ্টে অভ্যন্তরীণভাবে সঞ্চালিত পরীক্ষায়, বড় ফাইল ব্যাকআপের সময়গুলি 50 মিমি আরটিটির সাথে 1 জিবিপিএস সংযোগের জন্য প্রায় অর্ধেক কমে যায়। বৃহত্তর ব্যান্ডউইথের বিলম্ব পণ্যের সাথে সংযোগগুলির আরও ভাল পারফরম্যান্স থাকতে পারে। সিটিসিপি এবং রিসিভ উইন্ডো অটো-টুনিং একসাথে বর্ধিত লিঙ্ক ব্যবহারের জন্য কাজ করে এবং এর ফলে বড় ব্যান্ডউইথ-বিলম্ব পণ্য সংযোগের জন্য যথেষ্ট পারফরম্যান্স লাভ হতে পারে।

Comments

শুধু এই উত্তর একটি সম্পূরক হিসাবে, সার্ভার 2012 সালে PowerShell সমতুল্য / Win8.1 হয় Set-NetTCPSettingসঙ্গে -CongestionProviderপ্যারামিটার ... যা CCTP, DCTCP এবং ডিফল্ট গ্রহণ করে। উইন্ডোজ ক্লায়েন্ট এবং সার্ভারগুলি বিভিন্ন ডিফল্ট কনজেশন সরবরাহকারী ব্যবহার করে। টেকনেট.মাইক্রোসফট.ইন- ইউএস

— রায়ান

আপনি যা পেয়েছেন তা আমি দেখতে পাচ্ছি, তবে এটি প্রয়োগ হবে বলে মনে হচ্ছে না। এর স্বার্থে, আমি 30 মিনিট দৌড়েছি iperfএবং উইন্ডোটি এখনও 520 কেবিবি ছাড়েনি। এই আক্রমণাত্মক অ্যালগরিদম কোনও সুবিধা দেখানোর আগে আরও কিছু সিডব্লিউএনডি সীমাবদ্ধ করে চলেছে।

— স্মলক্ল্যাঞ্জার

একটি পুরানো (ইতিমধ্যে স্থির) ভিস্তা বাগ রয়েছে যা এইচটিএমএল প্রোটোকল সংক্রমণ করার সময় এই জাতীয় সমস্যা উপস্থাপন করে। এইচটিএমএল দ্বারা একই ফাইল স্থানান্তর করার সময় কি আপনার সমস্যাটি ঠিক একই দেখাচ্ছে বা এফটিপি দ্বারা বলুন?

— প্যাট

@ প্যাট - এটি করে। এসভিএন কমিটস (এইচটিটিপি এবং এইচটিটিপিএসের মাধ্যমে) এবং এডব্লিউএসের অন্য সিস্টেমে এফটিপি স্থানান্তরও একই সীমাবদ্ধতা প্রদর্শন করে।

— স্মলক্ল্যাঞ্জার

উইন ক্লায়েন্টের ফায়ারওয়াল কেমন? আপনি ফায়ারওয়াল পুরোপুরি বন্ধ পরীক্ষা করতে পারেন? এখানে দেখুন: জিজ্ঞাসা

— প্যাট

Answer 2

সমস্যাটি স্পষ্ট করা:

টিসিপির দুটি উইন্ডো রয়েছে:

• রিসিভ উইন্ডো: বাফারে কয়টি বাইট বাকি রয়েছে। এটি রিসিভার দ্বারা আরোপিত প্রবাহ নিয়ন্ত্রণ। টিসিপি শিরোলেখের মধ্যে উইন্ডো আকার এবং উইন্ডোং স্কেলিং ফ্যাক্টরটি তৈরি হওয়ায় আপনি ওয়্যারশার্কে প্রাপ্ত উইন্ডোর আকার দেখতে পারেন can টিসিপি সংযোগের উভয় পক্ষই তাদের গ্রহণের উইন্ডোর বিজ্ঞাপন দিবে, তবে সাধারণত আপনি যেটির যত্ন নেবেন তা হ'ল তথ্য সর্বাধিক প্রাপ্ত। আপনার ক্ষেত্রে, ক্লায়েন্টটি সার্ভারে আপলোড হওয়ায় এটি "সার্ভার"
• যানজট উইন্ডো। এটি প্রেরকের দ্বারা আরোপিত প্রবাহ নিয়ন্ত্রণ। এটি অপারেটিং সিস্টেম দ্বারা পরিচালিত হয় এবং টিসিপি শিরোনামে প্রদর্শিত হয় না। এটি দ্রুত ডেটা কীভাবে প্রেরণ করা হবে তা নিয়ন্ত্রণ করে।

আপনার সরবরাহ করা ক্যাপচার ফাইলটিতে। আমরা দেখতে পাচ্ছি যে রিসিভ বাফার কখনই উপচে পড়ছে না:

আমার বিশ্লেষণটি হ'ল প্রেরক যথেষ্ট দ্রুত প্রেরণ করছেন না কারণ প্রেরণের উইন্ডো (ওরফে কনজেশন কন্ট্রোল উইন্ডো) রিসিভারের আরডব্লিনকে সন্তুষ্ট করার জন্য যথেষ্ট পরিমাণে খোলেনি। সুতরাং সংক্ষিপ্তভাবে গ্রহনকারী "আমাকে আরও দিন" বলছেন, এবং উইন্ডোজ যখন প্রেরক হয় তখন এটি যথেষ্ট দ্রুত প্রেরণ করে না।

উপরোক্ত গ্রাফে আরডব্লিন খোলা থাকে এবং 0 500,000 বাইটের আরউইউইন ~ 500,000 বাইটের সাথে আমরা ব্যান্ডউইথের বিলম্বের পণ্যটি (500000) অনুযায়ী সর্বাধিক ট্রান্সপুট আশা করতে পারি তার প্রমাণ দিয়ে এটি প্রমাণিত হয় /0.09) * 8 = ~ 42 এমবিট / গুলি (এবং আপনি লিনাক্স ক্যাপচারে আপনার জিততে কেবল প্রায় 5 ডলার পাচ্ছেন)।

কিভাবে ঠিক হবে এটা?

আমি জানি না। interface tcp set global congestionprovider=ctcpআমার কাছে সঠিক জিনিস করার মতো শোনায় কারণ এটি প্রেরণ উইন্ডোকে বাড়িয়ে তুলবে (যা কনজেশন উইন্ডোর আরেকটি শব্দ)। আপনি বলেছেন যে কাজ করছে না। তাই কেবল তা নিশ্চিত করার জন্য:

1. এটি সক্ষম করার পরে কি আপনি পুনরায় বুট করেছেন?
2. চিমনি অফলোড চালু আছে? যদি এটি হয় তবে এটি একটি পরীক্ষা হিসাবে বন্ধ করার চেষ্টা করুন। আমি জানি না এটি সক্ষম হওয়ার পরে ঠিক কী অফলোড হয়ে যায়, তবে প্রেরণ উইন্ডোটি নিয়ন্ত্রণ করা যদি তাদের মধ্যে একটি হয় তবে এটি সক্ষম করা থাকলে কনজেশনপ্রাইডারটির কোনও প্রভাব নেই ... আমি কেবল অনুমান করছি ...
3. এছাড়াও, আমি মনে করি এটি উইন্ডোজ pre-এর পূর্বের হতে পারে তবে আপনি HKEY_LOCAL_MACHINE- সিস্টেম-কারেন্ট কন্ট্রোলসেট-পরিষেবাদি-এএফডি-প্যারামিটারগুলিতে DefaultSendWindow এবং DefaultReসেপ্ট উইন্ডো নামক দুটি রেজিস্ট্রি কীগুলির সাথে যুক্ত এবং খেলার চেষ্টা করতে পারেন। যদি এগুলি এমনকি কাজ করে, আপনি সম্ভবত এটির সিটিসিপি বন্ধ করে দিয়েছেন be
4. তবুও অন্য অনুমান, চেষ্টা করে দেখুন netsh interface tcp show heuristics। আমি মনে করি যে এটি RWIN হতে পারে, তবে এটি বলে না, সুতরাং এটি প্রেরণ উইন্ডোটিকে প্রভাবিত করে এমন ক্ষেত্রে অক্ষম / সক্ষম করে খেলুন।
5. এছাড়াও, নিশ্চিত করুন যে আপনার ড্রাইভারগুলি আপনার পরীক্ষার ক্লায়েন্টে আপ টু ডেট রয়েছে। হয়তো কিছু সবেমাত্র ভেঙে গেছে।

নেটওয়ার্ক চালকরা কিছু পুনর্লিখন / জিনিসগুলি সংশোধন করছেন (অফলোডিং অক্ষম থাকাকালীন চোখের সিপিইউ রাখুন) এই সম্ভাবনাটি হারাতে শুরু করার জন্য আপনার সমস্ত অফলোড লোড বৈশিষ্ট্যগুলির সাথে এই সমস্ত পরীক্ষার চেষ্টা করব। TCP_OFFLOAD_STATE_DELEGATED struct হয় অন্তত পরোক্ষভাবে যে CWnd অফলোড অন্তত সম্ভব বলে মনে হয়।

Comments

আমি আপনার "উত্তর" জানিয়েছি কারণ এটি আপনার উত্তর নয়; আমি সঙ্গে সঙ্গে নিচে ভোট পেয়েছি; এখন আমি দেখছি কীভাবে "লোকেরা" আপনার "উত্তর-উত্তর"

— প্যাট

@ প্যাট: আপনি ভোট নম্বরটিতে ক্লিক করতে পারেন এবং উপভোটস / ডাউনভোটেসের ভাঙ্গনও দেখতে পারেন। বর্তমানে আপনার উত্তরের কোনও ডাউনভোট নেই। আমার উত্তরটি তার সমস্যার সমাধান করে না (তবে কোনও উত্তর এখনও দেয় না), এটি সমস্যার ব্যাখ্যা এবং স্থানীয়করণ করে (আশা করি সঠিকভাবে!) যা সমস্যা সমাধানের গুরুত্বপূর্ণ পদক্ষেপ।

— কাইল ব্র্যান্ড্ট

@ কাইল ব্র্যান্ড্ট যদি আপনি নিজেরটি গ্রহণ করেন তবে এটি উত্তর নয় তবে আমি ভাবছি কেন এটি "স্বয়ংক্রিয়ভাবে" সরানো হচ্ছে না কেন আরও কিছু বিবেচনা না করে ?? এবং আপনি ভুল; আমি আপনার "উত্তর" রিপোর্ট করার সাথে সাথে একটি ডাউন-ভোট (অপ্রচলিত) পেয়েছি; একটি এখনও সরানো হয়নি। দেখে মনে হচ্ছে আপনি এখানে "বিশেষ" বিধি দ্বারা খেলছেন।

— প্যাট

@ প্যাট এটি যদি সহায়তা করে তবে কাইলের উত্তর-উত্তর অবিশ্বাস্যরূপে সহায়ক হয়েছে। আমার এখন কোন স্পষ্ট ধারণা রয়েছে যা কোন বাফারগুলি সীমাবদ্ধ করা হচ্ছে এবং আমি অনুভব করি যে ফলস্বরূপ আমি একটি সঠিক সমাধানের আরও কাছে closer কখনও কখনও এর মতো প্রশ্নগুলি একটি সহযোগিতামূলক প্রচেষ্টা হতে পারে যা কিছুটা ন্যায়বিচারমূলক সম্পাদনা দিয়ে একটি যথাযথ প্রশ্ন এবং যথাযথ A তে পরিণত হতে পারে ।

— স্মলক্ল্যাঞ্জার

@ স্মলক্ল্যাঞ্জারকে যথাযোগ্য সম্মান সহ, এসএফের একটি নিয়ম রয়েছে যা কাইল ব্র্যান্ড্ট সহ সমস্ত ব্যবহারকারীদের অনুসরণ করা উচিত; যদি তার উত্তর না হয় তবে এটি অবশ্যই "মুডারেটর" ক্লাবের মধ্যে তার যত বন্ধুবান্ধব হোক না কেন মন্তব্য হিসাবে মুছে ফেলা বা মুভি করা উচিত।

— প্যাট

Answer 3

@ পেট এবং @ কাইল দ্বারা এখানে কিছু দুর্দান্ত তথ্য রয়েছে। টিসিপি উইন্ডোজ গ্রহণ এবং প্রেরণের বিষয়ে কাইলের ব্যাখ্যাগুলিতে অবশ্যই কৃতজ্ঞ থাকুন , আমি মনে করি এ সম্পর্কে কিছুটা বিভ্রান্তি দেখা দিয়েছে। বিষয়গুলিকে আরও বিভ্রান্ত করার জন্য, আইপিএফটি "টিসিপি উইন্ডো" শব্দটি সেটিংসের সাথে ব্যবহার করে -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 ));
}

কাইল যেমন উল্লেখ করেছেন, সমস্যাটি লিনাক্স বাক্সে প্রাপ্ত উইন্ডো নিয়ে নয়, তবে প্রেরক যথেষ্ট পরিমাণে প্রেরণ উইন্ডোটি খুলছেন না। এটি এমন নয় যে এটি যথেষ্ট দ্রুত খোলায় না, এটি কেবল 64 ক্যাপে ক্যাপ করে।

উইন্ডোজ 7 এ ডিফল্ট সকেট বাফার আকারটি 64 কিলোমিটার। এমএসডিএন- এ থ্রুপুট সম্পর্কিত ডকুমেন্টেশন সকেট বাফার আকার সম্পর্কে কী বলে

উইন্ডোজ সকেট ব্যবহার করে টিসিপি সংযোগের মাধ্যমে ডেটা প্রেরণ করার সময়, সর্বাধিক মাধ্যমে আউটপুট অর্জনের জন্য পর্যাপ্ত পরিমাণে বকেয়া (প্রেরিত তবে স্বীকৃত নয়) টিসিপিতে রাখা জরুরি। টিসিপি সংযোগের জন্য সেরা থ্রুপুট অর্জনের জন্য বকেয়া তথ্যের পরিমাণের আদর্শ মানটিকে আদর্শ প্রেরণ ব্যাকলগ (আইএসবি) আকার বলে। আইএসবি মান হ'ল টিসিপি সংযোগের ব্যান্ডউইথ-বিলম্ব পণ্য এবং রিসিভারের বিজ্ঞাপনযুক্ত উইন্ডোটি (এবং আংশিকভাবে নেটওয়ার্কে যানজটের পরিমাণ) function

ঠিক আছে, ব্লা ব্লা ব্লা, এখন আমরা এখানে যাচ্ছি:

যে অ্যাপ্লিকেশনগুলি একটি ব্লকিং বা অ-ব্লক করা প্রেরণের অনুরোধটি সম্পাদন করে তা সাধারণত বিন্যাসের মাধ্যমে আউটপুট অর্জনের জন্য উইনসকের দ্বারা অভ্যন্তরীণ প্রেরণ বাফারিংয়ের উপর নির্ভর করে। প্রদত্ত সংযোগের জন্য প্রেরিত বাফার সীমাটি SO_SNDBUF সকেট বিকল্প দ্বারা নিয়ন্ত্রিত হয়। অবরুদ্ধকরণ এবং অবরুদ্ধকরণ প্রেরণ পদ্ধতির জন্য, প্রেরণ বাফার সীমাটি নির্ধারণ করে যে কতটা ডেটা টিসিপিতে বকেয়া রাখা আছে । যদি সংযোগের জন্য আইএসবি মান প্রেরণ বাফার সীমা চেয়ে বড় হয়, তবে সংযোগে প্রাপ্ত থ্রুপুটটি অনুকূল হবে না।

K৪ কে উইন্ডো ব্যবহার করে আপনার অতি সাম্প্রতিক আইপিএফ পরীক্ষার গড় থ্রুপুট ..৮ এমবিপিএস। এটি পরিসংখ্যান থেকে > সংক্ষিপ্তসার মধ্যে ওয়্যারশার্ক, যা সমস্ত বিট গণনা করে। সম্ভবত, আইপিআরপি টিসিপি ডেটা থ্রুটপুট গণনা করছে যা 5.7 এমবিপিএস। আমরা এফটিপি পরীক্ষার সাথে একই পারফরম্যান্সটি দেখতে পাচ্ছি ~ 5.6 এমবিপিএস।

একটি 64k প্রেরণকারী বাফার এবং 91ms আরটিটি সহ তাত্ত্বিক থ্রুপুটটি হল .... 5.5 এমবিপিএস। আমার জন্য যথেষ্ট বন্ধ করুন।

যদি আমরা আপনার 1 এমবি উইন্ডো আইপিআরপি পরীক্ষার দিকে নজর রাখি তবে টিপুটটি 88.2Mbps (কেবলমাত্র টিসিপি ডেটার জন্য 86.2Mbps)। 1 এমবি উইন্ডো সহ তাত্ত্বিক টিপুটটি 87.9 এমবিপিএস। আবার, সরকারী কাজের জন্য যথেষ্ট বন্ধ করুন।

এটি যা দেখায় তা হ'ল প্রেরণ সকেট বাফার সরাসরি প্রেরণ উইন্ডোটি নিয়ন্ত্রণ করে এবং এটি অন্য দিক থেকে প্রাপ্ত উইন্ডোটির সাথে মিলিয়ে থ্রুপুট নিয়ন্ত্রণ করে। বিজ্ঞাপন প্রাপ্ত উইন্ডোতে রুম রয়েছে, তাই আমরা রিসিভারের মাধ্যমে সীমাবদ্ধ নই।

ধরুন, এই অটোটুনিং ব্যবসায়টি কী? উইন্ডোজ 7 কি সেই জিনিসগুলি স্বয়ংক্রিয়ভাবে পরিচালনা করে না? যেমনটি উল্লেখ করা হয়েছে, উইন্ডোজ রিসিভ উইন্ডোটির অটো-স্কেলিং পরিচালনা করে তবে এটি প্রেরণ বাফারটিকেও গতিশীলভাবে পরিচালনা করতে পারে। আসুন এমএসডিএন পৃষ্ঠায় ফিরে যাই:

টিসিপির জন্য ডায়নামিক সেন্ড বাফারিং উইন্ডোজ 7 এবং উইন্ডোজ সার্ভার 2008 আর 2 এ যুক্ত হয়েছিল। ডিফল্টরূপে, টিসিপির জন্য ডায়নামিক প্রেরণ বাফারিং সক্ষম করা থাকে যদি না কোনও অ্যাপ্লিকেশন স্ট্রিম সকেটে SO_SNDBUF সকেট বিকল্প সেট করে না।

বিকল্পটি ব্যবহার করার 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 এর উপরে নয়? দুর্দান্ত প্রশ্ন। লিনাক্স কার্নেলগুলিতে একটি অটোটানিং টিসিপি স্ট্যাকও রয়েছে। টি-পেইন এবং কেনে যেমন একসাথে অটোটুন ডুয়েট করছেন, এটি সম্ভবত ভাল লাগবে না। এই দুটি স্বতঃজনিত টিসিপি একে অপরের সাথে কথা বলার স্ট্যাকগুলি নিয়ে কোনও সমস্যা রয়েছে।

অন্য একজনের ঠিক আপনার মতো সমস্যা ছিল এবং এটি ডিফল্ট প্রেরণ বাফার আকার বাড়ানোর জন্য একটি রেজিস্ট্রি সম্পাদনা দিয়ে এটি ঠিক করতে সক্ষম হয়েছিল। দুর্ভাগ্যক্রমে, এটি আর কাজ করবে বলে মনে হয় না, আমি চেষ্টা করার পরে এটি কমপক্ষে আমার পক্ষে হয়নি।

এই মুহুর্তে, আমি মনে করি এটি সীমাবদ্ধ ফ্যাক্টরটি হ'ল উইন্ডোজ হোস্টে প্রেরিত বাফার আকার। এটি দেওয়া হয়েছে যে এটি গতিশীলভাবে সঠিকভাবে বৃদ্ধি পাচ্ছে বলে মনে হচ্ছে না, একটি মেয়ে কী করবে?

আপনি পারেন:

• অ্যাপ্লিকেশনগুলি ব্যবহার করুন যা আপনাকে প্রেরণ বাফার অর্থাৎ উইন্ডো বিকল্পটি সেট করতে দেয়
• স্থানীয় লিনাক্স প্রক্সি ব্যবহার করুন
• একটি দূরবর্তী উইন্ডোজ প্রক্সি ব্যবহার করবেন?
• মাইক্রোসফাহাহাহাহাহাহাহা করে একটি মামলা খুলুন
• বিয়ার

দাবি অস্বীকার: আমি এটি গবেষণা করতে অনেক ঘন্টা ব্যয় করেছি এবং এটি আমার জ্ঞানের সেরা এবং গুগল-ফু এর সাথে সঠিক। তবে আমি আমার মায়ের কবরে শপথ করব না (তিনি এখনও বেঁচে আছেন)

Comments

ফ্যান্টাসিক ইনপুট; ধন্যবাদ. আমি আইপিএফ ২.০.৪ ব্যবহার করছি, আমি সেটিংস পরীক্ষা-নিরীক্ষা করব এবং আমার ওপিও কিছু নতুন ক্যাপ দিয়ে আপডেট করব।

— স্মলক্ল্যাঞ্জার

ঠিক আছে, আমি আরও গবেষণা এবং আপনার সাম্প্রতিক পরীক্ষার উপর ভিত্তি করে আমার "উত্তর" আপডেট করেছি

— ক্যারিহেড

ধন্যবাদ। কমপক্ষে অংশে এটা জেনে ভালো লাগল যে আমি শুধু পাগল হয়ে যাচ্ছি না। আমি এক্সপি / 2003 এর দিনগুলি থেকে কয়েকটি ব্লগ / থ্রেড পড়েছি যা এই রেজিস্ট্রি সেটিংসের প্রস্তাব দেয় তবে সেগুলি ভিস্তা / ২০০৮ এর আগে লেখা হয়েছিল এবং আমি দৃ sure়ভাবে নিশ্চিত যে তারা ভিস্তার পরে অগ্রাহ্য করেছে। আমি মনে করি আমি আসলে

— এমএসের

আমার গবেষণায় আমি যে দরকারী সরঞ্জামটি দেখতে পেয়েছি তা হ'ল এসডিকে ( মাইক্রোসফট . com/en-us/download/details.aspx?id=8279 ) tcpanalyzer.exe । এটি একটি গ্রাফিকাল নেটস্যাট যা আপনি একটি পৃথক সংযোগটি নির্বাচন করতে পারেন এবং টিসিপি স্ট্যাটাস যেমন আরটিটি, সিডব্লিউড, রিট্রান্সমিশন ইত্যাদি পেতে পারেন আমি প্রেরিত বাফারের আকারের বাইরেও সিডউএনডিটি ভালভাবে খুলতে পারতাম, তবে টিপুটটি বাড়েনি এবং ওয়্যারশার্ক যাচাই করা হয়নি এটি এখনও বাফার সীমিত প্রেরণ।

— ক্যারিহেড

"নেট" কমান্ডগুলি 7/8-এ অ্যাডভার্টাইজড হিসাবে কাজ করছে না এবং লোকেরা ম্যানুয়ালি সংশ্লিষ্ট রেজিস্ট্রি এন্ট্রিতে প্রবেশ করতে বাধ্য হচ্ছে সে সম্পর্কে আমি বেশ কয়েকটি ফোরামে মন্তব্য পেয়েছি; আমি ভাবছি যদি সিটিসিপি বিকল্পের সাথে এরকম কিছু ঘটছে।

— প্যাট

Answer 4

আপনি একবার টিসিপি স্ট্যাক টিউন করে নিলে আপনার উইনসক স্তরে এখনও কোনও বাধা থাকতে পারে। আমি খুঁজে পেয়েছি যে উইনসক (রেজিস্ট্রিটিতে আনুষঙ্গিক ফাংশন ড্রাইভার) কনফিগার করা উইন্ডোজ in এ আপলোড গতির জন্য (সার্ভারে ডেটা ঠেলাঠেলি করার জন্য) একটি বিশাল পার্থক্য তৈরি করে - মাইক্রোসফ্ট টি-সিপি-অ-ব্লকিং সকেটের জন্য অটোোটনিংয়ের একটি বাগ স্বীকার করেছে - কেবলমাত্র ব্রাউজারগুলি ব্যবহার করে এমন ধরণের সকেট ;-)

ডিফল্টসেন্ডউইনডোর জন্য ডিডাব্লর্ড কী যুক্ত করুন এবং এটি বিডিপি বা উচ্চতরতে সেট করুন। আমি 256000 ব্যবহার করছি।

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

ডাউনলোডের জন্য উইনসক সেটিং পরিবর্তন করা সাহায্য করতে পারে - ডিফল্টরসিপ উইন্ডোতে একটি কী যুক্ত করুন।

আপনি ফিডলার প্রক্সি এবং ক্লায়েন্ট এবং সার্ভার সকেট বাফার আকারগুলি সামঞ্জস্য করতে কমান্ডগুলি ব্যবহার করে বিভিন্ন সকেট স্তরের সেটিংস নিয়ে পরীক্ষা করতে পারেন :

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

Comments

অতিরিক্ত দুর্দান্ত বিট তথ্য। আপনার কি কোনও সুযোগেই এমএস বাগের জন্য একটি রেফারেন্স লিঙ্ক রয়েছে?

— স্মলক্ল্যাঞ্জার

Answer 5

উত্তরে সমস্ত বিশ্লেষণ পড়ে, এই সমস্যাটি খুব মনে হচ্ছে আপনি উইন্ডোজ 7 / 2008আর 2 ওরফে উইন্ডোজ 6.1 চালাচ্ছেন

উইন্ডোজ .1.১-এ নেটওয়ার্কিং স্ট্যাক (টিসিপি / আইপি ও উইনসক) মারাত্মকভাবে ত্রুটিযুক্ত ছিল এবং এর পুরো হোস্ট এবং বাগের পারফরম্যান্স সমস্যা ছিল যা মাইক্রোসফ্ট eventually.১-এর প্রাথমিক প্রকাশের পর থেকে বহু বছর ধরে হটফিক্সিংয়ের পরে সম্বোধন করেছিল।

এই হটফিক্সগুলি প্রয়োগ করার সর্বোত্তম উপায় হ'ল সমর্থন.মাইক্রোসফট.কমের সমস্ত প্রাসঙ্গিক পৃষ্ঠাগুলি ম্যানুয়ালি পরীক্ষা করে নেওয়া এবং ম্যানুয়ালি অনুরোধ করা এবং নেটওয়ার্ক স্ট্যাক হটফিক্সগুলির এলডিআর সংস্করণগুলি ডাউনলোড করা (এর মধ্যে বেশ কয়েকটি ডজন রয়েছে)।

প্রাসঙ্গিক হটফিক্সগুলি খুঁজতে, আপনাকে অবশ্যই নীচের অনুসন্ধানের প্রশ্নের সাথে www.bing.com ব্যবহার করতে হবে site:support.microsoft.com 6.1.7601 tcpip.sys

উইন্ডোজ .1.১-এ এলডিআর / জিডিআর হটফিক্স ট্রেনগুলি কীভাবে কাজ করে তাও আপনার বুঝতে হবে

আমি সাধারণত উইন্ডোজ 6.1 এর জন্য আমার নিজের এলডিআর ফিক্সগুলির তালিকা (কেবল নেটওয়ার্ক স্ট্যাক ফিক্সগুলি নয়) বজায় রাখতে ব্যবহার করি এবং তারপরে সক্রিয়ভাবে আমি এই যে কোনও উইন্ডোজ 6.1 সার্ভার / ক্লায়েন্টের কাছে এসেছি সেগুলি প্রয়োগ করেছিলাম। নিয়মিত নতুন এলডিআর হটফিক্সেস পরীক্ষা করা খুব সময় সাধ্যের কাজ ছিল।

ভাগ্যক্রমে, মাইক্রোসফ্ট নতুন ওএস সংস্করণ সহ এলডিআর হটফিক্সগুলির অনুশীলন বন্ধ করে দিয়েছে এবং মাইক্রোসফ্ট থেকে স্বয়ংক্রিয় আপডেট পরিষেবাদির মাধ্যমে বাগ বাগগুলি এখন উপলভ্য।

আপডেট : উইন্ডোজ 7 এসপি 1- এর অনেকগুলি নেটওয়ার্ক বাগের কেবল একটি উদাহরণ - https://support.microsoft.com/en-us/kb/2675785

আপডেট 2 : এখানে একটি আর হটফিক্স রয়েছে যা একটি এসওয়াইএন প্যাকেটের দ্বিতীয় পুনঃপ্রেরণের পরে উইন্ডো স্কেলিংকে বাধ্য করার জন্য একটি নেট স্যুইচ যুক্ত করে (ডিফল্টরূপে, 2 এসওয়াইএন প্যাকেটগুলি পুনঃপ্রেরণের পরে উইন্ডো স্কেলিং নিষ্ক্রিয় করা হয়) https://support.microsoft.com/en- মার্কিন / kB / 2780879

Comments

ধন্যবাদ ক্রিস্টফ; এই এবং এসওয়াইএন-রিট্রান্সমিশন 'বৈশিষ্ট্য' সম্পর্কে খুব আকর্ষণীয় নতুন ইনপুটটি খুব অদ্ভুত; আমি এর পিছনে ডিজাইন লক্ষ্যটি মোটেও দেখতে পাচ্ছি না। (এক ধরণের অপরিশোধিত ভিড় সনাক্তকরণ, সম্ভবত?)। সমস্ত আসল পরীক্ষাগুলি Win7SP1 এ করা হয়েছিল; আমরা শীঘ্রই উইন 10 ট্রেলিং করব এবং এটি কীভাবে ভাড়া নিয়েছে তা দেখার জন্য এটির অনেকাংশ আবার চালানো আমার উপর।

— স্মলক্ল্যাঞ্জার

উইন্ডোজ 10 এর কোন শাখাটি আপনি পরীক্ষা করবেন? উইন্ডোজ 10-এ এখন পর্যন্ত নেটওয়ার্ক স্ট্যাকের সাথে আমার কোনও অভিজ্ঞতা নেই।

— ক্রিস্টোফ ওয়েজনার

এন্টারপ্রাইজ 1511 যা আমরা লক্ষ্য করছি target

— স্মলক্ল্যাঞ্জার

আমি দেখি. উইন্ডোজ 10 এর সাথে একটি শাখা নিয়ে সিদ্ধান্ত নেওয়া বেশ কঠিন যেহেতু অনেকগুলি রয়েছে। আমি ইতোমধ্যে উইন্ডোজ 10 এর সাথে একটি ইস্যুতে চলে এসেছি যেখানে আমি একটি নির্দিষ্ট বৈশিষ্ট্যটি ব্যবহার করতে পারি না কারণ আমি এলটিএসবি শাখায় ছিলাম। আমি আশা করি মাইক্রোসফ্ট সামগ্রিকভাবে উপলব্ধ শাখাগুলির সংখ্যা হ্রাস করেছে এবং পরিবর্তে প্রতিটি বিল্ডে কী কী সংশোধন এবং বৈশিষ্ট্য অন্তর্ভুক্ত রয়েছে সে সম্পর্কে তাদের নথিপত্র উন্নত করেছে ....

— ক্রিস্টোফ ওয়েজনার

Answer 6

আমি দেখতে এটি কিছুটা পুরনো পোস্ট তবে এটি অন্যকে সহায়তা করতে পারে।

সংক্ষেপে আপনাকে "রিসিভ উইন্ডো অটো-টিউনিং" সক্ষম করতে হবে:

netsh int tcp set global autotuninglevel=normal

সিটিসিপি মানে উপরের সক্ষম ছাড়া কিছুই নয়।

যদি আপনি "রিসিভ উইন্ডো অটো-টিউনিং" অক্ষম করেন তবে আপনি 64KB প্যাকেট আকারে আটকে যাবেন যা উচ্চ ব্রডব্যান্ড সংযোগগুলিতে দীর্ঘ আরটিটির উপর নেতিবাচক প্রভাব ফেলে। আপনি "সীমাবদ্ধ" এবং "হাইরেস্ট্রিক্টেড" বিকল্পের সাথেও পরীক্ষা করতে পারেন।

খুব ভাল রেফারেন্স: https://www.duckware.com/blog/how-windows-is-killing-internet-download-speeds/index.html

Answer 7

আমি উইন্ডোজ ক্লায়েন্ট (উইন্ডোজ 7) এর সাথে একই ধরণের সমস্যাটি অনুভব করছিলাম। আপনার বেশিরভাগ ডিবাগিংয়ের মধ্য দিয়ে আমি গিয়েছিলাম, নাগলে অ্যালগরিদম, টিসিপি চিমনি অফলোডিং এবং আরও অনেকগুলি টিসিপি সম্পর্কিত সেটিং পরিবর্তনগুলি অক্ষম করেছিলাম। তাদের অভাবে কোনও প্রভাব ছিল।

যা পরিশেষে এটি আমার জন্য স্থির করেছিল তা হ'ল এএফডি পরিষেবার রেজিস্ট্রিতে ডিফল্ট প্রেরণ উইন্ডোটি পরিবর্তন করা। সমস্যাটি আফড.সেস ফাইলের সাথে সম্পর্কিত বলে মনে হচ্ছে। আমি বেশ কয়েকটি ক্লায়েন্টকে পরীক্ষা করেছিলাম, কেউ কেউ ধীর আপলোড প্রদর্শন করেছিল এবং কিছু কিছু করেনি তবে সবগুলি ছিল উইন্ডোজ 7 মেশিন। ধীর আচরণটি প্রদর্শনকারী মেশিনগুলির AFD.sys একই সংস্করণ ছিল। AFD.sys এর নির্দিষ্ট সংস্করণযুক্ত কম্পিউটারগুলির জন্য রেজিস্ট্রি ওয়ার্কআউন্ডের প্রয়োজন (দুঃখিত, সংস্করণ # এর পুনরায় মনে রাখবেন না)।

\ CurrentControlSet \ HKLM সার্ভিস \ এএফডি \ পরামিতি

অ্যাড - ডিডাবর্ড - ডিফল্টসেন্ড উইন্ডো

মান - দশমিক - 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 ফাইলের কয়েকটি সংস্করণে ডিফল্ট মানটি খুব কম থাকে।

আমি লক্ষ্য করেছি যে বেশিরভাগ এমএস পণ্যগুলিতে ধীর আপলোড সমস্যা ছিল (আই, মিনি-রিডাইরেক্টর (ওয়েবডিএভি), উইন্ডোজ এক্সপ্লোরার এর মাধ্যমে এফটিপি, ইত্যাদি ...) তৃতীয় পক্ষের সফ্টওয়্যার ব্যবহার করার সময় (উদাহরণস্বরূপ ফাইলজিলা) আমার একই ধীর-ডাউনগুলি ছিল না ।

এএফডি.সিস সমস্ত উইনসক সংযোগকে প্রভাবিত করে, তাই এই ফিক্সটি এফটিপি, এইচটিটিপি, এইচটিটিপিএস ইত্যাদিতে প্রয়োগ করা উচিত ...

এছাড়াও, এই ফিক্সটি কোথাও কোথাও উপরেও তালিকাভুক্ত ছিল, সুতরাং এটি কারওর জন্য কাজ করে তবে আমি এর জন্য কৃতিত্ব নিতে চাই না, তবে এই থ্রেডে এত বেশি তথ্য ছিল যে আমি ভয় পেয়েছিলাম যে এটি সম্ভবত শেষ হয়ে গেছে।

Answer 8

ঠিক আছে, আমি নিজেই একটি অনুরূপ পরিস্থিতিতে চলে এসেছি (এবং আমার প্রশ্নটি এখানে ) এবং শেষ পর্যন্ত আমাকে টিসিপি স্কেলিং হুরিস্টিক্স অক্ষম করতে হবে, ম্যানুয়ালি স্বয়ংক্রিয়করণ প্রোফাইল সেট করতে হবে এবং সিটিসিপি সক্ষম করতে হবে:

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

Answer 9

আমার মন্তব্য করার মতো পর্যায়ে পয়েন্ট নেই তাই আমি তার পরিবর্তে একটি "উত্তর" পোস্ট করব। একই রকম / অভিন্ন সমস্যা হিসাবে উপস্থিত বলে মনে হচ্ছে (সার্ভারফাল্টের প্রশ্নটি এখানে দেখুন )। আমার (এবং সম্ভবত আপনার) সমস্যাটি উইন্ডোজগুলিতে আইপিএফ ক্লায়েন্টের প্রেরণ বাফার। এটি 64 কেবি অতিক্রম করে না। যখন প্রক্রিয়াটি স্পষ্টভাবে আকারের আকারে তৈরি না হয় তখন উইন্ডোজটি গতিশীলভাবে বাফার বাড়ানোর কথা। তবে সেই গতিশীল প্রবৃদ্ধি ঘটছে না।

আমি আপনার উইন্ডো স্কেলিং গ্রাফ সম্পর্কে নিশ্চিত নই যা আপনার "ধীর" উইন্ডোজ ক্ষেত্রে উইন্ডোটি 500,000 বাইট পর্যন্ত খোলা দেখায়। আমি প্রত্যাশা করেছি যে এই গ্রাফটি কেবলমাত্র M 64,000 বাইটে খোলা থাকবে যা আপনি 5 এমবিপিএসের মধ্যে সীমাবদ্ধ।

Answer 10

এটি একটি আকর্ষণীয় থ্রেড এবং হ'ল লম্বা ফ্যাট পাইপগুলিতে থ্রুপুট পরীক্ষা করার জন্য আমি উইন 7 / আইপিএফ ব্যবহার করেছিলাম এমন সমস্যার সাথে মেলে।

উইন্ডোজ 7 এর সমাধানটি হ'ল আইপিএফ সার্ভার এবং ক্লায়েন্ট উভয়ের জন্য নিম্নলিখিত কমান্ডটি কার্যকর করা।

netsh ইন্টারফেস টিসিপি বিশ্বব্যাপী স্বটোনিংলিভেল = পরীক্ষামূলক সেট করে

নোট: আপনি এটি করার আগে, স্বয়ংক্রিয়করণের বর্তমান অবস্থা রেকর্ড করতে ভুলবেন না:

netsh ইন্টারফেস টিসিপি গ্লোবাল শো

উইন্ডোটি স্বতঃ-টিউনিং স্তরটি পান: অক্ষম

তারপরে পাইপের প্রতিটি প্রান্তে আইপিএফ সার্ভার / ক্লায়েন্ট চালান।

আপনার পরীক্ষাগুলি অনুসরণ করে অটোটুনিং মানটি পুনরায় সেট করুন:

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.