מדריך להגדרות מתקדמות של כרטיס רשת ב-Windows - RSS/LSO/EEE/Wake on LAN

בכרטיס הרשת של Windows, בלשונית [Advanced], מופיעות הרבה מילים שלא מוכרות במבט ראשון. ‏Jumbo Packet,‏ Large Send Offload,‏ Interrupt Moderation,‏ Receive Side Scaling,‏ Flow Control,‏ Energy Efficient Ethernet. במבט על השמות בלבד מתחשק להפעיל הכול, אבל בפועל מה רוצים לתעדף קובע את התשובה הנכונה.

• להעלות את התפוקה בהעברות גדולות
• לצמצם השהיה של packet-ים קטנים
• להוריד את עומס ה-CPU
• לייצב חזרה משינה ו-Wake on LAN
• לבודד בעיית התאמה עם דרייבר או מתג

אם זה נשאר לא ברור ופשוט עושים “נפעיל הכול”, “ניתן Jumbo 9014”, “נקבע 1Gbps Full כי זה איטי”, זה נכשל די רגיל.

flowchart TB
    accTitle: נגיעה בלי מטרה ברורה נכשלת
    accDescr: תרשים המראה שאם לא ברור מה רוצים לתעדף ופשוט מפעילים הכול, מגדירים Jumbo, או קובעים מהירות, זה נוטה להיכשל, ואילו קביעת המטרה מקודם משנה את התשובה הנכונה.
    vague1["לא ברור מה רוצים לתעדף"] --> hasty1["פשוט מפעילים הכול / Jumbo / קביעה"]
    hasty1 --> acc1["נכשל די רגיל"]
    clear1["קובעים מה רוצים לתעדף"] -->|"זה משנה את התשובה"| pick3["מצטמצם מה שצריך לגעת בו"]

איור 1: נגיעה בהגדרות שנראות חזקות בלי מטרה נכשלת, וקביעת מטרה מצמצמת את מה שצריך לגעת בו.

המאמר הזה מתמקד בעיקר בכרטיסי Ethernet קוויים ב-Windows 10 /‏ 11 /‏ Windows Server, ומסדר את הגישה לטיפול בהגדרות המתקדמות של NIC בעבודה מעשית. נכתוב יחד את משמעות ההגדרה, מה נוטה לקרות כשמעלים / מורידים / מפעילים / מבטלים ערך, ובאילו מצבים כדאי לגעת בה — כך שאפשר לראות את התמונה הכוללת.

חשוב לציין ששם התצוגה והערכים האפשריים משתנים מאוד בין יצרן לדרייבר. לפעמים Jumbo Packet הוא Jumbo Frames, לפעמים Receive Buffers הוא Receive Descriptors, ולפעמים Priority & VLAN הוא Packet Priority & VLAN. במאמר הזה, פריטים בעלי משמעות קרובה מטופלים יחד.

איך משתמשים במאמר הזה

יש 14 פרקים והמאמר ארוך, לכן נציג קודם מפת ניווט. אין צורך לקרוא הכול.

הדרך הנפוצה ביותר היא כנראה “להיכנס מתוך תסמין, פרק 11 → הפרק המתאים להגדרה → חזרה בפרק 10”.

flowchart TB
    accTitle: מסלול הקריאה הנפוץ ביותר
    accDescr: תרשים המראה שנכנסים מתוך תסמין לפרק 11, בודקים מגמות טיפוסיות לפי תסמין, עוברים לפרק ההגדרה המתאימה כדי להבין את משמעותה, וחוזרים לפרק 10 לפי מטרה.
    sym1["נכנסים מתוך תסמין"] --> ch11["פרק 11 (מגמות טיפוסיות לפי תסמין)"]
    ch11 --> chd1["פרק ההגדרה המתאימה (5-9)"]
    chd1 --> ch10["פרק 10 (חזרה לפי מטרה)"]

איור 2: נכנסים מתוך תסמין לפרק 11, עוברים דרך פרק ההגדרה המתאימה, וחוזרים לפי המסקנה בפרק 10 — זה המסלול הטיפוסי.

מילון קיצורים מקוצר

כדי שיהיה נוח לקרוא לצד מסך ההגדרות, נרכז כאן את הקיצורים שמופיעים במאמר הזה.

1. קודם המסקנה

תחילה, רק את המסקנות שלא כדאי לפספס בעבודה מעשית.

• Speed & Duplex בעיקרון על Auto. בבעיית ירידה ל-100Mbps, קפיצה ישירה לקביעה קבועה של 1.0 Gbps Full Duplex היא הצעד האחרון.
• Checksum Offload /‏ RSS /‏ LSO /‏ RSC — בעיקרון מופעלים או בברירת מחדל. ביטול רשלני של כולם נוטה לבזבז CPU מיותר.
• Jumbo Packet רק כשהוא תואם מקצה לקצה. אם רק ה-NIC על 9014 אבל מסלול הביניים נשאר ב-1500, זו מלכודת.
• Interrupt Moderation הוא משיכת חבל בין תפוקה להשהיה. הגברה מקלה על ה-CPU אבל מגדילה השהיה.
• Flow Control עשוי לצמצם drops, אבל גם עשוי להרחיב עומס.
• EEE /‏ Green Ethernet /‏ Selective Suspend הן הגדרות לחיסכון בחשמל, לא הגדרות להאצה.
• VMQ /‏ SR-IOV מיועדים למארח Hyper-V, אלה לא קסם שמאיץ מחשב שולחני רגיל.
• Wake on Pattern Match נוטה לגרום ל-wake לא רצוי, ואם רוצים רק Wake on LAN, בטוח יותר להתמקד ב-Magic Packet.
• פריטים ישנים כמו TCP Chimney Offload עדיף לא לגעת בהם היום.

בקיצור, ההגדרות המתקדמות של NIC אינן “מקום שמפעילים בו הכול שנראה חזק”. זה מקום שקובעים בו האם רוצים תפוקה, השהיה, CPU, צריכת חשמל או תאימות, ונוגעים פריט אחד בכל פעם.

flowchart TB
    accTitle: מקומה של לשונית ההגדרות המתקדמות
    accDescr: תרשים המראה שההגדרות המתקדמות של NIC אינן מקום שמפעילים בו הכול שנראה חזק, אלא מקום שקובעים בו איזה ציר לתעדף ונוגעים פריט אחד בכל פעם.
    allon1["הפעלת הכול שנראה חזק"] -.->|"זה לא המקום הזה"| tab1["ההגדרות המתקדמות של NIC"]
    dec1["קביעת הציר הרצוי"] --> one2["נגיעה בפריט אחד בכל פעם"]
    one2 --> tab1

איור 3: לשונית ההגדרות המתקדמות משמשת רק אחרי שקובעים איזה ציר רוצים, ואז נוגעים פריט אחד בכל פעם.

מפת הידע של המאמר

המאפיינים המתקדמים של כרטיס רשת ב-Windows (כרטיסיית Advanced) כוללים פריטים רבים — ‏Speed & Duplex,‏ Jumbo Frame,‏ Checksum Offload,‏ LSO/TSO,‏ RSC/LRO,‏ RSS,‏ Interrupt Moderation,‏ Flow Control,‏ EEE,‏ Wake on LAN,‏ Selective Suspend ו-VMQ/SR-IOV — וכולם מוגדרים באותה כרטיסייה. כשרוצים תפוקה גבוהה בהעברות גדולות כדאי להפעיל Jumbo,‏ LSO,‏ RSC ו-RSS, ואילו כשרוצים השהיה נמוכה כדאי לשקול השבתה של RSC,‏ Interrupt Moderation ו-EEE. קיבוע צד אחד בלבד ב-Speed & Duplex עלול לגרום לאי-התאמת duplex, ו-EEE עלול לגרום ל-downshift של הקישור ל-100Mbps; כאשר Checksum Offload פעיל, לכידה מקומית עלולה להיראות כאילו יש בה שגיאות checksum, אך ניתן להבחין בכך באמצעות pktmon או port מראה.

flowchart LR
    accTitle: מפת הידע של מדריך המאפיינים המתקדמים של כרטיס רשת ב-Windows
    accDescr: תרשים המראה כיצד כל הגדרות המאפיינים המתקדמים של כרטיס הרשת מתכנסות בכרטיסייה Advanced, כיצד ההגדרות המומלצות נבדלות בין דגש על תפוקה לדגש על השהיה נמוכה, כיצד Speed & Duplex ו-EEE עלולים לגרום ל-downshift או לאי-התאמת duplex, ואת הקשר בין Checksum Offload להופעת שגיאות checksum בלכידה מקומית ולבדיקה עם pktmon.
    nic_advanced_properties["הגדרות מתקדמות של כרטיס הרשת (לשונית Advanced)"]
    speed_duplex["Speed & Duplex"]
    duplex_mismatch["אי-התאמת duplex"]
    link_speed_downshift["ירידת מהירות הקישור"]
    jumbo_frame["Jumbo Packet/Jumbo Frames"]
    checksum_offload["Checksum Offload"]
    local_capture_checksum_error["שגיאות checksum בלכידה מקומית"]
    pktmon["Packet Monitor(pktmon)"]
    lso_tso["Large Send Offload(LSO/TSO)"]
    rsc_lro["Receive Segment Coalescing(RSC/LRO)"]
    rss_nic["Receive Side Scaling(RSS)"]
    interrupt_moderation["Interrupt Moderation"]
    flow_control_8023x["Flow Control(802.3x pause frame)"]
    eee["Energy Efficient Ethernet(EEE/Green Ethernet)"]
    wake_on_lan["Wake on LAN(Wake on Magic Packet)"]
    selective_suspend["Selective Suspend"]
    vmq_sriov["VMQ/VMMQ/SR-IOV"]
    low_latency_workload["עומס עבודה שמחייב השהיה נמוכה"]
    large_transfer_workload["עומס עבודה של העברות גדולות ותפוקה גבוהה"]
    hyper_v_host_networking["תצורת הרשת של מארח Hyper-V"]
    nic_resume_failure["תקלות חיבור בכרטיס הרשת אחרי יציאה משינה"]
    speed_duplex -->|"מוגדר באמצעות"| nic_advanced_properties
    speed_duplex -.->|"עלול לגרום ל"| duplex_mismatch
    speed_duplex -.->|"מצמצם"| link_speed_downshift
    jumbo_frame -->|"מוגדר באמצעות"| nic_advanced_properties
    checksum_offload -->|"מוגדר באמצעות"| nic_advanced_properties
    checksum_offload -.->|"עלול לגרום ל"| local_capture_checksum_error
    local_capture_checksum_error -->|"נבדק באמצעות"| pktmon
    lso_tso -->|"מוגדר באמצעות"| nic_advanced_properties
    rsc_lro -->|"מוגדר באמצעות"| nic_advanced_properties
    rss_nic -->|"מוגדר באמצעות"| nic_advanced_properties
    interrupt_moderation -->|"מוגדר באמצעות"| nic_advanced_properties
    flow_control_8023x -->|"מוגדר באמצעות"| nic_advanced_properties
    eee -->|"מוגדר באמצעות"| nic_advanced_properties
    wake_on_lan -->|"מוגדר באמצעות"| nic_advanced_properties
    selective_suspend -->|"מוגדר באמצעות"| nic_advanced_properties
    vmq_sriov -->|"מוגדר באמצעות"| nic_advanced_properties
    rsc_lro -.->|"שימוש לא מומלץ ל"| low_latency_workload
    interrupt_moderation -.->|"שימוש לא מומלץ ל"| low_latency_workload
    eee -.->|"שימוש לא מומלץ ל"| low_latency_workload
    jumbo_frame -.->|"מענה מומלץ ל"| large_transfer_workload
    rss_nic -->|"מענה מומלץ ל"| large_transfer_workload
    lso_tso -->|"מענה מומלץ ל"| large_transfer_workload
    rsc_lro -->|"מענה מומלץ ל"| large_transfer_workload
    vmq_sriov -->|"מענה מומלץ ל"| hyper_v_host_networking
    selective_suspend -.->|"עלול לגרום ל"| nic_resume_failure
    eee -.->|"עלול לגרום ל"| link_speed_downshift

בתרשים, קו מלא מציין קשר שמתקיים תמיד וקו מקווקו מציין קשר מותנה (תנאי ההתקיימות מפורטים בהסבר של כל קשר בעמוד המפורט). רשימת כל הקשרים (סך הכול 26, עם אסמכתה ורמת ודאות) והגדרות המושגים המרכזיים מרוכזות בעמוד המפורט של מפת הידע (ביפנית). נתונים: JSON-LD / Turtle

2. איפה רואים את ההגדרות

2.1 צפייה ב-GUI

דרך חיבורי הרשת

1. הרצת ncpa.cpl
2. לחיצה ימנית על המתאם הרצוי
3. מאפיינים ← תצורה
4. לשונית הגדרות מתקדמות (Advanced)

דרך מנהל ההתקנים

1. מנהל ההתקנים
2. מתאמי רשת
3. לחיצה ימנית על ה-NIC הרצוי ← מאפיינים
4. לשונית הגדרות מתקדמות

ההגדרות שמופיעות כאן הן הכוכב הראשי של המאמר הזה. עם זאת, גם הגדרות לשונית Power Management משמעותיות בעבודה מעשית, ונדון בהן בהמשך.

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 תלויים בדרייבר. כשכותבים סקריפט שינוי, בטוח יותר לבדוק קודם רשימה במחשב עצמו.

flowchart TB
    accTitle: הסדר הנכון לבדיקה עם PowerShell
    accDescr: תרשים המראה שלפני כתיבת סקריפט שינוי בודקים רשימה במחשב עצמו, מוודאים ששם התצוגה תלוי בדרייבר, ורק אז כותבים את הסקריפט, כולל גיבוי לפני השינוי.
    lst1["בדיקת רשימה במחשב עצמו"] --> dep1["אימות ששם התצוגה תלוי בדרייבר"]
    dep1 --> scr1["רק אז כתיבת סקריפט שינוי"]
    scr1 -.-> bk1["גם גיבוי לפני השינוי"]

איור 4: מכיוון ששם התצוגה תלוי בדרייבר, קודם בודקים רשימה במחשב עצמו ורק אז כותבים סקריפט.

3. עקרונות יסוד לפני שנוגעים

לפני שנוגעים בהגדרות NIC, פספוס בנקודות הבאות בדרך כלל גורם להיתקעות.

3.1 קודם קובעים “מה רוצים לשפר”

גם אם אומרים “הרשת איטית”, התוכן שונה לגמרי.

• העתקת קבצים גדולה איטית ← תפוקה,‏ RSS,‏ RSC,‏ LSO,‏ Jumbo, מאגר
• request/response קטנים מגיבים לאט ← Interrupt Moderation,‏ RSC,‏ EEE, עומק תור
• ה-CPU גבוה ← offload,‏ RSS,‏ RSC, הפרעות
• לא תקין אחרי חזרה משינה ← Selective Suspend,‏ Power Management,‏ WoL
• מתנתק מדי פעם / יורד ל-100Mbps ← כבל, מכשיר בצד השני,‏ Speed & Duplex,‏ EEE, דרייבר

אם נוגעים באותה הגדרה כשהמטרה שונה, זה לא רק לא משתפר — זה מחמיר.

flowchart TB
    accTitle: קודם מפרידים את תוכן ה"איטי"
    accDescr: תרשים המראה שגם אם התסמין הוא רשת איטית, התוכן שונה לגמרי, וקודם צריך לקבוע מה רוצים לשפר ולגעת רק בקבוצת ההגדרות המתאימה, אחרת המצב עלול להחמיר.
    slow1["הרשת איטית"] --> split1["קודם מפרידים את התוכן"]
    split1 --> aim1["נוגעים רק בקבוצת ההגדרות המתאימה למטרה"]
    slow1 -.->|"נוגעים בלי להפריד"| worse1["המצב מחמיר במקום להשתפר"]

איור 5: בלי להפריד את תוכן התסמין, נגיעה בהגדרות עלולה להחמיר את אותו “איטי” עצמו.

3.2 קודם חושדים בשכבה הפיזית ובמכשיר השני

יש בעיות שהגדרת NIC פשוט לא פותרת.

• כבל פגום
• אי-התאמה עם מתג / נתב / dock
• קושחה ישנה
• מחסור בחשמל בכרטיס רשת USB
• שגיאות בצד הפורט
• אובדן חבילות ושידור חוזר

בפרט, ירידה ל-100Mbps,‏ קישור שמנתק ומתחבר שוב, וקלקול רק בהעברה גדולה — מהיר יותר לבדוק את השכבה הפיזית ואת הצד השני לפני ההגדרות.

flowchart TB
    accTitle: קודם בודקים שכבה פיזית ומכשיר בצד השני
    accDescr: תרשים המראה שבתסמינים כמו ירידה ל-100Mbps, קישור שמנתק ומתחבר, או קלקול רק בהעברה גדולה, מהיר יותר לחשוד קודם בכבל ובמכשיר בצד השני לפני הגדרת ה-NIC.
    symp1["תסמינים של ירידה בקצב או ניתוק"] --> phys1["קודם כבל, מכשיר בצד השני, שכבה פיזית"]
    phys1 -->|"אם עדיין נשאר"| nicw1["מעבר לבידוד הגדרות NIC"]
    phys1 -.-> nofix1["יש בעיות שהגדרות פשוט לא פותרות"]

איור 6: בתסמינים סביב הקישור, מהיר יותר לחשוד קודם בשכבה הפיזית ובמכשיר השני, לפני ההגדרות.

3.3 משנים פריט אחד בכל פעם

אם משנים בבת אחת Jumbo,‏ LSO,‏ RSC,‏ RSS,‏ EEE, לא ברור מה השפיע. הנוהג הבסיסי הוא לרשום את ההגדרות שלפני השינוי, לשנות פריט אחד בכל פעם, ולמדוד את השינוי.

3.4 קובעים מה מודדים

לכל הפחות, כדאי לבדוק את אלה:

• מהירות הקישור (‏1G /‏ 2.5G /‏ 10G וכדומה)
• תפוקה
• השהיה
• שיעור עומס CPU
• סטטיסטיקת ה-NIC (‏drop /‏ error / מחסור מאגר)
• יציבות ההתאוששות משינה

שינוי הגדרות עדיף לראות במספרים, לא רק בתחושה.

flowchart TB
    accTitle: משנים פריט אחד ומשווים במספרים
    accDescr: תרשים המראה שרושמים את ההגדרות לפני השינוי, משנים פריט אחד בלבד, מודדים את המדד שנקבע, ומשווים במספרים ולא בתחושה — זהו הזרם הבסיסי לשינוי הגדרות.
    w1["רישום ההגדרות לפני השינוי"] --> w2["שינוי פריט אחד בלבד"]
    w2 --> w3["מדידת המדד שנקבע"]
    w3 --> w4["השוואה במספרים, לא בתחושה"]

איור 7: משנים פריט אחד בכל פעם ומשווים במספרים בין לפני לאחרי — זה הדפוס הבסיסי.

4. טבלת ההגדרות המרכזיות

תחילה, טבלה שמאפשרת לראות בבת אחת את התפקיד של כל הגדרה.

5. הגדרות סביב קישור וגודל מסגרת

5.1 Speed & Duplex

זו הגדרה שקשורה למשא ומתן על מהירות הקישור ועל duplex מלא/חצי. שם התצוגה הוא Speed & Duplex,‏ Link Speed,‏ Link Speed & Duplex וכדומה.

מה ההגדרה עושה

ב-Ethernet, ה-NIC והמכשיר השני קובעים באיזו מהירות ובאיזה duplex לתקשר.

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

לרוב אלה האפשרויות שמופיעות.

מה משתנה כשמשנים

קביעה ל-Auto

• בין מכשירים מודרניים, זה בדרך כלל הכי יציב
• ב-1000BASE-T ומעלה, Auto לרוב הנחת יסוד
• מתיישב בקלות גם עם משא ומתן על EEE ועל master/slave

קביעה ידנית קבועה

• לפעמים משתפרת ההתאמה עם מתג ישן או מכשיר בצד השני שקבוע בכוח
• אבל מצב של קביעה רק בצד אחד / Auto רק בצד שני הוא מקור לתקלות
• ‏duplex mismatch גורם לירידת מהירות, שידור חוזר והשהיה חריגה

מדיניות בסיסית בעבודה מעשית

בדרך כלל אפשר להשאיר ב-Auto. “הקצב לא מגיע ל-1Gbps אז נקבע ל-1Gbps Full” נראה חזק, אבל לרוב מפספס את שורש הבעיה.

flowchart TB
    accTitle: duplex mismatch שנגרם מקביעה בצד אחד
    accDescr: תרשים המראה שמצב של קביעה רק בצד אחד ו-Auto בצד השני גורם ל-duplex mismatch, שגורם לירידת מהירות, שידור חוזר והשהיה חריגה, ואילו Auto בשני הצדדים יציב יותר בין מכשירים מודרניים.
    mix1["קביעה רק בצד אחד, Auto בצד שני"] --> mm1["duplex mismatch"]
    mm1 --> sl2["ירידת מהירות, שידור חוזר, השהיה חריגה"]
    auto1["Auto בשני הצדדים"] -->|"בין מכשירים מודרניים"| stb1["בדרך כלל הכי יציב"]

איור 8: כשעירוב של קביעה ו-Auto גורם ל-duplex mismatch, ולכן בדרך כלל שני הצדדים נשארים ב-Auto.

5.2 Jumbo Packet /‏ Jumbo Frames

זו הגדרה לשימוש במסגרות Ethernet גדולות מהתקן. שם התצוגה הוא Jumbo Packet,‏ Jumbo Frames,‏ Jumbo Packet Size וכדומה.

מה ההגדרה עושה

Ethernet רגיל בדרך כלל פועל בהנחת MTU של 1500. הפעלת Jumbo Frame מאפשרת שימוש במסגרות גדולות בסביבות 9000 בייט.

עם זאת, כאן יש הרבה מלכודות בשם.

• הדרייבר עלול להציג גודל מסגרת כמו 9014 Bytes
• מערכת ההפעלה או הכלים עלולים להציג מבט L3 כמו MTU 9000
• המתג עלול לספור כולל CRC ותג VLAN

השוואה שטחית של המספרים גורמת בקלות למלכודת.

flowchart TB
    accTitle: אופני הספירה השונים של מספרי Jumbo
    accDescr: תרשים המראה שבאותה הגדרת Jumbo, הדרייבר מציג גודל מסגרת, מערכת ההפעלה והכלים מציגים MTU במבט L3, והמתג סופר כולל תג ו-CRC, ולכן השוואה שטחית של המספרים בלבד היא מלכודת.
    drv1["הדרייבר: הצגת גודל מסגרת"] --> cmp2["אותו דבר, נספר אחרת"]
    osv1["מערכת ההפעלה / כלים: MTU במבט L3"] --> cmp2
    sw1["המתג: כולל תג ו-CRC"] --> cmp2
    cmp2 --> trap1["השוואה שטחית של המספרים היא מלכודת"]

איור 9: הדרייבר, מערכת ההפעלה והמתג סופרים אחרת, ולכן אין להשוות בין מספרי Jumbo שטחית.

מה משתנה כשמשנים

הגדלה / הפעלה

• בשליחת נתונים גדולים, מספר ה-packet-ים יורד
• מספר פעולות עיבוד הכותרת יורד
• שיעור עומס ה-CPU נוטה לרדת
• מצד שני, זמן התפיסה של packet בודד מתארך
• אם משהו במסלול לא תומך, זה מקור ל-drop או fragmentation

חזרה לתקן / ביטול

• התאימות הגבוהה ביותר
• מספר ה-packet-ים גדל
• בהעברה גדולה, נוטה לעלות עומס CPU / כותרת

מדיניות בסיסית בעבודה מעשית

ל-Jumbo יש משמעות רק כשהוא תואם מקצה לקצה.

• ה-NIC שלכם
• ה-NIC של הצד השני
• המתג שבדרך
• אם יש VLAN או מתג וירטואלי — גם העומס שלו

אם אחד מאלה נשאר על 1500, לא רק שלא מקבלים תועלת — זה נהיה מקור לתקלה.

flowchart TB
    accTitle: ל-Jumbo יש משמעות רק כשהוא תואם מקצה לקצה
    accDescr: תרשים המראה של-Jumbo Frame יש משמעות רק כשה-NIC שלנו, המתג שבדרך וה-NIC של הצד השני כולם תואמים מקצה לקצה, ואם אחד מהם נשאר על 1500 זה מקור לתקלה במקום תועלת.
    myn1["ה-NIC שלנו"] --> mid1["המתג שבדרך"]
    mid1 --> yrn1["ה-NIC של הצד השני"]
    yrn1 --> okj1["רק כשהכול תואם — יש משמעות"]
    mid1 -.->|"אם אחד נשאר על 1500"| ngj1["אין תועלת — מקור לתקלה"]

איור 10: ל-Jumbo יש משמעות רק כשכולם במסלול תואמים, ואם אפילו אחד נשאר על 1500, זה פועל הפוך.

5.3 Gigabit Master / Slave Mode

זו הגדרה של 1000BASE-T שנוגעת למי מוביל את השעון כ-master ומי כ-slave. במחשב רגיל כמעט אף פעם לא נוגעים בזה.

מדיניות בסיסית

• Auto בעיקרון
• מעריכים רק בבעיית איכות קישור עם מכשיר ישן מסוים
• לא מטפלים בזה כבורג כוונון ביצועים אלא אם יש הנחיה מהיצרן

5.4 Wait for Link / הגדרות מצב קישור

הגדרה כמו Wait for Link נוגעת להאם הדרייבר מדווח על מצב הקישור רק אחרי שה-auto negotiation הצליח. ‏Log Link State Event הוא כלי אבחון שרושם עלייה/ירידה של הקישור ליומן האירועים.

מדיניות בסיסית

• במחשב רגיל אפשר להשאיר בברירת המחדל
• המשמעות היא לא בביצועים עצמם אלא באבחון אופן ההופעה בהפעלה ובכשלים
• לא פריט שנוגעים בו ראשון

6. הגדרות שמשפיעות על עומס CPU, תפוקה והשהיה

זה הרצועה שנראית “משפיעה ביותר”. פעמים רבות היא באמת משפיעה, אבל הכיוון של ההשפעה נחלק בבירור.

flowchart TB
    accTitle: קבוצת ההגדרות הזו מתחלקת בכיוון ההשפעה
    accDescr: תרשים המראה שקבוצת ההגדרות שמשפיעה על עומס CPU, תפוקה והשהיה מתחלקת בבירור לכיוון של עיבוד מרוכז שמיטיב עם תפוקה ו-CPU, וכיוון של עיבוד פרטני שמיטיב עם השהיה.
    band1["הרצועה שנראית משפיעה"] --> dir1["כיוון עיבוד מרוכז"]
    band1 --> dir2["כיוון עיבוד פרטני"]
    dir1 -.-> g1["יתרון לתפוקה ול-CPU"]
    dir2 -.-> g2["יתרון להשהיה"]

איור 11: גם ברצועה זהה, כיוון ההשפעה נחלק בין נטייה לתפוקה לנטייה להשהיה.

6.1 Checksum Offload

הגדרה שמעבירה את חישוב ה-checksum של IP /‏ TCP /‏ UDP ל-NIC.

מדיניות בסיסית

• בעיקרון מופעל
• אם רוצים להוריד CPU — משאירים
• שגיאת checksum בלכידה לרוב היא רק אופן ההופעה של ה-offload
• ביטול זמני לצורך בידוד התאמה — לגיטימי

6.2 Large Send Offload‏ (LSO) /‏ TSO /‏ Offload TCP Segmentation

הגדרה שמפצלת נתוני שליחה גדולים של TCP למסגרות קטנות, בצד ה-NIC.

על מה זה משפיע

• תפוקה בתקשורת עתירת שליחה
• צמצום עומס CPU
• שליחה רציפה גדולה יחסית

מדיניות בסיסית

• בדרך כלל מופעל
• כשיש חשד להתאמה עם יישום או דרייבר מסוים, מבטלים זמנית ובודקים הבדל

6.3 Receive Segment Coalescing‏ (RSC) /‏ Large Receive Offload

הגדרה שמאחדת בצד הקבלה כמה קטעי TCP.

על מה זה משפיע

• תפוקת צד הקבלה
• צמצום עומס CPU

נקודות זהירות

• לפעמים חיסרון בהשהיה נמוכה או בתצפית ברמת packet
• פרשנות לכידה או תצפית תזמון משתנה מעט

מדיניות בסיסית

• מפעילים אם רוצים תפוקת קבלה
• מועמד להערכה אם רוצים לבחון השהיה של request/response קטנים

flowchart TB
    accTitle: איך RSC משפיע והיכן מתחלקת ההערכה
    accDescr: תרשים המראה ש-RSC מאחד כמה קטעי TCP שהתקבלו בצד ה-NIC, משפיע על תפוקת קבלה וצמצום CPU, אך בהשהיה נמוכה או בעדיפות תצפית עלול להיות חיסרון ולכן נהיה מועמד להערכה.
    seg1["כמה קטעי TCP שהתקבלו"] --> coal1["איחוד בצד ה-NIC (RSC)"]
    coal1 --> up1["משפיע על תפוקת קבלה ו-CPU"]
    coal1 -.->|"בהשהיה נמוכה / עדיפות תצפית"| dn1["חיסרון אפשרי — מועמד להערכה"]

איור 12: RSC הוא הגדרה שמעבדת קבלה במרוכז, ואם רוצים דווקא השהיה, זה נהיה מועמד להערכה.

6.4 offload חדשים יותר בצד UDP‏ (USO /‏ URO)

ב-NIC ובמערכות הפעלה חדשות יותר, לפעמים נראים offload חדשים יותר גם בשליחה וקבלה של UDP.

מדיניות בסיסית

• גם אם מופיע, לא לסטות מברירת המחדל בהתחלה
• מודדים רק כשהדרייבר חדש מספיק וברור מהו עומס העבודה היעד
• בפתרון תקלות, לא נוגעים בכוח

6.5 Receive Side Scaling‏ (RSS)

הגדרה שמפזרת עיבוד קבלה בין כמה מעבדים. משמעותית מאוד בסביבת multi-core.

מדיניות בסיסית

• ב-multi-core, בעיקרון מופעל
• בודקים ראשון בתסמין של תקיעה על מעבד יחיד
• כוכב ראשי גם ב-Hyper-V ולפני high-throughput

flowchart TB
    accTitle: איך עיבוד הקבלה משתנה עם או בלי RSS
    accDescr: תרשים המראה שכש-RSS מבוטל, עיבוד הקבלה מתרכז במעבד יחיד ונוטה להיחסם, וכשהוא מופעל, העיבוד מתפזר בין כמה מעבדים ונוטה לגדול ב-multi-core.
    rin1["תעבורת הקבלה"] -->|"RSS מבוטל"| one3["מתרכזת במעבד יחיד ונוטה להיחסם"]
    rin1 -->|"RSS מופעל"| sp2["מתפזרת בין כמה מעבדים"]
    sp2 --> sc1["נוטה לגדול ב-multi-core"]

איור 13: RSS הוא מנגנון שמפזר את עיבוד הקבלה בין כמה מעבדים, ובודקים אותו ראשון בתסמין של תקיעה על מעבד יחיד.

6.6 RSS Queues /‏ RSS Processors /‏ RSS Profile

פריטים שקובעים את מקבילות ה-RSS.

מדיניות בסיסית

• מתחילים מברירת המחדל
• מגדילים רק אחרי שרואים עומס CPU או הטיה בין תורים
• הגדלה מיותרת עד המקסימום עלולה להגדיל עומס הפרעות ו-DPC

6.7 Interrupt Moderation /‏ Interrupt Moderation Rate

הגדרה שמפחיתה את תדירות ההפרעות, וסוחרת בין עומס CPU להשהיה.

מגמה

• גבוה יותר / Adaptive ← ה-CPU נוטה להיות נוח יותר, אך ההשהיה נוטה לעלות
• נמוך יותר / Off ← ההשהיה נוטה לרדת, אך עומס CPU /‏ DPC נוטה לעלות

מדיניות בסיסית

• מתחילים מברירת מחדל / Adaptive
• אם ה-jitter של packet-ים קטנים מטריד, מעריכים Low / Off
• בהעברה גדולה, ברירת המחדל לרוב פשוטה יותר

flowchart TB
    accTitle: משיכת החבל של Interrupt Moderation
    accDescr: תרשים המראה שהגברת Interrupt Moderation ל-Adaptive או גבוה מקלה על ה-CPU אך נוטה להגדיל השהיה, ואילו הורדתו ל-Low או Off מורידה השהיה אך נוטה להגדיל עומס CPU ו-DPC.
    im1["Interrupt Moderation"] -->|"גבוה / Adaptive"| cpuok["ה-CPU נוח יותר"]
    cpuok -.-> lat1["ההשהיה נוטה לעלות"]
    im1 -->|"נמוך / Off"| latok["ההשהיה נוטה לרדת"]
    latok -.-> cpu2["עומס CPU / DPC נוטה לעלות"]

איור 14: הפחתת תדירות ההפרעות היא סחר בין CPU להשהיה, ומעריכים אותה מנקודת מוצא של ברירת מחדל או Adaptive.

6.8 Receive Buffers /‏ Receive Descriptors ו-Transmit Buffers /‏ Transmit Descriptors

הגדרות שמשנות את עומק ה-ring / המאגר.

כיוון ההשפעה

• עמידות ל-burst
• תפוקה מתמשכת
• הימנעות מ-drop

תופעות לוואי

• צריכת הזיכרון גדלה
• התור מעמיק וייתכן שהשהיית ההמתנה בתור תגדל

מדיניות בסיסית

• מגדילים רק כשרואים drop או מחסור מאגר
• נמנעים מלהגדיל למקסימום סתם

flowchart TB
    accTitle: מתי כדאי להגדיל עומק מאגר
    accDescr: תרשים המראה שהעמקת המאגר משפיעה על עמידות burst והימנעות מ-drop, אך גם גורמת לצריכת זיכרון והשהיית תור, ולכן מגדילים רק כשרואים drop או מחסור מאגר, ונמנעים מהגדלה מקסימלית סתם.
    obs1["רואים drop או מחסור מאגר"] -->|"רק כשרואים"| inc1["מגדילים את המאגר"]
    inc1 -.-> side1["צריכת זיכרון והשהיית תור עלולות לגדול"]
    non1["הגדלה מקסימלית סתם"] -.->|"נמנעים מזה"| inc1

איור 15: מגדילים מאגר רק כשהתסמין נראה במספרים, ונמנעים מהגדלה מקסימלית סתמית.

6.9 Flow Control

הגדרה שקשורה לשליחה וקבלה של 802.3x pause frame.

מדיניות בסיסית

• מועמד אם רוצים להפחית drop
• עם זאת, ה-pause עלול להרחיב עומס אחר
• ברצועת השהיה נמוכה, בודקים בזהירות
• חושבים יחד עם תכנון הרשת הכולל

flowchart TB
    accTitle: הפן הכפול של Flow Control
    accDescr: תרשים המראה שה-pause frame של Flow Control לפעמים מפחית drop, אך לפעמים מרחיב עומס אחר, ולכן צריך לשקול אותו יחד עם תכנון הרשת הכולל.
    fc1["pause frame (Flow Control)"] -->|"לפעמים משפיע"| less1["הפחתת drop"]
    fc1 -.->|"לפעמים מרחיב"| cong1["עומס אחר"]
    fc1 --> tot1["מוחלט יחד עם תכנון הרשת הכולל"]

איור 16: Flow Control לפעמים מפחית drop אך לפעמים מרחיב עומס, ולכן לא מחליטים עליו לבדו.

7. הגדרות סביב VLAN,‏ QoS ווירטואליזציה

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

הרצועה שמטפלת ב-VLAN לפי 802.1Q וב-Priority לפי 802.1p.

מדיניות בסיסית

• שמים לב רק כשבאמת משתמשים ב-VLAN /‏ QoS
• בסביבת access port פשוטה, אפשר להשאיר בברירת המחדל
• תצורה שבה תג נוסף אוטומטית מקשה על בידוד, אז שימו לב

7.2 VMQ /‏ VMMQ /‏ SR-IOV

זו הגדרה שמקבלת משמעות במארח Hyper-V או בתשתית וירטואליזציה.

מדיניות בסיסית

• לא מטפלים בה ככוונון מחשב שולחני רגיל
• במארח Hyper-V, מעריכים יחד עם תצורת vSwitch, הקצאת תורים והגדרות בצד ה-guest
• קשה להגיע לתשובה נכונה אם בודקים רק צד אחד

flowchart TB
    accTitle: יחידת ההערכה של VMQ / SR-IOV
    accDescr: תרשים המראה ש-VMQ ו-SR-IOV מקבלים משמעות במארח Hyper-V, אך צריך להעריך אותם יחד עם תצורת vSwitch, הקצאת תורים והגדרות בצד ה-guest, ושהערכה של צד אחד בלבד לא מספיקה.
    vm1["VMQ / VMMQ / SR-IOV"] --> hv1["מקבלים משמעות במארח Hyper-V"]
    hv1 --> setb["מוערכים יחד עם vSwitch, תורים וצד ה-guest"]
    vm1 -.->|"לא מטפלים כך"| dt1["ככוונון מחשב שולחני רגיל"]

איור 17: הגדרות הוירטואליזציה נבחנות רק כשמסתכלים יחד על המארח, ה-vSwitch וה-guest.

7.3 RDMA /‏ DCB /‏ PFC — עולם נפרד

הרצועה הזו, שכוללת SMB Direct ו-Ethernet ללא אובדן, היא עולם די נפרד.

מדיניות בסיסית

• מפרידים מכוונון מחשב שולחני רגיל של 1GbE /‏ 2.5GbE
• בודקים יחד את חומרי היצרן ואת תכנון המתג

8. הגדרות סביב חיסכון בחשמל, שינה ו-Wake on LAN

8.1 Energy Efficient Ethernet‏ (EEE) /‏ Green Ethernet

הגדרה שמורידה צריכת חשמל בזמן idle של הקישור, לצורך חיסכון.

איך מסתכלים על זה

• לא הגדרה שמאיצה
• משפיעה על צריכת חשמל
• בהתאם לתנאי המכשיר השני והכבל, לפעמים מועמד לבידוד של אי-יציבות קישור או ירידה ל-100Mbps

מדיניות בסיסית

• בשימוש כללי, אפשר להשאיר בברירת המחדל
• באי-יציבות קישור, ירידה ל-100Mbps, או עדיפות להשהיה נמוכה — קודם כל מועמד לבידוד

flowchart TB
    accTitle: מקומו של EEE
    accDescr: תרשים המראה ש-EEE הוא הגדרת חיסכון בחשמל שמורידה צריכה בזמן idle של הקישור ואינה הגדרת מהירות, ובהתאם לתנאי המכשיר והכבל היא מועמד לבידוד באי-יציבות קישור או ירידה ל-100Mbps.
    eee1["EEE / Green Ethernet"] --> sv3["הורדת צריכה בזמן idle"]
    eee1 -.->|"לא הגדרת האצה"| spd1["מהירות / ביצועים"]
    eee1 -.->|"בהתאם למכשיר ולכבל"| tgl1["מועמד לבידוד באי-יציבות / ירידה בקצב"]

איור 18: EEE הוא הגדרת חיסכון בחשמל, ובאי-יציבות קישור או ירידה ל-100Mbps הוא קודם כל מועמד לבידוד.

8.2 Selective Suspend /‏ Device Sleep / בקרת קישור בזמן Standby

במילים פשוטות, זו הגדרה של עד כמה מרדימים את ה-NIC בזמן idle או שינה.

מדיניות בסיסית

• במחשב נייד, מתחילים מברירת המחדל
• אם יש תקלת התאוששות, חושדים בה ראשונה
• במחשב לבקרת מכשירים או בהפעלה 24/7, לפעמים דווקא ביטול ברור יותר

8.3 Wake on Magic Packet /‏ Wake on Pattern Match

זו הגדרה להעיר מחשב רדום, דרך הרשת.

מדיניות בסיסית

• אם צריך Wake on LAN — מפעילים Magic Packet
• אם לא צריך — מבטלים
• Pattern Match רק כשהצורך ברור

יש מקרים רגילים שבהם ההפעלה רק ב-NIC לא מספיקה כדי להעיר. בודקים יחד גם את צד ה-BIOS /‏ UEFI וגם את לשונית Power Management.

flowchart TB
    accTitle: התנאים שבהם Wake on LAN באמת פועל
    accDescr: תרשים המראה ש-Wake on LAN פועל רק כשגם הגדרת Magic Packet ב-NIC, גם הגדרת BIOS/UEFI, וגם לשונית Power Management מתואמים יחד, ולכן צריך לבדוק שלושה מקומות במקביל.
    m1["הגדרת Magic Packet ב-NIC"] --> wol1["Wake on LAN פועל"]
    m2["הגדרות BIOS / UEFI"] --> wol1
    m3["לשונית Power Management"] --> wol1
    wol1 -.-> pt2["Pattern Match נוטה לגרום להתעוררות שגויה"]

איור 19: WoL פועל רק כששלושת המקומות — NIC,‏ BIOS/UEFI ולשונית ניהול החשמל — מתואמים יחד.

8.4 ARP Offload /‏ NS Offload

הגדרה שבה ה-NIC נותן תגובה מינימלית גם בזמן שינה.

מדיניות בסיסית

• בדרך כלל מופעל / ברירת מחדל
• לרוב נוגעים בזה זמנית לצורך בידוד התאמה סביב שינה

8.5 הגדרות לשונית Power Management

בנוסף ללשונית Advanced, במאפייני ה-NIC יש גם לשונית Power Management. גם היא חשובה בשקט.

בדרך כלל רואים את שלוש אלה:

• 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

מדיניות בסיסית

• בבעיית התאוששות, חושדים ראשון ב-Allow the computer to turn off this device...
• אם רוצים למנוע התעוררות שגויה, מפעילים את Only allow a magic packet...
• אם Wake on LAN עצמו לא נחוץ, אפשר לבטל את כל הגדרות ה-wake

flowchart TB
    accTitle: איך קוראים את לשונית Power Management
    accDescr: תרשים המראה שבבעיית התאוששות חושדים קודם בהגדרת אישור כיבוי ההתקן, ואם רוצים למנוע התעוררות שגויה מפעילים הגדרת Magic Packet בלבד, ואם Wake on LAN עצמו לא נחוץ מבטלים את כל הגדרות ה-wake.
    q4["מה מטריד"] -->|"בעיית התאוששות"| a1["חושדים קודם בהגדרת אישור הכיבוי"]
    q4 -->|"מניעת התעוררות שגויה"| a2["הגדרת העלאה רק עם Magic Packet"]
    q4 -->|"WoL עצמו לא נחוץ"| a3["ביטול כל הגדרות ה-wake"]

איור 20: בלשונית Power Management, המקום הראשון לגעת בו נקבע לפי סוג הבעיה.

9. הגדרות נוספות שרואים לעיתים אך נוגעים בהן לעיתים רחוקות

9.1 Network Address /‏ Locally Administered Address

הגדרה לדריסה ידנית של כתובת ה-MAC.

מדיניות בסיסית

• בדרך כלל לא נוגעים
• לא הגדרת ביצועים
• משתמשים רק בסביבת מעבדה או בדרישה מיוחדת

9.2 Adaptive Inter-Frame Spacing

הגדרה ותיקה למדי. ב-switched full-duplex Ethernet מודרני היא לא כוכב ראשי.

מדיניות בסיסית

• ברשת LAN רגילה מודרנית, נשארים בברירת המחדל
• נוגעים רק בציוד ישן או בסביבה מיוחדת, לפי הנחיית היצרן

9.3 Header Data Split

הגדרה בעיקר לשרתים, מסוג שעוזרת לעיבוד CPU על ידי הפרדה בין header ל-payload.

מדיניות בסיסית

• מיועדת לשרתים / לעומס עבודה ספציפי
• בלקוח רגיל, נשארים בברירת המחדל

9.4 Low Latency Interrupts

בחלק מהיצרנים יש פריט כמו Low Latency Interrupts.

מדיניות בסיסית

• משתמשים רק כשמדדו וזה מנצח
• לא רצועה שמפעילים לפי תחושה

9.5 פריטים ישנים כמו TCP Chimney Offload /‏ IPsec Task Offload

ב-NIC ובדרייברים ישנים יותר, לפעמים רואים פריטים כאלה.

מדיניות בסיסית

• היום לא נוגעים, לא משתמשים — זו התשובה הנכונה
• לא נגררים אחר תאימות או חומרים ישנים

flowchart TB
    accTitle: העמדה המשותפת של פרק 9
    accDescr: תרשים המראה שדריסת כתובת MAC, הגדרות ותיקות, הגדרות מיועדות לשרת, ופריטי offload ישנים משותפים בעמדה של השארה בברירת מחדל, ונגיעה רק כשיש הנחיית יצרן, דרישה ברורה ומדידה.
    rare1["הפריטים שהוזכרו בפרק 9"] --> keep1["בדרך כלל נשארים בברירת המחדל"]
    keep1 -->|"נוגעים רק"| cond1["כשיש הנחיית יצרן או דרישה ברורה"]
    cond1 -.-> meas1["משתמשים רק כשמדדו וזה מנצח"]

איור 21: גם אם רואים אותם, בדרך כלל לא נוגעים בהם, ומטפלים רק כשיש הנחיה ברורה ומדידה.

10. הנחיה מקוצרת לפי מטרה

בהמשך יופיע כמה פעמים “הערכת ביטול” ו”מועמד לביטול”. המשמעות היא לא “לבטל”, אלא להפוך למועמד להערכה. התוכן זהה בדיוק לעקרונות של 3.3 ו-3.4, ובאופן קונקרטי אלה ארבעת הצעדים:

1. שמירת ההגדרות שלפני השינוי (‏Export-Csv מ-12.1)
2. ביטול פריט אחד בלבד (3.3)
3. מדידת המדד שנקבע ב-3.4 (תפוקה, השהיה, CPU, סטטיסטיקת NIC, יציבות התאוששות)
4. אם אין השפעה — חוזרים למצב הקודם

אם מדלגים על 4, מצטברים שינויים חסרי משמעות ומקשה על הבידוד הבא. אנא קראו את הפריטים הבאים כרשימת מועמדים להפעלת ארבעת הצעדים האלה.

flowchart TB
    accTitle: ארבעת הצעדים של הערכת ביטול
    accDescr: תרשים המראה שהלולאה של הערכת ביטול היא שמירת ההגדרות לפני השינוי, ביטול פריט אחד בלבד, מדידת המדד שנקבע, וחזרה למצב הקודם אם אין השפעה.
    h1["שמירת ההגדרות לפני השינוי"] --> h2["ביטול פריט אחד בלבד"]
    h2 --> h3["מדידת המדד שנקבע"]
    h3 -->|"אם אין השפעה"| h4["חזרה למצב הקודם"]
    h4 -.->|"למועמד הבא"| h2

איור 22: “הערכת ביטול” לא אומרת לבטל — היא אומרת לבצע את ארבעת הצעדים האלה ולמדוד.

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: מגדילים מעט אם יש drop
• Interrupt Moderation: ברירת מחדל / גבוה מעט
• EEE: הערכת ביטול אם עדיפות ליציבות

בהעברות גדולות, הפחתת מספר packet-ים, הפחתת CPU והימנעות ממחסור תור נוטים להשפיע.

10.3 מצלמות תעשייתיות / בקרת מכשירים / עדיפות להשהיה נמוכה

• Speed & Duplex: בעיקרון Auto. אם צריך, קביעה קבועה שתואמת את הצד השני
• Jumbo: מעריכים אם המצלמה, ה-NIC והמתג תואמים
• Checksum Offload: בעיקרון מופעל
• LSO: אם יש חשד בהתאמת שליחה — הערכת ביטול זמנית
• RSC: מועמד לביטול אם עדיפות להשהיה נמוכה או לתצפית
• Interrupt Moderation: מעריכים Low / Off
• Buffers: לא להגדיל יתר על המידה
• Flow Control: צריך להעריך את תופעות הלוואי של ה-pause
• EEE / Green Ethernet: מועמד לביטול
• Selective Suspend / ניהול חשמל: מועמד לביטול

הגדרות שאופטמות תפוקה לא בהכרח יתרון להשהיה נמוכה.

10.4 מארח Hyper-V

• VMQ /‏ VMMQ /‏ SR-IOV: מעריכים לפי התצורה
• RSS: חשוב לתעבורת צד המארח
• RSC: יש מגבלות בהתאם לתצורת ה-vSwitch
• QoS /‏ VLAN: מתאימים לתכנון ה-vSwitch
• Flow Control /‏ PFC: חושבים יחד עם תכנון האחסון /‏ RDMA

זה לא כוונון מחשב שולחני, אלא תכנון תשתית וירטואליזציה.

10.5 הגדרה זמנית לצורך פתרון תקלות

בבידוד תקלה, חזרה לעולם פשוט זמנית היא הגישה החזקה.

• Speed & Duplex: Auto
• MTU: 1500
• Jumbo: מבוטל
• EEE: מבוטל
• LSO: מבוטל זמנית
• RSC: מבוטל זמנית
• Interrupt Moderation: ברירת מחדל או נמוך
• Wake / חיסכון בחשמל: מבוטל אם לא נחוץ
• ההגדרות שלפני השינוי: חובה לשמור

בבידוד, פשטות ההתנהגות מנצחת על אופטימיזציית ביצועים.

11. נקודות בדיקה ראשונות לפי תסמין

11.1 אמור להיות 1Gbps /‏ 2.5Gbps אבל מתקבל 100Mbps

סדר הבדיקה הראשוני נראה בערך כך:

1. כבל
2. dock / כרטיס רשת USB / מתאם המרה
3. פורט המתג
4. עדכון דרייבר
5. EEE / Green Ethernet
6. החזרת Speed & Duplex ל-Auto
7. אם עדיין לא — קביעה קבועה שתואמת את הצד השני

קביעה ידנית מיידית היא המוצא האחרון.

flowchart TB
    accTitle: סדר הבדיקה בירידה ל-100Mbps
    accDescr: תרשים המראה שהחקירה בירידה ל-100Mbps עוברת בסדר של כבל, dock או כרטיס רשת USB, פורט המתג, עדכון דרייבר, בידוד EEE, חזרה ל-Auto Negotiation, ורק אם עדיין לא עוזר — קביעה קבועה שתואמת את הצד השני.
    s1["כבל"] --> s2["dock / כרטיס רשת USB / המרה"]
    s2 --> s3["פורט המתג"]
    s3 --> s4["עדכון דרייבר"]
    s4 --> s5["בידוד EEE"]
    s5 --> s6["החזרת Speed & Duplex ל-Auto"]
    s6 -->|"אם עדיין לא עוזר"| s7["קביעה קבועה שתואמת את הצד השני"]

איור 23: חקירת הירידה בקצב מתקדמת מהשכבה הפיזית, וקביעה ידנית קבועה היא המוצא האחרון.

11.2 העברה גדולה איטית, אבל ה-ping רגיל

מה שכדאי לבדוק:

• Checksum Offload
• LSO
• RSC
• RSS
• Receive / Transmit Buffers
• Jumbo Frame (אם יש מסלול ייעודי)
• ‏drop /‏ error בסטטיסטיקת ה-NIC

זו בעיה מסוג תפוקה, ולכן Jumbo, תור ו-offload נוטים להשפיע.

11.3 השהיה גדולה ב-request/response קטנים, jitter מטריד

חמישה דברים שכדאי לבדוק:

• Interrupt Moderation
• RSC
• EEE
• Flow Control
• האם ה-Buffers מוגדלים יתר על המידה

ברצועה הזו, אופטימיזציה שמעבדת במרוכז לפעמים דווקא מגדילה השהיה מורגשת.

11.4 NIC נעלם / לא מתחבר כמה שניות אחרי חזרה משינה

חמישה דברים סביב ניהול החשמל שכדאי לבדוק:

• Selective Suspend
• הגדרות Device Sleep / Standby
• Allow the computer to turn off this device... בלשונית Power Management
• קושחת dock / כרטיס רשת USB
• שילוב הגדרות ה-wake

בעיית התאוששות לרוב קשורה יותר לניהול חשמל מאשר ל-NIC עצמו.

11.5 בלכידת חבילות נראה כמות גדולה של שגיאות checksum

לפני שאומרים בבהילות “הקו התקלקל”, בודקים כאן:

• האם Checksum Offload מופעל
• האם LSO מופעל
• האם הלכידה לפני השליחה או על ה-wire
• האם זה זהה גם כשרואים ממארח אחר או מפורט מראה

שגיאת checksum בלכידה מקומית, לרוב במידה רבה היא רק אופן ההופעה של ה-offload.

נבהיר רק את הנקודה השלישית: “האם הלכידה לפני השליחה או על ה-wire”. כשלוכדים במחשב שלכם עצמו, רואים את החבילה לפני שה-NIC מילא את ה-checksum. אם ה-offload מופעל, שדה ה-checksum עדיין ריק או בערך זמני, אז כלי הניתוח כמובן מציג “לא תקין”. יכול בהחלט לקרות שהחבילה שבאמת עברה על הכבל תקינה.

flowchart TB
    accTitle: המנגנון שגורם לשגיאת checksum בלכידה מקומית
    accDescr: תרשים המראה שלכידה במחשב עצמו רואה את החבילה לפני שה-NIC מילא checksum, ולכן הכלי מציג לא תקין כשה-offload מופעל, בעוד שבמראה פורט על ה-wire החבילה בפועל תקינה.
    lc1["לכידה במחשב עצמו"] --> pre1["רואים חבילה לפני מילוי checksum"]
    pre1 --> bad1["הכלי מציג לא תקין"]
    wire1["מבט על ה-wire דרך פורט מראה"] --> okw1["החבילה בפועל תקינה"]
    okw1 -.-> ver1["השוואה בין השניים מאשרת שזה אופן ההופעה של ה-offload"]

איור 24: מיקום הלכידה המקומית קודם ל-NIC, ולכן הצגת השגיאה כש-offload מופעל לרוב היא רק אופן הופעה.

הכלים שמשתמשים בהם לבדיקה, בדרך כלל שלושה:

לוג ה-pktmon ניתן להמיר ל-pcapng, כך שאפשר לפתוח אותו ישירות ב-Wireshark.

pktmon etl2pcap log.etl --out capture.pcapng

אם “מקומית רואים שגיאת checksum, בפורט מראה זה תקין”, זה מאושר כאופן ההופעה של ה-offload. רק אחרי הבדיקה הזו נוגעים בהגדרות.

11.6 רק ה-VM ב-Hyper-V איטי / CPU לא מאוזן

מה שצריך לבדוק לא מוגבל ל-RSS ברמת מחשב שולחני.

• VMQ /‏ VMMQ
• SR-IOV
• ‏vSwitch binding
• VLAN /‏ QoS
• חלוקת התפקידים בין RSS בצד המארח לתור בצד ה-VM

בוירטואליזציה, נוח יותר לסדר בציור מי מטפל בכל packet.

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 דוגמת שינוי

שם התצוגה בפועל שונה בכל NIC, ולכן קודם בודקים רשימה ורק אז משנים.

# דוגמה: שינוי 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 <IP הצד השני> -f -l 1472

# מקביל ל-MTU של 9000
ping <IP הצד השני> -f -l 8972

‏1472 ו-8972 הם ה-payload לאחר הפחתת כותרות IP /‏ ICMP. הם לא זהים למספר 9014 Bytes שמוצג בממשק הדרייבר.

12.6 הערות לעבודה מעשית

• חלק מההגדרות דורשות ביטול / הפעלה של המתאם או הפעלה מחדש
• ‏DisplayName עלול להיות מתורגם
• גם באותו יצרן, שם הפריט עלול להשתנות בין גרסאות דרייבר
• כשאוטומטים עם PowerShell, בטוח יותר קודם לרשום את הערכים במחשב עצמו ורק אז לכתוב

13. סיכום

הגדרות ה-NIC המתקדמות ב-Windows, כשמסתכלים רק על שמות הפריטים, כולן נראות “חזקות”. אבל בפועל, זה עולם שבו התשובה הנכונה משתנה לפי מה רוצים לתעדף — תפוקה, השהיה, CPU, חשמל או תאימות.

נסכם את עיקרי המאמר:

• Speed & Duplex בעיקרון Auto
• Jumbo רק כשתואם מקצה לקצה
• Checksum /‏ RSS /‏ LSO /‏ RSC — בעיקרון ברירת המחדל חזקה
• Interrupt Moderation הוא סחר בין תפוקה להשהיה
• Buffers רק כמו שנדרש
• EEE /‏ Selective Suspend /‏ Wake הן שאלות של חשמל / התאוששות
• VMQ /‏ SR-IOV הן שאלות של Hyper-V
• בפריטי offload ישנים — לא נוגעים

והדבר החשוב ביותר הוא שלושת אלה:

1. קובעים מה רוצים לשפר
2. משנים פריט אחד בכל פעם
3. משווים במספרים בין לפני לאחרי

הגדרות NIC אינן מתג קסם שמאיץ. עם זאת, כשהמטרה תואמת, זה משפיע מאוד. לעומת זאת, כשהמטרה לא תואמת, זה בקלות פועל הפוך.

flowchart TB
    accTitle: שלושת הדפוסים החשובים ביותר
    accDescr: תרשים המראה שאם קובעים מה רוצים לשפר, משנים פריט אחד בכל פעם, ומשווים במספרים בין לפני לאחרי, הגדרות NIC משפיעות מאוד כשהמטרה תואמת, אך פועלות הפוך אם היא לא תואמת.
    r1["קביעה מה רוצים לשפר"] --> r2["שינוי פריט אחד בכל פעם"]
    r2 --> r3["השוואה במספרים בין לפני לאחרי"]
    r3 --> eff1["כשהמטרה תואמת — משפיע מאוד"]
    r1 -.->|"כשהמטרה לא תואמת"| back1["פועל הפוך בקלות"]

איור 25: אם שומרים על שלושת הדפוסים — מטרה, פריט אחד ומספרים — זה משפיע, ובלעדיהם זה פועל הפוך.

14. מקורות

להלן מקורות רשמיים / חומרי יצרן ששימשו בסיס לכתיבת המאמר הזה. מכיוון שיש הרבה תנודתיות במונחים בין דרייברי Windows ל-NIC, בטוח ביותר לבדוק בסופו של דבר לפי שם וגרסת הדרייבר של ה-NIC שלכם.

• Microsoft Learn: NIC advanced properties
• Microsoft Learn: Network Adapter Performance Tuning in Windows Server
• Microsoft Learn: Hardware Only (HO) features and technologies
• Microsoft Learn: Overview of Single Root I/O Virtualization (SR-IOV)
• Microsoft Learn: Standardized INF Keywords for NDIS QoS
• Microsoft Learn: Standardized INF Keywords for Power Management
• Microsoft Learn: Setting RSS parameters
• Microsoft Learn: Overview of receive segment coalescing
• Microsoft Learn: How to optimize network adapter power management settings
• Microsoft Learn: Deprecated networking features in Windows Server
• Microsoft Learn: Packet Monitor (Pktmon)
• Microsoft Learn: pktmon etl2pcap
• Microsoft Learn: UDP Segmentation Offload (USO)
• Microsoft Learn: UDP Receive Segment Coalescing Offload (URO)
• Intel Support: Advanced Settings for Intel Ethernet Adapters
• Intel Support: בטוח יותר לבדוק קביעת מהירות, Jumbo,‏ Interrupt Moderation,‏ EEE,‏ WoL וכדומה מתוך מאמרי התמיכה לפי דגם ה-NIC

מאמרים קשורים

מאמרים עדכניים עם אותן תגיות, להעמקה בנושאים קרובים.

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

האם כדאי לבטל את Large Send Offload‏ (LSO)?

בדרך כלל כדאי להשאיר אותו מופעל. LSO הוא מנגנון שמפצל נתוני שליחה גדולים של TCP למסגרות קטנות בצד כרטיס הרשת, והוא משפיע על תפוקה וצמצום עומס CPU בתקשורת עתירת שליחה. ביטול רשלני נוטה לגרום לבזבוז CPU מיותר. שווה לשקול ביטול רק כשיש חשד לחוסר התאמה עם יישום או דרייבר מסוים, לצורך בידוד זמני והשוואה, או במצבים כמו מצלמות תעשייתיות ובקרת מכשירים שרוצים להעריך את התאמת השליחה. גם אם מבטלים לצורך בידוד, ברגע שמתברר שהסיבה אחרת, חוזרים לערך ברירת המחדל.

מה זה Receive Segment Coalescing‏ (RSC)? האם כדאי לבטל אותו?

RSC הוא הגדרה שבה כרטיס הרשת מאחד כמה קטעי TCP בצד הקבלה, ומכונה גם Large Receive Offload. הוא משפיע על תפוקת הקבלה ועל צמצום עומס CPU, ולכן במיקוד קבלה המדיניות הבסיסית היא להפעיל אותו. מצד שני, בהשהיה נמוכה או בתצפית ברמת packet הוא עלול להיות חיסרון, וגם פרשנות לכידת חבילות ותצפיות תזמון משתנה מעט. במצבים שרוצים לצמצם השהיה של request/response קטנים, או בסביבות שמעדיפות השהיה נמוכה ותצפית, זה מועמד להערכת ביטול. אפשר לבדוק את המצב הנוכחי עם Get-NetAdapterRsc.

כשאמור להיות 1Gbps אבל מתקבל קישור של 100Mbps, מה בודקים?

קביעה ידנית מיידית של Speed & Duplex היא המוצא האחרון. סדר הבדיקה הוא: קודם כבל, אחר כך dock / כרטיס רשת USB / מתאם המרה, פורט המתג, עדכון דרייבר, בידוד EEE / Green Ethernet, החזרת Speed & Duplex ל-Auto, ורק אם זה לא עוזר — קביעה קבועה שתואמת את הצד השני. ירידה ל-100Mbps או ניתוק קישור נובעים לרוב מהשכבה הפיזית או מהמכשיר השני, ולא מהגדרת ה-NIC. מצב שבו רק צד אחד קבוע וצד שני על Auto גורם ל-duplex mismatch, שגורם לירידת מהירות, שידור חוזר והשהיה חריגה.

בסופו של דבר, אילו הגדרות NIC מתקדמות ב-Windows כדאי להפעיל?

במחשב שולחני / נייד רגיל, העיקרון הבסיסי הוא לא לסטות מברירת המחדל. Speed & Duplex — Auto,‏ Checksum Offload /‏ LSO /‏ RSC /‏ RSS — בעיקרון מופעלים או בברירת מחדל, Jumbo Packet — רק כשהוא תואם מקצה לקצה בין ה-NIC, הצד השני והמתגים שבדרך. EEE ו-Selective Suspend הן הגדרות לחיסכון בחשמל, לא הגדרות להאצה. כשמשנים, קובעים קודם מה רוצים לשפר (תפוקה, השהיה, CPU, צריכת חשמל), משנים פריט אחד בכל פעם, ומשווים במספרים בין לפני לאחרי.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.