Maybe in 6.6.27; assuming that the developers will note my suggestions for some changes to fix several bugs... not going to hold my breath though ...

A suggestion to pass on to the BOINC developers:

Modify the code for assigning a new workunit to a slot so that it will not assign any new workunit to a slot which still contains a file named boinc_lockfile left over from a previous workunit. Instead, use some other slot, even if a new slot directory must be created for this purpose.

It seems that, at least under Vista SP1, those files are so hard to delete manually without a reboot that some other method is needed to avoid them.

This change would avoid the problems I've seen on a few BOINC projects about files not cleaned up properly at the end of a previous workunit preventing any more workunits from running successfully in the same slot until after the next reboot.

If you want to search for projects with this problem, Rosetta@home and Ralph@home have it the most often among the projects I participate in, and call it the lockfile problem.

A long known problem.

I am wondering if it is an artifact of the fact that they preempt some tasks without proper checkpointing tests. I posted an analysis on Alpha list this week end, though the most likely outcome is that it will be ignored. Sadly, it is a small change (one line) but it is most likely to be ignored. That is what history says will happen.

Trying it on my own is a useless exercise in that I have never been able to get a working version compiled and if I did I cannot get it to work because of the new permissions regime they have. And even if I did, they would never believe me if I told them it worked.

Doesn't it compile in VS2005 now? That should be easier than in previous versions to debug?

Rob

Doesn't it compile in VS2005 now? That should be easier than in previous versions to debug?

Rob

Doesn't it compile in VS2005 now? That should be easier than in previous versions to debug?

Rob

I don't know, I was struggling with the directions to make a windows environment and after about 6 hours had to give up. The instructions did not match the reality and you have to install lots of different software items to get going.

Probably would not matter. even if I told them it worked and supplied the changes they would do something else. That is what history says would happen.

Changes for 6.6.27

- removed outdated translation files; updated template
- client: view 2 GPUs as equivalent if their memory differs by <30%. (maybe their memory differed slightly from the most capable one)
- client: simplify enforce_schedule(), and maybe fix bugs.
New approach: take the "ordered_schedule_results" list, add running jobs that haven't finished their time slice, and order the result appropriately. Then run jobs in order until CPUs are filled. Simpler and clearer than the old way.

= client: fix compiler warning