From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <5d375e920904200758m1a1a96den579673e107b57b19@mail.gmail.com> <7c22175ab60f8a5ae2cf894d462b29e5@9netics.com> <3e1162e60904201118u18e8846bkbfec62e561a15a91@mail.gmail.com> <3e1162e60904201155l2b29c0b7ge248c36f82f7324@mail.gmail.com> <3e1162e60904201317v4d50be85x4597a1a6a3123959@mail.gmail.com> Date: Mon, 20 Apr 2009 14:18:11 -0700 Message-ID: <3e1162e60904201418g54ba56f4pbf8fc31bf95a9d81@mail.gmail.com> From: David Leimbach To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=00151750e7f0561e22046803118d Subject: Re: [9fans] Plan9 - the next 20 years Topicbox-Message-UUID: ebf36290-ead4-11e9-9d60-3106f5b1d025 --00151750e7f0561e22046803118d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Mon, Apr 20, 2009 at 1:33 PM, erik quanstrom wrote: > > > not that i can think of. but that addresses throughput, but not > latency. > > > > > > Right, but with better throughput overall, you can "hide" latency in some > > applications. That's what HTTP does with this AJAX fun right? > > > > Show some of the page, load the rest over time, and people "feel better > > about stuff". > > > > I had an application for SNMP in Erlang that did too much serially, and > by > > increasing the number of outstanding requests, I got the overall job done > > sooner, despite the latency issues. This improved the user experience by > > about 10 seconds less wait time. Tagged requests was actually how I > > implemented it :-) > > > > 9p can't fix the latency problems, but applications over 9p can be > designed > > to try to hide some of it, depending on usage. > > 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. > Yeah, I guess due to my lack of having written a 9p client by hand, I've forgotten that a new 9p client session is stateful, and at the root of the hierarchy presented by the server. No choice but to walk, even if you know the path to the named resource in advance. This seems to give techniques like REST a bit of an advantage over 9p. (yikes) Would we want a less stateful 9p then? Does that end up being HTTP or IMAP or some other thing that already exists? Dave > - erik > > --00151750e7f0561e22046803118d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Apr 20, 2009 at 1:33 PM, erik qu= anstrom <quanst= ro@coraid.com> wrote:
> > not that i can think of. =A0but that addresses = throughput, but not latency.
>
>
> Right, but with better throughput overall, you can "hide" la= tency in some
> applications. =A0That's what HTTP does with this AJAX fun right? >
> Show some of the page, load the rest over time, and people "feel = better
> about stuff".
>
> I had an application for SNMP in Erlang that did too much serially, an= d by
> increasing the number of outstanding requests, I got the overall job d= one
> sooner, despite the latency issues. =A0This improved the user experien= ce by
> about 10 seconds less wait time. =A0Tagged requests was actually how I=
> implemented it :-)
>
> 9p can't fix the latency problems, but applications over 9p can be= designed
> to try to hide some of it, depending on usage.

let's take the path /sys/src/9/pc/sdata.c. =A0for http, getting this path takes one request (with the prefix http://$server)
with 9p, this takes a number of walks, an open. =A0then you
can start with the reads. =A0only 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.
=
Yeah, I guess due to my lack of having written a 9p client b= y hand, I've forgotten that a new 9p client session is stateful, and at= the root of the hierarchy presented by the server. =A0No choice but to wal= k, even if you know the path to the named resource in advance.

This seems to give techniques like REST a bit of an adv= antage over 9p. =A0(yikes)

Would we want a less st= ateful 9p then? =A0Does that end up being HTTP or IMAP or some other thing = that already exists?

Dave


- erik


--00151750e7f0561e22046803118d--