> I can see it ending up in such a situation that the CC will bump E@H up the
> queue in order that it makes the deadline to the detrement of the other
> three projects running on that machine.
>
In effect that is what i (and probably many others) are doing manually from time to time to keep up with this project.
I am now considering dedicating one of my crunchers exclusively to Einstein and detaching from Einstein on the others.
I hesitate to do this because it feels contrary to the spirit of BOINC but more likely from my learned fear from the early days of SETI Classic when often i found myself with a cold and lonely CPU.
Einstein outages are rare and short and BOINC is able to overcome this easily.
So what am I waiting for?
> > I can see it ending up in such a situation that the CC will bump E@H up
> the
> > queue in order that it makes the deadline to the detrement of the other
> > three projects running on that machine.
> >
Work is downloaded from projects in long-term debt order (highest debt gets first crack). The average debt is maintained at 0. Projects with negative debt do not get to download work unless there is no work available for a CPU, or the total amount of work on the host for all projects is less than the connect every X days value. Therefore if a project needs to use the crunch earliest deadline first mode to complete on time, then it will not be elidgable for work download for a time, and will not be likely to download work for some further time.
> In effect that is what i (and probably many others) are doing manually from
> time to time to keep up with this project.
> I am now considering dedicating one of my crunchers exclusively to Einstein
> and detaching from Einstein on the others.
> I hesitate to do this because it feels contrary to the spirit of BOINC but
> more likely from my learned fear from the early days of SETI Classic when
> often i found myself with a cold and lonely CPU.
> Einstein outages are rare and short and BOINC is able to overcome this
> easily.
> So what am I waiting for?
>
4.35 to become the suggested version?
So dose this mean 4.35 will hurry up and finish a WU, upload the WU, but not report the WU. So all the effort/time to finish before the deadline goes to waste because the report is not done before the deadline ?? If this is true it fixes nothing!
> So dose this mean 4.35 will hurry up and finish a WU, upload the WU, but not
> report the WU. So all the effort/time to finish before the deadline goes to
> waste because the report is not done before the deadline ?? If this is true it
> fixes nothing!
>
>
It will still report automatically under the same conditions as previous clients.
> > So dose this mean 4.35 will hurry up and finish a WU, upload the WU, but
> not
> > report the WU. So all the effort/time to finish before the deadline goes
> to
> > waste because the report is not done before the deadline ?? If this is
> true it
> > fixes nothing!
> >
> >
> It will still report automatically under the same conditions as previous
> clients.
>
Hi
That is my point! If there is no code to force the report before the deadline compleating the WU before the deadline fixes nothing.
> > So what am I waiting for?
> >
> 4.35 to become the suggested version?
>
hehe.
Already running 4.35 on one box.
Your new scheduling code is very impressive. There’s a lot going on there!
Maybe I’m waiting to see if 4.35 can tame Einstein a bit.
One thing that seems to be missing with this version of the CC is a detailed explaination of how this new deadline/timeslicing combo works. Would like to see some of that... Overall though, now that I've had a bit more time to evaluate, it seems to be clearing it up... Another thing that I have noticed with the new CC is that it can have more than one WU on the go from the SAME project on a single CPU system. Although not running at the same time, this should do a good service to those who have WUs queued for same date or consecutive days on one project, where the box in question is doing multiple projects.
Now that I have seen it in action, this new hybrid system looks a whole lot better than just pure timeslicing.
> One thing that seems to be missing with this version of the CC is a detailed
> explaination of how this new deadline/timeslicing combo works. Would like to
> see some of that...
I think it will take a bit for Paul to put it all in his manual ;)
If you look in this Thread over @Seti, you can see some of the features explained.
> > It will still report automatically under the same conditions as previous
> > clients.
> >
> Hi
>
> That is my point! If there is no code to force the report before the deadline
> compleating the WU before the deadline fixes nothing.
>
>
Scheduler RPCs occur under 3 conditions:
1) deadline less than 24 hours away.
2) more work needed.
3) manual.
> 1. Do you think 4.35 handles scheduling of work any better than earlier
> versions?
> 2. Any particular differences you have noticed?
> 3. How many E@H work units did you have on hand when the interval was 3 days?
> 4. Has that number reduced at all yet? (probably too early to say at the
> moment)
> 5. Do you have any finished & uploaded results which still show as "ready
> to report"?
>
In follow-up to questions 1 & 4 Gary...
1. Now I've had time to evaluate the CC (and the CC has had time to evaluate my mess!!) I can say that on the Athlon64 at least, v4.35 handles the deadlines MUCH better than previous versions of the client. The 1900+ is still churning away at the cache, but, based on previous experience, I can't see there being any problem deadines currently.
4. Work isn't downloaded in exactly the same way as previous versions if the CC has had to fight deadlines on a particular project. Anyways, I've split the profiles for the two machines now and put the Athlon64 back to 3days, whilst the 1900+ remains on 1.5 days. What I forgot to mention was that I wasn't helped by a dead PSU in the Athlon64 over the last couple of days.
> I can see it ending up in
)
> I can see it ending up in such a situation that the CC will bump E@H up the
> queue in order that it makes the deadline to the detrement of the other
> three projects running on that machine.
>
In effect that is what i (and probably many others) are doing manually from time to time to keep up with this project.
I am now considering dedicating one of my crunchers exclusively to Einstein and detaching from Einstein on the others.
I hesitate to do this because it feels contrary to the spirit of BOINC but more likely from my learned fear from the early days of SETI Classic when often i found myself with a cold and lonely CPU.
Einstein outages are rare and short and BOINC is able to overcome this easily.
So what am I waiting for?
> > I can see it ending up in
)
> > I can see it ending up in such a situation that the CC will bump E@H up
> the
> > queue in order that it makes the deadline to the detrement of the other
> > three projects running on that machine.
> >
Work is downloaded from projects in long-term debt order (highest debt gets first crack). The average debt is maintained at 0. Projects with negative debt do not get to download work unless there is no work available for a CPU, or the total amount of work on the host for all projects is less than the connect every X days value. Therefore if a project needs to use the crunch earliest deadline first mode to complete on time, then it will not be elidgable for work download for a time, and will not be likely to download work for some further time.
> In effect that is what i (and probably many others) are doing manually from
> time to time to keep up with this project.
> I am now considering dedicating one of my crunchers exclusively to Einstein
> and detaching from Einstein on the others.
> I hesitate to do this because it feels contrary to the spirit of BOINC but
> more likely from my learned fear from the early days of SETI Classic when
> often i found myself with a cold and lonely CPU.
> Einstein outages are rare and short and BOINC is able to overcome this
> easily.
> So what am I waiting for?
>
4.35 to become the suggested version?
BOINC WIKI
So dose this mean 4.35 will
)
So dose this mean 4.35 will hurry up and finish a WU, upload the WU, but not report the WU. So all the effort/time to finish before the deadline goes to waste because the report is not done before the deadline ?? If this is true it fixes nothing!
Stanley
Boinc Wikipedia - the FAQ in active change
> So dose this mean 4.35 will
)
> So dose this mean 4.35 will hurry up and finish a WU, upload the WU, but not
> report the WU. So all the effort/time to finish before the deadline goes to
> waste because the report is not done before the deadline ?? If this is true it
> fixes nothing!
>
>
It will still report automatically under the same conditions as previous clients.
BOINC WIKI
BOINCing since 2002/12/8
> > So dose this mean 4.35
)
> > So dose this mean 4.35 will hurry up and finish a WU, upload the WU, but
> not
> > report the WU. So all the effort/time to finish before the deadline goes
> to
> > waste because the report is not done before the deadline ?? If this is
> true it
> > fixes nothing!
> >
> >
> It will still report automatically under the same conditions as previous
> clients.
>
Hi
That is my point! If there is no code to force the report before the deadline compleating the WU before the deadline fixes nothing.
Stanley
Boinc Wikipedia - the FAQ in active change
> > So what am I waiting
)
> > So what am I waiting for?
> >
> 4.35 to become the suggested version?
>
hehe.
Already running 4.35 on one box.
Your new scheduling code is very impressive. There’s a lot going on there!
Maybe I’m waiting to see if 4.35 can tame Einstein a bit.
One thing that seems to be
)
One thing that seems to be missing with this version of the CC is a detailed explaination of how this new deadline/timeslicing combo works. Would like to see some of that... Overall though, now that I've had a bit more time to evaluate, it seems to be clearing it up... Another thing that I have noticed with the new CC is that it can have more than one WU on the go from the SAME project on a single CPU system. Although not running at the same time, this should do a good service to those who have WUs queued for same date or consecutive days on one project, where the box in question is doing multiple projects.
Now that I have seen it in action, this new hybrid system looks a whole lot better than just pure timeslicing.
> One thing that seems to be
)
> One thing that seems to be missing with this version of the CC is a detailed
> explaination of how this new deadline/timeslicing combo works. Would like to
> see some of that...
I think it will take a bit for Paul to put it all in his manual ;)
If you look in this Thread over @Seti, you can see some of the features explained.
Grüße vom Sänger
> > It will still report
)
> > It will still report automatically under the same conditions as previous
> > clients.
> >
> Hi
>
> That is my point! If there is no code to force the report before the deadline
> compleating the WU before the deadline fixes nothing.
>
>
Scheduler RPCs occur under 3 conditions:
1) deadline less than 24 hours away.
2) more work needed.
3) manual.
BOINC WIKI
BOINCing since 2002/12/8
> 1. Do you think 4.35
)
> 1. Do you think 4.35 handles scheduling of work any better than earlier
> versions?
> 2. Any particular differences you have noticed?
> 3. How many E@H work units did you have on hand when the interval was 3 days?
> 4. Has that number reduced at all yet? (probably too early to say at the
> moment)
> 5. Do you have any finished & uploaded results which still show as "ready
> to report"?
>
In follow-up to questions 1 & 4 Gary...
1. Now I've had time to evaluate the CC (and the CC has had time to evaluate my mess!!) I can say that on the Athlon64 at least, v4.35 handles the deadlines MUCH better than previous versions of the client. The 1900+ is still churning away at the cache, but, based on previous experience, I can't see there being any problem deadines currently.
4. Work isn't downloaded in exactly the same way as previous versions if the CC has had to fight deadlines on a particular project. Anyways, I've split the profiles for the two machines now and put the Athlon64 back to 3days, whilst the 1900+ remains on 1.5 days. What I forgot to mention was that I wasn't helped by a dead PSU in the Athlon64 over the last couple of days.