Re: determining host performance for task assignment

Hello,

I agree the inherent performance of CPU servers
will seldom change, but they are not always equally
loaded, in terms of jobs, and the wallclock time taken
to execute a submitted job will therefore vary, yeah ?

Another argument is that many processors now do
either clock throttling for guarding against thermal
emergencies, and some do both dynamic voltage
and frequency scaling. So now the performance of
you cluster may vary dynamically based on how well
your machine room is getting cooled :-[

The motivation in my case is more to determine the
"dynamic processor equivalent" of  cpu servers (if you will),
to enable some sort of load balancing. Not load balancing
in the general  sense, but rather to determine, at the point
at which you send a task to a server, which server would
likely give you the best wallclock execution time.

In other words, you mention the "desirability" of a cpu
being a combination of many factors --- why not measure
that "attractiveness" empirically/dynamically by running
a small test occasionally ? Better yet provide a clean interface
for re-running this test / caching its result etc. That is what i'm
doing but am not too happy with.

This solution has the appeal of not requiring any potentially
flawed formulation for calculating the "desirability". What
you measure is what you get. But, of course, the synthetic
benchmarks for measurement are not perfect. Thanks.

cheers,



On Mar 14, 2004, at 12:16 PM, andrey mirtchovski wrote:

> Here are my thoughts,
>
> The thing about performance for cpu servers is that it never really 
> changes.
> It does on some laptops when the power cord is unplugged, but we aren't
> really going to unplug the cpu's intentionally :)
>
> What may be more of a concern for a person starting a job (or a 
> scheduler) is
> how much load there is on a particular machine and how that load 
> changes
> with time. That said, how 'desirable' a cpu may be to run jobs on 
> becomes an
> equation of several factors, including CPU speed, total and available
> memory, number of (compute) jobs running or scheduled to run there and 
> the
> current, perhaps 'expected' load of the system. (In a real HPC 
> environment
> the load should average 1 times #CPUs on the system).
>
> MAUI (PBS too?) has what it calls a 'processor equivalent', or PE, 
> which
> is assigned by administrator when a system is configured in. It is 
> used in
> several of the formulas for calculating priorities and various 
> execution
> time penalties. I have been mulling on incorporating something similar,
> but I want to involve more factors in calculating it, including 
> bogomips,
> flops or dhrystone and make it dynamically updated.
>
> I haven't done it yet because I'm more concerned with making resfs 
> report
> policies (max jobs, users allowed, max wallclock time, etc.) which, 
> afaik, no
> other resource discovery system has.
>
> cheers, andrey
>
> On Fri, 12 Mar 2004 [email protected] wrote:
>
>> This has come up twice in the last several hours, so i figure
>> i'll ask for opinions here.
>>
>> To determine a dynamic task assignment to hosts, i'm using a
>> /dev/perf that takes a simple 'calibrate x' command and reports
>> (based on "x") (1) a "bogusmips" value which is just the result
>> of a timed empty loop (2) a Dhrystone 2.1 value or (3) a Flops
>> number. The timing is based on wallclock time to give a measure
>> of system load.  I've glossed over some details.
>>
>> This solution was thrown  together in a few minutes, and I don't think
>> very much of it. How do people here do this ? How is it proposed to
>> be done in 9grid (from reading the IPDPS paper I only grok
>> that details like processor speed and amount of memory will be
>> part of the information posted in /srv, or, via /dev/cputype). Thanks.
>>
>> cheers,
>>
>> _______________________________________________
>> 9grid mailing list
>> 9grid-bRIBFEq44iy2p8tyqo/[email protected]
>> http://nwn.definitive.org/mailman/listinfo/9grid
>>
>
> _______________________________________________
> 9grid mailing list
> 9grid-bRIBFEq44iy2p8tyqo/[email protected]
> http://nwn.definitive.org/mailman/listinfo/9grid