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.
