[9fans] cpu(1) design... - Plan9

This is a discussion on [9fans] cpu(1) design... - Plan9 ; Trivial questions about cpu(1). was there ever any thought that cpu could/should put you onto the least loaded machine in your authdom (or an option to do this) or is this breaking the one tool does one job principal? If ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: [9fans] cpu(1) design...

  1. [9fans] cpu(1) design...

    Trivial questions about cpu(1).

    was there ever any thought that cpu could/should put you onto
    the least loaded machine in your authdom (or an option to do this)
    or is this breaking the one tool does one job principal?

    If so has anyone ever done this (not difficult) or is the idea that
    you would only want to cpu(1) to another machine because of the services
    or network topology you (as a human) want rather than just to find more grunt.

    seccondly - why does cpu not have a default argument? this constantly
    irritates me, I often cpu as a different user, to run a command and go
    to a machine other than that defined by /env/cpu but no matter which
    I want I always need to flag the argument.

    just idle curiosity, its Friday after all.

    -Steve

  2. Re: [9fans] cpu(1) design...

    On 11/9/07, Steve Simon wrote:

    // was there ever any thought that cpu could/should put you
    // onto the least loaded machine in your authdom...

    That seems more a server function than a client function to me; thus,
    cpu(1) would be the wrong place to do it. I'd rather the servers in
    some cluster figure out amongst themselves who handles a given call,
    rather than the client having to do some sort of polling or inquiry.
    Also, that keeps a more consistent user experience.


    // ...is the idea that you would only want to cpu(1) to another
    // machine because of the services or network topology you
    // (as a human) want rather than just to find more grunt.

    Certainly originally cpu(1) was frequently used simply to get to a
    bigger machine. That's the way many of the early docs describe its
    use, and was also the practice at the Labs a decade ago. This use has
    become less common (at least for me) as terminals become so much more
    powerful.

    Wanting to get at particular resources is also a valid reason, of
    course, although in my usage import and friends more often serve that
    need.

    // why does cpu not have a default argument?

    I'm not sure I follow what you're asking for here. $cpu *is* the
    default; if you want something else, you can give it.

    Anthony

  3. Re: [9fans] cpu(1) design...

    On Nov 9, 2007 2:40 PM, Anthony Sorace wrote:
    > On 11/9/07, Steve Simon wrote:
    > // why does cpu not have a default argument?
    >
    > I'm not sure I follow what you're asking for here. $cpu *is* the
    > default; if you want something else, you can give it.


    i think what steve's getting at is: why doesn't cpu take
    any non-flagged command-line arguments?

    i have to say i've been caught out in the past by doing:

    cpu netstat

    rather than:

    cpu -c netstat

    but you live and learn.

  4. Re: [9fans] cpu(1) design...

    > // ...is the idea that you would only want to cpu(1) to another
    > // machine because of the services or network topology you
    > // (as a human) want rather than just to find more grunt.
    >
    > Certainly originally cpu(1) was frequently used simply to get to a
    > bigger machine. That's the way many of the early docs describe its
    > use, and was also the practice at the Labs a decade ago. This use has
    > become less common (at least for me) as terminals become so much more
    > powerful.


    it's all about the io. at home i have a pretty symmetric situation.
    all the cpu servers and terminals have an equally slow connection to
    the fileserver. i would imagine most people have a similar situation
    at home. then it might matter who has cycles to burn, if the fs still isn't
    the bottleneck.

    at coraid, one cpuserver has a 10gbe connection to the fileserver,
    many have a gbe connection to the fileserver, and several are on
    the wrong side of a wireless link. there is a performance heirarchy, but
    it has nothing to with processing power.

    - erik


  5. Re: [9fans] cpu(1) design...

    ah, i see. yes, i've been caught by that as well.

    the problem is i've also been caught doing 'cpu system', thinking of
    it as a parallel to ssh or telnet. i probably assume -c more often
    than -h, but that does seem less consistent with other "remote access"
    commands.

  6. Re: [9fans] cpu(1) design...

    >i think what steve's getting at is: why doesn't cpu take
    >any non-flagged command-line arguments?


    >> ah, i see. yes, i've been caught by that as well.
    >>
    >> the problem is i've also been caught doing 'cpu system', thinking of
    >> it as a parallel to ssh or telnet. i probably assume -c more often
    >> than -h, but that does seem less consistent with other "remote access"
    >> commands.


    Yes, exactly - It just "feels strange", I know I can bodge it locally
    but I was just thought it strange that it works this way and wondered
    if there was a reason (in the mists of time perhaps).

    > That seems more a server function than a client function to me;


    I was imagining somthing like the load balancing code I have seen for Unix,
    each box multicasts a load estimate regularly and a local daemon picks these up
    and answers "which is the least loaded machine" requests; obviously I also
    imagined a much more elegant solution for a plan9 environment...

    -Steve

  7. Re: [9fans] cpu(1) design...

    On Nov 9, 2007 7:33 AM, Steve Simon wrote:

    >
    > I was imagining somthing like the load balancing code I have seen for Unix,
    > each box multicasts a load estimate regularly and a local daemon picks these up
    > and answers "which is the least loaded machine" requests; obviously I also
    > imagined a much more elegant solution for a plan9 environment...


    see andrey's thesis. Mount a mon server and you have a file system of
    servers. Then you can just read the files, pick the least loaded one,
    and run on it.

    Along with the other 400 people who just picked that least-loaded node
    but hey, that's the inherent race conditions you get. :-)

    ron

  8. Re: [9fans] cpu(1) design...

    >>
    >> I was imagining somthing like the load balancing code I have seen for Unix,
    >> each box multicasts a load estimate regularly and a local daemon picks these up
    >> and answers "which is the least loaded machine" requests; obviously I also
    >> imagined a much more elegant solution for a plan9 environment...

    >
    > see andrey's thesis. Mount a mon server and you have a file system of
    > servers. Then you can just read the files, pick the least loaded one,
    > and run on it.
    >
    > Along with the other 400 people who just picked that least-loaded node
    > but hey, that's the inherent race conditions you get. :-)


    why not move the decision of who picks up the job to the cpu server?
    this would solve the race.

    - erik


+ Reply to Thread