Date: Mon, 04 May 2009 11:23:54 -0500 From: Lawrence Stewart <lstewart@freebsd.org> To: George Neville-Neil <gnn@neville-neil.com> Cc: freebsd-net@freebsd.org, qingli@freebsd.org Subject: Re: Slow local TCP transfers on -CURRENT Message-ID: <49FF169A.9040708@freebsd.org> In-Reply-To: <070BE192-6D18-4DB9-87AE-49233996CCA4@neville-neil.com> References: <00C19FCC-837A-44B8-A0C9-C56E3D02F8EF@dragondata.com> <49FC3984.8050609@freebsd.org> <070BE192-6D18-4DB9-87AE-49233996CCA4@neville-neil.com>
index | next in thread | previous in thread | raw e-mail
George Neville-Neil wrote: > > On May 2, 2009, at 08:16 , Lawrence Stewart wrote: > >> Kevin Day wrote: >>> I've been seeing this for a few months now on -CURRENT. TCP transfers >>> to local IP addresses (but not 127.0.0.1) are incredibly slow. >>> Transfer from localhost: >>> # scp "root@127.0.0.1:/boot/kernel/kernel" . >>> kernel >>> 100% 11MB 11.1MB/s 00:00 >>> Appropriately fast. >>> Transfer from an IP on a local interface: >>> # scp "root@216.14.96.4:/boot/kernel/kernel" . >>> kernel >>> 0% 16KB 13.0KB/s 14:37 ETA >>> The routes seem normal: >>> # route get 127.0.0.1 >>> route to: localhost >>> destination: localhost >>> interface: lo0 >>> flags: <UP,HOST,DONE,LOCAL> >>> recvpipe sendpipe ssthresh rtt,msec mtu weight expire >>> 0 0 0 0 16384 1 0 >>> # route -n get 216.14.96.4 >>> route to: 216.14.96.4 >>> destination: 216.14.96.0 >>> mask: 255.255.255.128 >>> interface: nfe0 >>> flags: <UP,DONE> >>> recvpipe sendpipe ssthresh rtt,msec mtu weight expire >>> 0 0 0 0 1500 1 0 >>> nfe0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu >>> 1500 >>> >>> options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4> >>> ether 00:30:48:c6:dd:9c >>> inet 216.14.96.4 netmask 0xffffff80 broadcast 216.14.96.127 >>> Takes 10-60 minutes to copy, stalling frequently during the transfer. >>> It's not limited to just scp either, all TCP transfers seem to stall >>> this way. >>> I don't believe I'm doing anything unusual, has anyone seen anything >>> like this? >> >> Known fallout from the ARPv2 work I believe. As a workaround until it >> gets fixed: >> >> route add -host (if-ip) -iface lo0 (note I haven't tested this myself) >> >> (see the Jan 2009 freebsd-net@ thread "Bacula: VERY SLOW on SAME host" >> for some details). >> > > Anyone know if there is a fix in the offing? Qing (added to CC) is aware of the problem. Not sure how far off the fix is. Cheers, Lawrencehome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49FF169A.9040708>