When we are easily able to create cases "live", why do we need memorex?



On Jan 8, 2010, at 8:09 AM, [email protected] wrote:

> This is a case I was worried about from the instant you said that a multi
> CPU task would take priority over N-1 single CPU tasks at the same
> priority.
> 
> This is a case that should be solved.  Returning a task weeks late when all
> tasks could have been completed on time is in my opinion a major oops.
> 
> The problem I had with the scheduler tester was that it was a major pain.
> It took hours to generate a decent dataset that was not dominated by
> startup interactions.  It was also hard to generate scenarios that showed
> the problems.  Please note that when you insisted that all changes be
> validated through the test suite that you stopped getting suggestions for
> changes.
> 
> jm7
> 
> 
> 
>             David Anderson                                                
>             <[email protected]                                             
>             ey.edu>                                                    To 
>             Sent by:                  [email protected]              
>             <boinc_alpha-boun                                          cc 
>             [email protected].         [email protected], BOINC   
>             edu>                      Alpha Mailing List                  
>                                       <[email protected]>      
>                                                                   Subject 
>             01/07/2010 05:42          Re: [boinc_alpha] EDF and multi CPU 
>             PM                        tasks.                              
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> The scheduling policy for multithread apps is the result of many
> iterations.
> We're at a point where a change to improve one scenario is
> likely to worsen other scenarios.
> 
> I suggest that we resurrect the client simulator to study proposed
> changes "in the lab".
> It will require a bit of work to make the simulator handle
> multithread and GPU apps; is anyone interested in doing this?
> 
> -- David
> 
> [email protected] wrote:
>> I have a dual CPU system that is currently running Aqua.  The run time
> for
>> Aqua is grossly over estimated.  However, I believe that the task would
> be
>> in EDF anyway based on the speed of the computer and my estimate of the
>> length of the task.
>> 
>> Now for the problem:
>> 
>> I have about a dozen other tasks on the host, most of which have
> deadlines
>> before the Aqua task (the exceptions are the CPDN and CPDN Beta tasks).
> It
>> appears that two of these tasks have to enter EDF (or N for a system with
>> more than 2 CPUs) in order to override the processing of the Aqua task.
>> What happens if there is one task left with an earlier deadline than the
>> Aqua task?  It appears that it will not be run until after the Aqua task
> is
>> finished - about a week after the deadline for the earlier deadline task
> in
>> this case.
>> 
>> Possible solutions:
>> 
>> 1)  When generating the list of tasks to run, skip tasks that do not have
>> the processor count to run now.  Note that if skipping a task that needs
>> EDF because of this, it would be a good idea to pick a task with an
> earlier
>> deadline than the task that has the deadline problem and insufficient
>> resources.  This increases the probabilities of everything meeting
> deadline
>> in this case.  It also means that there is not an idle CPU.
>> 
>> 2)  Order all tasks in priority order and let enforcement sort out what
> can
>> to run now based on such things as CPU/GPU availability and RAM
>> availability.
>> 
>> jm7
>> 
> 
> _______________________________________________
> boinc_alpha mailing list
> [email protected]
> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_alpha
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
> 
> 
> 
> _______________________________________________
> boinc_dev mailing list
> [email protected]
> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.

_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Reply via email to