Windows에서의 NIC 상세 설정을 한꺼번에 정리 - Jumbo Packet, RSS, LSO, RSC, Flow Control, EEE, Wake on LAN까지
· 小村 豪 · 네트워크, NIC, Ethernet, 성능 튜닝, Windows 개발
Windows의 NIC의 [고급] 탭은 익숙하지 않은 용어가 꽤 많이 나열됩니다.
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로 고정」을 하면 꽤 평범하게 사고납니다.
이 글에서는 주로 Windows 10 / 11 / Windows Server의 유선 Ethernet 어댑터를 대상으로, NIC의 상세 설정을 실무에서 만질 때의 사고방식을 정리합니다. 설정의 의미, 값을 올리거나 내리거나 유효화 / 무효화하면 무엇이 일어나기 쉬운지, 어떤 장면에서 만져야 할지를 한꺼번에 둘러볼 수 있도록 씁니다.
덧붙여 NIC의 표시 이름이나 고를 수 있는 값은 벤더와 드라이버로 꽤 바뀝니다.
Jumbo Packet이 Jumbo Frames였거나, Receive Buffers가 Receive Descriptors였거나, Priority & VLAN이 Packet Priority & VLAN이었거나 합니다. 이 글에서는 의미가 가까운 것은 한꺼번에 다룹니다.
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, 소비 전력, 호환성 중 어느 것을 취하러 갈지를 정하고 1개씩 만지는 장소입니다.
2. 어디서 설정을 볼까
2.1 GUI로 본다
네트워크 접속에서 들어간다
ncpa.cpl을 실행- 대상 어댑터를 오른쪽 클릭
- 속성 → 구성
- 상세 설정 (Advanced) 탭
장치 관리자에서 들어간다
- 장치 관리자
- 네트워크 어댑터
- 대상 NIC를 오른쪽 클릭 → 속성
- 상세 설정 탭
여기에 나열되는 항목이 이 글의 주역입니다. 다만, 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는 드라이버 의존입니다. 변경 스크립트를 쓸 때는 실기에서 먼저 일람을 보는 편이 안전합니다.
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, 드라이버
목적이 다른데 같은 설정을 만지면 개선은커녕 악화됩니다.
3.2 먼저 물리층과 상대 기기를 의심한다
NIC 설정으로는 고쳐지지 않는 문제도 평범하게 있습니다.
- 케이블 불량
- 스위치 / 라우터 / dock의 상성
- 오래된 firmware
- USB NIC의 전력 부족
- 포트 측의 에러
- 패킷 로스나 재송신
특히 100Mbps로 떨어진다, 링크가 플랩한다, 대용량 전송만 망가진다는 설정보다 먼저 물리와 상대를 보는 편이 빠릅니다.
3.3 1회에 1항목만 바꾼다
Jumbo, LSO, RSC, RSS, EEE를 한꺼번에 바꾸면 무엇이 효과적이었는지 알 수 없게 됩니다. 변경 전의 설정을 써내고 1 항목씩 바꿔 변화를 재는 것이 기본입니다.
3.4 측정할 것을 정한다
최저한 다음은 보고 싶은 곳입니다.
- 링크 속도(1G / 2.5G / 10G 등)
- 스루풋
- 레이턴시
- CPU 사용률
- NIC의 통계(drop / error / buffer shortage)
- 슬립 복귀의 안정성
설정 변경은 체감뿐만 아니라 숫자로 보는 편이 강합니다.
4. 주요 설정의 일람표
먼저 설정별의 역할을 한 장으로 볼 수 있는 표를 둡니다.
| 설정 | 무엇을 하는 설정인가 | 올리거나 / 유효로 하면 일어나기 쉬운 일 | 내리거나 / 무효로 하면 일어나기 쉬운 일 | 기본 방침 |
|---|---|---|---|---|
| Speed & Duplex | 링크 속도와 duplex의 교섭 / 고정 | 오래된 상대와 맞추면 연결될 수 있지만, 불일치면 duplex mismatch나 속도 저하 | Auto로 돌리면 modern한 기기에서는 안정되기 쉽다 | 기본은 Auto |
| Jumbo Packet / Jumbo Frames | MTU보다 큰 프레임을 사용한다 | 큰 전송에서 CPU와 header overhead가 줄어들기 쉽다 | 호환성은 높지만 packet 수는 늘어난다 | 전용 경로에서 end-to-end로 맞출 때만 |
| Checksum Offload | IP / TCP / UDP의 checksum을 NIC에서 처리 | CPU가 내려가기 쉽다 | OS 측 계산이 늘어 CPU가 올라가기 쉽다 | 원칙 유효 |
| LSO / TSO | 큰 TCP 송신 데이터를 NIC가 분할 | send-heavy한 throughput와 CPU에 효과적이기 쉽다 | CPU 부하는 늘어나지만 상성 구분에는 사용하기 쉽다 | 통상은 유효 |
| RSC / LRO | 수신 TCP 세그먼트를 NIC 측에서 결합 | 수신 throughput와 CPU에 효과적이기 쉽다 | 입자가 세세해져, 저 레이턴시에서는 유리할 수 있다 | 수신 중시라면 유효 |
| RSS | 수신 처리를 복수 CPU에 분산 | multi-core에서 throughput / scalability가 올라가기 쉽다 | 단일 CPU 집중으로 막히기 쉽다 | multi-core에서는 유효가 기본 |
| Interrupt Moderation | 인터럽트 빈도를 억제 | CPU가 편해지지만 latency는 늘어나기 쉽다 | latency는 내려가지만 CPU / DPC 부하가 올라가기 쉽다 | 기본 / Adaptive를 기점 |
| Receive / Transmit Buffers | 링 / 버퍼의 깊이 | burst 내성이나 sustained throughput에 효과적이기 쉽다 | 메모리 소비는 줄지만 drop에 약해진다 | 부족 시에만 늘린다 |
| Flow Control | 802.3x pause frame의 송수신 | drop을 줄일 수 있는 경우가 있다 | tail latency에는 유리할 수 있다 | 네트워크 전체 설계와 맞춘다 |
| Priority & VLAN | 802.1p / 802.1Q 태그 부여 | VLAN / QoS를 사용할 수 있다 | 단순한 L2로서 동작한다 | 필요할 때만 |
| VMQ / SR-IOV | Hyper-V / 가상화용의 NIC 지원 | VM throughput / CPU에 효과적 | 통상 호스트로서는 단순해진다 | Hyper-V 호스트용 |
| EEE / Green Ethernet | 절전을 위한 Low-Power Idle | 소비 전력은 내려가지만 상성 문제가 나올 수 있다 | 전력은 늘어나지만 안정되기 쉬운 경우가 있다 | 속도 설정이 아니다 |
| Selective Suspend | NIC를 idle 시에 저전력화 | 전력은 내려간다 | 복귀 안정성은 올라갈 수 있다 | 문제 시에는 구분 후보 |
| Wake on Magic Packet / Pattern Match | 슬립 중의 wake 조건 | 원격 기동할 수 있다 | 의도하지 않은 wake를 방지하기 쉽다 | 필요할 때만 유효 |
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로 고정」은 겉보기는 강해 보이지만 핵심을 빗나가는 경우가 많습니다.
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 태그 포함으로 셀 수 있다
숫자만 나란히 비교하면 꽤 평범하게 빠집니다.
변경하면 어떻게 바뀌는가
크게 한다 / 유효화한다
- 큰 데이터를 보낼 때 packet 수가 줄어든다
- header 처리 횟수가 줄어든다
- CPU 사용률이 내려가기 쉽다
- 한편으로 1 packet당의 점유 시간은 길어진다
- 경로상의 어딘가가 미대응이면 drop이나 fragmentation의 원인이 된다
표준으로 돌린다 / 무효화한다
- 호환성은 가장 높다
- packet 수는 늘어난다
- 대용량 전송에서는 CPU / header overhead가 늘어나기 쉽다
실무상의 기본 방침
Jumbo는 end-to-end로 맞춰져 처음으로 의미가 있습니다.
- 자신의 NIC
- 상대의 NIC
- 도중의 스위치
- VLAN이나 가상 스위치를 끼우면 그 overhead
이 중 어느 것이 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 부하, 스루풋, 레이턴시에 효과적인 설정
여기가 가장 「효과 있을 것 같다」고 보이는 대역입니다. 실제로 효과적인 경우도 많지만, 효과 있는 방향이 깔끔하게 나뉩니다.
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를 보고 싶다면 평가 대상
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의 앞에서도 주역이 되기 쉽다
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를 평가
- 대용량 전송이라면 기본값 쪽이 자연스러운 경우가 많다
6.8 Receive Buffers / Receive Descriptors와 Transmit Buffers / Transmit Descriptors
링 / 버퍼의 깊이를 바꾸는 설정입니다.
효과 있는 방향
- burst 내성
- sustained throughput
- drop 회피
부작용
- 메모리 소비가 늘어난다
- queue가 깊어져 대기 행렬 지연이 늘어날 수 있다
기본 방침
- drop이나 buffer shortage가 보일 때만 늘린다
- 어쩐지 최대로 하는 것은 피한다
6.9 Flow Control
802.3x pause frame의 송수신에 관한 설정입니다.
기본 방침
- drop을 줄이고 싶다면 후보가 된다
- 다만 pause가 별도의 폭주를 넓힐 수 있다
- 저 레이턴시계에서는 신중히 본다
- 네트워크 전체 설계와 세트로 생각한다
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 할당, 게스트 측 설정과 일체로 평가한다
- 한쪽만 봐도 정답은 나오기 어렵다
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화, 저 레이턴시 중시에서는 먼저 구분 후보
8.2 Selective Suspend / Device Sleep / Standby 시 링크 제어
요컨대, idle 시나 슬립 시에 NIC를 어디까지 재울지의 설정입니다.
기본 방침
- 노트 PC에서는 기본값부터 시작
- 복귀 트러블이 있다면 최초로 의심한다
- 장치 제어 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 탭 측도 맞춰서 봅니다.
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계는 전부 무효로 좋다
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나 드라이버에서는 이러한 항목을 볼 수 있습니다.
기본 방침
- 지금은 만지지 않는다, 사용하지 않는다가 정답
- 호환성이나 오래된 자료에 끌려가지 않는다
10. 목적별의 대략적인 지침
10.1 보통의 데스크톱 / 노트 PC
- 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가 된다
먼저 보는 순서는 대체로 다음입니다.
- 케이블
- dock / USB NIC / 변환 어댑터
- 스위치 측 포트
- 드라이버 업데이트
- EEE / Green Ethernet
- Speed & Duplex를 Auto로 돌린다
- 그래도 안 되면 상대와 맞춘 고정을 시도한다
갑자기 수동 고정은 최후입니다.
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가 신경쓰인다
보고 싶은 것은 다음입니다.
- Interrupt Moderation
- RSC
- EEE
- Flow Control
- Buffers를 너무 담고 있지 않은가
이 대역에서는 한꺼번에 처리하는 계의 최적화가 오히려 체감 지연을 늘릴 수 있습니다.
11.4 슬립 복귀 후에 NIC가 사라진다 / 수 초 연결되지 않는다
보고 싶은 것은 다음입니다.
- 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의 보이는 방식인 경우가 정말로 많습니다.
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회에 1항목만 바꾼다
- 변경 전후를 숫자로 비교한다
NIC 설정은 마법의 빨라지는 스위치가 아닙니다. 다만, 목적이 맞으면 꽤 효과적입니다. 반대로 목적이 어긋나면 꽤 자연스럽게 역효과를 부릅니다.
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
- Intel Support: Advanced Settings for Intel Ethernet Adapters
- Intel Support: 속도 고정, Jumbo, Interrupt Moderation, EEE, WoL 등은 NIC 형번별의 서포트 기사에서 확인하는 것이 안전합니다
관련 기사
같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.
TCP 재전송으로 산업용 카메라 통신이 수 초 멈출 때 - RFC1323 타임스탬프와 재전송 대기의 구분
산업용 카메라 통신이 가끔 수 초 멈추는 원인을 패킷 캡처로 추적해, RTO 재전송 대기와 RFC1323 타임스탬프 옵션의 효과를 정리합니다. Wireshark 확인 포인트와 구분 사용 표도 함께 제시합니다.
COM 컴포넌트나 OCX / ActiveX 개발에서 빠지기 쉬운 것 - Visual Studio의 32bit / 64bit, 등록, 관리자 권한의 덫을 정리
COM 컴포넌트와 ActiveX, OCX 개발에서 자주 만나는 0x80040154나 0x80070005를 비트 수, 등록 방식, HKCU와 HKLM 스코프, 관리자 권한이라는 네 축으로 풀어 Visual Studio 2022의 64bit화 시대에...
ClickOnce란 무엇인가 - 구조, 업데이트, 어울리는 장면・어울리지 않는 장면을 실무 시점에서 정리
ClickOnce가 무엇이고 매니페스트, 캐시, 업데이트, 서명이 어떻게 맞물려 동작하는지를 Mermaid 그림과 함께 정리하고, 사내용 .NET 데스크톱 앱 배포에서 어울리는 안건과 어울리지 않는 안건을 실무 시점에서 판단할 수 있도록 도와드립니다.
Windows 샌드박스로 Windows 앱 개발의 검증을 빠르게 하는 방법 - 관리자 권한 문제, 클린 환경, 권한 부족・리소스 부족의 재현을 실무용으로 정리
Windows Sandbox로 Windows 앱의 클린 환경 검증을 빠르게 하는 실무 노하우를 정리합니다. .wsb 파일을 용도별로 나누고, 입력은 읽기 전용・출력만 쓰기 가능으로 분리하며, 표준 사용자나 메모리 부족, GPU 없는 상태의 재현까...
자동 업데이트 기능의 보안 기본 - 나쁜 패턴과 베스트 프랙티스
자동 업데이트를 신뢰 경계로 다루는 사고방식을 정리합니다. HTTPS만으로 부족한 이유, signed metadata와 클라이언트 측 검증, 키 분리, fail-closed와 rollback, MSIX·ClickOnce 등 Windows의 기존 ...
관련 토픽
이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.
Windows 기술 토픽
Windows 개발, 장애 조사, 기존 자산 활용에 관한 KomuraSoft LLC 기사를 모은 토픽 허브입니다.
장애 조사 & 장기 가동 장애
간헐적 장애, 통신 진단, 장기 가동 크래시, 실패 경로 테스트 기반을 정리한 토픽 페이지입니다.
이 주제와 연결되는 서비스
이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.
Windows 앱 개발
상주 처리, 장비 연동, 운영 로그, 유지 보수 가능한 구조가 필요한 Windows 데스크톱 애플리케이션을 지원합니다.
저자 프로필
기사 저자의 프로필 페이지입니다.
Go Komura
합동회사 코무라소프트 대표
Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.
공개 링크