Difference between revisions of "Problem with e1000: Open issue with latency"
(Sometimes the modprobe fix won't work unless you reload the driver) |
m (line break, should have previewed!) |
||
| Line 4: | Line 4: | ||
<tt>modprobe -r e1000</tt> | <tt>modprobe -r e1000</tt> | ||
| + | |||
<tt>modprobe e1000 RxIntDelay=8</tt> | <tt>modprobe e1000 RxIntDelay=8</tt> | ||
Revision as of 17:39, 6 February 2007
This issue has been observed with the 2.6.17 linux kernel and the e1000 on the T60 and t60p. The bug is being tracked here
The recommended fix is to load the e1000 driver with an RxIntDelay of 8 or 32, to ensure success, you should also reload the driver by removing it before inserting it:
modprobe -r e1000
modprobe e1000 RxIntDelay=8
This fix is recommended by Intel developers, and has been shown to work at least anecdotally by the other of this page.
What is RxIntDelay?
From the Intel site:
This value delays the generation of receive interrupts in units of 1.024 microseconds. Receive interrupt reduction can improve CPU efficiency if properly tuned for specific network traffic. Increasing this value adds extra latency to frame reception and can end up decreasing the throughput of TCP traffic. If the system is reporting dropped receives, this value may be set too high, causing the driver to run out of available receive descriptors.
CAUTION: When setting RxIntDelay to a value other than 0, adapters may hang (stop transmitting) 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 RxIntDelay is set to zero.
