From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <775b8d190706232116u43d53d7bl71d0267a1b246be3@mail.gmail.com> Date: Sun, 24 Jun 2007 14:16:32 +1000 From: "Bruce Ellis" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] 9P optimization In-Reply-To: <20070623200857.H1471@orthanc.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070623043028.A0A7C1E8C51@holo.morphisms.net> <20070623174825.A31325@orthanc.ca> <8ccc8ba40706232004t38102644r7d5dd145ee15d026@mail.gmail.com> <20070623200857.H1471@orthanc.ca> Topicbox-Message-UUID: 865fbe26-ead2-11e9-9d60-3106f5b1d025 rangbooming has lead to extreme optimiazations. i'll let skip comment on it (he's asleep i guess). but i couldn't have much worse RTT (sydney-seattle), and the traffic seems a lot lower now, and the latency has improved extraordinarily. brucee On 6/24/07, Lyndon Nerenberg wrote: > > The problem with cfs is that you still suffer the RPC to check for validity. > > With 100ms of RTT, count 5 and you have a second. Also, for synthesized > > files, > > the cache does not save you from doing a walk, open, read. > > I'll be accused of being a heretic, but let me claim that much of the > design of IMAP is geared towards avoiding those RTTs for that very reason. > A good IMAP client wins by doing intelligent cacheing, and it gets there > by using the subtle aspects of the protocol that accomodate that. > > Much as people slag the protocol, it does work well over slow (high > latency) links, given a client that understands the protocol (sadly, most > don't). > > I'm very curious about the efficiency of cfs, but my P9 environment > doesn't have a remote terminal. It would be interesting to instrument cfs > and collect some stats on the protocol behaviour behind the cache ... > > --lyndon >