2010/10/15 ron minnich :
> 2010/10/15 :
>> i wonder if making 9p work better over high latency connections is
>> even the right answer to the problem.
>
> The reason I care is that the link from a CPU node to a file server on
> blue gene is high latency. It might as well be cross-country, it's so
gt; Date: Sat, 16 Oct 2010 02:30:42 +0300
> Subject: Re: [9fans] πp
> 2010/10/16 erik quanstrom :
>> On Fri Oct 15 17:14:18 EDT 2010, bumbudo...@gmail.com wrote:
>>> 2010/10/15 erik quanstrom :
>>> >> isn't tag field for this intended?
>>> >
>>&
when you are in kiev, video streams YOU!
--
cinap
--- Begin Message ---
2010/10/16 erik quanstrom :
> On Fri Oct 15 17:14:18 EDT 2010, bumbudo...@gmail.com wrote:
>> 2010/10/15 erik quanstrom :
>> >> isn't tag field for this intended?
>> >
>> > [...]
>> >
>> >> so this means to me that a client ca
2010/10/16 erik quanstrom :
> On Fri Oct 15 17:14:18 EDT 2010, bumbudo...@gmail.com wrote:
>> 2010/10/15 erik quanstrom :
>> >> isn't tag field for this intended?
>> >
>> > [...]
>> >
>> >> so this means to me that a client can send some T-messages and then
>> >> (or concurrently) wait the R-messag
On Fri Oct 15 17:14:18 EDT 2010, bumbudo...@gmail.com wrote:
> 2010/10/15 erik quanstrom :
> >> isn't tag field for this intended?
> >
> > [...]
> >
> >> so this means to me that a client can send some T-messages and then
> >> (or concurrently) wait the R-messages.
> >> in inferno from mount(1) and
It is probably worth trying. However, it wouldn't make copying a file
from sources any faster, or help a Blue Gene node do a snapshot any
quicker.
John
2010/10/15 Julius Schmidt :
> Perhaps I'm getting this all wrong, but to me this seems like an
> interesting idea, especially if you consider th
CPUs have big caches to move the code closer to the data (well a copy of the
data anyway).
Closeness in general is good, the question is what to move and how :-)
Dave
2010/10/15 Julius Schmidt
> Perhaps I'm getting this all wrong, but to me this seems like an
> interesting idea, especially if
Perhaps I'm getting this all wrong, but to me this seems like an
interesting idea, especially if you consider the impact of being "near
the files" on some classically considered computationally stressy tasks
like compiling (esp. with kencc). So moving the code near the data
definitely seems worth
2010/10/15 erik quanstrom :
>> isn't tag field for this intended?
>
> [...]
>
>> so this means to me that a client can send some T-messages and then
>> (or concurrently) wait the R-messages.
>> in inferno from mount(1) and styxmon(8) i deduced that this case is
>> also considered.
>> it's true that
There are definitely cases when moving the code instead of the data
makes sense. But that discussion is mostly unrelated to the one on how
to make the file I/O work better over high-latency links.
2010/10/15 erik quanstrom :
> On Fri Oct 15 12:33:19 EDT 2010, lu...@ionkov.net wrote:
>> What if the
On Fri Oct 15 12:33:19 EDT 2010, lu...@ionkov.net wrote:
> What if the data your process needs is located on more than one
> server? Play ping-pong?
one either plays ping pong with the process or data. one
could imagine cases where the former case makes sense.
- erik
> And even if you get that right, it may not work well on hardware. We
> saw cases with linux migration, while migrating from one x86 to
> another, where valid FP values would cause the target to get an FP
> trap. Made no sense, but it's what happened, because the two x86's
> were different *implem
ht migrating processes was part of Osprey's story :-).
> --
> cinap
>
>
> -- Forwarded message --
> From: Francisco J Ballesteros
> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
> Date: Fri, 15 Oct 2010 16:59:02 +0200
> Subject:
On Fri, 15 Oct 2010 18:19:50 +0200 cinap_len...@gmx.de wrote:
>
> i wonder if making 9p work better over high latency connections is
> even the right answer to the problem. the real problem is that the
> data your program wants to work on in miles away from you and
> transfering it all will suck
2010/10/15 Nemo :
> So, when I hear migration, I just tend to see what happens after it has
> been implemented and faces the spaghethy phase.
And even if you get that right, it may not work well on hardware. We
saw cases with linux migration, while migrating from one x86 to
another, where valid F
2010/10/15 Charles Forsyth :
>>The transition from a stream to the packet-oriented file IO protocol has
>>never been comfortable.
>
> `RPC-oriented' might be more accurate than `packet-oriented', given the
> way that streams are implemented.
Correct.
ron
back to the 80s, or was it 70s?
many people have implemented migration.
the first i remember is swaping (yes, not paging) out a process, then swapping
it back into a different machine. iirc, it might be the sprite unix, not quite
sure.
the point is, the migrated process still needs all the conne
>The transition from a stream to the packet-oriented file IO protocol has never
>been comfortable.
`RPC-oriented' might be more accurate than `packet-oriented', given the
way that streams are implemented.
ll Labs <9fans@9fans.net>
> Date: Fri, 15 Oct 2010 10:43:34 -0600
> Subject: Re: [9fans] πp
> And how is fork going to help when the forked processes need to
> exchange the data over the same high-latency link?
>
> 2010/10/15 :
>> fork!
>>
>> --
>>
> Date: Fri, 15 Oct 2010 10:31:47 -0600
> Subject: Re: [9fans] πp
> What if the data your process needs is located on more than one
> server? Play ping-pong?
>
> Thanks,
> Lucho
>
> 2010/10/15 :
>> i wonder if making 9p work better over high latency connection
2010/10/15 :
> i wonder if making 9p work better over high latency connections is
> even the right answer to the problem.
The reason I care is that the link from a CPU node to a file server on
blue gene is high latency. It might as well be cross-country, it's so
bad.
> would it not be cool to h
t;9fans@9fans.net>
> Date: Fri, 15 Oct 2010 10:31:47 -0600
> Subject: Re: [9fans] πp
> What if the data your process needs is located on more than one
> server? Play ping-pong?
>
> Thanks,
> Lucho
>
> 2010/10/15 :
>> i wonder if making 9p work better over h
9fans.net>
> Date: Fri, 15 Oct 2010 16:59:02 +0200
> Subject: Re: [9fans] πp
> It's not just that you can stream requests or not.
> If you have caches in the path to the server, you'd like to batch together (or
> stream or whatever you'd like to call that) request
en i read the "bring the computation
> to the data" point from the ospray talk.
>
> --
> cinap
>
>
> -- Forwarded message --
> From: Francisco J Ballesteros
> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
> Date: Fri, 15 Oct
i wonder if making 9p work better over high latency connections is
even the right answer to the problem. the real problem is that the
data your program wants to work on in miles away from you and
transfering it all will suck. would it not be cool to have a way to
teleport/migrate your process to
i wonder if making 9p work better over high latency connections is
even the right answer to the problem. the real problem is that the
data your program wants to work on in miles away from you and
transfering it all will suck. would it not be cool to have a way to
teleport/migrate your process to
I already implemented that behavior in go9p on the plane back from
Seattle. I need to test it a bit before I check it in the repository.
The good thing about it is that it doesn't break any existing clients
or servers.
How is it going to be exposed to the clients is another issue. I am
still not s
It's not just that you can stream requests or not.
If you have caches in the path to the server, you'd like to batch together (or
stream or whatever you'd like to call that) requests so that if a client is
reading a file and a single rpc suffices, the cache, in the worst case, knows
that it has to
kov.net
> > To: 9fans@9fans.net
> > Reply-To: 9fans@9fans.net
> > Date: Thu Oct 14 23:13:59 CES 2010
> > Subject: Re: [9fans] πp
> >
> > It can't be dealt with the current protocol. It doesn't guarantee that
> > Topen will be executed once Twalk is
2010/10/14 Latchesar Ionkov
> It can't be dealt with the current protocol. It doesn't guarantee that
> Topen will be executed once Twalk is done. So can get Rerrors even if
> Twalk succeeds.
>
>
It can be dealt with if the scheduling of the pipeline is done properly.
You just have to eliminate t
A simpler way to add pipelining to 9P is to
define that multiple outstanding messages
with the same tag are allowed and that the
server must process and respond to messages
with a given tag in the order it receives them.
This only requires changes to servers that
are actually multithreaded. All th
> isn't tag field for this intended?
[...]
> so this means to me that a client can send some T-messages and then
> (or concurrently) wait the R-messages.
> in inferno from mount(1) and styxmon(8) i deduced that this case is
> also considered.
> it's true that most of the servers i seen until now
We pronouce it pie pee
> Is it Pi-Ro, or do you actually call it Pipi?
2010/10/15 Jacob Todd :
> Eh, what's Πp?
check http://iwp9.org/slides/osprey.pdf
Eh, what's Πp?
Is it Pi-Ro, or do you actually call it Pipi?
concept in
excruciating detail. There's a lot more to it than just changing walk and
open.
Sape
> From: lu...@ionkov.net
> To: 9fans@9fans.net
> Reply-To: 9fans@9fans.net
> Date: Thu Oct 14 23:13:59 CES 2010
> Subject: Re: [9fans] πp
>
> It can't be dealt with the cu
isn't tag field for this intended?
so if Twalk succeeded and Topen failed, souldn't the client be able to
track the failure of Topen based on tag?
in intro(5) it says:
" Each T-message has a tag field, chosen and used by the
client to identify the message. The reply to the message
On Thu Oct 14 17:21:35 EDT 2010, lu...@ionkov.net wrote:
> It can't be dealt with the current protocol. It doesn't guarantee that
> Topen will be executed once Twalk is done. So can get Rerrors even if
> Twalk succeeds.
exactly. a set of outstanding can be overlapped in the current
protocol iff t
It can't be dealt with the current protocol. It doesn't guarantee that
Topen will be executed once Twalk is done. So can get Rerrors even if
Twalk succeeds.
2010/10/13 Venkatesh Srinivas :
>> 2) you can't pipeline requests if the result of one request depends on the
>> result of a previous. for in
> I guess I'm trying to imagine how specifically you could pipeline, not the
> general ways in which pipelining will fail with 9P.
Well as it turns out, I got inspired by the discussions of
streaming and implemented one approach in Inferno on the
plane on the way back home. Unfortunately, my
>
> 2) you can't pipeline requests if the result of one request depends on the
> result of a previous. for instance: walk to file, open it, read it, close
> it.
> if the first operation fails, then subsequent operations will be invalid.
>
Given careful allocation of FIDs by a client, that can be d
2010/10/13 roger peppe
> 2010/10/13 David Leimbach :
> > I guess I do not understand how 9p doesn't support pipelining. All
> > requests are tagged and can be dealt with between client and server in
> > any order right?
>
> two issues (at least):
>
> 1) concurrently sent requests can be reorder
2010/10/13 David Leimbach :
> I guess I do not understand how 9p doesn't support pipelining. All
> requests are tagged and can be dealt with between client and server in
> any order right?
two issues (at least):
1) concurrently sent requests can be reordered (they're serviced in separate
thread
I guess I do not understand how 9p doesn't support pipelining. All
requests are tagged and can be dealt with between client and server in
any order right?
On Wednesday, October 13, 2010, Eric Van Hensbergen wrote:
> For folks interested in more info on the πp portion of Noah's Osprey talk,
> An
For folks interested in more info on the πp portion of Noah's Osprey talk,
Anant's thesis is available online: http://proness.kix.in/misc/πp-v2.pdf
-eric
46 matches
Mail list logo
