From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <03110ba85f92f462a8702413ac1c0a5a@gmail.com> Date: Tue, 20 Nov 2007 17:04:47 -0500 From: anyrhine@gmail.com To: 9fans@cse.psu.edu Subject: Re: [9fans] sources/contrib In-Reply-To: <333c3d5c4dfff180853969bcfdf2b867@coraid.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-zmxlpgsfssjbuhlfyqcwztogso" Topicbox-Message-UUID: 049d85f2-ead3-11e9-9d60-3106f5b1d025 This is a multi-part message in MIME format. --upas-zmxlpgsfssjbuhlfyqcwztogso Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit the latency problem does not show up before you have actual propagation delay. if you're next door with a 34k modem, all your latency is bare transmission time (time spent stuffing bits along the wire), and you are prefectly happy because your link gets full utilization. now, if you are physically 200ms away and have a the fastest link on the planet, you might be less than happy using 1 second [Twalk Topen, Tread, Tread, Tclunk] to read a file of any size, because your fast and fancy link isn't used, so you're paying for nothing. the problem really does exist, but there are bigger ones that are easier to solve. --upas-zmxlpgsfssjbuhlfyqcwztogso Content-Type: message/rfc822 Content-Disposition: inline Delivered-To: anyrhine@gmail.com Received: by 10.115.58.20 with SMTP id l20cs632189wak; Tue, 20 Nov 2007 13:50:30 -0800 (PST) Received: by 10.150.54.6 with SMTP id c6mr1012856yba.1195595430118; Tue, 20 Nov 2007 13:50:30 -0800 (PST) Return-Path: <9fans-bounces+anyrhine=gmail.com@cse.psu.edu> Received: from mail.cse.psu.edu (psuvax1.cse.psu.edu [130.203.4.6]) by mx.google.com with ESMTP id m5si8020383roe.2007.11.20.13.50.29; Tue, 20 Nov 2007 13:50:30 -0800 (PST) Received-SPF: pass (google.com: domain of 9fans-bounces+anyrhine=gmail.com@cse.psu.edu designates 130.203.4.6 as permitted sender) client-ip=130.203.4.6; Authentication-Results: mx.google.com; spf=pass (google.com: domain of 9fans-bounces+anyrhine=gmail.com@cse.psu.edu designates 130.203.4.6 as permitted sender) smtp.mail=9fans-bounces+anyrhine=gmail.com@cse.psu.edu Received: from psuvax1.cse.psu.edu (localhost [127.0.0.1]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 31AF2C6D66 for ; Tue, 20 Nov 2007 16:50:29 -0500 (EST) X-Original-To: 9fans@cse.psu.edu Delivered-To: 9fans@cse.psu.edu Received: from localhost (localhost [127.0.0.1]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id DE8AC6356F for <9fans@cse.psu.edu>; Tue, 20 Nov 2007 16:50:08 -0500 (EST) Received: from mail.cse.psu.edu ([127.0.0.1]) by localhost (psuvax1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21309-01-27 for <9fans@cse.psu.edu>; Tue, 20 Nov 2007 16:50:06 -0500 (EST) Received: from coraid.com (unknown [65.14.39.133]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 635A16351E for <9fans@cse.psu.edu>; Tue, 20 Nov 2007 16:50:06 -0500 (EST) Message-ID: <333c3d5c4dfff180853969bcfdf2b867@coraid.com> From: erik quanstrom Date: Tue, 20 Nov 2007 16:46:22 -0500 To: 9fans@cse.psu.edu Subject: Re: [9fans] sources/contrib In-Reply-To: <5d375e920711201336t6eaeba6fi35151042bd22194c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 9fans-bounces+anyrhine=gmail.com@cse.psu.edu Errors-To: 9fans-bounces+anyrhine=gmail.com@cse.psu.edu > Read 9fans archives, replica/pull has wiped out more than a handful of systems, > if you run venti you can recover, but it is not fun. i think a few well-choosen hurestics could solve most of these cases. > And as erik points out, replica also has trouble with many corner cases. > > And finally, it is incredibly slow, but that is probably mostly due to > 9p's latency sensitivity. i just don't see the latency problem. even when i was using a 34k modem, updates were pretty quick, i have seen the case where applychanges was very slow. but using cphist instead solved the problem. i can't explain why applychanges can be very slow for me. - erik --upas-zmxlpgsfssjbuhlfyqcwztogso--