From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <20110218222141.B390D5B44@mail.bitblocks.com> References: <201102181445.41877.dexen.devries@gmail.com> <201102181753.30125.dexen.devries@gmail.com> <7769a67a9fbc1fae2186ff9315457e0d@ladd.quanstro.net> <20110218194658.8BEA75B77@mail.bitblocks.com> <20110218222141.B390D5B44@mail.bitblocks.com> Date: Sat, 19 Feb 2011 08:57:16 -0800 Message-ID: From: Skip Tavakkolian To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: b1b995ac-ead6-11e9-9d60-3106f5b1d025 it seems to me that trying Op (Octopus) on Plan 9 would be a logical first = step. On Fri, Feb 18, 2011 at 2:21 PM, Bakul Shah wro= te: > On Fri, 18 Feb 2011 13:06:43 PST John Floren =A0wrote: >> On Fri, Feb 18, 2011 at 12:15 PM, erik quanstrom = wr=3D >> ote: >> >> > i don't think that it makes sense to say that since replica >> >> > is slow and hg/rsync are fast, it follows that 9p is slow. >> >> >> >> It is the other way around. 9p can't handle latency so on >> >> high latency pipes programs using 9p won't be as fast as >> >> programs using streaming (instead of rpc). Granted that there >> >> are many other factors when it comes to hg & replica but >> >> latency is a major one. >> > >> > you're still comparing apples and girraffes. =3DA0rsync/hg have >> > protocols ment for syncing. =3DA0replica uses 9p, which is not a >> > protocol designed for syncing. =3DA0it's designed for regular file >> > access. =3DA0it would be similarly difficult to use rsync's protocol >> > directly for file access. >> >> So why does replica use 9P? Because it's *The Plan 9 Protocol*. If >> *The Plan 9 Protocol* turns out to not serve our needs, we need to >> figure out why. > > The point I was trying to make (but clearly not clearly) was > that simplicity and performance are often at cross purposes > and a simple solution is not always "good enough". =A0RPC > (which is what 9p is) is simpler and perfectly fine when > latencies are small but not when there is a lot of latency in > relation to the amount of work doable with each rpc call. > > Instead of reading/writing in small chunks, you want to > minimize the number of request/response round trips by > conveying information at a more abstract level (which is > what rsync does). > >> 9P as specified in the documentation might not necessarily be the >> problem, but the implementation apparently is. > > It is inherent to 9p (and RPC). > > The wikipedia page on plan9 says "Plan 9 was engineered for > modern distributed environments, designed from the start to > be a networked operating system." -- but it _is_ curious that > a networked/distributed OS does not handle latency well. This > may be a heretical thing to say but there it is :-) > > I think it is worth looking at a successor protocol instead > of just minimally fixing up 9p (a clean slate approach frees > up your mind. =A0You can then merge the two later). > >