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

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

[Steve Simon]

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

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

[Anthony Sorace]

On 11/9/07, Steve Simon <steve@quintile.net> 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

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

[roger peppe]

On Nov 9, 2007 2:40 PM, Anthony Sorace <anothy@gmail.com> wrote:
> On 11/9/07, Steve Simon <steve@quintile.net> 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.

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

[Anthony Sorace]

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.

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

[Steve Simon]

>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

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

[ron minnich]

On Nov 9, 2007 7:33 AM, Steve Simon <steve@quintile.net> 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

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

[erik quanstrom]

>>
>> 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

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

[erik quanstrom]

> // ...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