RE: e1000 -> 82540EM on linux 2.6.0-test[45] very slow in one direction

RE: e1000 -> 82540EM on linux 2.6.0-test[45] very slow in one direction

[Leech, Christopher]

> Btw, I had to compile the e1000 driver as a module. Compiled in it
> doesn't work, as is stated on the intel support page:

> This is not clear from the kernel config help. A patch against
> 2.6.0-test6 is attached (I don't know how to only give n/m as an
> option).

This patch is not necessary or desired.  The version of e1000 that ships
with the kernel source should work fine statically linked, and the
comment on the Intel support web page applies to the separate download
of the e1000 source.  If you download the driver source from Intel and
do the work to add it into a kernel source tree yourself, Intel customer
support may not help you when you have problems.

If you are having problems compiling in the version of e1000 that ships
with the kernel, please report it on netdev and we'll try and help.
 
> Btw2, can somebody please explain what the option E1000_NAPI does?

NAPI is a network driver polling mode interface.  It enables a form of
software managed interrupt moderation, and may result in better
performance under some traffic patterns (specifically sustained high
packet rate reception).

-- Chris

Re: e1000 -> 82540EM on linux 2.6.0-test[45] very slow in one direction

[Sander]

Leech, Christopher wrote (ao):
> > Btw, I had to compile the e1000 driver as a module. Compiled in it
> > doesn't work, as is stated on the intel support page:
> 
> > This is not clear from the kernel config help. A patch against
> > 2.6.0-test6 is attached (I don't know how to only give n/m as an
> > option).
> 
> This patch is not necessary or desired. The version of e1000 that ships
> with the kernel source should work fine statically linked, and the
> comment on the Intel support web page applies to the separate download
> of the e1000 source. If you download the driver source from Intel and
> do the work to add it into a kernel source tree yourself, Intel customer
> support may not help you when you have problems.
> 
> If you are having problems compiling in the version of e1000 that ships
> with the kernel, please report it on netdev and we'll try and help.

I'm sorry for the patch. The problem I had with e1000 compiled into the
kernel was that the interface resets every 60(?) seconds, and there was
no network connection. After a google search I came onto the intel
support page, saw the module-only text, tried e1000 as a module and it
worked. This all is with the e1000 driver which is in the 2.6.0-test6
kernel, which I thought was the intel provided driver.
The server is co-located now, so I'm sorry to say that I can't try
again to give more details.

> > Btw2, can somebody please explain what the option E1000_NAPI does?
> 
> NAPI is a network driver polling mode interface.  It enables a form of
> software managed interrupt moderation, and may result in better
> performance under some traffic patterns (specifically sustained high
> packet rate reception).

Aha, tnx. Can you please provide a patch to get this text in the 2.6
help?

Re: e1000 -> 82540EM on linux 2.6.0-test[45] very slow in one direction

[Florian Zwoch]

issue seems to partly solved. the e1000 driver seems to be ok!
i reconfigured my kernel and intentionally left out netfilter options. 
after that my network performance was back to normal.

netfilter was only compiled in the kernel. it was not used with any rules!

so my wild guess would be that something with the netfilter code (i am 
not 100% sure it was netfilter.. _maybe_ it was some small odd kernel 
option i accidently enabled/disabled) is broken since test3 (again 
uncertified. but i firstly noticed this switching from test3 to test4).

Florian Zwoch wrote:
> hi,
> this has been discussed very roughly before. but unfortunately no real 
> solution has been brought up so far (or i have not read it yet).
> 
> problem in short: the 82540EM intel gigabit adapter became very slow as 
> of 2.6.0-test4. maybe earlier versions were als affected aswell, but i 
> noticed this behaviour on test4 and later. the 'slowness' of the adapter 
> only affects a certain data direction. i performed the following tests 
> to show you what is wrong.
> 
> dummy data file was 34257856 bytes (34.3MB).
> test machines were a pentium4 with the intel adapter, and a pentium2 266 
> with a lowcost realtek card (runs linux 2.4).
> 
> SCP:
>   e1000 -> 8139too    28.6KB/s
>   e1000 <- 8139too    4.6MB/s
> 
> SMB:
>   e1000 -> 8139too    3.0MB/s
>   e1000 <- 8139too    3.3MB/s
> 
> FTP
>   e1000 -> 8139too    54KB/s
>   e1000 <- 8139too    9.4MB/s
> 
> as you can see reveiving data is no problem at all (maybe another 
> protocol can create some problems in this case?). but sending data is 
> awesome slow! exception is the samba protocol. why is that? i thought 
> that samba may use udp instead of tcp. but iptraf did not show any udp 
> packets going around so i guess i was wrong.
> 
> the problem gets worse while trying to test things over the internet. 
> scp stalls incredibly often on my 256kbit/s upstream. so does ftp and 
> irc dcc protocol. irc dcc ends up with sending 0.3KB/s on a megabyte 
> sized file.
> 
> before people again trying to tell me that some duplex settings could be 
> messed up - then tell me why this should happen. when i boot into 2.4 
> kernel with that test machine the nic works without problems. so IF 
> duplex stuff is the reason for the hickups something must be wrong with 
> the duplex detection code in the new driver/kernel?
> 
> i tried vanilla 2.6.0-test5, 2.6.0-test5-mm2 and mm3 + 2.6.0-test5-bk4. 
> none of these gave any difference regarding network performance.

Re: e1000 -> 82540EM on linux 2.6.0-test[45] very slow in one direction

[Ookhoi]

[-- Attachment #1: Type: text/plain, Size: 4256 bytes --]

Hi Florian and others,

Florian Zwoch wrote (ao):
> issue seems to partly solved. the e1000 driver seems to be ok!
> i reconfigured my kernel and intentionally left out netfilter options. 
> after that my network performance was back to normal.
> 
> netfilter was only compiled in the kernel. it was not used with any rules!
> 
> so my wild guess would be that something with the netfilter code (i am 
> not 100% sure it was netfilter.. _maybe_ it was some small odd kernel 
> option i accidently enabled/disabled) is broken since test3 (again 
> uncertified. but i firstly noticed this switching from test3 to test4).

I have the same problem with a dual port gigabit intel nic. Download is
very fast, upload around 40k/sec.

Kernel is 2.6.0-test6
Nic is dual port gigabit intel 82546EB
The nic is connected to a 100Mbit switch, only one port in use.

If I do 'ethtool -A eth0 tx on' the machine is offline for 50 seconds.
When it is back online the upload is fast for a few seconds, and then
returns to its old speed. Full 'ethtool -d eth0' output below.

I have netfilter enabled, and will try another -test6 kernel with
netfilter not compiled in to see if that indeed makes a difference.

Btw, I had to compile the e1000 driver as a module. Compiled in it
doesn't work, as is stated on the intel support page:

http://www.intel.com/support/network/adapter/1000/linux/e1000.htm

" This driver is only supported as a loadable module at this time. Intel
is not supplying patches against the kernel source to allow for static
linking of the driver."

This is not clear from the kernel config help. A patch against
2.6.0-test6 is attached (I don't know how to only give n/m as an
option).

Btw2, can somebody please explain what the option E1000_NAPI does?

"
      Use Rx Polling (NAPI) (E1000_NAPI) [N/y] (NEW) ?

Sorry, no help available for this option yet.
"


Thanks in advance.


ethtool -d eth0 gives:

MAC Registers
-------------
0x00000: CTRL (Device control register)  0x08F00249
      Duplex:                            full
      Endian mode (buffers):             little
      Link reset:                        reset
      Set link up:                       1
      Invert Loss-Of-Signal:             no
      Receive flow control:              enabled
      Transmit flow control:             disabled
      VLAN mode:                         disabled
      Auto speed detect:                 disabled
      Speed select:                      1000Mb/s
      Force speed:                       no
      Force duplex:                      no
0x00008: STATUS (Device status register) 0x0000BB43
      Duplex:                            full
      Link up:                           link config
      TBI mode:                          disabled
      Link speed:                        100Mb/s
      Bus type:                          PCI-X
      Bus speed:                         133MHz
      Bus width:                         64-bit
0x00100: RCTL (Receive control register) 0x00008002
      Receiver:                          enabled
      Store bad packets:                 disabled
      Unicast promiscuous:               disabled
      Multicast promiscuous:             disabled
      Long packet:                       disabled
      Descriptor minimum threshold size: 1/2
      Broadcast accept mode:             accept
      VLAN filter:                       disabled
      Cononical form indicator:          disabled
      Discard pause frames:              filtered
      Pass MAC control frames:           don't pass
      Receive buffer size:               2048
0x02808: RDLEN (Receive desc length)     0x00001000
0x02810: RDH   (Receive desc head)       0x00000014
0x02818: RDT   (Receive desc tail)       0x00000010
0x02820: RDTR  (Receive delay timer)     0x00000000
0x00400: TCTL (Transmit ctrl register)   0x0004010A
      Transmitter:                       enabled
      Pad short packets:                 enabled
      Software XOFF Transmission:        disabled
      Re-transmit on late collision:     disabled
0x03808: TDLEN (Transmit desc length)    0x00001000
0x03810: TDH   (Transmit desc head)      0x000000DC
0x03818: TDT   (Transmit desc tail)      0x000000DC
0x03820: TIDV  (Transmit delay timer)    0x00000040

[-- Attachment #2: e1000-help-patch.diff --]
[-- Type: text/plain, Size: 740 bytes --]

--- drivers/net/Kconfig.orig	2003-10-03 12:17:48.000000000 +0200
+++ drivers/net/Kconfig	2003-10-03 12:27:56.000000000 +0200
@@ -1876,9 +1876,12 @@
 	  More specific information on configuring the driver is in 
 	  <file:Documentation/networking/e1000.txt>.
 
-	  To compile this driver as a module, choose M here and read
-	  <file:Documentation/networking/net-modules.txt>.  The module
-	  will be called e1000.
+	  This driver is only supported as a loadable module at this
+	  time. Intel is not supplying patches against the kernel source
+	  to allow for static linking of the driver.
+
+	  Read <file:Documentation/networking/net-modules.txt>. The
+	  module will be called e1000.
 
 config E1000_NAPI
 	bool "Use Rx Polling (NAPI)"

Re: e1000 -> 82540EM on linux 2.6.0-test[45] very slow in one direction

[Ookhoi]

Ookhoi wrote (ao):
> Florian Zwoch wrote (ao):
> > issue seems to partly solved. the e1000 driver seems to be ok!
> > i reconfigured my kernel and intentionally left out netfilter options. 
> > after that my network performance was back to normal.
> > 
> > netfilter was only compiled in the kernel. it was not used with any rules!
> > 
> > so my wild guess would be that something with the netfilter code (i am 
> > not 100% sure it was netfilter.. _maybe_ it was some small odd kernel 
> > option i accidently enabled/disabled) is broken since test3 (again 
> > uncertified. but i firstly noticed this switching from test3 to test4).

> I have netfilter enabled, and will try another -test6 kernel with
> netfilter not compiled in to see if that indeed makes a difference.

I can confirm now that disabling netfilter in 2.6.0-test6 makes the nic
perform oke wrt upload.
I (just like Florian) had no iptables rules active in the former
2.6.0-test6 kernel, but netfilter was compiled in.