Send 9fans mailing list submissions to
       9fans@9fans.net

To subscribe or unsubscribe via the World Wide Web, visit
       http://mail.9fans.net/listinfo/9fans
or, via email, send a message with subject or body 'help' to
       9fans-request@9fans.net

You can reach the person managing the list at
       9fans-owner@9fans.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of 9fans digest..."


Today's Topics:

  1. Re: A simple experiment (roger peppe)
  2. Re: ctrl radeon: not working for ATI Radeon 9600 Mobility?
     (Venkatesh Srinivas)
  3. Re: A simple experiment (David Leimbach)
  4. Re: A simple experiment (Eric Van Hensbergen)
  5. Re: A simple experiment (erik quanstrom)
  6. Re: A simple experiment (David Leimbach)
  7. Re: A simple experiment (erik quanstrom)
  8. Re: A simple experiment (erik quanstrom)
  9. Re: A simple experiment (David Leimbach)


----------------------------------------------------------------------

Message: 1
Date: Thu, 29 Apr 2010 13:40:53 +0100
From: roger peppe <rogpeppe@gmail.com>
Subject: Re: [9fans] A simple experiment
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Message-ID:
       <z2gdf49a7371004290540g29060151k700bac13f78f34dc@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

On 28 April 2010 19:42, ron minnich <rminnich@gmail.com> wrote:
> 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.

what happens if the consumer is slow and the Rstream writer
blocks? how do you stop all the other replies on the connection
waiting for the consumer to get on with it?

in fact, how do you stop it deadlocking if the consumer is in
fact waiting for one of those replies?

i suppose this comes down to what the API looks like.
isochronous might be easier, as a slow reader is a bad reader
so you could just throw away some data.



------------------------------

Message: 2
Date: Thu, 29 Apr 2010 08:44:37 -0400
From: Venkatesh Srinivas <me@acm.jhu.edu>
Subject: Re: [9fans] ctrl radeon: not working for ATI Radeon 9600
       Mobility?
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Message-ID:
       <t2jf75780241004290544reb54e94n977f8c5b26c82a38@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

On Thu, Apr 29, 2010 at 7:17 AM, erik quanstrom <quanstro@quanstro.net> wrote:
>> I added two lines of code to /sys/src/cmd/aux/vga/radeon.h; compiled
>> vga and kernel; added line to /lib/vgadb.
>> Now kernel sees the device (and I see it too: cat /dev/vgactl), but
>> attempt to start framebuffer gives blank screen. Pointers are
>> appreciated!
>
> it didn't work for me, either. ?i added a bit of
> code to support the newer "atom bios" but
> ran out of patience and the vesa driver works.

ATOM BIOS should be unnecessary for the R9600; it is an r300-era card.
I've not ever tried with a mobility (is it an m10?) r9600, but the
desktop variant works when its PCI IDs are added... I forget whether I
had to enable r300hack, though, for it...

-- vs



------------------------------

Message: 3
Date: Thu, 29 Apr 2010 05:54:34 -0700
From: David Leimbach <leimy2k@gmail.com>
Subject: Re: [9fans] A simple experiment
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Message-ID:
       <t2j3e1162e61004290554y3a1ea10br5f6ec89cc46ad4c1@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

On Thu, Apr 29, 2010 at 5:40 AM, roger peppe <rogpeppe@gmail.com> wrote:

> On 28 April 2010 19:42, ron minnich <rminnich@gmail.com> wrote:
> > 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.
>
> what happens if the consumer is slow and the Rstream writer
> blocks? how do you stop all the other replies on the connection
> waiting for the consumer to get on with it?
>
> in fact, how do you stop it deadlocking if the consumer is in
> fact waiting for one of those replies?
>
> i suppose this comes down to what the API looks like.
> isochronous might be easier, as a slow reader is a bad reader
> so you could just throw away some data.
>
>
It sounds ok on the surface so far.  Does RStream signal the end of the
stream chunks, or does the TStreamer already know that answer?  Is there any
sort of realtime constraint for handling incoming RStream chunks?   I would
think this could be ok, even if it forces the client to put the streamed
blocks somewhere handy while processing is going on.  Streaming audio and
video over plan 9 links this way might be nice.

But then I start to wonder why we feel we want to compete with HTTP when it
already works, and is still fairly simple.  Nothing wrong with improving 9P
I suppose, but what's so wrong with HTTP transfers that it warrants changing
our beloved resource sharing protocol?  Maybe I'm being too practical, and
not feeling adventurous or something :-)

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.9fans.net/private/9fans/attachments/20100429/04570ac5/attachment-0001.htm>

------------------------------

Message: 4
Date: Thu, 29 Apr 2010 08:19:22 -0500
From: Eric Van Hensbergen <ericvh@gmail.com>
Subject: Re: [9fans] A simple experiment
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Message-ID:
       <j2ta4e6962a1004290619yc038805ds524525e3d535c68@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Apr 28, 2010 at 3:51 PM, ron minnich <rminnich@gmail.com> wrote:
> On Wed, Apr 28, 2010 at 1:36 PM, Francisco J Ballesteros <nemo@lsub.org> wrote:
>
>> That's similar to a Tget in op with unlimited replies. The difference adds on
>> quickly.
>
> neat, I need to study op more than I did :-)
>

For the record, I kept telling you that.

   -eric



------------------------------

Message: 5
Date: Thu, 29 Apr 2010 10:22:37 -0400
From: erik quanstrom <quanstro@quanstro.net>
Subject: Re: [9fans] A simple experiment
To: 9fans@9fans.net
Message-ID: <43de5c2167c0a4851aeafaa07a0b982d@kw.quanstro.net>
Content-Type: text/plain; charset="US-ASCII"

> what happens if the consumer is slow and the Rstream writer
> blocks? how do you stop all the other replies on the connection
> waiting for the consumer to get on with it?

the tcp window closes. and the producer blocks.

> in fact, how do you stop it deadlocking if the consumer is in
> fact waiting for one of those replies?

i don't think i understand this.

i think Tstream would be very dependant on the
transport layer.  that's the part that makes me nervous.
all the world's a tcp?

- erik



------------------------------

Message: 6
Date: Thu, 29 Apr 2010 07:36:21 -0700
From: David Leimbach <leimy2k@gmail.com>
Subject: Re: [9fans] A simple experiment
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Message-ID:
       <m2v3e1162e61004290736vf921c63am5c3bc0d00fb5eb54@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

On Thu, Apr 29, 2010 at 7:22 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> > what happens if the consumer is slow and the Rstream writer
> > blocks? how do you stop all the other replies on the connection
> > waiting for the consumer to get on with it?
>
> the tcp window closes. and the producer blocks.
>
> > in fact, how do you stop it deadlocking if the consumer is in
> > fact waiting for one of those replies?
>
> i don't think i understand this.
>
> i think Tstream would be very dependant on the
> transport layer.  that's the part that makes me nervous.
> all the world's a tcp?
>
>
What does 9P require to function?  If TStream has the same or lesser
requirements, then there's no problem right?  This comes back to my
wondering why we don't just use 9P to set up HTTP streams.


> - erik
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.9fans.net/private/9fans/attachments/20100429/f3db15ab/attachment-0001.htm>

------------------------------

Message: 7
Date: Thu, 29 Apr 2010 10:35:34 -0400
From: erik quanstrom <quanstro@quanstro.net>
Subject: Re: [9fans] A simple experiment
To: 9fans@9fans.net
Message-ID: <40cf59cfc2735e232f0fd67df725e65d@kw.quanstro.net>
Content-Type: text/plain; charset="US-ASCII"

> But then I start to wonder why we feel we want to compete with HTTP when it
> already works, and is still fairly simple.  Nothing wrong with improving 9P
> I suppose, but what's so wrong with HTTP transfers that it warrants changing
> our beloved resource sharing protocol?  Maybe I'm being too practical, and
> not feeling adventurous or something :-)

do we put a http bag on the side of every /n/remoteslowlink
fileserver, since 9p can't take care of it's own business?

- erik



------------------------------

Message: 8
Date: Thu, 29 Apr 2010 10:43:48 -0400
From: erik quanstrom <quanstro@quanstro.net>
Subject: Re: [9fans] A simple experiment
To: 9fans@9fans.net
Message-ID: <816a521c149b06088f5023d3dfddf0ed@kw.quanstro.net>
Content-Type: text/plain; charset="US-ASCII"

> What does 9P require to function?  If TStream has the same or lesser
> requirements, then there's no problem right?  This comes back to my
> wondering why we don't just use 9P to set up HTTP streams.

see /sys/src/doc/il/il.ps
- reliable,
- in order.
(the other three are not hard requirements)

i would think that Tstream has greater requirements.
it would seem to require flow control.

- erik



------------------------------

Message: 9
Date: Thu, 29 Apr 2010 08:03:25 -0700
From: David Leimbach <leimy2k@gmail.com>
Subject: Re: [9fans] A simple experiment
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Message-ID:
       <u2n3e1162e61004290803v6e9f804erc0e7b8ebf33866dc@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

On Thu, Apr 29, 2010 at 7:43 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> > What does 9P require to function?  If TStream has the same or lesser
> > requirements, then there's no problem right?  This comes back to my
> > wondering why we don't just use 9P to set up HTTP streams.
>
> see /sys/src/doc/il/il.ps
> - reliable,
> - in order.
> (the other three are not hard requirements)
>
> i would think that Tstream has greater requirements.
> it would seem to require flow control.
>
> - erik
>
>

9P doesn't require any flow control?  That doesn't seem right :-)  But then
again it doesn't stream, at least in the traditional way I think of
streaming.  To stream you typically need flow control, so 9P isn't good for
streaming in the sense I think of streaming. (yet?)

Fix 9P or don't is the decision to be made.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.9fans.net/private/9fans/attachments/20100429/a57ee49b/attachment.htm>

End of 9fans Digest, Vol 72, Issue 79
*************************************