On Apr 26, 4:23 pm, quans...@quanstro.net (erik quanstrom) wrote:
/sys/src/cmd/aux/vga/radeon.c uses radeon_pciids in radeon.h.
it ignores the vids and dids in /lib/vgadb. this is probablly a
mistake.
- erik
I added two lines of code to /sys/src/cmd/aux/vga/radeon.h; compiled
vga and
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
On 28 April 2010 19:42, ron minnich rminn...@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
On Thu, Apr 29, 2010 at 7:17 AM, erik quanstrom quans...@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
On Thu, Apr 29, 2010 at 5:40 AM, roger peppe rogpe...@gmail.com wrote:
On 28 April 2010 19:42, ron minnich rminn...@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
On Wed, Apr 28, 2010 at 3:51 PM, ron minnich rminn...@gmail.com wrote:
On Wed, Apr 28, 2010 at 1:36 PM, Francisco J Ballesteros n...@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
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
On Thu, Apr 29, 2010 at 7:22 AM, erik quanstrom quans...@quanstro.netwrote:
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
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
On Thu, Apr 29, 2010 at 7:43 AM, erik quanstrom quans...@quanstro.netwrote:
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
On Thu, Apr 29, 2010 at 7:35 AM, erik quanstrom quans...@quanstro.netwrote:
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
Hello
how well it works with firewalls, address translation, deep inspection, etc.?
never tried il outside home. . .
gabi
- Original Message
From: erik quanstrom quans...@quanstro.net
To: 9fans@9fans.net
Sent: Thu, April 29, 2010 4:43:48 PM
Subject: Re: [9fans] A simple experiment
On Thu, Apr 29, 2010 at 8:03 AM, David Leimbach leim...@gmail.com wrote:
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
On Thu, Apr 29, 2010 at 5:40 AM, roger peppe rogpe...@gmail.com 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?
there are not replies -- the rstream is a reply. If
On Thu, Apr 29, 2010 at 8:06 AM, David Leimbach leim...@gmail.com wrote:
I'm totally undecided on this, but just asking the question to make sure
everyone feels good about adding streaming to 9P, which seems to indicate a
need to add flow control as well.
the problem of multiplexing several
On Thu, Apr 29, 2010 at 10:16 AM, ron minnich rminn...@gmail.com wrote:
On Thu, Apr 29, 2010 at 8:03 AM, David Leimbach leim...@gmail.com wrote:
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
Wasn't IL somewhat abandoned because to make it as good as TCP you
basically had to implement TCP anyway?
due to a failure of vision, the internet only does
well with certain types of ip packets.
il is still an excellent protocol for local networks.
9P doesn't require any flow control?
On Thu, Apr 29, 2010 at 8:34 AM, erik quanstrom quans...@quanstro.netwrote:
Wasn't IL somewhat abandoned because to make it as good as TCP you
basically had to implement TCP anyway?
due to a failure of vision, the internet only does
well with certain types of ip packets.
il is still an
9p, like aoe, is a ping-pong protocol. each message requires an ack.
therefore, the transport layer doesn't need flow control.
Right, but when you have one T message for many R messages, doesn't that
change things a bit?
yes. if you were to add that, then a flow-controlled transport
On Thu, 29 Apr 2010 11:34:44 EDT erik quanstrom quans...@quanstro.net wrote:
Wasn't IL somewhat abandoned because to make it as good as TCP you
basically had to implement TCP anyway?
due to a failure of vision, the internet only does
well with certain types of ip packets.
:-)
il is
On Thu, Apr 29, 2010 at 10:08 AM, Bakul Shah bakul+pl...@bitblocks.com wrote:
Short of a sliding window that is as large as the capacity of
the pipe, you can't expect to keep it full. As usual one has
to trade off simplicity vs performance.
I do hope 9p evolves.
The problem revealed by
9p, like aoe, is a ping-pong protocol. each message requires an ack.
therefore, the transport layer doesn't need flow control.
Therefore, it is also not able to utilise bandwidth
effectively over longhaul links. As an example, US coast
to coast round trip time latency is about 100ms. Now
Oh, and, it is likely that when we issue that many or more reads, we
want a flow controlled network. Just guessing :-)
the downside of course is that the set of suitable protocols
is then greatly reduced. tftp, rudp, il, cec to name a few simple
protocols (yes i've done 9p over cec) would then
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
On Thu, Apr 29, 2010 at 10:48 AM, Tim Newsham news...@lava.net wrote:
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
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
i think in almost all cases putting Op between 9P endpoints will
solve the slowness problem of high rtt networks.
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
Hmmm is Op the same Op from Octopus?
Just making sure.
Dave
On Thu, Apr 29, 2010 at 11:41 AM, Skip Tavakkolian 9...@9netics.com wrote:
i think in almost all cases putting Op between 9P endpoints will
solve the slowness problem of high rtt networks.
But then I start to wonder why we feel
due to a failure of vision, the internet only does
well with certain types of ip packets.
Well now *there* is a sweeping statement about the state of the universe
circa 1980. Care to elaborate a teensy bit?
On Thu Apr 29 14:53:56 EDT 2010, lyn...@orthanc.ca wrote:
due to a failure of vision, the internet only does
well with certain types of ip packets.
Well now *there* is a sweeping statement about the state of the universe
circa 1980. Care to elaborate a teensy bit?
if you pick a random
ladd; time fcp /n/c/n/other/quanstro/plan9.tar.bz2 /dev/null
0.00u 0.06s 105620.50r fcp /n/c/n/other/quanstro/plan9.tar.bz2 /dev/null #
status= interrupt
- erik
But then I start to wonder why we feel we want to compete with HTTP when it
already works, and is still fairly simple.
http is by no means simple, although yes, it could be still more complicated.
due to a failure of vision, the internet only does
well with certain types of ip packets.
Well now *there* is a sweeping statement about the state of the universe
circa 1980. Care to elaborate a teensy bit?
i think the point is IL v. TCP; this is dejavu all over again:
Hmmm is Op the same Op from Octopus?
yes. nemo has put the op specific stuff here:
/n/sources/contrib/nemo/octopus/op.src.tgz
fyi:
from rangboom.com network (colo at a ISP):
cpu% telnet il!minooka.coraid.com!4000
connected to il!minooka.coraid.com!4000 on /net/il/3
from 9netics.com (centurytel DSL): still waiting :)
On Thu Apr 29 14:53:56 EDT 2010, lyn...@orthanc.ca wrote:
due to a failure of
On Thu Apr 29 15:55:44 EDT 2010, 9...@9netics.com wrote:
fyi:
from rangboom.com network (colo at a ISP):
cpu% telnet il!minooka.coraid.com!4000
connected to il!minooka.coraid.com!4000 on /net/il/3
from 9netics.com (centurytel DSL): still waiting :)
interesting. i was able to
On Thu Apr 29 15:55:44 EDT 2010, 9...@9netics.com wrote:
fyi:
from rangboom.com network (colo at a ISP):
cpu% telnet il!minooka.coraid.com!4000
connected to il!minooka.coraid.com!4000 on /net/il/3
from 9netics.com (centurytel DSL): still waiting :)
interesting. i was
On Thu, Apr 29, 2010 at 08:06, Gabriel Díaz gd...@rejaa.com wrote:
Hello
how well it works with firewalls, address translation, deep inspection,
etc.? never tried il outside home. . .
It doesn't play well with firewalls, NAT, or deep inspection because
none of the vendors have added support
On Thu, Apr 29, 2010 at 12:44 PM, C H Forsyth fors...@vitanuova.com wrote:
But then I start to wonder why we feel we want to compete with HTTP when
it
already works, and is still fairly simple.
http is by no means simple, although yes, it could be still more
complicated.
I guess I think
There are a few dsl's which require you to use their routers with NAT
and other stuff, but I've never tried these out, I've always had real
IP connections here...
As long as we have enough ipv4 adresses I would say: Build your own
firewall, router or NAT...
On 4/29/10, Christopher Nielsen
It doesn't play well with firewalls, NAT, or deep inspection because
none of the vendors have added support for it. I tried to get Cisco to
add IL support back in 2001, but they politely refused.
oddly, i'm not having trouble going through 5 different nats
over 2 residential and 2 business dsl
On Thu, Apr 29, 2010 at 13:40, erik quanstrom quans...@quanstro.net wrote:
It doesn't play well with firewalls, NAT, or deep inspection because
none of the vendors have added support for it. I tried to get Cisco to
add IL support back in 2001, but they politely refused.
oddly, i'm not having
On Thu, Apr 29, 2010 at 01:32:23PM -0700, Christopher Nielsen wrote:
It doesn't play well with firewalls, NAT, or deep inspection because
none of the vendors have added support for it. I tried to get Cisco to
add IL support back in 2001, but they politely refused.
Add support to what? Also
I agree that NAT and stateful firewalls (e.g. 'ip inspect' in IOS)
would need explicit support to understand the packet layout.
what il services would you apply spi to? one doesn't
ftp or http over il.
NAT - it should simply die, until then
run IL over IPv6 and avoid NAT?
il isn't defined
ron said:
Oh, and, it is likely that when we issue that many or more reads, we
want a flow controlled network. Just guessing :-)
You'd want one, sure. But (unless I'm missing something) it doesn't
seem that increasing the number of outstanding messages would
*require* it (your
On Thu, 29 Apr 2010 13:23:00 EDT erik quanstrom quans...@quanstro.net wrote:
9p, like aoe, is a ping-pong protocol. each message requires an ack.
therefore, the transport layer doesn't need flow control.
Therefore, it is also not able to utilise bandwidth
effectively over longhaul
My impression is that it was pulled from mainline mostly because it
was seen as being too much work to maintain for a small group. It's
also not really sensible to talk about as good as without defining
your context. Over fast, local networks, IL is faster than TCP. It's
not as
If the sender-receiver pipe can hold N bytes and the sender
is streaming (that is, keeping the pipe full), the sender
*will* be ahead of the receiver by N bytes. So a *streaming*
protcol has to allow it to be N bytes ahead.
i don't think this is the normal definition.
Even if you have one
48 matches
Mail list logo
