Tag for 6.10.5 release, all platforms boinc_core_release_6_10_5
- Mgr: skip exit confirmation dialog if user pressed emergency Exit button on AsyncRPCDlg
- Mac installer: ask user whether to allow non-administrative users to run and control BOINC
- Mac installer: create a new command-line tool AddRemoveUser; updated ReadMe file

- client: add code for faking ATI GPUs
- client: cap time_stats dt at 2 weeks, so people upgrading to 6.10 won't get big drop in on_frac.
- client: fix bug in RR simulation: start only enough jobs to fill CPUs per project, not all the CPU jobs at once. I'm not sure how much difference this makes, but this is how it's supposed to work.
- client: if app_info.xml doesn't specify flops, use an estimate that takes GPUs into account.
- client: if it's been more than 2 weeks since time stats update, don't decay on_frac at all.
- client: save space in req msg. Didn't make much difference.
- client: fix bug in FIFO selection of coproc jobs (Comment by David: senility setting in?)
- client: add <fraction_done> to boinc_task_state.xml
- client: change order in poll loop so that:
1) job finishes
2) job gets marked as "ready to report"
3) scheduler RPC is initiated
Hopefully this won't have an unintended side-effect.

- client: tweak policy for device busy time. Should eliminate some spurious "job won't complete by deadline" msgs.
- client: cap project-supplied backoffs at 28 days
- client: anal-retentive alphabetization
- client and scheduler RPC: add optional <cpu_backoff>, <cuda_backoff>, and <ati_backoff> elements to scheduler reply. These specify backoffs for the resource types, overriding the existing backoff mechanism. Projects can supply these if they don't have apps of a particular type and don't want to get periodic requests for them.

Any difference between this and Crunch3r's preview version?

Any difference between this and Crunch3r's preview version?

Pretty sure that there are a few as they were only done in the last few hours ... at least according to the check-in notes I looked at this morning ...

The biggest one I see is the one where DA finally took a look at RR Sim and admitted it was broken.

the others that will make a difference are the caps on the stats so you don't get the huge fluctuation becasue of the long standing bug ...

Still wants to try and download a lot of SETI work, I set NNW for the time being.

---

I just tried it, aside from trying and succeeding in downloading a bunch more WCG work (CPU idle it thought) it also screwed up one of the numbers for back off to this super long number which it happily stored in the client state file ...

Ugh ... back to 6.10.3 which at least almost works right ...

6.10.5 by my test is fatally flawed and will ask for the full queue of work in each request until you NNT it ... I just posted a log on BOINC Alpha and relevant lines ...

I do no know if the version by Crunch3r has this error or not, though I would suspect it does and this may well be the error that is in 6.10.4 as well ... maybe if the UCB types will look at it they can fix the issue ...

I downloaded it from Crunch3r's post and it did that also.

---

Ahrgh, now that explains why my i7 was flooded with PG Wus next to my Milkys crunching on my ATI.
I had to kill 600 PG WUs ore even more. Of course the client downloaded them over night... :-(
And it stopped even my Milkys from being processed as it only wanted to crunch the zillions of PG WUs. *sigh*


Back to 6.6 20. :-)

---

Lovely greetings, Cori

Ahrgh, now that explains why my i7 was flooded with PG Wus next to my Milkys crunching on my ATI.
I had to kill 600 PG WUs ore even more. Of course the client downloaded them over night... :-(
And it stopped even my Milkys from being processed as it only wanted to crunch the zillions of PG WUs. *sigh*


Back to 6.6 20. :-)

In my experience 6.6.20 is one of the worst choices to fall back to ... YMMV ... I have had good luck with (and am currently running) 6.6.28, 6.6.33 and 6.6.36 (Mac version)

The dt number corruption should be fixed in 6.10.6; but no notes on the unconstrained work fetch yet ... at its simplest the issue seems to be that the client takes no notice of the work on hand and keeps asking for the full queue size each time. The only limiting factor then becomes the server refusing to issue more work... which as most have noted can be a very high number.

For list constrained projects like MW or GPU Grid this is not an issue because you cannot get that many tasks ... but on project like SaH you can get thousands ...

I have no problems at all with 6.6.20.

---

Calm Chaos Forum...Join Calm Chaos Now

I have no problems at all with 6.6.20.

6.6.20 has a really nasty bug (which has intermittently shown up in other releases) where tasks take twice as long as normal to complete. This can happen with GPU or CPU tasks. It hit me on GPU Grid and two other people on Rosetta and SaH (AP) respectfully.

If it works for you thats cool ... but, that scheduling issue has never been found and if you are not paying attention may or may not show up in a way you can notice ...