On Mon, 20 Apr 2009 16:33:41 EDT erik quanstrom <quans...@coraid.com> wrote: > let's take the path /sys/src/9/pc/sdata.c. for http, getting > this path takes one request (with the prefix http://$server) > with 9p, this takes a number of walks, an open. then you > can start with the reads. only the reads may be done in > parallel. > > given network latency worth worring about, the total latency > to read this file will be worse for 9p than for http.
Perhaps one can optimize for the common case by extending 9p a bit: use special values for certain parameters to allow sending consecutive Twalk, (Topen|Tcreate), (Tread|Twrite) without waiting for intermeditate R messages. This makes sense since the time to prepare /process a handful of messages is much shorter than roundtrip latency. A different performance problem arises when lots of data has to be fetched. You can pipeline data requests by having multiple outstanding requests. A further refinement would to use something like RDMA -- in essence the receiver tells the sender where exactly it wants the data delivered (thus minimizing copying & processing). You can very easily extend the model to have data chunks delivered to different machines in a cluster. This is like separating a very high speed "data plane" (with little or no processing) from a low speed "control plane" (with lots of processing) in a modern switch/router.
