From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Sat, 19 Feb 2011 10:09:08 EST." <0ae086afeb91d54fac0fc361d993f5a0@ladd.quanstro.net> References: <201102181445.41877.dexen.devries@gmail.com> <201102181753.30125.dexen.devries@gmail.com> <7769a67a9fbc1fae2186ff9315457e0d@ladd.quanstro.net> <20110218222141.B390D5B44@mail.bitblocks.com> <0ae086afeb91d54fac0fc361d993f5a0@ladd.quanstro.net> From: Bakul Shah Date: Sat, 19 Feb 2011 12:09:01 -0800 Message-Id: <20110219200901.575D75B63@mail.bitblocks.com> Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: b1d0798e-ead6-11e9-9d60-3106f5b1d025 On Sat, 19 Feb 2011 10:09:08 EST erik quanstrom wrote: > > It is inherent to 9p (and RPC). > > please defend this. i don't see any evidence for this bald claim. We went over latency issues multiple times in the past but let us take your 80ms latency. You can get 12.5 rpc calls through in 1 sec even if you take 0 seconds to generate & process each request & response. If each call transfers 64K, at most you get a throughput of 800KB/sec. If you pipeline your requests, without waiting for each reply, you are using streaming. To avoid `streaming' you can setup N parallel connections but that is again adding a lot of complexity to a relatively simple problem. > > 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? Better handling of latency at a minimum? If I were to do this I would experiment with extending the channel concept. > 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. No. I just use Ron's hg repo now. > 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. For things like remote copy of a whole bunch of files caching is not going to help you much but streaming will. So will increasing parllelism (upto a point). Compression might.