linux: e1000 device parameters

참고 사이트 : Intel(R) PRO-1000 어댑터 제품군용 Red Hat Linux 드라이버 Intel(R) 네트워크 어댑터 사용 설명서 (다른 URL이 있겠지만, 이것만 찾아냈다;)

하나씩 살펴보자.

첫번째

XsumRX

값 '1'을 지정하면 드라이버가 수신 패킷(UDP와 TCP 모두 포함)의 IP 체크섬을 어댑터 하드웨어에 오프로드합니다.

.. 이게 뭐야 라는 생각이 들게 만든다. 근데 사실 영문으로 보면 이렇게 적혀 있단다.

XsumRX
"A value of '1' indicates that the driver should enable IP checksum offload for received packets (both UDP and TCP) to the adapter hardware."

아 네; 그러니까 수신 패킷들에 대한 Checksum Offload를 설정하는 것인데, 자 이 Checksum Offload란 무엇인가 하니,

참고 사이트 : 네이버 :: 지식iN (지식인도 알고 있다!)

Checksum Offload 라는건 하드웨어 검사 합계라는 항목입니다. 네트워크의 과도한 입출력시 인터넷을 차단하는 방화벽 개념입니다. 최신 랜카드에는 TASK_OFFLOAD 라는 기능이 있습니다.
checksum offload, Large Send 등이 대표적 입니다..

네. 필요 없는거군요. 기본으로 1로 되어 있다고 하니 0으로 바꿔주면 되겠다.

두번째

RxIntDelay	이 값은 1.024마이크로초 단위로 수신 인터럽트 생성을 지연시킵니다. 특정 네트워크 트래픽에 맞게 제대로 조정된 경우에는 수신 인터럽트를 줄여서 CPU 효율성을 높일 수 있습니다. 이 값을 높이면 프레임 수신 대기 시간이 늘어나므로 TCP 트래픽 처리량을 줄일 수 있습니다. 수신이 끊겼다는 메시지가 나타나면 이 값이 너무 높아서 드라이버가 사용 가능한 수신 설명자 범위를 벗어난 것일 수 있습니다.
RxAbsIntDelay	이 값은 1.024마이크로초 단위로 수신 인터럽트 생성의 지연을 제한합니다. 이 값은 RxIntDelay 값이 0이 아닌 경우에만 유용하며 설정된 시간 내에 초기 패킷이 수신된 후 인터럽트가 생성되도록 합니다. 특정 네트워크 조건에서는 RxIntDelay와 함께 적절히 조정하여 트래픽 처리량을 높일 수 있습니다
TxIntDelay	이 값은 1.024마이크로초 단위로 전송 인터럽트 생성을 지연시킵니다. 특정 네트워크 트래픽에 맞게 제대로 조정된 경우에는 전송 인터럽트를 줄여서 CPU 효율성을 높일 수 있습니다. 전송이 끊겼다는 메시지가 나타나면 이 값이 너무 높아서 드라이버가 사용 가능한 전송 설명자 범위를 벗어난 것일 수 있습니다.
TxAbsIntDelay	이 값은 1.024마이크로초 단위로 전송 인터럽트 생성의 지연을 제한합니다. 이 값은 TxIntDelay 값이 0이 아닌 경우에만 유용하며 설정된 시간 내에 초기 패킷이 전송된 후 인터럽트가 생성되도록 합니다. 특정 네트워크 조건에서는 TxIntDelay와 함께 적절히 조정하여 트래픽 처리량을 높일 수 있습니다.

그러니까 전송 지연에 관련된 내용인데, 문서상으로는 RxIntDelay의 기본값은 0, TxIntDelay의 기본값은 64로 되어 있다. (커널 2.6.9의 e1000 소스를 참조하면, 기본값은 RxIntDelay쪽이 128, TxIntDelay쪽이 0으로 되어 있다; 어쨌든 문서가 오래된 것이니 소스를 우선적으로 참조.)

이것이 맞는지는 모르겠지만 인텔쪽 문서에 이런 것이 있고,

참고 사이트 : Interrupt Moderation Using Intel® Gigabit Ethernet Controllers Application Note (AP-450)

invalid-file

이런 내용이 나온다.

Page 14

4.1 Absolute Timers

Configuring the absolute timers is typically a matter of determining the desired interrupt rate or the desired number of packets per interrupt. To receive approximately 3000 interrupts per second, software would configure the absolute timers to interrupt every 333 μs.
Alternately, to receive approximately 50 packets per interrupt, the GbE controller must interrupt approximately 1620 times per second (81,000 packets-per-second at 50 packets-per-interrupt). Software would then configure the absolute timers to interrupt every 617 μs.

4.2 Packet Timers

Testing has shown that values between 20 and 40 μs work well for the packet timers.

Software might set the packet timers to expire after two full-length packet-times, or approximately 25 μs. The packet timers would then expire when throughput falls below about 333 Mb/s (two unused packet-times follow every packet arrival; approximately one-third of the total bandwidth is in use). At greater levels of use, the packet timers would likely chain repeatedly until the one of the absolute timers expired.

음 대략 세팅할 적정값들을 제시해 놓은 것 같은데, 인터럽트당 들어오는 패킷의 갯수나 기타 튜닝에 대한 값들을 적용해서 계산할 수 있을지 모르겠다.

커널 문서에도 설명은 찾을 수 있다.

참고 사이트 : Linux-2.6.17-Documentation-networking-e1000.txt

하지만 위의 박스 안의 내용과 다를 것이 없어 보인다.

RxIntDelay에 대해서는 조금 더 재미있는 문서를 찾을 수 있는데,

참고 사이트 : Re: Early SPECWeb99 results on 2.5.33 with TSO on e1000

Since with NAPI we can safely use RxIntDelay=0 (e1000 terminologi). With the classical IRQ we simply had to add latency (RxIntDelay of 64-128 us common for GIGE) this just to survive at higher speeds  (GIGE max is 1.48 Mpps) and with the interrupt latency

그러니까 NAPI를 설정했을때는 안전하게 RxIntDelay를 0으로 줄 수 있다는 의미인것 같다. 어쨌든 찾을 수 있는 많은 튜닝 문서에서는 Rx나 Tx나 IntDelay를 0으로 세팅하는 것이 일반적이다.
경험에 의해 선택해야 한다면 일단 보류.

세번째

InterruptThrottleRate

이 값은 컨트롤러가 생성하는 초당 최대 인터럽트 수를 나타냅니다. InterruptThrottleRate는 인터럽트 조정에 사용되는 또 다른 설정입니다. 동적 모드에서는 추론 알고리즘을 사용하여 현재 트래픽 로드에 따라 InterruptThrottleRate를 조정합니다. 참고: InterruptThrottleRate는 TxAbsIntDelay 및 RxAbsIntDelay 매개변수보다 우선합니다. 즉, TxAbsIntDelay 및 RxAbsIntDelay 값을 최소화해도 컨트롤러는 InterruptThrottleRate가 허용하는 것보다 많은 인터럽트를 생성하지 않습니다.

음 일단 R/Tx*Delay보다 우선한다는 것은 알겠고, 인터럽트 갯수를 늘려준다는 것도 알겠음.

이것으로 검색하다보면 이런 글을 찾을 수 있는데,

참고 사이트 : Intel Gigabit e1000 driver tuning - 2CPU.com Discussion Forums

이 댓글이 인상적이다.

참고 사이트 : 2CPU.com Discussion Forums - View Single Post - Intel Gigabit e1000 driver tuning

세팅의 변화에 따라서 ping 지연시간의 변화를 나타낸 것인데 정말 흥미롭지 않은가.
테스트를 해보았다.
대상은 2대의 서버이고, 양쪽 다 세팅을 건드리지 않았을 경우.

32 packets transmitted, 32 received, 0% packet loss, time 31000ms
rtt min/avg/max/mdev = 0.058/0.156/0.244/0.052 ms, pipe 2

지연시간이 좀 많이 나온다.
한쪽에 InterruptThrottleRate=0를 적용했을 경우.

31 packets transmitted, 31 received, 0% packet loss, time 30009ms
rtt min/avg/max/mdev = 0.038/0.098/0.160/0.038 ms, pipe 2

지연 시간이 눈에 띄게 줄었다!
양쪽 다 InterruptThrottleRate=0를 적용하는 경우는?

32 packets transmitted, 32 received, 0% packet loss, time 30997ms
rtt min/avg/max/mdev = 0.028/0.032/0.050/0.008 ms, pipe 2

음 뭔가 튜닝이 되는 것 처럼 보인다.
인텔 사이트의 아래 문서에는 좀 더 자세한 설명이 들어 있는데,

참고 사이트 : Network Connectivity - Linux Base Driver Overview and Installation

The driver can limit the amount of interrupts per second that the adapter will generate for incoming packets. It does this by writing a value to the adapter that is based on the maximum amount of interrupts that the adapter will generate per second.

Setting InterruptThrottleRate to a value greater or equal to 100
will program the adapter to send out a maximum of that many interrupts per second, even if more packets have come in. This reduces interrupt load on the system and can lower CPU utilization under heavy load, but will increase latency as packets are not processed as quickly.

The default behaviour of the driver previously assumed a static InterruptThrottleRate value of 8000, providing a good fallback value for all traffic types, but lacking in small packet performance and latency. The hardware can handle many more small packets per second however, and for this reason an adaptive interrupt moderation algorithm was implemented.

Since 7.3.x, the driver has two adaptive modes (setting 1 or 3) in which it dynamically adjusts the InterruptThrottleRate value based on the traffic that it receives. After determining the type of incoming traffic in the last timeframe, it will adjust the InterruptThrottleRate to an appropriate value for that traffic.

The algorithm classifies the incoming traffic every interval into
classes. Once the class is determined, the InterruptThrottleRate value is adjusted to suit that traffic type the best. There are three classes defined: "Bulk traffic", for large amounts of packets of normal size; "Low latency", for small amounts of traffic and/or a significant percentage of small packets; and "Lowest latency", for almost completely small packets or minimal traffic.

In dynamic conservative mode, the InterruptThrottleRate value is set to 4000 for traffic that falls in class "Bulk traffic". If traffic falls in the "Low latency" or "Lowest latency" class, the InterruptThrottleRate is increased stepwise to 20000. This default mode is suitable for most applications.

For situations where low latency is vital such as cluster or grid computing, the algorithm can reduce latency even more when
InterruptThrottleRate is set to mode 1. In this mode, which operates
the same as mode 3, the InterruptThrottleRate will be increased stepwise to 70000 for traffic in class "Lowest latency".

Setting InterruptThrottleRate to 0 turns off any interrupt moderation
and may improve small packet latency, but is generally not suitable
for bulk throughput traffic
NOTE: InterruptThrottleRate takes precedence over the TxAbsIntDelay and RxAbsIntDelay parameters. In other words, minimizing the receive and/or transmit absolute delays does not force the controller to generate more interrupts than what the Interrupt Throttle Rate allows.

CAUTION: If you are using the Intel(R) PRO/1000 CT Network Connection (controller 82547), setting InterruptThrottleRate to a value greater than 75,000, may hang (stop transmitting) adapters
under certain network conditions. If this occurs a NETDEV
WATCHDOG message is logged in the system event log. In
addition, the controller is automatically reset, restoring the network connection. To eliminate the potential for the hang, ensure that InterruptThrottleRate is set no greater than 75,000 and is not set to 0.

NOTE: When e1000 is loaded with default settings and multiple adapters are in use simultaneously, the CPU utilization may increase non-linearly. In order to limit the CPU utilization without impacting
the overall throughput, we recommend that you load the driver as
follows:

modprobe e1000 InterruptThrottleRate=3000,3000,3000

This sets the InterruptThrottleRate to 3000 interrupts/sec for the first, second, and third instances of the driver. The range of 2000 to 3000 interrupts per second works on a majority of systems and is a good starting point, but the optimal value will be platform-specific. If CPU utilization is not a concern, use RX_POLLING (NAPI) and default driver settings.

음. 나중에 꼭 한번 읽어볼께. (지켜주지 못해서 미안. ▶◀)
/var/log/message에서 메시지 상으로 확인해 본 결과, 어쨌든 e1000 자체는 NAPI로 컴파일 된 것이 확실하고.

Sep 28 11:56:48 localhost kernel: Intel(R) PRO/1000 Network Driver - version 7.0.33-k2-NAPI
Sep 28 11:56:48 localhost kernel: Copyright (c) 1999-2005 Intel Corporation.

참고 사이트 : [Beowulf] Home beowulf - NIC latencies (lantency 설정에 대한 설명인것 같다. 읽어보진 않았고, 차후 참고용.)
참고 사이트 : RE: e1000 autotuning doesn't get along with itself

음. 왠지 느낌이 있는 결과다. 즉시 netperf를 깔고 테스트 시작.
일단 양쪽 다 기본 세팅에서 시작했다.

./netperf -t TCP_RR -H 192.168.100.120 -D
TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.100.120 (192.168.100.120) port 0 AF_INET : demo
Interim result: 8001.71 Trans/s over 1.00 seconds
Interim result: 5531.83 Trans/s over 1.45 seconds
Interim result: 4417.55 Trans/s over 1.25 seconds
Interim result: 7962.63 Trans/s over 1.00 seconds
Interim result: 8000.62 Trans/s over 1.00 seconds
Interim result: 8003.62 Trans/s over 1.00 seconds
Interim result: 8003.62 Trans/s over 1.00 seconds
Interim result: 6056.24 Trans/s over 1.32 seconds
Local /Remote
Socket Size   Request  Resp.   Elapsed  Trans.
Send   Recv   Size     Size    Time     Rate
bytes  Bytes  bytes    bytes   secs.    per sec

65536  131072000 1        1       10.00    6543.20
131072000 131072000

어우야.. 좀 너무하잖니;
한쪽만 InterruptThrottleRate=0을 적용했다.

./netperf -t TCP_RR -H 192.168.100.120 -D
TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.100.120 (192.168.100.120) port 0 AF_INET : demo
Interim result: 8003.61 Trans/s over 1.00 seconds
Interim result: 8004.48 Trans/s over 1.00 seconds
Interim result: 8002.47 Trans/s over 1.00 seconds
Interim result: 8003.49 Trans/s over 1.00 seconds
Interim result: 8004.47 Trans/s over 1.00 seconds
Interim result: 8003.46 Trans/s over 1.00 seconds
Interim result: 8003.49 Trans/s over 1.00 seconds
Interim result: 8004.48 Trans/s over 1.00 seconds
Interim result: 8004.47 Trans/s over 1.00 seconds
Local /Remote
Socket Size   Request  Resp.   Elapsed  Trans.
Send   Recv   Size     Size    Time     Rate
bytes  Bytes  bytes    bytes   secs.    per sec

65536  131072000 1        1       10.00    8003.76
131072000 131072000

그래도 숫자들이 조금 균일해졌다.
양쪽 다 InterruptThrottleRate=0을 적용했다.

./netperf -t TCP_RR -H 192.168.100.120 -D
TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.100.120 (192.168.100.120) port 0 AF_INET : demo
Interim result: 23953.83 Trans/s over 1.00 seconds
Interim result: 23969.45 Trans/s over 1.00 seconds
Interim result: 23978.54 Trans/s over 1.00 seconds
Interim result: 23968.29 Trans/s over 1.00 seconds
Interim result: 23986.86 Trans/s over 1.00 seconds
Interim result: 23973.79 Trans/s over 1.00 seconds
Interim result: 23976.45 Trans/s over 1.00 seconds
Interim result: 23960.19 Trans/s over 1.00 seconds
Interim result: 23990.04 Trans/s over 1.00 seconds
Local /Remote
Socket Size   Request  Resp.   Elapsed  Trans.
Send   Recv   Size     Size    Time     Rate
bytes  Bytes  bytes    bytes   secs.    per sec

65536  131072000 1        1       10.00    23975.03
131072000 131072000

우워워워.. 이거 너무 좋은데.

그 밖에 양쪽 다 InterruptThrottleRate=1, 50000, 100000을 적용해 봤지만, 각각 초당 Transaction 2025.08, 16254.01, 19495.30 을 기록했다. 결국 0이 제일 튜닝이 된 값인듯.

2007/10/04 - [프로그래밍/System (Linux/FreeBSD)] - epoll을 사용한 서버 프로그램, e1000 튜닝 (InterruptThrottleRate=0) 적용후.
2007/10/29 - [프로그래밍/System (Linux/FreeBSD)] - 서버 프로그램, e1000 튜닝 (RxDescriptors=4096) 적용후.