"Overworked" is always relative to a particular resource type,
and is based on the LTD for that resource type.
john.mcl...@sybase.com wrote:
> Earlier you indicated that CUDA LTD was not in the same units as CPU LTD.
> However, this brings up a problem. The concept of overworked is in the
> same
> From: Paul D. Buck
> To: TarotApprentice
> Cc: BOINC dev
> Sent: Sunday, 26 April, 2009 11:13:20 AM
> Subject: Re: [boinc_dev] 6.6.20 and work scheduling
>> I'd suggest:
>> a) Download finishes (more work has arrived - we need to check deadlines)
>> b) Task completes (we have a free resource)
IIRC, that was put into place as part of a way to deal with high
priority vs. lower priority items.
I don't remember if it was an internal hospital grid or some form of
internal research grid, but the example that comes to mind is during the
normal course of the grid's operation they process 10-20
On Apr 25, 2009, at 5:30 PM, TarotApprentice wrote:
>> Date: Sat, 25 Apr 2009 14:31:01 -0500
>> From: "John Keck"
>> Subject: Re: [boinc_dev] 6.6.20 and work scheduling
>> To: "Paul D. Buck" , "Richard Haselgrove"
>> > >
>> Cc: BOINC Developers Mailing List ,
>> John McLeod
>> Message-ID: <4
Hello everyone,
Is there something like semaphore or mutex in BOINC that I could use in work
generator and assimilator ?
I got to call some perl scripts in work generator to create new work units, it
keep reminding me some 'sync' problem.
thanks,
-Keye
> Date: Sat, 25 Apr 2009 14:31:01 -0500
> From: "John Keck"
> Subject: Re: [boinc_dev] 6.6.20 and work scheduling
> To: "Paul D. Buck" , "Richard Haselgrove"
>
> Cc: BOINC Developers Mailing List , John McLeod
>
> Message-ID: <49ac83b79e5d462cbe9dc89290e34...@tsi5200w>
> Content-Type: text/pla
On Apr 25, 2009, at 1:53 PM, Richard Haselgrove wrote:
>> I know, Richard you don't see as much need for this, but, this is
>> the reason I cannot do more on the other end.
>>
>> Oh, and I won't even mention the waste of compute time doing
>> nothing once every 10 seconds ...
>
> OK, I'm con
> I know, Richard you don't see as much need for this, but, this is the
> reason I cannot do more on the other end.
>
> Oh, and I won't even mention the waste of compute time doing nothing once
> every 10 seconds ...
OK, I'm convinced - especially if there's a guard time using that
interesting
On Apr 25, 2009, at 12:31 PM, John Keck wrote:
> I definitely agree with Paul; I don't see a good reason to test for
> a CPU reschedule more than once a minute and 5 to 10 minutes seems
> more reasonable with the exception of a resource going idle. In the
> best case we are wasting cycles t
On Apr 25, 2009, at 1:48 AM, Richard Haselgrove wrote:
> Paul D. Buck wrote
>
>> Again, the point being that we still have the issue were BOINC
>> continually changes its mind about what should be running.
>>
>> One of the causes is that we call the schedulling routine so
>> often. But that
I definitely agree with Paul; I don't see a good reason to test for a CPU
reschedule more than once a minute and 5 to 10 minutes seems more reasonable
with the exception of a resource going idle. In the best case we are wasting
cycles that could be used by the science app. In the worst case we k
On Apr 25, 2009, at 1:48 AM, Richard Haselgrove wrote:
> Paul D. Buck wrote
>
>> Again, the point being that we still have the issue were BOINC
>> continually changes its mind about what should be running.
>>
>> One of the causes is that we call the schedulling routine so
>> often. But that
Paul D. Buck wrote
> Again, the point being that we still have the issue were BOINC
> continually changes its mind about what should be running.
>
> One of the causes is that we call the schedulling routine so often. But
> that is not all of it. Even if we do throttle the number of calls to
13 matches
Mail list logo
