Problem with e1000: Open issue with latency - Revision history

Hs12 at 14:14, 16 July 2007

2007-07-16T14:14:56Z

Hs12 at 14:14, 16 July 2007

2007-07-16T14:14:03Z

Beagle: The bios update works better

2007-04-12T00:40:41Z

The bios update works better

Noahf: links to bios update 2.11, which fixes latency problem

2007-03-30T22:37:23Z

links to bios update 2.11, which fixes latency problem

Beagle: Recommending value of 32 over 8

2007-03-20T13:52:40Z

Recommending value of 32 over 8

Beagle: line break, should have previewed!

2007-02-06T16:39:16Z

line break, should have previewed!

Beagle: Sometimes the modprobe fix won't work unless you reload the driver

2007-02-06T16:38:39Z

Sometimes the modprobe fix won't work unless you reload the driver

Beagle: created page for explanation of latency issue

2007-02-06T02:27:36Z

created page for explanation of latency issue

New page

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 [http://bugme.osdl.org/show_bug.cgi?id=6929 here]

The recommended fix is to load the e1000 driver with an RxIntDelay of 8 or 32:

<tt>modprobe e1000 RxIntDelay=8</tt>

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 [http://www.intel.com/support/network/sb/cs-009209.htm 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.''

@@ Line 12: / Line 12: @@
 Another fix seems to be installing the newest driver from intel (7.6.5),
-the latest 2.6.22 ships with 7.3.2 and exposes latency problems on a T60
+the latest linux kernel 2.6.22 ships with 7.3.2 and exposes latency
-(symptom: every other ICMP response to a host on the local net takes
+problems on a T60 (symptom: every other ICMP response to a host on the
-about 1000ms.
+local net takes about 1000ms.

← Older revision		Revision as of 14:14, 16 July 2007
Line 10:		Line 10:

	This fix is recommended by Intel developers, and has been shown to help, but not completely solve the problem, at least anecdotally. 32 seems to work better than 8, again, anecdotally.		This fix is recommended by Intel developers, and has been shown to help, but not completely solve the problem, at least anecdotally. 32 seems to work better than 8, again, anecdotally.
		+
		+	Another fix seems to be installing the newest driver from intel (7.6.5),
		+	the latest 2.6.22 ships with 7.3.2 and exposes latency problems on a T60
		+	(symptom: every other ICMP response to a host on the local net takes
		+	about 1000ms.
		+

	===What is RxIntDelay?===		===What is RxIntDelay?===

@@ Line 1: / Line 1: @@
 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 [http://bugme.osdl.org/show_bug.cgi?id=6929 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:
+[http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-63027 BIOS update 2.11] is reported to fix the problem so that setting RxIntDelay is not necessary.
 <tt>modprobe -r e1000</tt>
@@ Line 7: / Line 9: @@
 <tt>modprobe e1000 RxIntDelay=32</tt>
-This fix is recommended by Intel developers, and has been shown to work at least anecdotally by the author of this page. 32 seems to work better than 8, again, anecdotally.
+This fix is recommended by Intel developers, and has been shown to help, but not completely solve the problem, at least anecdotally. 32 seems to work better than 8, again, anecdotally.
 ===What is RxIntDelay?===

← Older revision		Revision as of 22:37, 30 March 2007
Line 8:		Line 8:

	This fix is recommended by Intel developers, and has been shown to work at least anecdotally by the author of this page. 32 seems to work better than 8, again, anecdotally.		This fix is recommended by Intel developers, and has been shown to work at least anecdotally by the author of this page. 32 seems to work better than 8, again, anecdotally.
		+
		+	Alternatively, [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-63027 BIOS update 2.11] is reported to fix the problem so that setting RxIntDelay is not necessary.

	===What is RxIntDelay?===		===What is RxIntDelay?===

@@ Line 5: / Line 5: @@
 <tt>modprobe -r e1000</tt>
-<tt>modprobe e1000 RxIntDelay=8</tt>
+<tt>modprobe e1000 RxIntDelay=32</tt>
-This fix is recommended by Intel developers, and has been shown to work at least anecdotally by the other of this page.
+This fix is recommended by Intel developers, and has been shown to work at least anecdotally by the author of this page. 32 seems to work better than 8, again, anecdotally.
 ===What is RxIntDelay?===

← Older revision		Revision as of 16:39, 6 February 2007
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>