Hi.
My first post on this list. :-)
So, i own Intel MBO, DQ67EP, which have embedded NIC - 82579LM. Card is
reported as:
# lspci -nn -v -s 00:19.0
00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit
Network Connection [8086:1502] (rev 04)
Subsystem: Intel Corporation Device [8086:200f]
Flags: bus master, fast devsel, latency 0, IRQ 51
Memory at fe600000 (32-bit, non-prefetchable) [size=128K]
Memory at fe628000 (32-bit, non-prefetchable) [size=4K]
I/O ports at f080 [size=32]
Capabilities: [c8] Power Management version 2
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [e0] PCI Advanced Features
Kernel driver in use: e1000e
I use it with Fedora (3.8.13 based kernel, but i did try all up to 3.9.4).
Problem with this one is that, on high load, while connected at 1Gb -
drop packets. To make things worse, any of counters viewed either via
ethtool -S or netstat -s does not show any problems. At least on side
where the card is (server side). Client side does experience drops, and
they are visible on netstat (tcp/icmp stack).
I did try to search for solution, but g00gle does not report back any
solution. I did found _a lot_ of users complaining about this card, and
also about 82579v card. It seems that for 82597v there is some solution
- but not for 82597LM. Also, i did try latest stable drivers from
http://sourceforge.net/projects/e1000/, numbered 2.3.2, but without any
luck.
My setup is quite simple - two boxes connected with shielded cat6 cable.
Back to back. Cable is about 3m long. It works flawlessly with other
hardware.
Now, this is what i am experiencing:
1. ping from host A (with i82579LM) -> host B
# ping -f -c 10000 192.168.10.101
PING 192.168.10.101 (192.168.10.101) 56(84) bytes of data.
...........
--- 192.168.10.101 ping statistics ---
10000 packets transmitted, 9989 received, 0% packet loss, time 2552ms
rtt min/avg/max/mdev = 0.111/0.206/0.871/0.057 ms, ipg/ewma 0.255/0.209 ms
#
As it can be seen, i'm missing 11 packets!
2. udp performance test host A is server, host B is client
# iperf -M 1000 -u -s
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size: 208 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.10.1 port 5001 connected with 192.168.10.157 port 57572
------------------------------------------------------------
Client connecting to 192.168.10.157, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 208 KByte (default)
------------------------------------------------------------
[ 5] local 192.168.10.1 port 44804 connected with 192.168.10.157 port 5001
[ ID] Interval Transfer Bandwidth Jitter Lost/Total
Datagrams
[ 3] 0.0-30.0 sec 3.75 MBytes 1.05 Mbits/sec 0.360 ms 3/ 2676
(0.11%)
[ 5] 0.0-30.0 sec 3.75 MBytes 1.05 Mbits/sec
[ 5] Sent 2676 datagrams
[ 5] Server Report:
[ 5] 0.0-30.0 sec 3.75 MBytes 1.05 Mbits/sec 0.361 ms 0/ 2676 (0%)
#
And client side:
# iperf -M 1000 -u -c 192.168.10.1 -d -t 30
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size: 208 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 192.168.10.1, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 208 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.10.157 port 57572 connected with 192.168.10.1 port 5001
[ 3] local 192.168.10.157 port 5001 connected with 192.168.10.1 port 44804
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-30.0 sec 3.75 MBytes 1.05 Mbits/sec
[ 4] Sent 2676 datagrams
[ 3] 0.0-30.0 sec 3.75 MBytes 1.05 Mbits/sec 0.361 ms 0/ 2676 (0%)
[ 4] Server Report:
[ 4] 0.0-30.0 sec 3.75 MBytes 1.05 Mbits/sec 0.359 ms 3/ 2676
(0.11%)
#
Again, clear evidence of packet loss. Also, packet loss is not constant
- sometimes it's bigger, rarely smaller.
With no solution on horizon, i did try to fix it myself. :-)
In the end, it seems that this chip has "K1 power save" optimization,
and at 1Gb speeds this is causing chaos - that is, packet loss. I did
found some hints on some message boards about this, so i did use
http://www.intel.com/content/dam/doc/datasheet/82579-gbe-phy-datasheet-vol-2-1.pdf
and try to turn it off. Patch is attached, and it is against 2.3.2 of
e1000e driver.
In this pdf, page 91, table 59, describes in details power modes. I just
simply turned on bit 13, which disables K1 mode in 1Gbit speeds.
This patch fixes all my problems with this card, no more packet
loss/drops. Patch is somewhat "rough" (i could use some fancy name), i
guess, but it does provide solution. :-)
I would like to ask that this fix is included in e1000e driver, and
published asap. Reason is that there is _a lot_ of those devices, and
people are having problems, without Intel doing anything. Or it seems so.
Anyhow, i will post on other lists and reference this mail as fix.
Thanks,
H.
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
E1000-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit
http://communities.intel.com/community/wired
