OK, this is pretty much what is already done. However, there are more
things to be done than just CPU and work fetch scheduling.
The sleep has to be 1 second because there ARE things in the loop that have
to run that frequently. For example the messages from the science
applications have to be read and cleared out very frequently.
jm7
"Paul D. Buck"
<p.d.b...@comcast
.net> To
[email protected]
04/29/2009 04:22 cc
PM BOINC Developers Mailing List
<[email protected]>, Mark
Pottorff <[email protected]>,
"Josef W. Segur"
<[email protected]>
Subject
Re: [boinc_dev] 6.6.20 and work
scheduling
I don't know what you said because your mail program and the mailing
list does not seem to agree with each other.
Why not baby steps...
As I said in the text file this is what you told me is the essence of
the current BOINC operational loop.
What SHOULD it be to be correct in your mind?
main ()
begin
initialize
loop forever
do what needs to be done
detect-events;
if events
if number of resources < 4
then
use old
scheduler
else
schedule-resources (event list)
do whatever else needs to be done
sleep; // isn't this where the 60
second limit should occur?
end loop; // forever
end // main
"detect-events" is a pseudo operation / function that collects all the
events since the last pass through the main loop.
That list is passed on...
But, the important question is if my code is wrong, what is correct in
your mind?
On Apr 29, 2009, at 12:52 PM, [email protected] wrote:
>
>
> jm7
>
>
>
> "Paul D. Buck"
> <p.d.b...@comcast
> .net
> > To
> [email protected]
> 04/29/2009
> 03:47 cc
> PM BOINC Developers Mailing List
> <[email protected]>,
> Mark
> Pottorff <[email protected]>,
> "Josef W. Segur"
> <[email protected]>
>
> Subject
> Re: [boinc_dev] 6.6.20 and work
> scheduling
>
>
>
>
>
>
>
>
>
>
>
> On Apr 29, 2009, at 6:08 AM, [email protected] wrote:
>
> You have the logic upside down.
>
> What logic, where?
>
> Your code leads to major thrashing of tasks.
>
> Um, how... I only witch out tasks at task completion and at TSI
>
> Unless you check the global state, you run the risk of starting
> and
> stopping a series of tasks IN THE SAME SECOND. because they all
> checkpointed, and there is a perverse chain of what to run next.
> Inspecting the global state is a much better solution than
> trying to
> figure
> out exactly what to do on a particular event as there is the
> probability
> that several events will happen during the same second.
>
> Well, I hate to break this to you, but the basic core of that pseudo
> code
> that you just slammed is pretty well lifted from what is currently
> coded.
>
> ?? The code I have looked at does not distinguish between where the
> event
> came from. It also does not turn off several tasks and then turn
> them back
> on in the same second. In otherwords, the Pseudo code does not
> match what
> I have seen.
>
>
> Which could be why I see the nonsense going on in the systems I have.
>
> I would also point out that the only reason I came up with this sub-
> optimal
> design is that you keep insisting that doing resource scheduling on a
> second by second basis is the way to go. Now, you insist that it
> isn't.
> Which is ti?
>
> Remember, I am the guy that says that we should be slowing down the
> speed
> of the scheduling so that we don't try to do everything at the same
> second.
> A solution you keep rejecting because you want to run resource
> scheduling
> every second.
>
> Also, If you also read the code more carefully, the loop through the
> list
> of events means that each checkpoint event is handled in order one
> by one.
> You know, the code:
>
> schedule-resources (event list)
> iterate through event list
>
>
> No, the end of the loop is NOT the place to do the limit on how
> frequently
> anything can happen. The interprocess communications also
> occurs in
> this
> polling loop, and that has to happen much more frequently.
>
> Again, that was what I understood from your assertions over time as
> to how
> the system is constructed NOW ... with only minor adjustments to
> adapt to
> the changes I suggest.
>
> So, Sir John, you are real good at coming up with ways to prove that
> no
> idea will work.
>
> What we have doesn't work ...
>
> Why don't you propose something that will work?
>
> And, by the way, from your comments I am not convinced you actually
> read
> the code ...
>
_______________________________________________
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.
