Were it set up as a BOINC project then it would be simple to use and would attract those of us addicted to running large numbers of projects.
As I understand it though the running of the simulations is a manual process. Is that correct? One of the flaws of the resource scheduling as it is currently implemented is that no attempt is made to do any sort of "packing" analysis where the time lanes are filled with tasks to see what is the best packing that can be done. The unspoken question is why are we allowing the MT tasks to crowd out other tasks simply by the virtue of the fact that they are MT. Why are we not allowing the user the control over setting the max number of cores that the MT task can use. For example, on my quad I may want to allow the MT task to run on all 4 cores, or perhaps only on 2... on the i7 systems I might want something less restrictive like no more than 6 cores so that the problem of your scenario would not occur. On Jan 8, 2010, at 9:15 AM, [email protected] wrote: > It would be good if we had a suite of tests to run CPU schedulers through > and a proposed CPU scheduler change could be tested quickly. I proposed > setting this up as the "BOINC" project tasks. The memorex in this case > could get us answers about the effectiveness much faster than live does. > The problem is that the edge conditions do not happen frequently. Most of > the time on most machines any CPU scheduler will work. It is only > sometimes that there is a major problem where some task will be reported > weeks late, or a resource is ignored for a day or two... > > jm7 > > > > "Paul D. Buck" > <p.d.b...@comcast > .net> To > Sent by: BOINC Developers Mailing List > <boinc_dev-bounce <[email protected]> > [email protected] cc > u> [email protected] > Subject > Re: [boinc_dev] [boinc_alpha] EDF > 01/08/2010 12:02 and multi CPU tasks. > PM > > > > > > > > > > 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. > > > _______________________________________________ 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.
