I had interest in being able to see plan 9 source at bitbucket.org.
Part of the driver was my continuing inability to get replica to work
well at home, and part just a need to tinker :-)
So, I created an empty repo at bitbucket.org,
http://bitbucket.org/rminnich/sysfromiso/overview
and then did t
Nice work, but couldn't you just bind /n/sources/plan9/sys/src
to the hg repo and push from there?
> More importantly, it's going to be easier for me to bisect and find
> problems when I build from kernel source, which is very handy in my
> case. The web interface of bitbucket gives me a pretty reasonable way
> to compare different revs. I'm offering this note in the event others
> want to use t
On Tue, Apr 27, 2010 at 1:54 PM, wrote:
> Nice work, but couldn't you just bind /n/sources/plan9/sys/src
> to the hg repo and push from there?
>
That would almost certainly be slower than grabbing the ISO via HTTP
and getting the file tree locally.
John
FWIW, I pull -n first, then see what´s going to change, then
merge what I care about, then pull without -n, adding -s´s and -c´s as
a result of which file I merged, and I´m done.
Regarding pulls from sources I´ve found no problem so far (other than speed).
Indeed, speed is not a problem here becau
On Tue Apr 27 13:58:39 EDT 2010, slawmas...@gmail.com wrote:
> On Tue, Apr 27, 2010 at 1:54 PM, wrote:
> > Nice work, but couldn't you just bind /n/sources/plan9/sys/src
> > to the hg repo and push from there?
> >
>
> That would almost certainly be slower than grabbing the ISO via HTTP
> and get
On Tue, Apr 27, 2010 at 1:59 PM, erik quanstrom wrote:
> On Tue Apr 27 13:58:39 EDT 2010, slawmas...@gmail.com wrote:
>> On Tue, Apr 27, 2010 at 1:54 PM, wrote:
>> > Nice work, but couldn't you just bind /n/sources/plan9/sys/src
>> > to the hg repo and push from there?
>> >
>>
>> That would almo
On Tue, Apr 27, 2010 at 2:35 PM, John Floren wrote:
> On Tue, Apr 27, 2010 at 1:59 PM, erik quanstrom wrote:
>> On Tue Apr 27 13:58:39 EDT 2010, slawmas...@gmail.com wrote:
>>> On Tue, Apr 27, 2010 at 1:54 PM, wrote:
>>> > Nice work, but couldn't you just bind /n/sources/plan9/sys/src
>>> > to
> My experiments have shown that copying a large file via HTTP is
> significantly faster than copying the same file via 9P.
were you using fcp?
i'm curious as to where the differences could come from, since the
usual suspects that can make the difference (establishing a
connection, sequential re
looks like you got it going
fetching http://plan9.bell-labs.com/sources/extra/plan9.tar.bz2
would improve your dowload speed as it only contains the
source
On Tue, Apr 27, 2010 at 2:38 PM, ron minnich wrote:
> I had interest in being able to see plan 9 source at bitbucket.org.
> Part of the driv
"Federico G. Benavento" said:
> looks like you got it going
>
> fetching http://plan9.bell-labs.com/sources/extra/plan9.tar.bz2
> would improve your dowload speed as it only contains the
> source
>
> On Tue, Apr 27, 2010 at 2:38 PM, ron minnich wrote:
> > I had interest in being able to see pl
On Tue, Apr 27, 2010 at 10:49 AM, erik quanstrom wrote:
> is plan 9 really that complicated that bisect is a useful tool?
> perhaps i'm still in the dark ages, but i've done fine with
> diff(1) and history(1).
Not good enough for me.
>
> perhaps the key difference is that i sync with sources by
On Tue, Apr 27, 2010 at 10:59 AM, erik quanstrom wrote:
> it would be interesting to try. if hg can push in parallel, it
> could be competitive. fetching the iso, decompressing the iso,
> etc are not free. and you can't push anything until after step
> 2. talk about killer latency.
pulling a
On Tue, Apr 27, 2010 at 12:03 PM, Skip Tavakkolian <9...@9netics.com> wrote:
>> My experiments have shown that copying a large file via HTTP is
>> significantly faster than copying the same file via 9P.
>
> were you using fcp?
>
> i'm curious as to where the differences could come from, since the
>
> > is plan 9 really that complicated that bisect is a useful tool?
> > perhaps i'm still in the dark ages, but i've done fine with
> > diff(1) and history(1).
>
> Not good enough for me.
why?
- erik
Ok, I admit its a trivial experiment but:
> fcp is still a 9p conversation. http get is a tcp stream. Fcp is
> better than cp but not that much better.
> If you're yanking one file, a TCP stream is pretty ideal. Dropping 9p
> on top of it, even when the 9p involves multiple TREADs
> in flight, is
On 28 Apr 2010, at 12:51, Steve Simon wrote:
Ok, I admit its a trivial experiment but:
fcp is still a 9p conversation. http get is a tcp stream. Fcp is
better than cp but not that much better.
If you're yanking one file, a TCP stream is pretty ideal. Dropping 9p
on top of it, even when the
> larch% time cp /n/sources/extra/plan9.tar.bz2 /dev/null
> 0.02u 0.52s 647.90r cp /n/sources/extra/plan9.tar.bz2 /dev/null
>
> larch% time fcp /n/sources/extra/plan9.tar.bz2 /dev/null
> 0.01u 0.85s 49.69r fcp /n/sources/extra/plan9.tar.bz2 /dev/null
>
> l
> Could round-trip times be adding up? Does 9p do one file at once
> strictly?
i think you mean, does 9p have 1 outstanding message.
it does not. 9p supports having as many outstanding
messages as one wishes. if you do a pread(2), the kernel
will only maintain a single outstanding message for
On 28 Apr 2010, at 14:26, erik quanstrom wrote:
Could round-trip times be adding up? Does 9p do one file at once
strictly?
i think you mean, does 9p have 1 outstanding message.
it does not. 9p supports having as many outstanding
messages as one wishes. if you do a pread(2), the kernel
will
> Yeah, if I understand right that is what I meant. Good to know, but
> I'm back to the drawing board on why 9p is sometimes so very much
> slower than transferring the equivalent files in a tar file over http.
rtt.
> Maybe fcp should be used with a large number of threads? :s
the only limit
when timing http it's also a good idea to check that your
isp hasn't got the item cached. admittedly, that in itself
is a further potential advantage to http, because http
caches abound, whereas 9p-based caches are few and far between.
I admit I am surprised by how much a difference there is, it should
be just Tread and Rread headers shouldn't it?
If you have high latency or high bandwidth, the maximum message
size for the 9p messages will be too small to keep the pipe full
if you're using read serially. Did you take a look at
My apologies, I didn't notice you had used fcp as well. Oops.
On Wed, 28 Apr 2010, Tim Newsham wrote:
I admit I am surprised by how much a difference there is, it should
be just Tread and Rread headers shouldn't it?
If you have high latency or high bandwidth, the maximum message
size for the
On Wed Apr 28 13:58:40 EDT 2010, news...@lava.net wrote:
> > I admit I am surprised by how much a difference there is, it should
> > be just Tread and Rread headers shouldn't it?
>
> If you have high latency or high bandwidth, the maximum message
> size for the 9p messages will be too small to kee
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. the
> real issue is the # of messages outstanding.
Trivially, it always matters: what if msize is 1?
There's always a
> 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.
streams are an illusion of the transport layer.
- erik
On Wed, Apr 28, 2010 at 12:06 PM, erik quanstrom
wrote:
>> 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.
>
> streams are an illusion of the transport layer.
packets, bytes, and bits are ill
> 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
On Wed, Apr 28, 2010 at 1:36 PM, Francisco J Ballesteros 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 :-)
ron
Francisco J Ballesteros said:
> > 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
On Wed, Apr 28, 2010 at 2:05 PM, EBo wrote:
> cool. Is Tstream integrated back into 9p and publicly available?
no, it's an experiment at this point. there are other ideas out there,
and I should have paid more attention to op as nemo points out :-)
the main point was to see what was possible,
>> 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 yo
On Wed, Apr 28, 2010 at 11:05 PM, EBo wrote:
> Also, where can i find out more info about op and Tget?
>
http://lsub.org/ls/export/opiwp9.pdf
http://lsub.org/ls/export/opiwp9tlk.pdf
--
- curiosity sKilled the cat
> no, it's an experiment at this point. there are other ideas out there,
> and I should have paid more attention to op as nemo points out :-)
understand. Don't you just HATE it when you come up with something cool and
then find a different alternative stashed in the literature ;-) I look
forwar
yes and no.
Yes in that you can use inferno + op to bridge plan 9 systems.
No in that there's no native implementation yet.
On Wed, Apr 28, 2010 at 11:18 PM, Skip Tavakkolian <9...@9netics.com> wrote:
>>> We did a simple experiment recently: added a new 9p type called
>>> Tstream, because this is
On 28 April 2010 19:42, ron minnich 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 result
On Thu, Apr 29, 2010 at 5:40 AM, roger peppe wrote:
> On 28 April 2010 19:42, ron minnich 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
On Wed, Apr 28, 2010 at 3:51 PM, ron minnich wrote:
> On Wed, Apr 28, 2010 at 1:36 PM, Francisco J Ballesteros
> 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 tellin
> 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 wait
> 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 pr
On Thu, Apr 29, 2010 at 7:22 AM, erik quanstrom 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 fa
> 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 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
> - r
On Thu, Apr 29, 2010 at 7:35 AM, erik quanstrom 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
> chang
Hello
how well it works with firewalls, address translation, "deep inspection", etc.?
never tried il outside home. . .
gabi
- Original Message
From: erik quanstrom
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 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
> streaming in t
On Thu, Apr 29, 2010 at 5:40 AM, roger peppe 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 the consumer is
sl
On Thu, Apr 29, 2010 at 8:06 AM, David Leimbach 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 streams onto one
On Thu, Apr 29, 2010 at 10:16 AM, ron minnich wrote:
> On Thu, Apr 29, 2010 at 8:03 AM, David Leimbach 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 typica
> 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? T
On Thu, Apr 29, 2010 at 8:34 AM, erik quanstrom 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 still an excellent pro
> > 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 transp
On Thu, 29 Apr 2010 11:34:44 EDT erik quanstrom 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 still an excelle
On Thu, Apr 29, 2010 at 10:08 AM, Bakul Shah 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 fcp is worse than th
> > 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 100
> 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 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 practical
On Thu, Apr 29, 2010 at 10:48 AM, Tim Newsham 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
>> changing
>
> >> 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?)
> >> F
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 wh
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
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 ran
>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:
http://group
> 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 vis
>>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.
they'll stop when the spec is massive enough to undergo gravitation
collapse.
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 a
> 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 :)
>
> inter
On Thu, Apr 29, 2010 at 08:06, Gabriel Díaz 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 for it.
On Thu, Apr 29, 2010 at 12:44 PM, C H Forsyth 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 it's simple b
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 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 trouble going through 5 different nats
over 2 residential and 2 business d
On Thu, Apr 29, 2010 at 13:40, erik quanstrom 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 trouble going
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 defi
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 performance
On Thu, 29 Apr 2010 13:23:00 EDT erik quanstrom 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 links. As a
> 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
>I agree that NAT and stateful firewalls (e.g. 'ip inspect' in IOS)
>would need explicit support to understand the packet layout.
it's a pity that the protocol revisions didn't move the port-addressing
function outside individual protocols.
> erik said:
>
>> why is using nat to make many hosts look like one a bad thing?
>
> I suspect the reaction is based on being forced to use it when you'd
> rather not, like many residential ISPs require. It's particularly
> upsetting when the CPE doesn't even have a globally routable address.
How
I suspect the reaction is based on being forced to use it when you'd
rather not, like many residential ISPs require. It's particularly
upsetting when the CPE doesn't even have a globally routable address.
How much is many?
Um, some? I don't have any sort of global count. I've had 7 broadband
On Fri, 30 Apr 2010 01:01:59 EDT erik quanstrom wrote:
> > 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 see any reason why 9p couldn't use some of the same
> > congestion control ideas. the trick would be to feed back packet loss
> > detection and retransmission info to the point where file io gets
> > turned into rpcs→the mount driver
>
> Agreed -- sort of what I meant by "I hope 9p ev
On Fri, 30 Apr 2010 12:13:59 EDT erik quanstrom
wrote:
> > > i don't see any reason why 9p couldn't use some of the same
> > > congestion control ideas. the trick would be to feed back packet loss
> > > detection and retransmission info to the point where file io gets
> > > turned into rpcsât
Doesn't make it past my Vonage modem/router.
It would otherwise probably make it past the
Cable modem.
On Thu, Apr 29, 2010 at 12:03 PM, erik quanstrom wrote:
> if you pick a random protocol type that's not tcp or udp and
> the chances your little packets will make it across the intertubes
> will
89 matches
Mail list logo
