دليل الخصائص المتقدّمة لـ NIC في Windows - Jumbo Frames و RSS و LSO و RSC و Flow Control و EEE و Wake on LAN

· · Windows, الشبكات, NIC, Ethernet, ضبط الأداء, تطوير Windows

غالباً ما تبدو علامة التبويب Advanced في محوّل شبكة Windows أقوى بكثير ممّا هي في الواقع.
Jumbo Packet و Large Send Offload و Interrupt Moderation و Receive Side Scaling و Flow Control و Energy Efficient Ethernet. تبدو الأسماء كلّها وكأنّها ينبغي أن تجعل الأمور أسرع، لكن في الممارسة تعتمد الإجابة الصحيحة على ما تحاول تحسينه.

  • هل تريد throughput أفضل لعمليّات النقل الكبيرة؟
  • latency أقلّ لحركة المرور الصغيرة من نوع request/response؟
  • استخدام CPU أقلّ؟
  • سلوك أفضل عند الـ sleep والاستئناف، أو Wake on LAN موثوق؟
  • طريقة أنظف لعزل مشكلة تتعلّق بالـ driver أو بتوافق الـ switch؟

إذا كان هذا الهدف غامضاً، فإنّ “تشغيل كلّ شيء” طريقة عاديّة جدّاً لجعل الأمور أسوأ.

يركّز هذا المقال على محوّلات Ethernet السلكيّة في Windows 10 و Windows 11 و Windows Server.
الهدف ليس سرد كلّ خاصّيّة ممكنة خاصّة بالموزّع، بل شرح ما تعنيه عادةً الخصائص المتقدّمة الشائعة، وما الذي يميل إلى الحدوث عند رفعها أو خفضها أو تفعيلها أو تعطيلها، ومتى يستحقّ كلّ إعداد فعلاً أن يُلمَس.

موزّعو المحوّلات وحزم الـ drivers يستخدمون أسماء مختلفة.
قد يظهر Jumbo Packet على هيئة Jumbo Frames. قد يظهر Receive Buffers على هيئة Receive Descriptors. قد يصبح Priority & VLAN هو Packet Priority & VLAN. في هذا المقال تُجمَع الإعدادات ذات النيّة نفسها معاً.

1. النسخة المختصرة

ها هي الخلاصة العمليّة أوّلاً.

  • عادةً ما ينبغي أن يبقى Speed & Duplex على Auto.
  • Checksum Offload و RSS و LSO و RSC من الأفضل عادةً تركها مُفعَّلة أو على قيمها الافتراضيّة.
  • jumbo frames لا تكون منطقيّة إلّا عندما يكون المسار متوافقاً من البداية إلى النهاية.
  • Interrupt Moderation يقايض الـ latency بانخفاض في حمل CPU.
  • Flow Control يمكنه تقليل الـ drops، لكنّه يمكنه أيضاً نشر الازدحام.
  • EEE و Green Ethernet و Selective Suspend هي إعدادات طاقة، لا إعدادات سرعة.
  • VMQ و SR-IOV هي بشكل رئيسيّ لمستضيفي Hyper-V والافتراضيّة.
  • Wake on Pattern Match غالباً ما يكون أكثر إثارةً للمشاكل من Wake on Magic Packet.
  • الخصائص القديمة جدّاً مثل TCP Chimney Offload عادةً ليست المكان الذي تريد أن تنفق فيه وقتك.

النقطة الأساسيّة بسيطة: الخصائص المتقدّمة لـ NIC ليست صفحة تُفعِّل فيها كلّ ما يبدو قويّاً.
إنّها صفحة تختار فيها أيّ مقايضة تريدها فعلاً: throughput، أو latency، أو استخدام CPU، أو سلوك الطاقة، أو التوافق.

2. أين تجد الإعدادات

2.1 في الواجهة الرسوميّة

يمكنك الوصول إلى ذلك من أيّ من المسارين أدناه.

من Network Connections

  1. شغّل ncpa.cpl
  2. انقر بزرّ الفأرة الأيمن على المحوّل المستهدف
  3. افتح Properties -> Configure
  4. افتح علامة التبويب Advanced

من Device Manager

  1. افتح Device Manager
  2. وسّع Network adapters
  3. انقر بزرّ الفأرة الأيمن على NIC وافتح Properties
  4. افتح علامة التبويب Advanced

هناك تعيش معظم الإعدادات التي يناقشها هذا المقال.
لكن علامة التبويب Power Management تهمّ أيضاً، خاصّةً لسلوك الاستئناف و Wake on LAN.

2.2 في PowerShell

PowerShell أفضل عندما تريد جرد القيم الحاليّة أو أخذ نسخة احتياطيّة قبل تغيير أيّ شيء.

Get-NetAdapter

Get-NetAdapterAdvancedProperty -Name "Ethernet" |
  Sort-Object DisplayName |
  Format-Table DisplayName, DisplayValue, RegistryKeyword, RegistryValue -Auto

في بعض المحوّلات تكون قيم RegistryKeyword موحّدة بما يكفي لإظهار أسماء مثل *RSS أو *VMQ أو *SRIOV أو *EEE.
لكنّ DisplayName و DisplayValue ما زالا معرَّفين من الـ driver، لذا فمن الأكثر أماناً فحص المحوّل الفعليّ أوّلاً قبل كتابة scripts تعتمد عليهما.

3. قواعد أساسيّة قبل تغيير أيّ شيء

3.1 حدّد ما يعنيه “أفضل” فعلاً

عبارة “الشبكة بطيئة” يمكن أن تصف عدّة مشاكل مختلفة جدّاً.

  • نسخ الملفّات الكبيرة بطيء
    -> throughput، RSS، RSC، LSO، jumbo frames، الـ buffers
  • حركة المرور الصغيرة من نوع request/response تبدو متأخّرة
    -> Interrupt Moderation، RSC، EEE، عمق الطابور
  • استخدام CPU مرتفع جدّاً
    -> الـ offloads، RSS، RSC، سلوك المقاطعات
  • الأمور تنكسر بعد الـ sleep والاستئناف
    -> Selective Suspend، Power Management، Wake on LAN
  • الـ link يسقط أحياناً أو يعود إلى 100 Mbps
    -> الكابل، الجهاز المقابل، Speed & Duplex، EEE، الـ driver

إذا كان الهدف خاطئاً، فإنّ خيار الضبط عادةً ما يكون خاطئاً أيضاً.

3.2 اشتبه في الطبقة الفيزيائيّة والجهاز المقابل مبكّراً

بعض المشاكل ليست مشاكل خصائص NIC على الإطلاق.

  • كابل سيّئ
  • مشكلة توافق مع switch أو dock أو router
  • firmware قديم
  • طاقة غير كافية على USB NIC
  • أخطاء في جانب المنفذ
  • فقد للحزم وإعادة إرسال في مكان آخر من المسار

إذا كانت الأعراض هي “يتفاوض على 100 Mbps” أو “الـ link يرفّ” أو “عمليّات النقل الكبيرة هي الشيء الوحيد الذي ينكسر”، فإنّ الطبقة الفيزيائيّة تستحقّ الانتباه قبل علامة التبويب Advanced.

3.3 غيّر شيئاً واحداً في كلّ مرّة

إذا غيّرت jumbo frames و LSO و RSC و RSS و EEE معاً، فلن تعرف ما الذي ساعد وما الذي أضرّ.
دوّن الحالة الحاليّة، وغيّر خاصّيّةً واحدة، وقِس مرّةً أخرى.

3.4 حدّد ما ستقيسه

كحدٍّ أدنى، يساعد مراقبة:

  • سرعة الـ link
  • الـ throughput
  • الـ latency
  • استخدام CPU
  • عدّادات NIC مثل drops و errors و shortages
  • استقرار الـ sleep والاستئناف

الضبط بالحدس وحده عادةً ما يكون أضعف من الضبط بالأرقام.

4. جدول مرجعيّ سريع

الإعداد ماذا يفعل ما يميل إلى الحدوث عند تفعيله أو رفعه ما يميل إلى الحدوث عند تعطيله أو خفضه الموقف الافتراضيّ
Speed & Duplex يتفاوض على سرعة الـ link والـ duplex أو يثبّتهما يمكن أن يساعد مع الأجهزة المقابلة القديمة، لكن عدم التطابق قد يسبّب متاعب شديدة Auto عادةً الأكثر أماناً على الشبكات الحديثة اترك Auto
Jumbo Packet / Jumbo Frames يستخدم frames أكبر من MTU 1500 المعتاد يمكن أن يقلّل CPU وعبء الترويسة في عمليّات النقل الكبيرة أقصى توافق، لكن حزم أكثر فقط عندما يكون المسار متوافقاً من البداية إلى النهاية
Checksum Offload يحسب checksums الخاصّة بـ IP/TCP/UDP على NIC يخفّض عادةً تكلفة CPU يعيد عمل الـ checksum إلى نظام التشغيل عادةً مُفعَّل
LSO / TSO يسمح لـ NIC بتقطيع عمليّات إرسال TCP الكبيرة غالباً ما يساعد throughput الإرسال الثقيل واستخدام CPU أسهل لعزل التوافق، لكن بتكلفة CPU أعلى عادةً مُفعَّل
RSC / LRO يدمج عمليّات استقبال TCP غالباً ما يساعد throughput الاستقبال واستخدام CPU حبيبيّة أدقّ للحزم، أحياناً أفضل للحالات الحسّاسة لـ latency يُقيَّم حسب عبء العمل
RSS يوزّع معالجة الاستقبال عبر عدّة CPUs قابليّة توسّع أفضل على الأنظمة متعدّدة الأنوية أسهل لاختناق نواة واحدة عادةً مُفعَّل
Interrupt Moderation يقلّل تردّد المقاطعات حمل CPU أقلّ latency أقلّ لكن تكلفة CPU/DPC أعلى ابدأ بالقيمة الافتراضيّة
Receive / Transmit Buffers يغيّر عمق الـ ring أو الطابور تحمّل أفضل للـ bursts، وأحياناً throughput مستدام أفضل استخدام ذاكرة أقلّ، لكن أسهل في النفاد زِده فقط عند الحاجة
Flow Control يستخدم pause frames يمكن أن يقلّل الـ drops يمكنه كشف أو تضخيم مقايضات الازدحام في مكان آخر اعتبره خياراً يخصّ الشبكة بأكملها
Priority & VLAN يطبّق سلوك 802.1p / 802.1Q مفيد عندما يكون VLAN/QoS متعمّداً سلوك Ethernet مسطّح أبسط استخدمه فقط عند الحاجة
VMQ / SR-IOV يساعد الشبكات الافتراضيّة مفيد على مستضيفي Hyper-V سلوك مستضيف أبسط بشكل رئيسيّ للافتراضيّة
EEE / Green Ethernet يوفّر الطاقة عند خمول الـ link استخدام طاقة أقلّ غالباً أبسط وأحياناً أكثر استقراراً هذا خيار طاقة، لا خيار سرعة
Selective Suspend يضع NIC في حالات طاقة أقلّ استخدام طاقة أقلّ غالباً سلوك استئناف أبسط مرشّح جيّد للعزل عند مشاكل الاستئناف
Wake on Magic Packet / Pattern Match يحدّد شروط الإيقاظ الإيقاظ عن بُعد ممكن عمليّات إيقاظ غير مقصودة أقلّ فعّله فقط عند الحاجة

5.1 Speed & Duplex

تتحكّم هذه الخاصّيّة في التفاوض على سرعة الـ link والـ duplex.
يمكن أن تظهر باسم Speed & Duplex أو Link Speed أو Link Speed & Duplex.

تشمل الخيارات النمطيّة:

  • Auto Negotiation
  • 100 Mbps Full Duplex
  • 1.0 Gbps Full Duplex
  • 2.5 Gbps Full Duplex
  • 10 Gbps Full Duplex

إرشاد عمليّ

Auto عادةً هو الجواب الصحيح.

معدّات Ethernet الحديثة مصمّمة حول التفاوض. إذا كان طرف ثابتاً والطرف الآخر متروكاً على Auto، أو إذا كان الجهاز المقابل قديماً وغريب الأطوار، فقد ينتهي بك الأمر إلى عدم تطابق duplex، أو إعادات إرسال، أو أداء ضعيف يبدو أكثر غرابةً من المشكلة الأصليّة.

إذا ظهر link يجب أن يكون 1 Gbps على هيئة 100 Mbps، فإنّ المشتبه بهم المعتادون هم:

  • جودة الكابل
  • توصيل ناقص للموصلات
  • سلوك dock أو USB NIC
  • مشاكل منفذ الـ switch
  • سلوك EEE / Green Ethernet
  • عمر الـ driver

عادةً ما يكون فرض السرعة يدويّاً هو الخطوة الأخيرة، لا الأولى.

5.2 Jumbo Packet / Jumbo Frames

تسمح هذه الخاصّيّة بـ frames Ethernet أكبر من مسار MTU المعياريّ البالغ 1500 بايت.

ما الذي يتغيّر عادةً

عندما تكون jumbo frames مدعومةً فعلاً من البداية إلى النهاية:

  • ينخفض عدد الحزم
  • يقلّ عبء الترويسة
  • يمكن أن تتحسّن تكلفة CPU
  • يمكن أن تتحسّن كفاءة عمليّات النقل الكبيرة

لكن هناك فخاخ:

  • بعض الـ drivers تعرض قيماً مثل 9014 Bytes كحجم frame
  • أدوات نظام التشغيل غالباً تصف الإعداد بـ MTU 9000
  • قد تحسب الـ switches العلامات والتأطير بشكل مختلف

لذا فإنّ “9014” و “9000” ليسا بالضرورة الرقم نفسه موصوفاً بطريقتين. قد يعكسان وجهات نظر مختلفة.

إرشاد عمليّ

استخدم jumbo frames فقط عندما تتحكّم في المسار جيّداً بما يكفي للتحقّق من:

  • NIC الخاصّ بك
  • NIC الجهاز المقابل
  • الـ switches الوسيطة
  • أيّ عبء لوسم VLAN
  • أيّ عبء لـ switch افتراضيّ أو نفق

إذا كان جزء من المسار لا يزال فعليّاً عند 1500، يمكن أن تتحوّل jumbo frames إلى ثقب تصحيح بدلاً من تحسين السرعة.

5.3 Gigabit Master / Slave Mode

بعض المحوّلات، خاصّةً بعض موديلات Intel، تكشف خاصّيّة تتعلّق بـ توقيت master/slave على 1000BASE-T.

إرشاد عمليّ

  • اتركها على Auto ما لم يكن هناك سبب محدّد لعدم ذلك
  • فكّر فيها كإعداد إنقاذ للتوافق أو التفاوض، لا كأداة لضبط الأداء

خصائص مثل Wait for Link و Log Link State Event تتعلّق عادةً بـ كيفيّة إبلاغ الـ driver عن جاهزيّة الـ link، لا بـ throughput الخام.

إرشاد عمليّ

  • اتركها على قيمها الافتراضيّة في سيناريوهات سطح المكتب العاديّة
  • يمكن أن تهمّ أثناء استكشاف الأخطاء، أو سلوك وقت الإقلاع، أو التحقّق من تجاوز الفشل
  • عادةً ليست أوّل مقبض ضبط تلمسه

6. الإعدادات التي تؤثّر على حمل CPU و throughput و latency

تبدو هذه المجموعة الأكثر ارتباطاً بالأداء، وغالباً ما تكون كذلك. وهي أيضاً حيث تصبح المقايضات حقيقيّة.

6.1 Checksum Offload

ينقل هذا عمل checksum لـ IP و TCP و UDP إلى NIC.

إرشاد عمليّ

  • اتركه عادةً مُفعَّلاً
  • يخفّض غالباً تكلفة CPU
  • أخطاء checksum الظاهريّة في التقاط الحزم المحلّيّ غالباً ما تكون مجرّد أثر جانبيّ بصريّ للـ offload
  • يمكن أن يكون تعطيله مؤقّتاً مفيداً عند عزل مشاكل التوافق

6.2 Large Send Offload (LSO) / TSO

يتيح هذا لـ NIC تقسيم إرسال TCP كبير إلى frames أصغر.

إرشاد عمليّ

  • اتركه عادةً مُفعَّلاً
  • غالباً ما يساعد throughput الإرسال الثقيل واستخدام CPU
  • إذا بدا تطبيق محدّد أو مسار driver مشبوهاً، فإنّ تعطيله مؤقّتاً يمكن أن يساعد في عزل المشكلة

6.3 Receive Segment Coalescing (RSC) / LRO

يجمع هذا عدّة TCP segments مستلَمة قبل أن تتحرّك أعلى في الـ stack.

إرشاد عمليّ

  • جيّد لـ throughput جانب الاستقبال وكفاءة CPU
  • يستحقّ إعادة التقييم لأعباء العمل ذات الـ latency المنخفض أو الحسّاسة لرؤية الحزم
  • ليس كلّ مسار استقبال “أكثر كفاءةً” ينتج إحساساً أفضل بالزمن الحقيقيّ

6.4 offloads UDP الأحدث (USO / URO)

تكشف بعض تركيبات NIC ونظام التشغيل الأحدث عن offloads على جانب UDP أيضاً.

إرشاد عمليّ

  • إذا ظهرت، ابدأ بتركها على قيمها الافتراضيّة
  • قِس قبل تغييرها
  • لاستكشاف الأخطاء العاديّ، عادةً ليست أوّل مكان تذهب إليه

6.5 Receive Side Scaling (RSS)

يوزّع RSS معالجة الاستقبال عبر عدّة CPUs. على الأنظمة الحديثة متعدّدة الأنوية، هو واحد من أهمّ الخصائص في الصفحة.

إرشاد عمليّ

  • عادةً فعّله
  • إذا كانت نواة CPU واحدة مشغولة بشكل غير متناسب بينما يتعطّل throughput الشبكة، تحقّق من RSS مبكّراً

6.6 RSS queues / processors / profile

تتحكّم هذه الخصائص في مقدار التوازي الذي يمكن أن يستخدمه RSS.

إرشاد عمليّ

  • ابدأ بالقيمة الافتراضيّة
  • زِد فقط عندما تُظهر القياسات اختناقاً حقيقيّاً
  • عدد طوابير أكثر يمكن أن يعني أيضاً عمل مقاطعات و DPC أكثر

6.7 Interrupt Moderation / Interrupt Moderation Rate

هذه واحدة من أوضح المقايضات في كامل اللوحة.

  • moderation أعلى أو adaptive
    -> عادةً حمل CPU أقلّ، لكن latency أعلى
  • moderation أقلّ أو Off
    -> عادةً latency أقلّ، لكن تكلفة CPU/DPC أعلى

إرشاد عمليّ

  • ابدأ بالقيمة الافتراضيّة أو وضع adaptive
  • إذا كنت تهتمّ بالـ jitter أو latency الرسائل الصغيرة، اختبر إعدادات أقلّ
  • إذا كان الهدف الرئيسيّ هو throughput الكتلة، فإنّ القيمة الافتراضيّة تتصرّف غالباً جيّداً

6.8 Receive Buffers / Descriptors و Transmit Buffers / Descriptors

تغيّر هذه عمق الطابور.

إرشاد عمليّ

  • يمكن أن تساعد في تحمّل الـ bursts و throughput المستدام
  • يمكن أيضاً أن تزيد استخدام الذاكرة وتأخير الانتظار في الطابور
  • زِدها عندما يكون لديك دليل مثل drops أو shortages، لا لمجرّد أنّ رقماً أكبر موجود

6.9 Flow Control

هذا هو إعداد pause frame.

إرشاد عمليّ

  • قد يقلّل الـ drops في بعض البيئات
  • قد ينقل أيضاً ضغط الازدحام إلى مكان آخر
  • لحركة المرور الحسّاسة لـ latency، يستحقّ اختباراً دقيقاً بدلاً من الموافقة التلقائيّة

7. إعدادات VLAN و QoS والمتعلّقة بالافتراضيّة

7.1 Priority & VLAN / Packet Priority & VLAN / NDIS QoS

تهمّ هذه الخصائص عندما يكون وسم VLAN أو وسم الأولويّة متعمّداً.

إرشاد عمليّ

  • اتركها وحدها على شبكة access مسطّحة بسيطة
  • تعامل معها بجدّيّة عندما يعتمد تصميم الشبكة فعلاً على سلوك VLAN أو QoS

7.2 VMQ / VMMQ / SR-IOV

هذه بشكل رئيسيّ إعدادات مستضيف الافتراضيّة، خاصّةً على Hyper-V.

إرشاد عمليّ

  • ليست إعدادات سرعة عامّة لسطح المكتب
  • قيّمها مع تصميم vSwitch ووضع الطوابير وسلوك الضيف معاً

7.3 RDMA / DCB / PFC عالم آخر

عندما تنتقل المحادثة إلى SMB Direct أو RDMA أو PFC أو DCB، تكون في فضاء تصميم أكثر تخصّصاً بكثير.

إرشاد عمليّ

  • تعامل معه كموضوع منفصل عن ضبط سطح المكتب العاديّ بـ 1 GbE أو 2.5 GbE
  • تحقّق من جانب NIC وجانب الـ switch معاً

8. إعدادات توفير الطاقة والـ sleep و Wake on LAN

8.1 Energy Efficient Ethernet (EEE) / Green Ethernet

يتعلّق EEE بـ استخدام طاقة أقلّ عندما يكون الـ link خاملاً.

إرشاد عمليّ

  • ليس إعداد سرعة
  • قد يكون جيّداً تماماً في الاستخدام العاديّ للعميل
  • هو أيضاً مرشّح عزل شائع عندما تكون الأعراض عدم استقرار الـ link، أو تراجعاً غير مفسَّر، أو حسّاسيّة لـ latency منخفضة

تحدّد هذه الإعدادات مدى عدوانيّة دخول NIC إلى حالات طاقة أقلّ.

إرشاد عمليّ

  • معقول تركها على القيمة الافتراضيّة على أجهزة اللابتوب
  • يستحقّ التحقّق منها أوّلاً عندما يكون سلوك الاستئناف غير موثوق
  • أحياناً أسهل تعطيلها على أنظمة التحكّم الصناعيّ أو الأنظمة التي تعمل دائماً

8.3 Wake on Magic Packet / Wake on Pattern Match

تحدّد هذه الإعدادات كيف يُسمَح للجهاز بالاستيقاظ من نشاط الشبكة.

إرشاد عمليّ

  • إذا كنت تحتاج فقط Wake on LAN، فعّل Wake on Magic Packet
  • عطّل خصائص الإيقاظ كلّيّاً إذا لم تكن بحاجتها
  • تعامل مع Pattern Match بحذر لأنّه يمكن أن يسبّب عمليّات إيقاظ غير مقصودة

تذكّر أنّ إعدادات BIOS / UEFI وعلامة التبويب Power Management في Windows تهمّ هنا أيضاً. إعداد NIC وحده ليس دائماً كافياً.

8.4 ARP Offload / NS Offload

تسمح هذه لـ NIC بالردّ على قدر صغير من حركة الشبكة بينما النظام نائم.

إرشاد عمليّ

  • عادةً جيّد تركها مُفعَّلة
  • في الغالب تُلمَس مؤقّتاً أثناء استكشاف أخطاء الـ sleep والاستئناف

8.5 علامة التبويب Power Management

علامة التبويب المنفصلة Power Management غالباً تهمّ بقدر ما تهمّ علامة التبويب Advanced.

تشمل الخيارات الشائعة:

  • Allow the computer to turn off this device to save power
  • Allow this device to wake the computer
  • Only allow a magic packet to wake the computer

إرشاد عمليّ

  • إذا كان سلوك الاستئناف غير مستقرّ، فإنّ الخيار الأوّل شيء معقول جدّاً لفحصه
  • إذا كانت عمليّات الإيقاظ غير المرغوبة هي المشكلة، فإنّ خيار magic packet فقط هو غالباً الاختيار الأكثر أماناً

9. إعدادات أخرى تظهر لكن أقلّ شيوعاً للضبط

9.1 Network Address / Locally Administered Address

يتجاوز هذا يدويّاً عنوان MAC.

إرشاد عمليّ

  • ليس إعداد أداء
  • اتركه وحده ما لم يكن لديك حاجة اختبار أو ترحيل محدّدة جدّاً

9.2 Adaptive Inter-Frame Spacing

هذه خاصّيّة قديمة إلى حدٍّ ما لها تاريخ أكثر من قيمتها اليوميّة على شبكات Ethernet الحديثة المُبدَّلة كاملة الإرسال المزدوج.

إرشاد عمليّ

  • اتركها على القيمة الافتراضيّة في البيئات العاديّة
  • المسها فقط لحالة قديمة خاصّة أو حلّ بديل موجَّه من الموزّع

9.3 Header Data Split

هذا أكثر صلةً بسيناريوهات معيّنة موجَّهة للخادم منه على جهاز عميل نمطيّ.

إرشاد عمليّ

  • اتركه على القيمة الافتراضيّة ما لم يشر عبء العمل وإرشاد الموزّع بوضوح إليه

9.4 Low Latency Interrupts

يكشف بعض الموزّعين عن خاصّيّة باسم مماثل.

إرشاد عمليّ

  • استخدمها فقط إذا قال القياس إنّها تربح
  • لا تفعّلها فقط لأنّ الاسم يبدو جذّاباً

9.5 العناصر القديمة مثل TCP Chimney Offload / IPsec Task Offload

لا تزال بعض الـ drivers الأقدم تظهر خصائص offload قديمة جدّاً.

إرشاد عمليّ

  • في بيئات Windows الحاليّة، هذه عموماً ليست المكان الذي تريد أن تنفق فيه وقتك
  • فضّل إرشاد Microsoft الحاليّ على العادة القديمة

10. نقاط البداية حسب الهدف

10.1 استخدام سطح المكتب أو اللابتوب العاديّ

  • Speed & Duplex: Auto
  • MTU / Jumbo: 1500 / مُعطَّل
  • Checksum Offload: مُفعَّل
  • LSO: مُفعَّل
  • RSC: مُفعَّل
  • RSS: مُفعَّل
  • Interrupt Moderation: افتراضيّ / adaptive
  • Buffers: افتراضيّ
  • Flow Control: افتراضيّ
  • EEE / Green Ethernet: افتراضيّ
  • Selective Suspend: افتراضيّ
  • Wake on LAN: فقط عند الحاجة

الموقف الافتراضيّ عادةً هو نقطة البداية الصحيحة.

10.2 NAS والنسخ الاحتياطيّ وأعباء النسخ الكبير

  • Speed & Duplex: Auto
  • Jumbo: يُقيَّم فقط إذا أمكن مواءمة المسار المخصّص
  • Checksum Offload: مُفعَّل
  • LSO: مُفعَّل
  • RSC: مُفعَّل
  • RSS: مُفعَّل
  • RSS queues: زِدها فقط إذا برّرت القياسات ذلك
  • Receive / Transmit Buffers: زِدها فقط إذا أظهرت العدّادات ضغطاً
  • Interrupt Moderation: افتراضيّ أو أعلى قليلاً
  • EEE: فكّر في تعطيله إذا كان الاستقرار أهمّ

تستفيد هذه الأعباء غالباً من حزم أقلّ، وحمل CPU أقلّ، وتجنّب نقص الطوابير.

10.3 الكاميرات الصناعيّة، أو التحكّم في الأجهزة، أو مسارات الـ latency المنخفضة

  • Speed & Duplex: Auto أوّلاً، ثابت فقط عندما يتطلّب الجهاز المقابل ذلك
  • Jumbo: فقط عندما تدعمه الكاميرا و NIC والـ switch جميعاً بنظافة
  • Checksum Offload: عادةً مُفعَّل أوّلاً
  • LSO: عطّله مؤقّتاً إذا كان توافق جانب الإرسال مشبوهاً
  • RSC: غالباً يستحقّ تقييمه مُعطَّلاً
  • Interrupt Moderation: اختبر Low أو Off
  • Buffers: تجنّب التضخيم بدون دليل
  • Flow Control: اختبر بحذر
  • EEE / Green Ethernet: غالباً مرشّح للتعطيل
  • Selective Suspend / إدارة الطاقة: غالباً مرشّحة للتعطيل

تحسينات throughput العالية لا تنتج تلقائيّاً أفضل سلوك latency.

10.4 مستضيف Hyper-V

  • VMQ / VMMQ / SR-IOV: يُقيَّم مع التصميم الشامل
  • RSS: لا يزال مهمّاً على جانب المستضيف
  • RSC: خاضع لقيود الـ switch الافتراضيّ
  • QoS / VLAN: يطابق تصميم vSwitch
  • Flow Control / PFC: يُقيَّم مع تصميم التخزين أو RDMA

هذا تصميم بنية تحتيّة، لا مجرّد ضبط محوّل.

10.5 ملفّ تعريف مؤقّت لاستكشاف الأخطاء

عندما يكون الهدف الحقيقيّ هو التشخيص، يكون السلوك الأبسط أفضل من السلوك الأمثل نظريّاً.

  • Speed & Duplex: Auto
  • MTU: 1500
  • Jumbo: مُعطَّل
  • EEE: مُعطَّل
  • LSO: مُعطَّل مؤقّتاً
  • RSC: مُعطَّل مؤقّتاً
  • Interrupt Moderation: افتراضيّ أو أقلّ
  • Wake / power save: مُعطَّل إذا كان غير ضروريّ
  • احفظ الإعدادات الأصليّة أوّلاً

11. أوّل الأماكن للنظر فيها حسب العَرَض

11.1 يجب أن يكون 1 Gbps أو 2.5 Gbps، لكنّه يربط عند 100 Mbps

تحقّق، بهذا الترتيب العامّ:

  1. جودة الكابل
  2. سلوك dock / USB NIC / المحوّل
  3. منفذ الـ switch
  4. تحديثات الـ driver
  5. EEE / Green Ethernet
  6. أعد Speed & Duplex إلى Auto
  7. عندها فقط جرّب مطابقة الإعدادات اليدويّة على الجانبين

11.2 عمليّات النقل الكبيرة بطيئة، لكنّ ping يبدو طبيعيّاً

انظر إلى:

  • Checksum Offload
  • LSO
  • RSC
  • RSS
  • Receive / Transmit Buffers
  • jumbo frames، إذا كان المسار مخصّصاً
  • عدّادات drop و error في NIC

هذه عادةً مشكلة throughput، لا مشكلة وصول أساسيّ.

11.3 حركة المرور الصغيرة من نوع request/response تشعر ببطء أو jitter

انظر إلى:

  • Interrupt Moderation
  • RSC
  • EEE
  • Flow Control
  • ما إذا كانت الـ buffers مضخّمة الحجم

التحسينات الصديقة للتجميع يمكن أن تعمل ضدّ سلوك latency منخفض.

11.4 NIC يختفي بعد الـ sleep أو يستغرق عدّة ثوانٍ للتعافي

انظر إلى:

  • Selective Suspend
  • إعدادات Device Sleep أو المتعلّقة بـ standby
  • خيار Power Management الذي يسمح لـ Windows بإيقاف الجهاز
  • firmware الـ dock أو USB NIC
  • مزيج إعدادات الإيقاظ

مشاكل الاستئناف غالباً جدّاً مشاكل إدارة طاقة.

11.5 التقاط الحزم يُظهر أخطاء checksum كثيرة

قبل افتراض أنّ السلك سيّئ، أكّد:

  • ما إذا كان Checksum Offload مُفعَّلاً
  • ما إذا كان LSO مُفعَّلاً
  • ما إذا كان الالتقاط يرى الحزمة قبل الإرسال أم على السلك
  • ما إذا كان منفذ مرآة أو مستضيف آخر يرى الشيء نفسه

غالباً جدّاً، أخطاء checksum المحلّيّة هي مجرّد الجانب المرئيّ من سلوك offload.

11.6 فقط Hyper-V VMs بطيئة، أو يبدو استخدام CPU غير متساوٍ

عندها لا يكفي تفكير RSS بأسلوب سطح المكتب. انظر إلى:

  • VMQ / VMMQ
  • SR-IOV
  • ربط vSwitch
  • VLAN / QoS
  • كيف يقسم المستضيف والضيف عمل الطوابير

في الشبكات الافتراضيّة، رسم مسار الحزمة غالباً يساعد أكثر من تغيير خصائص عشوائيّة.

12. ملاحظات PowerShell عمليّة

12.1 خذ نسخة احتياطيّة من الحالة الحاليّة أوّلاً

Get-NetAdapterAdvancedProperty -Name "Ethernet" |
  Select-Object Name, DisplayName, DisplayValue, RegistryKeyword, RegistryValue |
  Export-Csv .\nic-advanced-backup.csv -NoTypeInformation -Encoding UTF8

12.2 اسرد الخصائص المتقدّمة

Get-NetAdapterAdvancedProperty -Name "Ethernet" |
  Sort-Object DisplayName |
  Format-Table DisplayName, DisplayValue, RegistryKeyword -Auto

12.3 افحص RSS و RSC والإحصائيّات

Get-NetAdapterRss -Name "Ethernet"
Get-NetAdapterRsc -Name "Ethernet"
Get-NetAdapterStatistics -Name "Ethernet"

12.4 أمثلة على التغييرات

# مثال: تغيير Jumbo Packet (القيم الفعليّة تختلف حسب NIC)
Set-NetAdapterAdvancedProperty -Name "Ethernet" `
  -DisplayName "Jumbo Packet" `
  -DisplayValue "9014 Bytes"
# مثال: ضبط عدد طوابير الاستقبال لـ RSS
Set-NetAdapterRss -Name "Ethernet" -NumberOfReceiveQueues 4

12.5 التحقّق من مسار Jumbo

# يقابل تقريباً مسار MTU 1500 المعياريّ
ping <peer-ip> -f -l 1472

# يقابل تقريباً مسار MTU 9000
ping <peer-ip> -f -l 8972

التفصيل المهمّ هو أنّ قيمة driver مثل 9014 Bytes ليست الرقم نفسه من وجهة النظر نفسها مثل أحجام payload في ping هذه.

12.6 ملاحظات عمليّة

  • بعض الإعدادات تتطلّب تعطيل المحوّل وإعادة تفعيله، أو إعادة تشغيل
  • قد تكون أسماء العرض مترجمة محلّيّاً
  • يمكن للموزّع نفسه إعادة تسمية العناصر عبر إصدارات الـ driver
  • إذا قمت بأتمتة التغييرات، فعدّد الجهاز الفعليّ أوّلاً ثمّ اكتب script ثانياً

13. الخلاصة

تبدو الخصائص المتقدّمة لـ NIC في Windows كجدار من الخيارات القويّة.
في الواقع هي مجموعة من المقايضات حول throughput و latency واستخدام CPU وسلوك الطاقة والتوافق.

إذا كانت هناك طريقة واحدة للتعامل معها بأمان، فهي هذه:

  • قرّر ما الذي تحاول تحسينه
  • غيّر خاصّيّةً واحدة في كلّ مرّة
  • قارن قبل وبعد بقياسات حقيقيّة

هذا النهج أكثر أماناً بكثير من الاعتماد على أسماء تبدو فقط سريعة.

14. المراجع

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

كيف نستعمل Windows Sandbox لتسريع التحقّق من تطبيقات Windows - صلاحيّات المسؤول والبيئات النظيفة وإعادة إنتاج حالات نقص الصلاحيّات أو الموارد

مرشد عمليّ يبيّن كيف يسرّع Windows Sandbox التحقّق من تطبيقات Windows، عبر ملفّات .wsb لكلّ سيناريو وفحوصات المستخدم القياسيّ ومحاكاة شُح...

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

يركّز على تطوير برامج ويندوز، والاستشارات التقنية، والتحقيق في الأخطاء، ويتميّز في المشاريع التي تبقى فيها الأصول القديمة ناشطة، وفي تشخيص الأعطال التي يصعب تحديد سببها.

روابط عامة

العودة إلى المدونة