Re: [9fans] 9p over high-latency - Plan9

This is a discussion on Re: [9fans] 9p over high-latency - Plan9 ; On Thu, Sep 18, 2008 at 7:51 PM, erik quanstrom wrote: >> Hm, but what's the alternative here? Readahead seems somewhat >> attractive, if difficult (I worry about blocking reads and timing >> sensitive file systems). > > the fundamental ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Re: [9fans] 9p over high-latency

  1. Re: [9fans] 9p over high-latency

    On Thu, Sep 18, 2008 at 7:51 PM, erik quanstrom wrote:
    >> Hm, but what's the alternative here? Readahead seems somewhat
    >> attractive, if difficult (I worry about blocking reads and timing
    >> sensitive file systems).

    >
    > the fundamental problem is that it becomes very difficult to
    > implement fileservers which don't serve up regular files.
    > you might make perminant changes to something stored on
    > a disk with readahead.


    I'm not sure this problem is insurmountable. Some simple heuristics
    along the lines of waiting a couple of Rreads to see if it looks like
    an i/o pattern that is slurping up the whole file could go a long way.
    However, I agree this is not the most reliable approach, and certainly
    doesn't fit with the simplicity ideal.

    > i'll admit that i don't understand the point of batching walks.
    > i'm not sure why one would set up a case where you know you'll
    > have a long network and where you know you'll need to execute
    > a lot of walks. most applications that do most i/o in a particular
    > directory set . to that directory to avoid the walks.


    Right, but unless the mnt driver keeps an fid around for every file
    in that directory set, every open is still two round trips - one to
    walk to the file, and one to actually open it. Which is almost twice
    as long as necessary. You might scoff at a single round trip, but as
    someone who uses ircfs over the internet, I can tell you the
    difference in responsiveness between echo and cat is noticeable
    (though ok, echo has two extra round trips in this case).

    > i'm not sure that octopus wouldn't be better off optimizing
    > latency by running many more threads. but that's just an ignorant
    > opinion.


    How can multiple threads possibly help with latency caused by
    operations that forced to be serial by the protocol? In fact, how can
    multithreading help with latency in general? It will help
    *throughput*, certainly, but unless you have a thread dedicated to
    predicting the future, I can't see where the benifit will come from.
    -sqweek


  2. Re: [9fans] 9p over high-latency

    On Thu, Sep 18, 2008 at 8:34 AM, sqweek wrote:
    > On Thu, Sep 18, 2008 at 7:51 PM, erik quanstrom wrote:
    >
    > How can multiple threads possibly help with latency caused by
    > operations that forced to be serial by the protocol? In fact, how can
    > multithreading help with latency in general? It will help
    > *throughput*, certainly, but unless you have a thread dedicated to
    > predicting the future, I can't see where the benifit will come from.
    >


    I'm not saying I know it would be a good idea, but you could implement
    speculative-9P which issued the equivalent of the batched requests
    without waiting for the responses of the prior request -- since you
    are on an in-order pipe the file server would get the requests in
    order and if they all succeeded, then you've reduced some latency.
    Of course any failure will cause issues, potentially bad issues (a
    bunch of walks followed by a create would end badly if one of the
    walks failed and the create put the file someplace undesirable).

    I think this is tending towards what was discussed at the first IWP9
    -- IIRC the idea was to use the same tid for all the operations
    (instead of a new tid per operation as would normally be done in
    multi-threaded 9P). An error or short-walk on any of the ops
    associated with that tid. I can't remember if we needed some op to
    represent transaction boundries in order to recover failed tids --
    anyone's memory better than mine?

    The problem again here is added complexity to client and server who
    have to track more state associated with these transactions....

    -eric


  3. Re: [9fans] 9p over high-latency

    > I'm not saying I know it would be a good idea, but you could implement
    > speculative-9P which issued the equivalent of the batched requests
    > without waiting for the responses of the prior request -- since you
    > are on an in-order pipe the file server would get the requests in
    > order and if they all succeeded, then you've reduced some latency.


    We did this, IIRC. It helped reduce latency, but for file trees like
    the one used
    by omero it was not enough (at least for 150ms rtts). In the end, the
    file server
    is pushing changes to the viewer via a "connection" file.

    Of course, for other devices it might be fine.


  4. Re: [9fans] 9p over high-latency

    > We did this, IIRC. It helped reduce latency, but...

    Are the modified kernel files still in your venti?
    I would be interested in having a play in a simple disk file
    sharing environment.

    -Steve


  5. Re: [9fans] 9p over high-latency

    I think I made it using a user-level program to talk to 9p
    servers trying to do some caching. I'll try to find out if I still
    have it in venti,
    I think I just removed
    the thing after finding out it was not going to work for retrieving omero trees.

    On Thu, Sep 18, 2008 at 10:05 PM, Steve Simon wrote:
    >> We did this, IIRC. It helped reduce latency, but...

    >
    > Are the modified kernel files still in your venti?
    > I would be interested in having a play in a simple disk file
    > sharing environment.
    >
    > -Steve
    >
    >



+ Reply to Thread