On Wed, Apr 28, 2010 at 11:00 AM, erik quanstrom <quans...@labs.coraid.com> wrote:
> unless you've got some sort of interrupt or cpu bottleneck, > i don't see what message size has to do with this issue. the > real issue is the # of messages outstanding. Trivially, it always matters: what if msize is 1? There's always a balance between packet size and parallelism in the # ops you send (i.e. outstanding packets in flight) and other factors I forget right now :-) Too big messages cause heartbreak and bad behavior in some networks. Too many messages in flight cause issues at each end. And, in the end, if what you want is a stream, then discrete request/response transactions can be made to work, but they don't always work as well. We did a simple experiment recently: added a new 9p type called Tstream, because this issue of streams vs. transactions has been bugging me for years. The semantics are simple: it's a lot like Tread (almost same packet) but a single Tstream results in any number of Rstreams, until you hit no more data (/dev/mouse) or maybe EOF (/usr/rminnich/movie). Andrey tossed a sample implementation into newsham's 9p library. We saw a 27x improvement in performance from calgary to sandia for a big file. Fcp did not come close. There's work to be done; 9p is great, but it's not the end of protocols. ron
