Date: Sat, 28 Nov 2009 12:36:37 -0700 From: Elliot Finley <efinley.lists@gmail.com> To: Robert Watson <rwatson@freebsd.org>, freebsd-current@freebsd.org Subject: Re: 8.0-RC3 network performance regression Message-ID: <54e63c320911281136v5621496ev8c803119e8274056@mail.gmail.com> In-Reply-To: <54e63c320911190842n352cd860q460684376065cd3a@mail.gmail.com> References: <54e63c320911181807m4ddb770br1281d1163ae3cf5f@mail.gmail.com> <alpine.BSF.2.00.0911190852470.12162@fledge.watson.org> <54e63c320911190842n352cd860q460684376065cd3a@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert, Here is more info that may be helpful in tracking this down. I'm now running 8.0-R on all boxes. If I use the following settings on the box that's running netserver: kern.ipc.maxsockbuf=16777216 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.recvbuf_inc=524288 net.inet.tcp.hostcache.expire=1 and I leave the netperf box at default, then I get 932Mbps. But if I then add the same settings to the box that I'm running netperf from, the speed drops down to around 420Mbps again. What other information is needed to help track this down? TIA Elliot On Thu, Nov 19, 2009 at 9:42 AM, Elliot Finley <efinley.lists@gmail.com>wrote: > > > On Thu, Nov 19, 2009 at 2:11 AM, Robert Watson <rwatson@freebsd.org>wrote: > >> >> On Wed, 18 Nov 2009, Elliot Finley wrote: >> >> I have several boxes running 8.0-RC3 with pretty dismal network >>> performance. I also have some 7.2 boxes with great performance. Using iperf >>> I did some tests: >>> >>> server(8.0) <- client (8.0) == 420Mbps >>> server(7.2) <- client (7.2) == 950Mbps >>> server(7.2) <- client (8.0) == 920Mbps >>> server(8.0) <- client (7.2) == 420Mbps >>> >>> so when the server is 7.2, I have good performance regardless of whether >>> the client is 8.0 or 7.2. when the server is 8.0, I have poor performance >>> regardless of whether the client is 8.0 or 7.2. >>> >>> Has anyone else noticed this? Am I missing something simple? >>> >> >> I've generally not measured regressions along these lines, but TCP >> performance can be quite sensitive to specific driver version and hardware >> configuration. So far, I've generally measured significant TCP scalability >> improvements in 8, and moderate raw TCP performance improvements over real >> interfaces. On the other hand, I've seen decreased TCP performance on the >> loopback due to scheduling interactions with ULE on some systems (but not >> all -- disabling checksum generate/verify has improved loopback on other >> systems). >> >> The first thing to establish is whether other similar benchmarks give the >> same result, which might us to narrow the issue down a bit. Could you try >> using netperf+netserver with the TCP_STREAM test and see if that differs >> using the otherwise identical configuration? >> >> Could you compare the ifconfig link configuration of 7.2 and 8.0 to make >> sure there's not a problem with the driver negotiating, for example, half >> duplex instead of full duplex? Also confirm that the same blend ot >> LRO/TSO/checksum offloading/etc is present. >> >> Could you do "procstat -at | grep ifname" (where ifname is your interface >> name) and send that to me? >> >> Another thing to keep an eye of is interrupt rates and pin sharing, which >> are both sensitive to driver change and ACPI changes. It wouldn't hurt to >> compare vmstat -i rates not just on your network interface, but also on >> other devices, to make sure there's not new aliasing. With a new USB stack >> and plenty of other changes, additional driver code running when your NIC >> interrupt fires would be highly measurable. >> >> Finally, two TCP tweaks to try: >> >> (1) Try disabling in-flight bandwidth estimation by setting >> net.inet.tcp.inflight.enable to 0. This often hurts low-latency, >> high-bandwidth local ethernet links, and is sensitive to many other >> issues >> including time-keeping. It may not be the "cause", but it's a useful >> thing to try. >> >> (2) Try setting net.inet.tcp.read_locking to 0, which disables the >> read-write >> locking strategy on global TCP locks. This setting, when enabled, >> significantly impoves TCP scalability when dealing with multiple NICs >> or >> input queues, but is one of the non-trivial functional changes in TCP. > > > Thanks for the reply. Here is some more info: > > netperf results: > storage-price-3 root:~#>netperf -H 10.20.10.20 > TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.20.10.20 > (10.20.10.20) port 0 AF_INET > Recv Send Send > Socket Socket Message Elapsed > Size Size Size Time Throughput > bytes bytes bytes secs. 10^6bits/sec > > 4194304 4194304 4194304 10.04 460.10 > > > The interface on both boxes is em1. Both boxes (8.0RC3) have two 4-port > PCIe NICs in them.Trying the two TCP tweaks didn't change anything. While > running iperf I did the procstat and vmstat: > > SERVER: > storage-price-2 root:~#>ifconfig em1 > em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 > options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4> > ether 00:15:17:b2:31:3d > inet 10.20.10.20 netmask 0xffffff00 broadcast 10.20.10.255 > media: Ethernet autoselect (1000baseT <full-duplex>) > status: active > > storage-price-2 root:~#>procstat -at | grep em1 > 0 100040 kernel em1 taskq 3 16 run - > > storage-price-2 root:~#>vmstat -i > interrupt total rate > irq14: ata0 22979 0 > irq15: ata1 23157 0 > irq16: aac0 uhci0* 1552 0 > irq17: uhci2+ 37 0 > irq18: ehci0 uhci+ 43 0 > cpu0: timer 108455076 2000 > irq257: em1 2039287 37 > cpu2: timer 108446955 1999 > cpu1: timer 108447018 1999 > cpu3: timer 108447039 1999 > cpu7: timer 108447061 1999 > cpu5: timer 108447061 1999 > cpu6: timer 108447054 1999 > cpu4: timer 108447061 1999 > Total 869671380 16037 > > CLIENT: > storage-price-3 root:~#>ifconfig em1 > em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 > options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4> > ether 00:15:17:b2:31:49 > inet 10.20.10.30 netmask 0xffffff00 broadcast 10.20.10.255 > media: Ethernet autoselect (1000baseT <full-duplex>) > status: active > > storage-price-3 root:~#>procstat -at | grep em1 > 0 100040 kernel em1 taskq 3 16 run - > > storage-price-3 root:~#>vmstat -i > interrupt total rate > irq1: atkbd0 2 0 > irq14: ata0 22501 0 > irq15: ata1 22395 0 > irq16: aac0 uhci0* 5091 0 > irq17: uhci2+ 125 0 > irq18: ehci0 uhci+ 43 0 > cpu0: timer 108421132 1999 > irq257: em1 1100465 20 > cpu3: timer 108412973 1999 > cpu1: timer 108412987 1999 > cpu2: timer 108413010 1999 > cpu7: timer 108413048 1999 > cpu6: timer 108413048 1999 > cpu5: timer 108413031 1999 > cpu4: timer 108413045 1999 > Total 868462896 16020 > > 7.2 BOX: > dns1 root:~#>ifconfig em0 > em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 > options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM> > ether 00:13:72:5a:ff:48 > inet X.Y.Z.7 netmask 0xffffffc0 broadcast X.Y.Z.63 > media: Ethernet autoselect (1000baseTX <full-duplex>) > status: active > > The 8.0RC3 boxes are being used for testing right now (production 2nd week > of December). If you want access to them, that wouldn't be a problem. > > TIA > Elliot > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54e63c320911281136v5621496ev8c803119e8274056>