From nobody@FreeBSD.org  Thu Mar 25 15:41:04 2010
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id AA307106564A
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 25 Mar 2010 15:41:04 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 7F5B28FC13
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 25 Mar 2010 15:41:04 +0000 (UTC)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id o2PFf4ei095838
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 25 Mar 2010 15:41:04 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id o2PFf4aZ095837;
	Thu, 25 Mar 2010 15:41:04 GMT
	(envelope-from nobody)
Message-Id: <201003251541.o2PFf4aZ095837@www.freebsd.org>
Date: Thu, 25 Mar 2010 15:41:04 GMT
From: Mike <mfahey@gmail.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: poor preformance with fxp driver &  intel 82550 chipset
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         145036
>Category:       kern
>Synopsis:       [fxp] poor preformance with fxp driver &  intel 82550 chipset
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    yongari
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Mar 25 15:50:06 UTC 2010
>Closed-Date:    Wed Apr 07 17:23:57 UTC 2010
>Last-Modified:  Wed Apr 07 17:23:57 UTC 2010
>Originator:     Mike
>Release:        8
>Organization:
>Environment:
>Description:
Machine is Proliant ML370 G2. The network card has a intel 82550 chipset.
Transfer rates with any other os I.E windows,novell are fine. 
I get high ping times and slow transfer rates about 5k max. The hardware is working. The interface is set to full-duplex.

Thanks!
>How-To-Repeat:

>Fix:


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-net 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Thu Mar 25 16:28:46 UTC 2010 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=145036 
State-Changed-From-To: open->feedback 
State-Changed-By: yongari 
State-Changed-When: Thu Mar 25 18:25:58 UTC 2010 
State-Changed-Why:  
What FreeBSD version do you use? 
And show me the output of dmesg and "ifconfig fxp0". 
Could you give me more details on 
"high ping times and slow transder rates about 5k max"? 
Would you let me know how did you measure network performance? 


Responsible-Changed-From-To: freebsd-net->yongari 
Responsible-Changed-By: yongari 
Responsible-Changed-When: Thu Mar 25 18:25:58 UTC 2010 
Responsible-Changed-Why:  
Grab. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=145036 

From: Pyun YongHyeon <pyunyh@gmail.com>
To: mike fahey <mfahey@gmail.com>
Cc: yongari@freebsd.org, bug-followup@FreeBSD.org
Subject: Re: kern/145036: [fxp] poor preformance with fxp driver & intel 82550 chipset
Date: Thu, 25 Mar 2010 15:10:24 -0700

 On Thu, Mar 25, 2010 at 04:14:55PM -0400, mike fahey wrote:
 > Hi, below are the answers to your questions. If I download a file from
 > another freebsd box we have The max transfer rate is 5k. Ssh to the box is
 > extremely slow. I tested the network card
 > by booting with a ultimate boot cd and try ftping up an image. Transfer
 > rates were fine.  Is there a different way you want me to test transfers?
 
 To measure network performance you should use one of network
 benchmarks tools in ports/benchmark. Normally I use netperf.
 
 > there is definitely a problem with freebsd and this nic. If you need any
 > other information please let me know.
 > 
 > Thanks in advance!
 > 
 > 
 > uname -a
 > FreeBSD fuse.sm.ptd.net 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21
 > 15:48:17 UTC 2009
 > root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
 > i386
 > 
 > dmesg output
 > 
 
 [...]
 
 > fxp0: <Intel 82559 Pro/100 Ethernet> port 0x2000-0x203f mem
 > 0xf7df0000-0xf7df0fff,0xf7c00000-0xf7cfffff irq 15 at device 2.0 on pci0
 > miibus0: <MII bus> on fxp0
 > inphy0: <i82555 10/100 media interface> PHY 1 on miibus0
 > inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
 > fxp0: Ethernet address: 00:08:02:55:a4:d1
 > fxp0: [ITHREAD]
 
 Your controller is not i82550, you just have a plain i52559 
 controller. I wonder why you said you have i82550 controller which
 has a lot of hardware offload features compared to i82559.
 
 [...]
 
 > ifconfig fxp0
 > fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
 >         options=2009<RXCSUM,VLAN_MTU,WOL_MAGIC>
 >         ether 00:08:02:55:a4:d1
 >         inet 10.102.4.10 netmask 0xffff0000 broadcast 10.102.255.255
 >         media: Ethernet autoselect (100baseTX <full-duplex>)
 >         status: active
 > 
 > Ping output
 > 
 > PING 10.105.1.5 (10.105.1.5): 56 data bytes
 > 64 bytes from 10.105.1.5: icmp_seq=0 ttl=127 time=3995.466 ms
 > 64 bytes from 10.105.1.5: icmp_seq=1 ttl=127 time=2994.201 ms
 > 64 bytes from 10.105.1.5: icmp_seq=2 ttl=127 time=1992.423 ms
 > 64 bytes from 10.105.1.5: icmp_seq=3 ttl=127 time=990.605 ms
 > 64 bytes from 10.105.1.5: icmp_seq=4 ttl=127 time=3987.967 ms
 > 64 bytes from 10.105.1.5: icmp_seq=5 ttl=127 time=2986.172 ms
 > 64 bytes from 10.105.1.5: icmp_seq=6 ttl=127 time=1984.363 ms
 > 64 bytes from 10.105.1.5: icmp_seq=7 ttl=127 time=982.534 ms
 > 64 bytes from 10.105.1.5: icmp_seq=8 ttl=127 time=3979.910 ms
 > 64 bytes from 10.105.1.5: icmp_seq=9 ttl=127 time=2978.120 ms
 > 64 bytes from 10.105.1.5: icmp_seq=10 ttl=127 time=1976.304 ms
 > 64 bytes from 10.105.1.5: icmp_seq=11 ttl=127 time=974.480 ms
 > 64 bytes from 10.105.1.5: icmp_seq=12 ttl=127 time=3972.851 ms
 > 64 bytes from 10.105.1.5: icmp_seq=13 ttl=127 time=2971.067 ms
 > 64 bytes from 10.105.1.5: icmp_seq=14 ttl=127 time=1969.246 ms
 > 64 bytes from 10.105.1.5: icmp_seq=15 ttl=127 time=967.432 ms
 > 64 bytes from 10.105.1.5: icmp_seq=16 ttl=127 time=3965.799 ms
 > 64 bytes from 10.105.1.5: icmp_seq=17 ttl=127 time=2964.006 ms
 > 64 bytes from 10.105.1.5: icmp_seq=18 ttl=127 time=1962.183 ms
 > 64 bytes from 10.105.1.5: icmp_seq=19 ttl=127 time=960.365 ms
 > 64 bytes from 10.105.1.5: icmp_seq=20 ttl=127 time=3958.735 ms
 > 64 bytes from 10.105.1.5: icmp_seq=21 ttl=127 time=2956.951 ms
 > 64 bytes from 10.105.1.5: icmp_seq=22 ttl=127 time=1955.119 ms
 > 64 bytes from 10.105.1.5: icmp_seq=23 ttl=127 time=953.297 ms
 > 
 
 Your issue looks like high latency time. By chance are you using
 polling(4)? Did the issue happen on 8.0-RELEASE only? If yes, what
 is the last known working release?
State-Changed-From-To: feedback->open 
State-Changed-By: yongari 
State-Changed-When: Fri Mar 26 17:11:20 UTC 2010 
State-Changed-Why:  
Feedback received. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=145036 

From: Pyun YongHyeon <pyunyh@gmail.com>
To: mike fahey <mfahey@gmail.com>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/145036: [fxp] poor preformance with fxp driver & intel 82550 chipset
Date: Fri, 26 Mar 2010 10:21:53 -0700

 On Fri, Mar 26, 2010 at 09:07:56AM -0400, mike fahey wrote:
 > Hi, polling was not enable and I ran ifconfig fxp0 -polling to disable it.
 > This made no difference.
 > I have hooked up the Proliant ml370 G2 and my workstation to a netgear
 > switch in the office.
 > 
 > Below are the results from ping and netperf. Thanks again for all of your
 > help!
 > 
 > 
 > The server is 10.102.4.10 and my workstation is 10.102.4.9. Both are plugged
 > into a
 > GS116 netgear 16port gigabit switch on my desk.
 > 
 
 Ok, could you login to the switch and check speed/duplex of port
 which is connected to your fxp(4) system? The switch should also
 agree on the resolved speed/duplex of your system. Use
 "ifconfig fxp0" to check current resolved speed/duplex of fxp(4).
 
 > ping output from the server
 > 64 bytes from 10.102.4.9: icmp_seq=0 ttl=128 time=0.687 ms
 > 64 bytes from 10.102.4.9: icmp_seq=1 ttl=128 time=2994.831 ms
 > 64 bytes from 10.102.4.9: icmp_seq=2 ttl=128 time=1993.021 ms
 > 64 bytes from 10.102.4.9: icmp_seq=3 ttl=128 time=991.203 ms
 > 64 bytes from 10.102.4.9: icmp_seq=4 ttl=128 time=3499.662 ms
 > 64 bytes from 10.102.4.9: icmp_seq=5 ttl=128 time=2497.883 ms
 > 64 bytes from 10.102.4.9: icmp_seq=6 ttl=128 time=1496.065 ms
 > 64 bytes from 10.102.4.9: icmp_seq=7 ttl=128 time=494.249 ms
 > 64 bytes from 10.102.4.9: icmp_seq=8 ttl=128 time=98.159 ms
 > 64 bytes from 10.102.4.9: icmp_seq=9 ttl=128 time=2073.872 ms
 > 64 bytes from 10.102.4.9: icmp_seq=10 ttl=128 time=1072.072 ms
 > 64 bytes from 10.102.4.9: icmp_seq=11 ttl=128 time=70.252 ms
 > 64 bytes from 10.102.4.9: icmp_seq=12 ttl=128 time=28.120 ms
 > 64 bytes from 10.102.4.9: icmp_seq=13 ttl=128 time=18.099 ms
 > 64 bytes from 10.102.4.9: icmp_seq=14 ttl=128 time=104.070 ms
 > 64 bytes from 10.102.4.9: icmp_seq=15 ttl=128 time=971.974 ms
 > 64 bytes from 10.102.4.9: icmp_seq=16 ttl=128 time=3969.416 ms
 > 64 bytes from 10.102.4.9: icmp_seq=17 ttl=128 time=2967.657 ms
 > 64 bytes from 10.102.4.9: icmp_seq=18 ttl=128 time=1965.837 ms
 > 64 bytes from 10.102.4.9: icmp_seq=19 ttl=128 time=964.022 ms
 > 64 bytes from 10.102.4.9: icmp_seq=20 ttl=128 time=3962.350 ms
 > 64 bytes from 10.102.4.9: icmp_seq=21 ttl=128 time=2960.586 ms
 > 64 bytes from 10.102.4.9: icmp_seq=22 ttl=128 time=1958.768 ms
 > 64 bytes from 10.102.4.9: icmp_seq=23 ttl=128 time=956.951 ms
 > 64 bytes from 10.102.4.9: icmp_seq=24 ttl=128 time=3955.287 ms
 > 64 bytes from 10.102.4.9: icmp_seq=25 ttl=128 time=2953.503 ms
 > 64 bytes from 10.102.4.9: icmp_seq=26 ttl=128 time=1951.750 ms
 > 64 bytes from 10.102.4.9: icmp_seq=27 ttl=128 time=949.932 ms
 > 
 > 
 
 I still have no idea why TTL of ICMP reply has 128. Normally it's
 value is 63 so this is the reason why I start to think about
 routing configuration.
State-Changed-From-To: open->closed 
State-Changed-By: yongari 
State-Changed-When: Wed Apr 7 17:22:55 UTC 2010 
State-Changed-Why:  
Close, submitter confirms polling(4) solved the poor latency issue. 
polling(4) may/may not be ideal solution to the issue but it seems 
there is no issue in fxp(4) itself. I think some other devices or 
driver in the system that shares the interrupt line of fxp(4) 
controller seems to cause the issue. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=145036 
>Unformatted:
