From owner-freebsd-current@FreeBSD.ORG Mon Jan 26 21:49:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C62616AAAA; Mon, 26 Jan 2004 21:49:11 -0800 (PST) Received: from mail.seekingfire.com (coyote.seekingfire.com [24.72.10.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id A720144A2A; Mon, 26 Jan 2004 20:52:09 -0800 (PST) (envelope-from tillman@seekingfire.com) Received: by mail.seekingfire.com (Postfix, from userid 500) id CE5EF63; Mon, 26 Jan 2004 22:52:08 -0600 (CST) Date: Mon, 26 Jan 2004 22:52:08 -0600 From: Tillman Hodgson To: current@freebsd.org Message-ID: <20040127045208.GC83558@seekingfire.com> References: <003c01c3de8d$d569edb0$471b3dd4@dual> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . X-GPG-Key-ID: 828AFC7B X-GPG-Fingerprint: 5584 14BA C9EB 1524 0E68 F543 0F0A 7FBC 828A FC7B X-GPG-Key: http://www.seekingfire.com/gpg_key.asc X-Urban-Legend: There is lots of hidden information in headers User-Agent: Mutt/1.5.5.1i cc: performance@freebsd.org Subject: Re: Old SUN NFS performance papers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2004 05:49:13 -0000 On Sat, Jan 24, 2004 at 09:14:51PM -0500, Robert Watson wrote: > I haven't done much benchmarking on NFS lately, but something worth > remembering is that people have spent a lot of time researching and > optimizing TCP for a variety of connection types, whereas the NFS code > basically has a static implementation of RPC backoff and flow control that > hasn't evolved much. TCP is aware of things like the pathwise-mtu to the > server and adapts, whereas UDP just loses packets due to fragmentation, > especially if you are using larger block sizes. Please do post your > discoveries on performance@, and perhaps we could build an NFS performance > tuning section in the FreeBSD Handbook (or if there's not that much > content, add it to the FAQ)? I once spent a great deal of time with bonnie++, gnuplot and LaTeX generating a nice 10-page or so document on NFS tuning between various systems (the server was always a FreeBSD 4-STABLE box of the 4.7 vintage with several vinum mirrors of various speeds). Naturally, I then lost the document when my home drive disintegated a few months later. i was /just/ in the process of moving my home dir to the file server where it would have multiple levels of backup ... Anyway, I'd be willing to do some more testing and writes up the results for the Handbook (when I get back from a much-needed vacation) if I could obtain several collaborators with a variety of hardware (NFS testing takes /much/ time to cover all the variants and hardware possibilities) and a good idea from someone (such as yourself) on what sort of testing would be seen as valuable. For instance, my primary concern is remote Maildir speed and backup up several servers onto a backup host (where it can spooled out to tape via some scripts). So my access patterns are fairly specific, and likely not typical. Guidance on what a typical NFS user looks like would be precious knowledge ;-) -T -- Page 38: Be sure that, in the excitement of creating a totally rad password, you resist the temptation to tell someone just to show off how smart you are. - Harley Hahn, _The Unix Companion_