הגדרות Advanced של NIC ב-Windows: RSS, LSO, EEE ו-Wake on LAN

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

• להעלות throughput בהעברות גדולות
• לקצר latency של packet-ים קטנים
• להוריד עומס CPU
• לייצב resume מ-sleep ו-Wake on LAN
• לבודד בעיית תאימות מול driver או switch

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

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

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

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

חשוב: שם התצוגה והערכים האפשריים משתנים מאוד בין vendor ל-driver. לפעמים 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 כברירת מחדל. בבעיית downshift ל-100Mbps, קיבוע מיידי ל-1.0 Gbps Full Duplex הוא הצעד האחרון.
• Checksum Offload / RSS / LSO / RSC —‏ Enable או default. כיבוי גורף בלי סיבה נוטה לבזבז CPU.
• Jumbo Packet רק כשהוא תואם end-to-end. אם רק ה-NIC על 9014 והנתיב באמצע נשאר 1500, זה מלכודת.
• Interrupt Moderation הוא trade-off בין throughput ל-latency. העלאה מקלה על ה-CPU ומעלה latency.
• Flow Control לפעמים מקטין drops, ולפעמים מרחיב congestion.
• EEE / Green Ethernet / Selective Suspend הן הגדרות חיסכון בחשמל, לא הגדרות האצה.
• VMQ / SR-IOV מיועדים ל-Hyper-V host. זה לא קסם שמאיץ desktop רגיל.
• Wake on Pattern Match נוטה לגרום ל-wake לא רצוי. אם צריך רק Wake on LAN, בטוח יותר להישאר על Magic Packet.
• פריטים ישנים כמו TCP Chimney Offload — היום עדיף לא לגעת.

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

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

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

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 26, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

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

2.1 ב-GUI

מחיבורי הרשת

1. מריצים ncpa.cpl
2. לחיצה ימנית על המתאם הרצוי
3. Properties ← Configure
4. כרטיסייה Advanced

ממנהל ההתקנים

1. Device Manager
2. Network adapters
3. לחיצה ימנית על ה-NIC ← Properties
4. כרטיסייה Advanced

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

2.2 ב-PowerShell

ב-PowerShell נוח יותר לראות רשימה של הערכים הנוכחיים, ולגבות אותם לפני שינוי.

Get-NetAdapter

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

בחלק מה-NIC-ים, RegistryKeyword הוא שם מתוקנן שנראה כמו *RSS, *VMQ, *SRIOV, *EEE. עם זאת, DisplayName ו-DisplayValue תלויים ב-driver. כשכותבים סקריפט שינוי, בטוח יותר קודם לרשום רשימה על המחשב עצמו.

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

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

3. כללים לפני שנוגעים בהגדרות

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

3.1 קודם מחליטים “מה רוצים לשפר”

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

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

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

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

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

3.2 קודם חושדים בשכבה הפיזית ובציוד ממול

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

• כבל פגום
• אי-התאמה מול switch / router / dock
• firmware ישן
• מחסור בחשמל ב-USB NIC
• שגיאות בצד הפורט
• packet loss ו-retransmit

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

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

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

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

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

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

לכל הפחות כדאי לראות:

• מהירות ה-link (1G / 2.5G / 10G וכו’)
• throughput
• latency
• אחוז CPU
• סטטיסטיקת NIC (drop / error / buffer shortage)
• יציבות resume מ-sleep

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

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

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

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

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

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

5.1 Speed & Duplex

זו הגדרה שקשורה למשא ומתן על מהירות ה-link ועל full/half 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

קיבוע ידני

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

קו בסיס בשטח

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

flowchart TB
    accTitle: duplex mismatch שנגרם מקיבוע בצד אחד
    accDescr: קיבוע בצד אחד ו-Auto בצד השני גורם ל-duplex mismatch, ואז ירידת מהירות, retransmit ו-latency חריג. Auto בשני הצדדים יציב יותר בין מכשירים מודרניים.
    mix1["קיבוע בצד אחד, Auto בצד שני"] --> mm1["duplex mismatch"]
    mm1 --> sl2["ירידת מהירות, retransmit, latency חריג"]
    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 bytes.

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

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

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

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

איור 9: ה-driver, ה-OS וה-switch סופרים אחרת, ולכן אין להשוות בין מספרי Jumbo שטחית.

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

הגדלה / Enable

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

חזרה לתקן / Disable

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

קו בסיס בשטח

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

• ה-NIC שלכם
• ה-NIC של הצד השני
• ה-switch בדרך
• אם יש VLAN או virtual switch — גם ה-overhead שלו

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

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

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

5.3 Gigabit Master / Slave Mode

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

קו בסיס

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

5.4 Wait for Link / הגדרות מצב link

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

קו בסיס

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

6. הגדרות שמשפיעות על CPU, throughput ו-latency

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

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

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

6.1 Checksum Offload

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

קו בסיס

• Enable כברירת מחדל
• אם רוצים להוריד CPU — משאירים
• שגיאת checksum ב-capture לרוב היא רק איך שה-offload נראה
• Disable זמני לצורך isolation של תאימות — לגיטימי

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

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

על מה זה משפיע

• throughput בתעבורה עם הרבה send
• הורדת עומס CPU
• send רציף גדול יחסית

קו בסיס

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

6.3 Receive Segment Coalescing (RSC) / Large Receive Offload

הגדרה שמאחדת בצד ה-receive כמה TCP segments.

על מה זה משפיע

• throughput בצד ה-receive
• הורדת עומס CPU

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

• לפעמים חיסרון ב-low latency או בתצפית ברמת packet
• פרשנות capture או תצפית timing משתנה מעט

קו בסיס

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

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

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

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

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

קו בסיס

• גם אם מופיע, לא לסטות מה-default בהתחלה
• מודדים רק כשה-driver חדש מספיק וברור מהו ה-workload
• ב-troubleshooting, לא נוגעים בכוח

6.5 Receive Side Scaling (RSS)

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

קו בסיס

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

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

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

6.6 RSS Queues / RSS Processors / RSS Profile

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

קו בסיס

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

6.7 Interrupt Moderation / Interrupt Moderation Rate

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

מגמה

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

קו בסיס

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

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

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

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

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

כיוון ההשפעה

• עמידות ל-burst
• throughput מתמשך
• הימנעות מ-drop

תופעות לוואי

• צריכת הזיכרון גדלה
• ה-queue מעמיק וייתכן ש-queueing delay יגדל

קו בסיס

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

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

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

6.9 Flow Control

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

קו בסיס

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

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

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

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

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

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

קו בסיס

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

7.2 VMQ / VMMQ / SR-IOV

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

קו בסיס

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

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

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

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

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

קו בסיס

• מפרידים מ-tuning של desktop רגיל ב-1GbE / 2.5GbE
• בודקים יחד את חומרי ה-vendor ואת תכנון ה-switch

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

8.1 Energy Efficient Ethernet (EEE) / Green Ethernet

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

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

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

קו בסיס

• בשימוש כללי, אפשר להשאיר default
• באי-יציבות link, downshift ל-100Mbps, או עדיפות ל-low latency — קודם כל מועמד ל-isolation

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

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

8.2 Selective Suspend / Device Sleep / בקרת link בזמן Standby

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

קו בסיס

• ב-laptop, מתחילים מ-default
• אם יש תקלת resume, חושדים בה ראשונה
• במחשב לבקרת מכשירים או בהפעלה 24/7, לפעמים דווקא Disable ברור יותר

8.3 Wake on Magic Packet / Wake on Pattern Match

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

קו בסיס

• אם צריך Wake on LAN —‏ Enable ל-Magic Packet
• אם לא צריך — Disable
• Pattern Match רק כשהצורך ברור

יש מקרים רגילים שבהם Enable רק ב-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 נוטה לגרום ל-wake שגוי"]

איור 19: WoL עובד רק כששלושת המקומות — NIC, BIOS/UEFI וכרטיסיית Power Management — מתואמים יחד.

8.4 ARP Offload / NS Offload

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

קו בסיס

• בדרך כלל Enable / default
• לרוב נוגעים בזה זמנית לצורך isolation של תאימות סביב sleep

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

קו בסיס

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

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

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

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

9.1 Network Address / Locally Administered Address

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

קו בסיס

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

9.2 Adaptive Inter-Frame Spacing

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

קו בסיס

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

9.3 Header Data Split

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

קו בסיס

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

9.4 Low Latency Interrupts

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

קו בסיס

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

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

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

קו בסיס

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

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

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

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

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

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

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

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

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

10.1 desktop / laptop רגיל

• Speed & Duplex: Auto
• MTU / Jumbo: 1500 / Disable
• Checksum Offload: Enable
• LSO: Enable
• RSC: Enable
• RSS: Enable
• Interrupt Moderation: default / Adaptive
• Buffers: default
• Flow Control: default
• EEE / Green Ethernet: default
• Selective Suspend: default
• Wake on LAN: רק כשצריך

כלומר, לא לסטות מה-default בהתחלה הוא קו הבסיס.

10.2 NAS / גיבוי / העתקה בכמות גדולה

• Speed & Duplex: Auto
• Jumbo: מעריכים אם אפשר להתאים נתיב ייעודי
• Checksum Offload: Enable
• LSO: Enable
• RSC: Enable
• RSS: Enable
• RSS queues: מגדילים מעט אם צריך
• Receive / Transmit Buffers: מגדילים מעט אם יש drop
• Interrupt Moderation: default / גבוה מעט
• EEE: evaluate Disable אם יציבות בעדיפות

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

10.3 מצלמות תעשייתיות / בקרת מכשירים / עדיפות ל-low latency

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

הגדרות שמייעלות throughput לא בהכרח יתרון ל-low latency.

10.4 Hyper-V host

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

זה לא tuning של desktop, אלא תכנון תשתית וירטואליזציה.

10.5 הגדרה זמנית לצורך troubleshooting

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• האם Checksum Offload Enable
• האם LSO Enable
• האם ה-capture לפני השליחה או על ה-wire
• האם זה זהה גם כשרואים ממארח אחר או מ-mirror port

שגיאת checksum ב-capture מקומי, לרוב במידה רבה היא רק איך שה-offload נראה.

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

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

איור 24: מיקום ה-capture המקומי קודם ל-NIC, ולכן הצגת השגיאה כש-offload Enable לרוב היא רק איך שזה נראה.

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

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

pktmon etl2pcap log.etl --out capture.pcapng

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

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

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

• VMQ / VMMQ
• SR-IOV
• vSwitch binding
• VLAN / QoS
• חלוקת התפקידים בין RSS בצד ה-host לתור בצד ה-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"

# דוגמה: הגדרת מספר תורי ה-receive של 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 שמוצג בממשק ה-driver.

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

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

13. סיכום

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

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

• Speed & Duplex —‏ Auto כברירת מחדל
• Jumbo רק כשתואם end-to-end
• Checksum / RSS / LSO / RSC —‏ default חזק כברירת מחדל
• Interrupt Moderation הוא trade-off בין throughput ל-latency
• Buffers רק כמו שנדרש
• EEE / Selective Suspend / Wake הן שאלות של power / resume
• 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. מקורות

להלן מקורות רשמיים / חומרי vendor ששימשו בסיס לכתיבת המאמר הזה. מכיוון שיש הרבה תנודתיות במונחים בין driver-ים של Windows ל-NIC, בטוח ביותר לבדוק בסופו של דבר לפי שם וגרסת ה-driver של ה-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)?

בדרך כלל משאירים אותו Enable. LSO מפצל נתוני TCP גדולים בצד ה-NIC למסגרות קטנות, וזה משפיע על throughput ועל הורדת CPU בתעבורה עם הרבה send. כיבוי בלי סיבה נוטה לבזבז CPU. שווה לבדוק Disable רק כשיש חשד לבעיית תאימות מול אפליקציה או driver מסוימים, לצורך isolation זמני והשוואה, או בסביבות כמו מצלמות תעשייתיות ובקרת מכשירים שבהן רוצים לבדוק את התאמת ה-send. גם אם כיביתם לצורך isolation, ברגע שמתברר שהסיבה אחרת מחזירים ל-default.

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

RSC מאחד כמה TCP segments בצד ה-receive, ב-NIC עצמו. קוראים לזה גם Large Receive Offload. הוא משפיע על throughput בקבלה ועל הורדת CPU, ולכן כש-receive הוא העיקר — Enable הוא קו בסיס. לעומת זאת, ב-low latency או כשרוצים לראות packet-ים בודדים הוא עלול להפריע, וגם פרשנות של packet capture ושל מדידות timing משתנה קצת. בסביבות שרוצים בהן לקצר latency של request/response קטנים, או שמעדיפות low latency ותצפית — זה מועמד ל-evaluate Disable. את המצב הנוכחי אפשר לראות עם Get-NetAdapterRsc.

אמור להיות 1Gbps, אבל ה-link עולה ב-100Mbps. מה בודקים?

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

בסוף, אילו הגדרות Advanced של NIC ב-Windows כדאי להשאיר Enable?

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

פרופיל הכותב

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

Go Komura

מנהל KomuraSoft LLC

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