From owner-freebsd-stable@FreeBSD.ORG Fri Apr 20 17:17:50 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 C1E0D16A400 for ; Fri, 20 Apr 2007 17:17:50 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.230]) by mx1.freebsd.org (Postfix) with ESMTP id 8085C13C4BD for ; Fri, 20 Apr 2007 17:17:50 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by nz-out-0506.google.com with SMTP id r28so824086nza for ; Fri, 20 Apr 2007 10:17:50 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jN+J+Vpl/szzVOf+YkUauDWw5E/jfKLsXO+GovsKmZDwxeOG0h22Oc4XyabJdjL2LlaBR6MRSvZg0Tzm5PGjopXx5ULYDoCEgB9jkE0eXoKHpllJifaWK/kfUqPTc3Nt9MgoTBtW5HWHykI0df31z+hocCGKPxpt2taggplAxwM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YH06LkKlCVuTV7sFbo/vbkjWSXFjZh0nkH61F+R79yMGmdKAjz+Jdh5h4t91A8wiLr3AZFLmBWVmTA/jyiAlOMfj5WifB1N5l3r1ZSR/gazRbhkBHG2Pdrf4/XnpfZxd0p4yKOmVjBIXxQgXcRc7kNLgL1cIPexHP4uUVWdOM5s= Received: by 10.114.52.1 with SMTP id z1mr1315226waz.1177089469574; Fri, 20 Apr 2007 10:17:49 -0700 (PDT) Received: by 10.114.103.15 with HTTP; Fri, 20 Apr 2007 10:17:49 -0700 (PDT) Message-ID: <2a41acea0704201017n42d4e987l77752ee8f7ca9f1f@mail.gmail.com> Date: Fri, 20 Apr 2007 10:17:49 -0700 From: "Jack Vogel" To: "Sven Willenberger" , freebsd-stable@freebsd.org In-Reply-To: <20070420160431.GA17356@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1176911436.7416.8.camel@lanshark.dmv.com> <1177084316.5457.5.camel@lanshark.dmv.com> <20070420160431.GA17356@icarus.home.lan> Cc: 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 17:17:50 -0000 On 4/20/07, Jeremy Chadwick wrote: > 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). What kind of hardware is this interface? Watchdogs mean TX cleanup isn't happening in a reasonable time, without further data its hard to know what might be going on. Jack