[9fans] About 9P ... - Plan9

This is a discussion on [9fans] About 9P ... - Plan9 ; I don't think so. Because we try to use results from past, and not to look ahead. On 6/23/07, Roman Shaposhnick wrote: > On Sat, 2007-06-23 at 01:48 +0200, Francisco J Ballesteros wrote: > > Skip wrote: > > :there ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 46

Thread: [9fans] About 9P ...

  1. Re: [9fans] About 9P ...

    I don't think so. Because we try to use results from past, and not to
    look ahead.


    On 6/23/07, Roman Shaposhnick wrote:
    > On Sat, 2007-06-23 at 01:48 +0200, Francisco J Ballesteros wrote:
    > > Skip wrote:
    > > :there were discussions about aysnc syscalls. /sys/src/cmd/fcp.c is a
    > > :good example of why they're not needed. streaming and long delay
    > > :networks can be handled this way too, as was pointed out (by Russ i
    > > :think) at iwp9.
    > >
    > > But there is one problem. Consider "lc".
    > >
    > > Usually you see
    > > walk
    > > clunk
    > > walk
    > > clunk
    > > walk
    > > open
    > > write
    > > clunk
    > >
    > > and also
    > > walk
    > > stat clunk
    > > walk
    > > open
    > > read
    > > clunk
    > >
    > > The problem is, how to know which RPCs to pack?

    >
    > Isn't it the very same problem that compilers have with
    > instruction pipelining?
    > http://en.wikipedia.org/wiki/Instruction_pipelining
    >
    > With an additional complication that you can't actually
    > look ahead very often?
    >
    > Thanks,
    > Roman.
    >
    >


  2. Re: [9fans] About 9P ...

    > So unless Russ is right and that the
    > fact FIDS are choosen by the client has
    > been decided arbitrarily ... I still have
    > no answer to my question.


    In the current version of 9P, there is no reason
    why the client has to choose the fids (file ids).
    You don't have to believe me, but it's true.

    The client must choose the tags (request ids)
    since it sends the first request message without
    any input from the server. The tags are what
    enable having multiple messages outstanding.

    There is an historical reason why fids are
    chosen by the client, but like most historical
    reasons, it no longer applies. In very early
    versions of 9P (before the first edition release),
    there were no tags. Replies were matched
    based on fid and type, so fids had to be chosen
    by the client, just as tags do now.

    Tags were introduced on November 21, 1990:
    http://swtch.com/go/fid2tag

    Russ


  3. Re: [9fans] About 9P ...

    > Tags were introduced on November 21, 1990:
    > http://swtch.com/go/fid2tag


    good question and great historical perspective.

    is software archaeology a formal discipline yet?


  4. Re: [9fans] About 9P ...

    Thank you Russ.

    Russ Cox a crit :
    >> So unless Russ is right and that the
    >> fact FIDS are choosen by the client has
    >> been decided arbitrarily ... I still have
    >> no answer to my question.
    >>

    >
    > In the current version of 9P, there is no reason
    > why the client has to choose the fids (file ids).
    > You don't have to believe me, but it's true.
    >
    > The client must choose the tags (request ids)
    > since it sends the first request message without
    > any input from the server. The tags are what
    > enable having multiple messages outstanding.
    >
    > There is an historical reason why fids are
    > chosen by the client, but like most historical
    > reasons, it no longer applies. In very early
    > versions of 9P (before the first edition release),
    > there were no tags. Replies were matched
    > based on fid and type, so fids had to be chosen
    > by the client, just as tags do now.
    >
    > Tags were introduced on November 21, 1990:
    > http://swtch.com/go/fid2tag
    >
    > Russ
    >
    >
    >
    >



  5. Re: [9fans] About 9P ...

    Don't know, but we have strong group on that on the other corridor of
    the building.
    They count lines, and count, and count...
    They use Linux mostly, and have a huge ammount of lines to count.

    On 6/23/07, Skip Tavakkolian <9nut@9netics.com> wrote:
    > > Tags were introduced on November 21, 1990:
    > > http://swtch.com/go/fid2tag

    >
    > good question and great historical perspective.
    >
    > is software archaeology a formal discipline yet?
    >
    >


  6. Re: [9fans] About 9P ...

    > 9P is just great for use when latency is reasonable (or not too bad,
    > with cfs), but to go further
    > away and still be comfortable using remote files, I'd say we need
    > another protocol.
    > I'd love to be proved wrong


    are there any protocols that deal well with latency?

    the only way i know to deal with latency is to do some
    sort of tagged queueing. (perhaps i don't know enough
    computer history.) unfortunately, this doesn't
    work if part of the data you need depend on some
    prior part; a conversation means ping-pong communication.

    the great news for 9p is that latency is decreasing. in
    /sys/doc/net/net.ps, the IL/ether latency is listed as
    having a latency of 1420µs. my home fileserver
    has a 57µs latency to my cpu server. (the fileserver is a
    pIII with a $19 rtl8169.)

    even custom Cyclone interface between the file server and
    the cpu server is listed as having a latency of 375µs.

    let's hope the same holds true for wireless networking.

    - erik

  7. Re: [9fans] About 9P ...

    >
    > Tags were introduced on November 21, 1990:
    > http://swtch.com/go/fid2tag


    Thanksgiving weekend. We kicked everyone off for the weekend
    and redid 9P to fix all the problems we'd figured out so far.

    -rob

  8. Re: [9fans] About 9P ...

    Francisco J Ballesteros wrote:
    > Don't know, but we have strong group on that on the other corridor of
    > the building.
    > They count lines, and count, and count...
    > They use Linux mostly, and have a huge ammount of lines to count.

    Of course :-)

    But then not many people are "fortunate enough" to see the lines in
    other systems, in order to be able to count them....


  9. [9fans] 9P optimization

    Before we think about turning 9P into NFSv4, it would be useful to examine
    the current use of cfs, and collect some stats on how effective it is.

  10. Re: [9fans] 9P optimization

    The problem with cfs is that you still suffer the RPC to check for validity.
    With 100ms of RTT, count 5 and you have a second. Also, for synthesized files,
    the cache does not save you from doing a walk, open, read.

    That sayd, I don't think a change in 9p is needed. Translating to
    another protocol for low links
    suffices.

    On 6/24/07, Lyndon Nerenberg wrote:
    > Before we think about turning 9P into NFSv4, it would be useful to examine
    > the current use of cfs, and collect some stats on how effective it is.
    >


  11. Re: [9fans] 9P optimization

    > The problem with cfs is that you still suffer the RPC to check for validity.
    > With 100ms of RTT, count 5 and you have a second. Also, for synthesized
    > files,
    > the cache does not save you from doing a walk, open, read.


    I'll be accused of being a heretic, but let me claim that much of the
    design of IMAP is geared towards avoiding those RTTs for that very reason.
    A good IMAP client wins by doing intelligent cacheing, and it gets there
    by using the subtle aspects of the protocol that accomodate that.

    Much as people slag the protocol, it does work well over slow (high
    latency) links, given a client that understands the protocol (sadly, most
    don't).

    I'm very curious about the efficiency of cfs, but my P9 environment
    doesn't have a remote terminal. It would be interesting to instrument cfs
    and collect some stats on the protocol behaviour behind the cache ...

    --lyndon

  12. Re: [9fans] 9P optimization

    I wrote (a long time ago) a caching file system, for root file
    systems, described here:
    http://mbgokhale.org/rminnich/job/au...r/autocache.ps, that did
    the simple thing: once you have the file, don't bother checking with
    the server until time + DeltaT, This might not work well for you, but
    in 1989, it worked wonderfully well as a root file system because:
    1. most files in most root file systems are never even looked at
    (particularly man pages!)
    2. They don't change much anyway -- think about it -- how often do
    people like to upgrade :-)

    So it is not always the case that you need to stat the cached files on
    each access. In fact, we watched NFS traffic on our backbone at the
    SRC for several months, and, as many other people have found, most
    files are mostly read.

    This type of optimization is fairly trivial for CFS, and would end up
    covering most files (see above); the few read-write ones left would
    not really hurt you too much. You could do much better in 9p because
    it is stateful.

    I have a new implementation of the autocacher (it's only for NFS)
    which I wrote ca. 1999, before I got to LANL; I had lost it but found
    it on my last day of work at LANL. I'll try to get it on my web page.
    It's a very simple program.

    thanks

    ron

  13. Re: [9fans] 9P optimization

    rangbooming has lead to extreme optimiazations. i'll let skip
    comment on it (he's asleep i guess). but i couldn't have much
    worse RTT (sydney-seattle), and the traffic seems a lot lower now,
    and the latency has improved extraordinarily.

    brucee

    On 6/24/07, Lyndon Nerenberg wrote:
    > > The problem with cfs is that you still suffer the RPC to check for validity.
    > > With 100ms of RTT, count 5 and you have a second. Also, for synthesized
    > > files,
    > > the cache does not save you from doing a walk, open, read.

    >
    > I'll be accused of being a heretic, but let me claim that much of the
    > design of IMAP is geared towards avoiding those RTTs for that very reason.
    > A good IMAP client wins by doing intelligent cacheing, and it gets there
    > by using the subtle aspects of the protocol that accomodate that.
    >
    > Much as people slag the protocol, it does work well over slow (high
    > latency) links, given a client that understands the protocol (sadly, most
    > don't).
    >
    > I'm very curious about the efficiency of cfs, but my P9 environment
    > doesn't have a remote terminal. It would be interesting to instrument cfs
    > and collect some stats on the protocol behaviour behind the cache ...
    >
    > --lyndon
    >


  14. Re: [9fans] 9P optimization

    > http://mbgokhale.org/rminnich/job/au...r/autocache.ps

    Interesting idea, I must read up on what else has been published on cacheing
    to avoid high latency links.

    It would be fun to modify cfs to have a couple of cache coherency algorithms,
    the timeout you describe could be one, Boyds ftp cache rule is also interesting -
    the timeout value is proportional to how long ago the file was last written, so
    old files tend to be stable.

    The cache could be dynamic on the device type on which the file lives,
    fossil/kfs/kenfs get timeouts, others are assumed to be synthetic files and so
    should have their verson numbers checked every time as cfs does now.

    We could even implement a /dev/fossilchg file which contains the dirstat(2) info
    of all modified files as they change. This would allow persistant (or at least
    long lived) connections to attempt to keep a near consistant view of the file.
    That is any file which has had an update since the local cfs has been started
    would have a known state (be it consistant or inconsisitant); similarly any file
    who had to have its version checked would have a known state also.

    This is of course a seperate issue to the coelessing of multiple p9 operations
    in a single packet as, though as previous posters pointed out it would help cfs too.

    my 2¢

    -Steve

  15. Re: [9fans] 9P optimization

    > It would be fun to modify cfs to have a couple of cache coherency algorithms,
    > the timeout you describe could be one, Boyds ftp cache rule is also interesting -
    > the timeout value is proportional to how long ago the file was last written, so
    > old files tend to be stable.


    I loath the idea of pushing state into 9P, but I wonder if a combination
    of client side cfs with a kqueue-like 'file is modified' server event
    might not solve most of the problem. Layered into aan perhaps?


    --lyndon

    What is this talk of 'release'? Klingons do not make software
    'releases'. Our software 'escapes' leaving a bloody trail of designers and
    quality assurance people in its wake.

  16. Re: [9fans] 9P optimization

    > I loath the idea of pushing state into 9P, but I wonder if a combination
    > of client side cfs with a kqueue-like 'file is modified' server event
    > might not solve most of the problem. Layered into aan perhaps?


    Not sure if I missunderstand you but I am _not_ suggesting pushing any
    state into p9.

    My thoughts where modifying cfs heuristics to reduce the probability of
    waiting for a coherence check (which could be quite a few RTTs).

    In the limit I also suggested providing a synthetic file which contains
    dirstat(1) info on modified files as they change - which I think is what
    you mean by a "kqueue-like 'file is modified' server".

    The problem with implementing this as a server program on the fileserver machine
    is that _all_ fossil/kfs/kenfs file accesses would have to pass through this server
    to be sure that a when a file is changed by somone else you are informed.
    As fossil (what I use) already knows this info I thougt it would be as well for it
    to provide this file itself.

    hope this clarifies.

    -Steve

  17. Re: [9fans] 9P optimization

    rather than go to these extremes, why not use a local root?
    run replica in a cron job if necessary. a paired-down root
    can fit in 32MB more-or-less.

    i use import so i can run acme locally, and cpu in acme windows to
    access machines at work. this way only command stdin, stdout, stderr
    and the files i edit cross the wire.

    - erik

  18. Re: [9fans] 9P optimization

    > Not sure if I missunderstand you but I am _not_ suggesting pushing any
    > state into p9.


    > My thoughts where modifying cfs heuristics to reduce the probability of
    > waiting for a coherence check (which could be quite a few RTTs).


    We're on the same track. This stuff would fit in cfs just as easily.
    What I'm curious about is if a 'the file was modified' callback would help
    -- basically, just a notification to flush the cache, which would let the
    client be more aggressive about holding blocks in the cache without having
    to ping the server on every read.

    9P wouldn't need any mods -- this would work easily as a filter pushed on
    the 9fs connection. But it would need a callback facility to notify the
    server side of the cache filter that the file had changed.

    --lyndon


  19. Re: [9fans] 9P optimization

    > rather than go to these extremes, why not use a local root?

    Even with a local root, importing stuff over (say) wifi can be painful.

    --lyndon

    NT as a file server is faster than a dead bat carrying Post-It notes
    underwater. But not by much.

  20. Re: [9fans] 9P optimization

    > rangbooming has lead to extreme optimiazations. i'll let skip
    > comment on it (he's asleep i guess). but i couldn't have much
    > worse RTT (sydney-seattle), and the traffic seems a lot lower now,
    > and the latency has improved extraordinarily.


    behavior of windows exploder (rer) and network latency really magnify
    this problem. we cache the walks, assisted by staling and usage
    tracking. staling >1×rtt will satiate incessant walk requests from
    cache.

    it is useful for what we're doing. brucee has an idea on how it could
    be applied to something like exportfs, for general use.

    regarding locks or cache expiry notification that others suggested,
    the proposal in snspaper was to address that, but in the end we all
    agreed that if you need it, a control file between the fileserver and
    the importing side would be sufficient.


+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast