From owner-freebsd-stable@FreeBSD.ORG Fri Apr 20 16:04:32 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DDE3116A403 for ; Fri, 20 Apr 2007 16:04:32 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from alnrmhc15.comcast.net (alnrmhc15.comcast.net [206.18.177.55]) by mx1.freebsd.org (Postfix) with ESMTP id B60C013C4B0 for ; Fri, 20 Apr 2007 16:04:32 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from icarus.home.lan (c-71-198-0-135.hsd1.ca.comcast.net[71.198.0.135]) by comcast.net (alnrmhc15) with ESMTP id <20070420160431b1500snjobe>; Fri, 20 Apr 2007 16:04:32 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 7B0D61FA03D; Fri, 20 Apr 2007 09:04:31 -0700 (PDT) Date: Fri, 20 Apr 2007 09:04:31 -0700 From: Jeremy Chadwick To: Sven Willenberger Message-ID: <20070420160431.GA17356@icarus.home.lan> Mail-Followup-To: Sven Willenberger , freebsd-stable@freebsd.org References: <1176911436.7416.8.camel@lanshark.dmv.com> <1177084316.5457.5.camel@lanshark.dmv.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1177084316.5457.5.camel@lanshark.dmv.com> User-Agent: Mutt/1.5.14 (2007-02-12) Cc: freebsd-stable@freebsd.org Subject: Re: CARP and em0 timeout watchdog X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 16:04:32 -0000 On Fri, Apr 20, 2007 at 11:51:56AM -0400, Sven Willenberger wrote: > Having done more diagnostics I have found out it is not CARP related at > all. It turns out that the same timeouts will happen when ftp'ing to the > physical address IPs as well. There is also an odd situation here > depending on which protocol I use. The two boxes are connected to a Dell > Powerconnect 2616 gig switch with CAT6. If I scp files from the > 192.168.0.18 to the 192.168.0.19 box I can transfer gigs worth without a > hiccup (I used dd to create various sized testfiles from 32M to 1G in > size and just scp testfile* to the other box). On the other hand, if I > connect to 192.168.0.19 using ftp (either active or passive) where ftp > is being run through inetd, the interface resets (watchdog) within > seconds (a few MBs) of traffic. Enabling polling does nothing, nor does > changing net.inet.tcp.{recv,send}space. Any ideas why I would be seeing > such behavioral differences between scp and ftp? You'll get a much higher throughput rate with FTP than you will with SSH, simply because encryption overhead is quite high (even with the Blowfish cipher). With a very fast processor and on a gigE network you'll probably see 8-9MByte/sec via SSH while 60-70MByte/sec via FTP. That's the only difference I can think of. The watchdog resets I can't explain; Jack Vogel should be able to assist with that. But it sounds like the resets only happen under very high throughput conditions (which is why you'd see it with FTP but not SSH). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |