Windows NIC 고급 설정 가이드 - RSS/LSO/EEE/Wake on LAN

Windows NIC의 [Advanced] 탭에는 익숙하지 않은 단어가 꽤 많이 나열됩니다. Jumbo Packet, Large Send Offload, Interrupt Moderation, Receive Side Scaling, Flow Control, Energy Efficient Ethernet. 이름만 보면 전부 켜고 싶어지지만, 실제로는 무엇을 우선할지에 따라 정답이 달라집니다.

• 대용량 전송의 스루풋을 올리고 싶은지
• 작은 packet의 레이턴시를 줄이고 싶은지
• CPU 사용률을 낮추고 싶은지
• 절전 복귀나 Wake on LAN을 안정시키고 싶은지
• 드라이버나 스위치와의 호환 문제를 원인 분리하고 싶은지

여기가 애매한 채로 “일단 전부 On” “일단 Jumbo 9014” “느리니까 1Gbps Full로 고정”을 하면, 꽤 흔하게 사고가 납니다.

flowchart TB
    accTitle: 목적이 애매한 채로 만지면 사고가 난다
    accDescr: 무엇을 우선할지 애매한 채로 일단 전부 On으로 하거나 Jumbo를 켜거나 속도를 고정하면 사고가 나기 쉽고, 우선할 일을 정한 뒤에 만지면 정답이 달라진다는 것을 보여주는 그림.
    vague1["무엇을 우선할지 애매하다"] --> hasty1["일단 전부 On·Jumbo·고정"]
    hasty1 --> acc1["꽤 흔하게 사고가 난다"]
    clear1["우선할 일을 정한다"] -->|"그래서 정답이 달라진다"| pick3["만져야 할 설정이 좁혀진다"]

그림1: 목적을 정하지 않고 강해 보이는 설정을 만지면 사고가 나고, 목적을 정하면 만질 곳이 좁혀집니다.

이 글에서는 주로 Windows 10 / 11 / Windows Server의 유선 Ethernet 어댑터를 대상으로, NIC 고급 설정을 실무에서 만질 때의 사고방식을 정리합니다. 설정의 의미, 값을 올리거나 / 내리거나 / 켜거나 / 끄면 무엇이 일어나기 쉬운지, 어떤 장면에서 만져야 하는지를 한꺼번에 둘러볼 수 있게 씁니다.

덧붙여 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은 end-to-end로 맞출 때만 사용합니다. NIC만 9014로 해도, 중간 경로가 1500인 채면 함정입니다.
• Interrupt Moderation은 throughput과 latency의 줄다리기입니다. 높게 하면 CPU는 편해지지만, 레이턴시는 늘어납니다.
• Flow Control은 drops를 줄이는 쪽으로 효과가 있을 수 있지만, 혼잡을 넓히기도 합니다.
• EEE / Green Ethernet / Selective Suspend는 절전을 위한 설정이며, 빠르게 만드는 설정이 아닙니다.
• VMQ / SR-IOV는 Hyper-V 호스트용이며, 보통의 데스크톱 PC를 빠르게 하는 마법이 아닙니다.
• Wake on Pattern Match는 의도하지 않은 wake의 원인이 되기 쉬우므로, Wake on LAN만 필요하면 Magic Packet에 맞추는 편이 안전합니다.
• TCP Chimney Offload 등 오래된 항목은 지금은 만지지 않는 편이 좋습니다.

요컨대, NIC 고급 설정은 “강해 보이는 것을 전부 켜는 장소”가 아닙니다. 스루풋, 레이턴시, CPU, 소비 전력, 호환성 중 무엇을 가져갈지를 정하고, 하나씩 만지는 장소입니다.

flowchart TB
    accTitle: 고급 설정 탭의 위치
    accDescr: NIC 고급 설정은 강해 보이는 것을 전부 켜는 장소가 아니라, 스루풋·레이턴시·CPU·소비 전력·호환성 중 무엇을 취할지 정한 뒤 하나씩 만지는 장소임을 보여주는 그림.
    allon1["강해 보이는 것을 전부 켠다"] -.->|"그런 장소가 아니다"| tab1["NIC 고급 설정"]
    dec1["어느 축을 취할지 정한다"] --> one2["하나씩 만진다"]
    one2 --> tab1

그림3: 고급 설정 탭은, 가져갈 축을 정한 뒤에 하나씩 만지는 장소로 사용합니다.

이 글의 지식 맵

Windows의 NIC 상세 설정(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 mismatch를, EEE는 링크가 100Mbps로 다운시프트되는 현상을 일으킬 수 있으며, Checksum Offload가 활성화되어 있으면 로컬 캡처에서 checksum 오류로 보일 수 있는데, 이는 pktmon이나 미러 포트로 확인하면 가려낼 수 있습니다.

flowchart LR
    accTitle: Windows NIC 상세 설정의 지식 맵
    accDescr: NIC 상세 설정의 각 항목이 Advanced 탭에서 구성된다는 것, 스루풋 중시와 저 레이턴시 중시로 권장 설정이 갈린다는 것, Speed & Duplex나 EEE가 다운시프트나 duplex mismatch의 원인이 될 수 있다는 것, Checksum Offload가 로컬 캡처의 checksum 오류로 보이는 현상과 pktmon으로 확인하는 방법의 관계를 보여주는 그림
    nic_advanced_properties["NIC 고급 설정(Advanced 탭)"]
    speed_duplex["Speed & Duplex"]
    duplex_mismatch["듀플렉스 미스매치"]
    link_speed_downshift["링크 속도 다운시프트"]
    jumbo_frame["점보 패킷/점보 프레임"]
    checksum_offload["체크섬 오프로드"]
    local_capture_checksum_error["로컬 캡처의 체크섬 오류"]
    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["인터럽트 조절"]
    flow_control_8023x["흐름 제어(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["절전 모드 복귀 후 NIC 연결 불량"]
    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

NIC에 따라서는 RegistryKeyword가 표준화된 이름이라, *RSS, *VMQ, *SRIOV, *EEE처럼 보이기도 합니다. 다만 DisplayName과 DisplayValue는 드라이버 의존입니다. 변경 스크립트를 쓸 때는 실제 기기에서 먼저 목록을 보는 편이 안전합니다.

flowchart TB
    accTitle: PowerShell로 확인할 때의 순서
    accDescr: 변경 스크립트를 쓰기 전에, DisplayName과 DisplayValue가 드라이버 의존임을 전제로 실제 기기에서 먼저 목록을 본 뒤에 쓴다는 안전한 순서를 보여주는 그림.
    lst1["실제 기기에서 목록을 본다"] --> dep1["표시 이름은 드라이버 의존임을 확인"]
    dep1 --> scr1["그다음에 변경 스크립트를 쓴다"]
    scr1 -.-> bk1["변경 전 백업도 남긴다"]

그림4: 표시 이름이 드라이버 의존이므로, 실제 기기의 목록을 먼저 본 뒤에 스크립트를 씁니다.

3. 만지기 전의 대원칙

NIC 설정을 만지기 전에, 여기를 빠뜨리면 대개 수렁에 빠집니다.

3.1 먼저 “무엇을 개선할지”를 정한다

같은 “네트워크가 느리다”라도, 속은 전혀 다릅니다.

• 큰 파일 복사가 느리다 → throughput, RSS, RSC, LSO, Jumbo, 버퍼
• 작은 request/response가 더디다 → Interrupt Moderation, RSC, EEE, 큐 깊이
• CPU가 높다 → 오프로드, 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의 호환
• 오래된 firmware
• USB NIC의 전력 부족
• 포트 측 오류
• 패킷 손실이나 재전송

특히 100Mbps로 떨어진다, 링크가 플랩한다, 대용량 전송만 깨진다는 설정보다 먼저 물리와 상대를 보는 편이 빠릅니다.

flowchart TB
    accTitle: 물리 계층과 상대 기기를 먼저 본다
    accDescr: 100Mbps로 떨어지거나 링크가 플랩하거나 대용량 전송만 깨지는 증상에서는, NIC 설정보다 먼저 케이블이나 상대 기기 등 물리 계층을 의심하는 편이 빠름을 보여주는 그림.
    symp1["다운시프트·플랩 등의 증상"] --> phys1["먼저 케이블·상대 기기·물리 계층"]
    phys1 -->|"그래도 남는다"| nicw1["NIC 설정의 원인 분리로"]
    phys1 -.-> nofix1["설정으로는 고쳐지지 않는 문제도 흔하다"]

그림6: 링크 계열 증상은 설정보다 먼저 물리 계층과 상대 기기를 의심하는 편이 빠릅니다.

3.3 한 번에 1항목만 바꾼다

Jumbo, LSO, RSC, RSS, EEE를 한꺼번에 바꾸면, 무엇이 효과가 있었는지 알 수 없습니다. 변경 전 설정을 적어 두고, 한 항목씩 바꿔서 변화를 측정하는 것이 기본입니다.

3.4 측정할 것을 정한다

최소한, 이 정도는 보고 싶은 부분입니다.

• 링크 속도 (1G / 2.5G / 10G 등)
• 스루풋
• 레이턴시
• CPU 사용률
• NIC 통계 (drop / error / buffer shortage)
• 절전 복귀의 안정성

설정 변경은 체감만이 아니라 숫자로 보는 편이 강합니다.

flowchart TB
    accTitle: 한 항목씩 바꿔 숫자로 비교한다
    accDescr: 변경 전 설정을 적어 두고, 1항목만 바꿔, 정해 둔 지표를 측정해, 체감이 아니라 숫자로 비교한다는 설정 변경의 기본 흐름을 보여주는 그림.
    w1["변경 전 설정을 적어 둔다"] --> w2["1항목만 바꾼다"]
    w2 --> w3["정한 지표를 측정한다"]
    w3 --> w4["체감이 아니라 숫자로 비교한다"]

그림7: 변경은 한 항목씩 하고, 전후를 숫자로 비교하는 것이 기본 형입니다.

4. 주요 설정의 목록 표

먼저, 설정마다의 역할을 한 장으로 볼 수 있는 표를 둡니다.

5. 링크와 프레임 크기 주변 설정

5.1 Speed & 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 byte 전후의 큰 프레임을 쓸 수 있게 됩니다.

다만 여기는 이름 함정이 많습니다.

• 드라이버는 9014 Bytes처럼 프레임 크기를 표시하는 경우가 있다
• OS나 도구는 MTU 9000처럼 L3 시점으로 보는 경우가 있다
• 스위치는 CRC나 VLAN 태그 포함으로 세는 경우가 있다

숫자만 가로로 나란히 비교하면, 꽤 흔하게 빠집니다.

flowchart TB
    accTitle: Jumbo 숫자를 세는 방식의 차이
    accDescr: 같은 Jumbo 설정이라도 드라이버는 프레임 크기, OS나 도구는 L3 시점의 MTU, 스위치는 CRC나 VLAN 태그 포함으로 세는 경우가 있어, 숫자만 가로로 비교하면 빠짐을 보여주는 그림.
    drv1["드라이버: 프레임 크기 표시"] --> cmp2["같은 것을 다른 세기 방식으로 보고 있다"]
    osv1["OS·도구: MTU의 L3 시점"] --> cmp2
    sw1["스위치: 태그나 CRC 포함"] --> cmp2
    cmp2 --> trap1["숫자만 가로 비교하면 빠진다"]

그림9: 드라이버·OS·스위치에서 세기 방식이 다르므로, Jumbo 숫자는 가로로 나란히 비교하지 않습니다.

바꾸면 어떻게 달라지는가

크게 하거나 / 켠다

• 큰 데이터를 보낼 때 packet 수가 줄어든다
• header 처리 횟수가 줄어든다
• CPU 사용률이 내려가기 쉽다
• 한편 packet당 점유 시간은 길어진다
• 경로상의 어딘가가 미대응이면 drop이나 fragmentation의 원인이 된다

표준으로 되돌리거나 / 끈다

• 호환성은 가장 높다
• packet 수는 늘어난다
• 대용량 전송에서는 CPU / header overhead가 늘어나기 쉽다

실무상의 기본 방침

Jumbo는 end-to-end로 맞춰져야 비로소 의미가 있습니다.

• 자신의 NIC
• 상대의 NIC
• 중간 스위치
• VLAN이나 가상 스위치를 끼운다면 그 overhead

이 중 하나가 1500인 채면, 효과가 나오지 않을뿐더러 장애의 원인이 됩니다.

flowchart TB
    accTitle: Jumbo는 end-to-end로 맞춰져야 비로소 의미가 있다
    accDescr: Jumbo Frame은 자신의 NIC, 중간 스위치, 상대 NIC까지 end-to-end로 맞춰져야 비로소 의미가 있고, 하나가 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로서 클록을 주도할지에 관한 설정입니다. 보통의 PC에서는 우선 만지지 않습니다.

기본 방침

• Auto가 기본
• 특정 오래된 상대 기기와의 link quality 문제에서만 평가한다
• 벤더 지시가 없는 한, 성능 tuning의 손잡이로는 다루지 않는다

5.4 Wait for Link / Link 상태 계열 설정

Wait for Link 같은 설정은 드라이버가 auto negotiation 성공을 기다린 뒤에 link 상태를 보고할지에 관여합니다. Log Link State Event는 link up/down을 이벤트 로그에 남기는 진단용입니다.

기본 방침

• 보통 PC는 기본값 그대로 두면 된다
• 성능 그 자체보다, 기동 시 보이는 모습이나 failover 진단에서 의미가 있다
• 먼저 만질 항목은 아니다

6. CPU 부하, 스루풋, 레이턴시에 효과가 있는 설정

여기가 가장 “효과가 날 것 같아 보이는” 구간입니다. 실제로 효과가 나는 경우도 많지만, 효과가 나는 방향이 깔끔하게 갈립니다.

flowchart TB
    accTitle: 이 구간의 설정은 효과가 나는 방향이 갈린다
    accDescr: CPU 부하·스루풋·레이턴시에 효과가 있는 설정군은, 모아 처리해 스루풋과 CPU를 취하는 방향과, 잘게 처리해 레이턴시를 취하는 방향으로 깔끔하게 갈림을 보여주는 그림.
    band1["효과가 날 것 같아 보이는 설정의 구간"] --> dir1["모아 처리하는 방향"]
    band1 --> dir2["잘게 처리하는 방향"]
    dir1 -.-> g1["스루풋·CPU에 유리"]
    dir2 -.-> g2["레이턴시에 유리"]

그림11: 같은 구간의 설정이라도, 스루풋 쪽과 레이턴시 쪽에서 효과가 나는 방향이 갈립니다.

6.1 Checksum Offload

IP / TCP / UDP checksum 계산을 NIC로 넘기는 설정입니다.

기본 방침

• 원칙적으로 사용
• CPU를 낮추고 싶으면 남긴다
• capture상의 checksum error는 offload의 보이는 모습인 경우가 많다
• 호환 원인 분리로 잠시 끄는 것은 있다

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

큰 TCP 송신 데이터를 NIC 쪽에서 작은 frame으로 분할하는 설정입니다.

어디에 효과가 있는가

• send-heavy한 throughput
• CPU 사용률 절감
• 큰 연속 송신

기본 방침

• 보통은 사용
• 특정 앱이나 드라이버 호환이 의심되면 잠시 끄고 차이를 본다

6.3 Receive Segment Coalescing (RSC) / Large Receive Offload

수신 측에서 여러 TCP segment를 합치는 설정입니다.

어디에 효과가 있는가

• 수신 측 throughput
• CPU 사용률 절감

주의점

• 저레이턴시나 packet 단위 관측에서는 불리해질 수 있다
• capture나 타이밍 관측의 해석이 조금 달라진다

기본 방침

• 수신 throughput을 가져가려면 사용
• 작은 request/response의 latency를 보려면 평가 대상

flowchart TB
    accTitle: RSC의 효과와 평가의 갈림
    accDescr: RSC는 수신한 여러 TCP 세그먼트를 NIC 쪽에서 합쳐 수신 스루풋과 CPU 절감에 효과가 있는 한편, 저레이턴시나 패킷 단위 관측에서는 불리해질 수 있어 평가 대상이 됨을 보여주는 그림.
    seg1["수신한 여러 TCP 세그먼트"] --> coal1["NIC 쪽에서 합친다 (RSC)"]
    coal1 --> up1["수신 스루풋·CPU에 효과가 있다"]
    coal1 -.->|"저레이턴시·관측 우선에서는"| dn1["불리해질 수 있어 평가 대상"]

그림12: RSC는 수신을 모아 처리하는 설정이며, 가져갈 것이 레이턴시 쪽이면 평가 대상이 됩니다.

6.4 UDP 계열의 비교적 새로운 오프로드 (USO / URO)

최근 NIC나 OS에서는 UDP 송수신에서도 비교적 새로운 offload가 보이기도 합니다.

기본 방침

• 나와 있어도, 우선 기본값에서 벗어나지 않는다
• 드라이버가 충분히 새롭고, 대상 workload가 분명할 때만 측정한다
• 트러블슈트에서는 무리하게 만지지 않는다

6.5 Receive Side Scaling (RSS)

수신 처리를 여러 CPU에 분산하는 설정입니다. multi-core 환경에서는 꽤 중요합니다.

기본 방침

• multi-core에서는 사용이 기본
• 단일 CPU에 붙어 있는 증상에서는 먼저 확인한다
• Hyper-V나 high-throughput 앞단에서도 주역이 되기 쉽다

flowchart TB
    accTitle: RSS 유무로 달라지는 수신 처리
    accDescr: RSS가 꺼져 있으면 수신 처리가 단일 CPU에 집중해 막히기 쉽고, 켜면 여러 CPU로 분산되어 multi-core 환경에서 스루풋이 올라가기 쉬움을 보여주는 그림.
    rin1["수신 트래픽"] -->|"RSS 무효"| one3["단일 CPU에 집중해 막히기 쉽다"]
    rin1 -->|"RSS 유효"| sp2["여러 CPU에 분산"]
    sp2 --> sc1["multi-core에서 늘어나기 쉽다"]

그림13: RSS는 수신 처리를 여러 CPU로 분산하는 메커니즘이며, 단일 CPU에 붙어 있는 증상에서는 먼저 확인합니다.

6.6 RSS Queues / RSS Processors / RSS Profile

RSS의 병렬도를 정하는 항목입니다.

기본 방침

• 기본값에서 시작한다
• CPU 사용률이나 queue 편향이 보인 뒤에 늘린다
• 함부로 최대까지 늘리면 인터럽트나 DPC 부하가 늘어날 수 있다

6.7 Interrupt Moderation / Interrupt Moderation Rate

인터럽트 빈도를 억제해, CPU 부하와 latency를 교환하는 설정입니다.

경향

• 높게 / Adaptive → CPU는 편해지기 쉽지만 latency는 늘어나기 쉽다
• 낮게 / Off → latency는 내려가기 쉽지만 CPU / DPC 부하는 올라가기 쉽다

기본 방침

• 기본값 / Adaptive를 출발점으로
• 작은 packet의 jitter가 신경 쓰이면 Low / Off를 평가
• 대용량 전송이면 기본값이 더 무난한 경우가 많다

flowchart TB
    accTitle: Interrupt Moderation의 줄다리기
    accDescr: Interrupt Moderation을 높게나 Adaptive로 하면 CPU는 편해지지만 레이턴시는 늘어나기 쉽고, 낮게나 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

링 / 버퍼의 깊이를 바꾸는 설정입니다.

효과가 나는 방향

• burst 내성
• sustained throughput
• drop 회피

부작용

• 메모리 소비가 늘어난다
• queue가 깊어져 대기열 지연이 늘어날 수 있다

기본 방침

• drop이나 buffer shortage가 보일 때만 늘린다
• 대충 최대로 하는 것은 피한다

flowchart TB
    accTitle: 버퍼 깊이를 늘릴 때
    accDescr: 버퍼를 깊게 하면 burst 내성이나 drop 회피에 효과가 있는 한편, 메모리 소비가 늘고 대기열 지연이 늘어날 수 있으므로, drop이나 buffer shortage가 보일 때만 늘린다는 판단을 보여주는 그림.
    obs1["drop이나 buffer shortage가 보인다"] -->|"보일 때만"| inc1["버퍼를 늘린다"]
    inc1 -.-> side1["메모리 소비와 대기열 지연이 늘 수 있다"]
    non1["대충 최대로 한다"] -.->|"피한다"| inc1

그림15: 버퍼는 증상이 숫자로 보일 때만 늘리고, 대충 최대는 피합니다.

6.9 Flow Control

802.3x pause frame의 송수신에 관한 설정입니다.

기본 방침

• drop을 줄이고 싶으면 후보가 된다
• 다만 pause가 다른 혼잡을 넓히기도 한다
• 저레이턴시 계열에서는 신중히 본다
• 네트워크 전체 설계와 세트로 생각한다

flowchart TB
    accTitle: Flow Control의 양면
    accDescr: Flow Control의 pause frame은 drop을 줄이는 쪽으로 효과가 있을 수 있는 한편, pause가 다른 혼잡을 넓히기도 하므로, 네트워크 전체 설계와 세트로 생각할 필요가 있음을 보여주는 그림.
    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

802.1Q VLAN이나 802.1p Priority를 다루는 구간입니다.

기본 방침

• VLAN / QoS를 실제로 쓸 때만 의식한다
• 단순한 access port 환경이면 기본값 그대로 두면 된다
• 태그가 멋대로 붙는 구성은 원인 분리를 어렵게 하므로 주의한다

7.2 VMQ / VMMQ / SR-IOV

이것은 Hyper-V 호스트나 가상화 기반에서 의미가 생기는 설정입니다.

기본 방침

• 보통의 desktop tuning으로는 다루지 않는다
• Hyper-V 호스트라면 vSwitch 구성, queue 할당, 게스트 측 설정과 함께 평가한다
• 한쪽만 봐도 정답은 나오기 어렵다

flowchart TB
    accTitle: VMQ / SR-IOV의 평가 단위
    accDescr: VMQ나 SR-IOV는 Hyper-V 호스트나 가상화 기반에서 의미가 생기는 설정이며, vSwitch 구성, queue 할당, 게스트 측 설정과 함께 평가해야 하고, 한쪽만 봐도 정답이 나오기 어려움을 보여주는 그림.
    vm1["VMQ / VMMQ / SR-IOV"] --> hv1["Hyper-V 호스트에서 의미가 생긴다"]
    hv1 --> setb["vSwitch·queue·게스트 측과 함께 평가"]
    vm1 -.->|"다루지 않는다"| dt1["보통의 desktop tuning"]

그림17: 가상화 계열 설정은 호스트·vSwitch·게스트를 함께 봐야 비로소 평가할 수 있습니다.

7.3 RDMA / DCB / PFC는 다른 세계

이 부근은 SMB Direct나 lossless Ethernet을 포함하는, 꽤 다른 세계입니다.

기본 방침

• 일반적인 1GbE / 2.5GbE 데스크톱 조정과는 나눠서 생각한다
• 벤더 자료와 스위치 측 설계를 세트로 확인한다

8. 절전, 슬립, Wake on LAN 주변 설정

8.1 Energy Efficient Ethernet (EEE) / Green Ethernet

절전을 위해, 링크 idle 때의 소비 전력을 낮추는 설정입니다.

보는 법

• 빠르게 만드는 설정이 아니다
• 소비 전력에는 효과가 있다
• 상대 기기나 케이블 조건에 따라서는, 링크 불안정이나 100Mbps downshift의 원인 분리 후보가 된다

기본 방침

• 일반 용도에서는 기본값이어도 된다
• 링크 불안정, 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 시 링크 제어

쉽게 말하면, idle 때나 슬립 때 NIC를 어디까지 재울지의 설정입니다.

기본 방침

• 노트북에서는 기본값에서 시작한다
• 복귀 문제가 있으면 처음에 의심한다
• 장치 제어 PC나 24/7 운용에서는, 오히려 끄는 편이 알기 쉬운 경우가 있다

8.3 Wake on Magic Packet / Wake on Pattern Match

이것은 슬립 중인 PC를, 네트워크를 통해 깨우기 위한 설정입니다.

기본 방침

• Wake on LAN이 필요하면 Magic Packet을 켠다
• 불필요하면 끈다
• Pattern Match는 필요성이 분명할 때만

NIC만 On으로 해도 안 깨는 일은 흔합니다. BIOS / UEFI 측과 Power Management 탭 측도 맞춰서 봅니다.

flowchart TB
    accTitle: Wake on LAN이 효과가 나는 조건
    accDescr: Wake on LAN은 NIC의 Magic Packet 설정만이 아니라, BIOS나 UEFI 측과 Power Management 탭 측도 맞춰져야 비로소 깨우므로, 세 곳을 맞춰 확인할 필요가 있음을 보여주는 그림.
    m1["NIC의 Magic Packet 설정"] --> 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 탭이 있습니다. 여기도 은근히 중요합니다.

자주 보는 것은 다음 3가지입니다.

• 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

주로 서버용으로, packet header와 payload를 나눠 다뤄 CPU 처리를 돕는 종류의 설정입니다.

기본 방침

• 서버용 / 특정 workload용
• 일반 클라이언트에서는 기본값 그대로

9.4 Low Latency Interrupts

벤더에 따라서는 Low Latency Interrupts 같은 항목이 있습니다.

기본 방침

• 측정해서 이길 때만 쓴다
• 분위기로 On 하는 구간이 아니다

9.5 TCP Chimney Offload / IPsec Task Offload 등 오래된 항목

오래된 NIC나 드라이버에서는 이런 항목을 볼 수 있습니다.

기본 방침

• 지금은 만지지 않고, 쓰지 않는 것이 정답
• 호환성이나 오래된 자료에 끌려가지 않는다

flowchart TB
    accTitle: 9장 항목의 공통 자세
    accDescr: MAC 주소 덮어쓰기나 오래된 설정, 서버용 설정, 오래된 오프로드 항목은 평소에는 기본값 그대로 만지지 않고, 벤더 지시나 분명한 요건과 측정이 있을 때만 만진다는 공통 자세를 보여주는 그림.
    rare1["9장에서 든 항목들"] --> keep1["평소에는 기본값 그대로 만지지 않는다"]
    keep1 -->|"만지는 것은"| cond1["벤더 지시·분명한 요건이 있을 때"]
    cond1 -.-> meas1["측정해서 이길 때만 쓴다"]

그림21: 보여도 평소에는 만지지 않는 구간이며, 분명한 지시나 요건과 측정이 있을 때만 손을 댑니다.

10. 목적별 대략 지침

아래에서는 “무효화 평가”, “무효화 후보“라는 쓰임이 여러 번 나옵니다. 이것은 “꺼라”가 아니라, 평가 대상으로 하라는 뜻입니다. 내용은 3.3과 3.4의 대원칙 그대로이며, 구체적으로는 이 네 단계입니다.

1. 변경 전 설정을 저장한다 (12.1의 Export-Csv)
2. 1항목만 끈다 (3.3)
3. 3.4에서 정한 지표를 측정한다 (스루풋, 레이턴시, CPU, NIC 통계, 복귀 안정성)
4. 효과가 없으면 되돌린다

4가 빠지면, 의미 없는 변경이 쌓여 다음 원인 분리가 어려워집니다. 아래 각 항목은, 이 네 단계를 돌리는 후보 목록으로 읽으시기 바랍니다.

flowchart TB
    accTitle: 무효화 평가의 네 단계
    accDescr: 변경 전 설정을 저장하고, 1항목만 끄고, 정한 지표를 측정하고, 효과가 없으면 되돌린다는, 무효화 평가의 네 단계 루프를 보여주는 그림.
    h1["변경 전 설정을 저장"] --> h2["1항목만 끈다"]
    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 절감, queue 부족 회피가 효과가 나기 쉽습니다.

10.3 산업용 카메라 / 장치 제어 / 저레이턴시 중시

• Speed & Duplex: Auto가 기본. 필요하면 상대에 맞춰 고정
• Jumbo: 카메라 / NIC / 스위치가 맞으면 평가
• Checksum Offload: 먼저 사용
• LSO: 송신 호환이 의심되면 잠시 무효화 평가
• RSC: 저레이턴시나 관측 우선이면 무효화 후보
• Interrupt Moderation: Low / Off를 평가
• Buffers: 너무 늘리지 않는다
• Flow Control: pause의 부작용을 평가해야 한다
• EEE / Green Ethernet: 무효화 후보
• Selective Suspend / 전원 관리: 무효화 후보

throughput 최적화 설정이, 반드시 low latency에 유리하지는 않습니다.

10.4 Hyper-V 호스트

• VMQ / VMMQ / SR-IOV: 구성에 따라 평가
• RSS: 호스트 측 트래픽에는 중요
• RSC: vSwitch 구성에 따라 제약이 있다
• QoS / VLAN: vSwitch 설계와 맞춘다
• Flow Control / PFC: 스토리지 / RDMA 설계와 한 세트로 생각한다

이것은 desktop tuning이 아니라, 가상화 기반 설계입니다.

10.5 트러블슈트용 임시 설정

장애 원인 분리에서는, 일단 단순한 세계로 되돌리는 것이 강합니다.

• Speed & Duplex: Auto
• MTU: 1500
• Jumbo: 무효
• EEE: 무효
• LSO: 잠시 무효
• RSC: 잠시 무효
• Interrupt Moderation: 기본값 또는 낮게
• Wake / power save: 불필요하면 무효
• 변경 전 설정: 반드시 저장

원인 분리에서는 성능 최적화보다 동작의 단순화가 이깁니다.

11. 증상별 처음 단서

11.1 1Gbps / 2.5Gbps여야 하는데 100Mbps가 된다

먼저 보는 순서는, 대체로 이렇습니다.

1. 케이블
2. dock / USB NIC / 변환 어댑터
3. 스위치 측 포트
4. 드라이버 업데이트
5. EEE / Green Ethernet
6. Speed & Duplex를 Auto로 되돌린다
7. 그래도 안 되면, 상대와 맞춘 고정을 시도한다

갑자기 수동 고정은 마지막입니다.

flowchart TB
    accTitle: 100Mbps로 떨어질 때 보는 순서
    accDescr: 케이블, dock나 USB NIC, 스위치 측 포트, 드라이버 업데이트, EEE 원인 분리, Auto Negotiation으로 되돌리기, 그래도 안 되면 상대와 맞춘 고정 순으로 봄을 보여주는 그림.
    s1["케이블"] --> s2["dock / USB NIC / 변환"]
    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 (전용 경로라면)
• NIC 통계의 drop / error

이것은 throughput 계열 문제이므로, Jumbo나 queue, offload가 효과가 나기 쉽습니다.

11.3 작은 request/response의 지연이 크고, jitter가 신경 쓰인다

확인하고 싶은 것은 이 5가지입니다.

• Interrupt Moderation
• RSC
• EEE
• Flow Control
• Buffers를 너무 올리지 않았는지

이 구간에서는 모아 처리하는 계열의 최적화가, 반대로 체감 지연을 늘리기도 합니다.

11.4 슬립 복귀 후 NIC가 사라지거나 / 몇 초 동안 연결되지 않는다

보고 싶은 것은, 전원 주변을 중심으로 이 5가지입니다.

• Selective Suspend
• Device Sleep / Standby 관련 설정
• Power Management 탭의 Allow the computer to turn off this device...
• dock / USB NIC의 firmware
• Wake 설정의 조합

복귀 문제는 NIC 그 자체보다 전원 관리인 경우가 많습니다.

11.5 packet capture에서 checksum error가 대량으로 보인다

서둘러 “회선이 고장 났다”고 말하기 전에, 여기를 확인합니다.

• Checksum Offload가 켜져 있는지
• LSO가 켜져 있는지
• capture가 송신 전인지, wire 위인지
• 다른 호스트나 미러 포트로 봤을 때도 같은지

로컬 capture의 checksum error는 offload의 보이는 모습인 경우가 정말 많습니다.

3번째 “capture가 송신 전인지, wire 위인지”만 보충합니다. 자기 PC에서 캡처하면, NIC가 checksum을 채우기 전의 패킷이 보입니다. offload가 켜져 있으면 checksum 란은 아직 비어 있거나 임시 값이므로, 분석 도구는 당연히 “오류”로 표시합니다. 실제로 케이블 위를 흐른 패킷은 올바른 경우가 흔합니다.

flowchart TB
    accTitle: 로컬 캡처에서 checksum 오류로 보이는 구조
    accDescr: 자기 PC에서의 캡처는 NIC가 checksum을 채우기 전의 패킷을 보므로, offload가 켜져 있으면 분석 도구가 오류로 표시하지만, 실제로 케이블 위를 흐른 패킷은 올바른 경우가 있다는 구조를 보여주는 그림.
    lc1["자기 PC에서 캡처"] --> pre1["checksum을 채우기 전의 패킷을 본다"]
    pre1 --> bad1["도구가 오류로 표시"]
    wire1["미러 포트로 wire 위를 본다"] --> okw1["실제 패킷은 올바르다"]
    okw1 -.-> ver1["양쪽을 비교하면 offload의 보이는 모습으로 확정"]

그림24: 로컬 캡처 위치는 NIC보다 앞이므로, offload 사용 시의 오류 표시는 보이는 모습의 문제인 경우가 많습니다.

확인에 쓰는 도구는, 대체로 다음 3가지입니다.

pktmon 로그는 pcapng로 변환할 수 있으므로, Wireshark에서 그대로 열 수 있습니다.

pktmon etl2pcap log.etl --out capture.pcapng

“로컬에서 보면 checksum error, 미러 포트에서 보면 정상”이면, 그것은 offload의 보이는 모습으로 확정입니다. 여기까지 확인한 뒤에 설정을 만집니다.

11.6 Hyper-V의 VM만 느리거나 / CPU가 편향된다

봐야 할 것은 desktop적인 RSS만이 아닙니다.

• VMQ / VMMQ
• SR-IOV
• vSwitch binding
• VLAN / QoS
• 호스트 측 RSS와 VM 측 queue의 분담

가상화에서는 누가 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는 IP / ICMP header를 뺀 payload입니다. 드라이버 UI의 9014 Bytes와 이 ping 숫자는 일치하지 않습니다.

12.6 실무 메모

• 일부 설정은 어댑터의 사용 안 함 / 사용이나 재시작이 필요합니다
• DisplayName이 로컬라이즈되어 있는 경우가 있습니다
• 같은 벤더라도 driver version으로 항목 이름이 바뀌는 경우가 있습니다
• PowerShell로 자동화한다면 실제 기기의 값을 먼저 나열한 뒤에 쓰는 편이 안전합니다

13. 정리

Windows NIC 고급 설정은, 항목 이름만 보면 전부 “강해 보입니다”. 하지만 실제로는 throughput, latency, CPU, power, compatibility 중 무엇을 취할지에 따라 정답이 달라지는 세계입니다.

이 글의 요점을 정리하면, 이렇습니다.

• Speed & Duplex는 기본적으로 Auto
• Jumbo는 end-to-end로 맞출 때만
• Checksum / RSS / LSO / RSC는 원칙적으로 기본값이 강하다
• Interrupt Moderation은 throughput과 latency의 트레이드오프
• Buffers는 필요한 만큼만
• EEE / Selective Suspend / Wake 계열은 power / resume 이야기
• VMQ / SR-IOV는 Hyper-V 이야기
• 오래된 offload 항목은 만지지 않는다

그리고, 가장 중요한 것은 다음 3가지입니다.

1. 무엇을 개선할지 정한다
2. 한 번에 1항목만 바꾼다
3. 변경 전후를 숫자로 비교한다

NIC 설정은 마법처럼 빨라지는 스위치가 아닙니다. 다만 목적이 맞으면 꽤 효과가 납니다. 반대로, 목적이 어긋나면 꽤 정직하게 역효과를 냅니다.

flowchart TB
    accTitle: 가장 중요한 3가지 형
    accDescr: 무엇을 개선할지 정하고, 한 번에 1항목만 바꾸고, 변경 전후를 숫자로 비교하는 3가지 형을 지키면, 목적이 맞는 한 NIC 설정은 꽤 효과가 있음을 보여주는 그림.
    r1["무엇을 개선할지 정한다"] --> r2["한 번에 1항목만 바꾼다"]
    r2 --> r3["변경 전후를 숫자로 비교한다"]
    r3 --> eff1["목적이 맞으면 꽤 효과가 난다"]
    r1 -.->|"목적이 어긋나면"| back1["정직하게 역효과를 낸다"]

그림25: 목적·1항목·숫자의 3가지 형을 지키면 효과가 나고, 벗어나면 역효과를 냅니다.

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 송신 데이터를 NIC 쪽에서 작은 프레임으로 분할하는 메커니즘으로, 송신이 많은 통신의 스루풋과 CPU 사용률 절감에 효과가 있습니다. 대충 끄면 CPU를 쓸데없이 쓰기 쉽습니다. 끄기를 검토하는 경우는 특정 앱이나 드라이버 호환이 의심될 때 잠시 끄고 차이를 보는 원인 분리 목적이거나, 산업용 카메라나 장치 제어처럼 송신 호환을 평가하고 싶을 때입니다. 원인 분리로 끈 경우에도, 원인이 따로 있다고 확인되면 기본값으로 되돌리는 것이 기본입니다.

Receive Segment Coalescing (RSC)이란 무엇인가요? 끄는 편이 좋나요?

RSC는 수신 측에서 여러 TCP 세그먼트를 NIC 쪽에서 합치는 설정이며, Large Receive Offload라고도 합니다. 수신 스루풋과 CPU 사용률 절감에 효과가 있으므로, 수신을 중시한다면 켜 두는 것이 기본 방침입니다. 반면 저레이턴시나 packet 단위 관측에서는 불리해질 수 있고, 패킷 캡처나 타이밍 관측의 해석도 조금 달라집니다. 작은 request/response의 레이턴시를 줄이고 싶은 장면이나, 저레이턴시·관측을 우선하는 환경에서는 무효화를 평가할 후보가 됩니다. Get-NetAdapterRsc로 현재 상태를 확인할 수 있습니다.

1Gbps여야 하는데 100Mbps로 링크될 때는 무엇을 확인하면 되나요?

갑자기 Speed & Duplex를 수동 고정하는 것은 최후의 수단입니다. 보는 순서는 먼저 케이블, 다음으로 dock / USB NIC / 변환 어댑터, 스위치 측 포트, 드라이버 업데이트, EEE / Green Ethernet 원인 분리, Speed & Duplex를 Auto로 되돌리기, 그래도 안 되면 상대와 맞춘 고정, 순서입니다. 100Mbps로 다운시프트하거나 링크가 끊기는 문제는 NIC 설정보다 물리 계층이나 상대 기기가 원인인 경우가 많습니다. 한쪽만 고정·한쪽만 Auto인 상태는 duplex mismatch를 일으켜 속도 저하나 재전송, 비정상적인 지연의 원인이 됩니다.

Windows NIC 고급 설정은 결국 무엇을 켜면 되나요?

보통의 데스크톱 / 노트북이라면, 우선 기본값에서 벗어나지 않는 것이 기본입니다. Speed & Duplex는 Auto, Checksum Offload / LSO / RSC / RSS는 원칙적으로 사용 또는 기본값, Jumbo Packet은 NIC·상대·중간 스위치까지 end-to-end로 맞출 수 있을 때만 사용합니다. EEE나 Selective Suspend는 절전을 위한 설정이지, 빠르게 만드는 설정이 아닙니다. 바꿀 때는 무엇을 개선할지(스루풋, 레이턴시, CPU, 소비 전력)를 먼저 정하고, 한 번에 1항목만 바꿔서 변경 전후를 숫자로 비교하는 것이 철칙입니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.