Chinaunix首页 | 论坛 | 博客
  • 博客访问: 15515386
  • 博文数量: 112
  • 博客积分: 11195
  • 博客等级: 上将
  • 技术积分: 1989
  • 用 户 组: 普通用户
  • 注册时间: 2005-06-20 11:04
文章分类

全部博文(112)

文章存档

2013年(2)

2012年(27)

2011年(6)

2010年(11)

2009年(6)

2007年(7)

2006年(23)

2005年(30)

分类: LINUX

2006-06-15 22:31:22

Intel的千兆网卡驱动(e1000.ko)加载的时候可以加上几个参数,如下:
insmod e1000.ko =
下面列出paramerter中和性能相关的几个以及他们的取值范围和默认值。
 
InterruptThrottleRate
范围:100-100000 (0=off, 1=dynamic)
默认:0
注:不支持82542, 82543, 82545, 82544芯片
 
RxDescriptors
范围:80-256 for 82542 and 82543-based adapters 
     80-4096 for all other supported adapters
默认:256
 
RxIntDelay
范围:0-65535 (0=off)
默认:0
 
RxAbsIntDelay
范围:0-65535 (0=off)
默认:128
 
TxDescriptors
范围:80-256 for 82542 and 82543-based adapters
     80-4096 for all other supported adapters
默认:256
 
TxIntDelay
范围:0-65535 (0=off)
默认:64
 
TxAbsIntDelay
范围:0-65535 (0=off)
默认:64
 
 
其中各种*IntDelay的单位是:1.024 microseconds
 
我们可以根据网卡的性能和cpu,内存,pci总线等不同来调整它们的值,另外可以编译网卡驱动的时候修改编译选项:NAPI和NO_NAPI。
make CFLAGS_EXTRA=-DCONFIG_E1000_NAPI
我找到一个关于如何修改这些参数取值得例子不过是英文的,怕翻译的不好,还是放上来原文吧。
 

A Sample Configuration

Some example settings are described below. These numbers are for illustration purposes only. For

optimal performance, the exact controller configuration is best determined through actual

experimentation.

The discussion below assumes that software is optimizing for full-size frames of 1538 bytes.

The calculations below make use of the following facts:

Gigabit Ethernet operates at 1.0 Gb/s or 1,000,000,000 bits per second. At this speed, the time required to transmit or receive a single bit (in other words, the bit-time) is 1.0 nanosecond.

A full-size Ethernet frame requires 1538 bytes (12,304 bits) of bandwidth:

—8-byte preamble and start-of-frame delimiter

—14-byte Ethernet header

—1500-byte payload

—4-byte FCS

—12-byte inter-packet gap

The controller can transmit or receive a full-size frame every 12.3 microseconds or approximately 81,000 packets per second.

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 microseconds.

Alternately, to receive approximately 50 packets per interrupt, the controller must interruptapproximately 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 microseconds.

Packet Timers

Experiments have shown that values between 20 and 40 microseconds work well for the packettimers.

Software might set the packet timers to expire after 2 full-length packet-times, or approximately 25

microseconds. The packet timers would then expire when throughput falls below about 333Mbps

(two unused packet-times follow every packet arrival, so approximately one-third of the total

bandwidth is in use). At greater levels of utilization, the packet timers would likely chain

repeatedly until the one of the absolute timers expired.

Interrupt Throttle Timer

Configuring the throttle timer is simply a question of determining the desired maximum interrupt

rate. As described earlier, software may realize better results by setting the throttle timer to

interrupt slightly more often than desired to reduce unnecessary latencies.

For typical applications, software might configure the controller to interrupt no more than 5000

times per second.

Different operating systems and environments will be capable of sustaining different maximum

interrupt rates. Experiments have demonstrated that Microsoft Windows-based operating systems

perform best when the device interrupts between 4,000 and 12,000 times per second. Linux-based

operating systems appear to perform best with an interrupt rate between 1,000 and 8,000 interrupts

per second. Other operating systems will perform differently.

Additional Tuning Considerations

The example configuration described above will require modifications to suit the intended

environment. The following factors may influence the tuning of the interrupt moderationparameters:

The latency associated with scheduling an interrupt handler. Larger scheduling latencies

 imply larger packet latencies. Lower interrupt delays may be required in these situations

to avoid overrun conditions and excessive per-packet delays.

The cost associated with handling an interrupt. In OS with low-cost interrupts, higher interrupt rates may be acceptable. In OS with high-cost interrupts, lower interrupt rates may be required.

The expected mixture of packet sizes. The preceding discussion assumes that software is optimizing for full-size frames. Optimizing for small packets or for a variety of packet sizes requires recalculating the expected packet rate.

The expected network utilization. High utilization implies high traffic rates, which makes the controller more susceptible to overrun conditions if it delays interrupts too long.

 

 
 
 
 
 
 
 

 

阅读(44216) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~