From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <4fa1305e0f56a0ef89c2e05320fa5997@coraid.com> References: <5fa9fbfe115a9cd5a81d0feefe413192@quintile.net> <4fa1305e0f56a0ef89c2e05320fa5997@coraid.com> Date: Wed, 28 Apr 2010 11:42:03 -0700 Message-ID: From: ron minnich 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] A simple experiment Topicbox-Message-UUID: 11a0b622-ead6-11e9-9d60-3106f5b1d025 On Wed, Apr 28, 2010 at 11:00 AM, erik quanstrom 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. =A0the > 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