Date: Fri, 23 Jan 2004 16:41:50 +0000 From: Karl Pielorz <kpielorz@tdx.co.uk> To: Robert Watson <rwatson@freebsd.org> Cc: freebsd-questions@freebsd.org Subject: Re: FreeBSD tunnels / performance et'al (gif/tun etc.) Message-ID: <16051437.1074876110@raptor> In-Reply-To: <Pine.NEB.3.96L.1040123105004.95365I-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1040123105004.95365I-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--On 23 January 2004 10:51 -0500 Robert Watson <rwatson@freebsd.org> wrote: >> I'm just wondering if it was something 'weird' such as the delay over >> the tunnel being on average 'just the right delay time' to cause >> problems that you wouldn't get on a LAN or something? :) > > I agree that something sounds weird -- I've had no problem tunneling > hundreds of megabits using similar hardware to what you're using, and what > sounds like a similar configuration. So it seems like something is going > on. Do you have any load information available on the systems -- i.e., > interrupt rate as measured by vmstat, cpu usage, etc? Are you using natd > or other address space translation? Both systems are dedicated boxes, i.e. they run the tunnel - and nothing else (no nat, nothing). Load on each was unremarkable, i.e. no excessive interrupts etc. on the hardware that didn't work we were getting about 300 or so interrupts a second on each network card. After the changes this it rose to about 800 a second per card [as the tunnel performance rose]. We're due to pull the failed machine from the remote end soon - If I get a chance I'll run it up here - though I don't think it's "flakey hardware/network card" - as when scp/ftp'ing to that host via either it's physical address, or tunnel endpoint address we got good performance... Looking briefly at the tcpdumps - it looks like there were a lot of duplicated ACK packets being sent from the remote side (which would suggest they never made it to the other side) - and that would also be a credible reason for the sessions stalling so badly... It'd also explain why at the time the 'aggregate' traffic flow on gif0 looked good, but individual machines/IP's were getting really pityful throughput... I'll see if I can dig out the original tcpdumps [most the debug stuff usually starts disappearing once the problem is solved, regardless of how :(] -Karl
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16051437.1074876110>