From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Sat, 19 Feb 2011 10:09:08 -0500 To: 9fans@9fans.net Message-ID: <0ae086afeb91d54fac0fc361d993f5a0@ladd.quanstro.net> 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> <20110218222141.B390D5B44@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: b1adad6e-ead6-11e9-9d60-3106f5b1d025 > 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". RPC > (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. this is a pretty general claim. but i don't see the argument. the difference between, e.g. tcp and an explicitly rpc protocol like 9p is basically 2 relevant things 1. 9p requires 1:1 message and reply; tcp can combine replies 2. 9p sends a set of tagged messages; tcp sends an ordered byte stream. i don't see how either one is necessarly going to slow 9p down. the structure of 9p (tagged rpc) is the same for reads & writes as aoe. aoe is always talking over a long fat network with large jitter, as disk drives are slow and sometimes misseek but have relatively large bandwidth. i've had no trouble filling even 10gbe pipes with aoe traffic. > 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). that's not what rsync does. rsync calculates and sends the differences. that's not on the same planet as 9p. by the way, rsync is fundamentally broken. it takes unbounded memory to do its job. > It is inherent to 9p (and RPC). please defend this. i don't see any evidence for this bald claim. > 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. You can then merge the two later). what is the goal? without a clear problem to solve that you can build a system around, i don't see the point. making replica fast doesn't seem like sufficient motivation to me at all. as to the problem of latency, i think there are two things i note 1. plan 9 can work well with latency. most days i do some link that has 25-2000ms latency. the way plan 9 is structured, this latency is not very noticable until it reaches ~750ms, and then only when i'm saving files, or sometimes, due to an oversite or bug in acme, when searching. clearly a kernel mk over a 2000ms link will take nearly forever, but you don't have to do that. you can cpu where you need to be and work there. 2. at cross-u.s. latencies of 80ms, serial file operations like mk can be painful. if bringing the work to the data doesn't work or still takes too many rtts, the only solution i see is to cache everything. and try to manage coherence vs. latency. - erik