Thanks Kathryn, I've done that.

When I drafted my addition to Mike's ticket I was astonished to see that I could apparently have submitted my extra comment under the name 'Anonymous'! As we all already have the option to choose a forum name that anonymises our real-life identity to the extent we want, I see no need for anonymous Trac requests.

If members wish for whatever reason to dissociate their Trac request from their forum identity, I think they can already register for Trac using a different nickname. Surely this provides sufficient freedom and protection?

---

Project switching.
Not reading all of this thread to see if it has been asked before.
Is possible to get project switching delay when project running is over 99% complete AND less than 10 minutes to completion.

Fed up of present situation where I have: 02:49:38 | 99.468% | 00:00:47 | Waiting to run.

Andy

Is possible to get project switching delay when project running is over 99% complete AND less than 10 minutes to completion.

Fed up of present situation where I have: 02:49:38 | 99.468% | 00:00:47 | Waiting to run.

Or more advanced version: a possibility to mark (e.g. per RPC) few single WUs to be prioritized for crunching (unless some other project/WU have deadline miss).

This would mean adding priority property to each WU (or result). Currently all WUs sort of share the same priority, WUs with deadline miss can be considered as having higher priority.

Peter

Is possible to get project switching delay when project running is over 99% complete AND less than 10 minutes to completion.

Fed up of present situation where I have: 02:49:38 | 99.468% | 00:00:47 | Waiting to run.

Or more advanced version: a possibility to mark (e.g. per RPC) few single WUs to be prioritized for crunching (unless some other project/WU have deadline miss).

This would mean adding priority property to each WU (or result). Currently all WUs sort of share the same priority, WUs with deadline miss can be considered as having higher priority.

Peter

That's also what I miss the most. I end up suspending projects everytime by hand just to get almost finished WUs out. It would be very helpful to have some kind of user configurable "threshold" for WU switching. E.g. WU's that are X % finished and end within Y hours should keep crunching.

I would also love to see in BOINC manager an overview with most data on one single tabulator:

- project progresses from tabulator "Tasks" (progress, status, to completion)
- statistic charts from tabulator "Statistics"
- last messages from tabulator "Messages"

---

BOINC 7.2.42 (x86_64) on Linux Ubuntu 16.04 (64 Bit), AMD APU 7850K 3.7 GHz, 32 GB RAM.

"Force" Task.

Equivalent to "Resume" suspended tasks, tasks in state "Waiting to run" should be able to be "forced" to continue. Reason: almost finished work units can be finished faster when the user tells. My workaround so far: suspending all other running tasks until the specific task continues - and when it's finished resuming the suspended tasks. But this requires the user to resume the other tasks. A single function "Force" would do this without any further intervention.

---

BOINC 7.2.42 (x86_64) on Linux Ubuntu 16.04 (64 Bit), AMD APU 7850K 3.7 GHz, 32 GB RAM.

More task informations:

1. Progress of the scheduled time (e.g. if each of the tasks can calculate for 1 hour, the progress should start at 0% on each task switch end end with 100% when the hour is over (and the task gets to "Waitung to run").

2. Indicator: which "Waiting to run" task is next? Or even better: an order number of the tasks to come next (selection "priority").

---

BOINC 7.2.42 (x86_64) on Linux Ubuntu 16.04 (64 Bit), AMD APU 7850K 3.7 GHz, 32 GB RAM.

1. Progress of the scheduled time (e.g. if each of the tasks can calculate for 1 hour, the progress should start at 0% on each task switch end end with 100% when the hour is over (and the task gets to "Waitung to run").

As a separate column or replacing the current progress bar? I think if it replaced the current progress bar it would be extremely confusing. End users may think that the task is continuely restarting.

2. Indicator: which "Waiting to run" task is next? Or even better: an order number of the tasks to come next (selection "priority").

This info, as far as I know, can be accessed by setting flags in cc_config.xml. But my understanding is that these things are calculated at the switch interval. And things can change from one switch point to the next. Someone correct me if I'm wrong (not that something like that would ever happen, LOL).

---

Kathryn :o)

1. Progress of the scheduled time (e.g. if each of the tasks can calculate for 1 hour, the progress should start at 0% on each task switch end end with 100% when the hour is over (and the task gets to "Waitung to run").

As a separate column or replacing the current progress bar? I think if it replaced the current progress bar it would be extremely confusing. End users may think that the task is continuely restarting.

A separate column or - even better - 2 progress bars in the same column cell (taking half the height of the cell) ... ;-)

---

BOINC 7.2.42 (x86_64) on Linux Ubuntu 16.04 (64 Bit), AMD APU 7850K 3.7 GHz, 32 GB RAM.

"Force" Task.

Equivalent to "Resume" suspended tasks, tasks in state "Waiting to run" should be able to be "forced" to continue. Reason: almost finished work units can be finished faster when the user tells.

Wrong. They will crunch at the same speed, not faster. I think you mean sooner. When you think about it, if task A finishes sooner then task B has to wait until later. Over the long run the work gets returned at the same rate. The only purpose it serves is to reduce the number of waiting tasks on the list. Does that serve any useful purpose? Is there any real need for it? None whatsoever. You can avoid having to look at all those messy unfinished tasks cluttering up your list of tasks by simply going out for a nice long walk. If the tasks get returned before the deadline then that's soon enough. If that is not soon enough then the projects have the option of shortening the deadline.

My workaround so far: suspending all other running tasks until the specific task continues - and when it's finished resuming the suspended tasks. But this requires the user to resume the other tasks. A single function "Force" would do this without any further intervention.

Your workaround serves no purpose. It's not a workaround, it's just a make work project to solve a problem that does not exist. To automate the needless work you're doing would be a bad waste of some programmer's valuable time.

Well, some projects have small WUs and some have very long (e.g. climateprediction WUs use several months!). The normal BOINC scheduler switches to the long running climate prediction WU (12% finished) even though a small WU from another project (90% finished) could be finished within the next hour. With many tasks this is an unnecessary pause for such small WUs.

---

BOINC 7.2.42 (x86_64) on Linux Ubuntu 16.04 (64 Bit), AMD APU 7850K 3.7 GHz, 32 GB RAM.

Well, some projects have small WUs and some have very long (e.g. climateprediction WUs use several months!). The normal BOINC scheduler switches to the long running climate prediction WU (12% finished) even though a small WU from another project (90% finished) could be finished within the next hour. With many tasks this is an unnecessary pause for such small WUs.

Which is why CPDN (and all other Climate projects) tell you not to attach to their project together with other projects, no matter how fast your PC is.

---

I can't remember reading that advice on cpdn for any computer however fast, though we've sometimes had to tell the owners of slow computers that they need to make a realistic choice. Even if you're running one of the mammoth 160-year models on a slowish machine, you can occasionally stop it and get get short workunits from other projects. But in such cases it may be best to switch projects or tasks manually and do a few days/weeks on the other project.

If you let boinc do the task switching and you're running a cpdn SAP model, you need to ensure that the time switch interval is longer than the SAP checkpoint interval. Otherwise the SAP might never ever advance.....

Anyway, cpdn members are now getting the option of choosing relatively shorter models instead of the mammoths if they want, so multi-projects crunchers may prefer these.

But please, everybody, finish your current cpdn models first!

---

That's right. I don't think any project can override the rules.

It's true that the cpdn servers don't enforce the workunit deadline.

---

I can't remember reading that advice on cpdn for any computer however fast, though we've sometimes had to tell the owners of slow computers that they need to make a realistic choice.

That's then probably what I was confused with. Thanks mo.v.

---

"Force" Task.

Equivalent to "Resume" suspended tasks, tasks in state "Waiting to run" should be able to be "forced" to continue. Reason: almost finished work units can be finished faster when the user tells. My workaround so far: suspending all other running tasks until the specific task continues - and when it's finished resuming the suspended tasks. But this requires the user to resume the other tasks. A single function "Force" would do this without any further intervention.

I would like to see this too. However I am hesitant to admit it since it would likely take the title for most abused test option. It would be useful to force a specific project or task to run to verify that some new feature is working or a bug has been squished. Suspending projects is more trouble than it is worth most of the time since it usually results in excess work from a project that you were not expecting.

---

BOINC WIKI

BOINCing since 2002/12/8

"Force" Task.

Equivalent to "Resume" suspended tasks, tasks in state "Waiting to run" should be able to be "forced" to continue. Reason: almost finished work units can be finished faster when the user tells. My workaround so far: suspending all other running tasks until the specific task continues - and when it's finished resuming the suspended tasks. But this requires the user to resume the other tasks. A single function "Force" would do this without any further intervention.

I would like to see this too. However I am hesitant to admit it since it would likely take the title for most abused test option. It would be useful to force a specific project or task to run to verify that some new feature is working or a bug has been squished. Suspending projects is more trouble than it is worth most of the time since it usually results in excess work from a project that you were not expecting.

The way I interpreted the rules in 5.8 and up was that even suspended work was counted towards the buffer to stop over committing the overall client. Tested this several times and absolute no additional work was being pulled from any active project.

Your request is a little bit like mine. My BOINC client gets over committed because it tries to pull down enough work to keep all CPU's busy even with the backlog switches set to zero. If several projects are suspended, those that aren't will keep pull down wu's until all the other parameters are satisfied unless I also shut off work requests. Its way complicated. All I want is to limit (a ceiling) the number of wu's any one project in my pool of projects can have on the client regardless of the state of the wu's on the client. Simple. That would balance everything fine. Like you I'm having to manually shut off work unit requests. During the day when I need part or all of my system back if I don't very carefully turn off new work requests AND THEN suspend the projects it causes more work to come down and the over commit happens etc..

As there seems not to be a lot of interest for the feature so far and iot doesn't look like its going to happen I'm trying to figure it out.

---

Ty < finally.. thinks he's got it fixed now

On the subject of "Force Task", could it be implemented to operate on only one task. So that once that chosen task has completed everything returns to normal.

I see it as;
select task.
click Force button,
Force button is now greyed out for other tasks, but can be used to un-force the selected task.
task finishes,
BOINC returns to normal operation and Force button is free to be used for another task.

Of course if you really wanted to get complicated then it could be expanded to one "Force"/cpu.

Andy

edit] I would probably want to see the "Force" button greyed out if BOINC was in EDF. [/edit

During the day when I need part or all of my system back if I don't very carefully turn off new work requests AND THEN suspend the projects it causes more work to come down and the over commit happens etc..

As there seems not to be a lot of interest for the feature so far and iot doesn't look like its going to happen I'm trying to figure it out.

If you crunch a lot of projects it can be confusing and a nuisance. One very simple yet very effective solution... write scripts that automate turning new work requests on/off. They would call boinccmd.exe with the --project url op args. Suppose you crunch LHC and ABC. The script to turn off new work would be like:

boinccmd --host localhost --passwd <password> --project http://abcathome.com/ nomorework
boinccmd --host localhost --passwd <password> --project http://lhcathome.cern.ch/lhcathome nomorework

The turn work on script would be like:

boinccmd --host localhost --passwd <password> --project http://abcathome.com/ allowmorework
boinccmd --host localhost --passwd <password> --project http://lhcathome.cern.ch/lhcathome allowmorework

If you need more details on making the scripts work then may I suggest starting a new thread on that matter rather than cluttering this thread.

Well, to automate it I'd have to set up a daemon that would look about twice a second at the work pool to determine which commands to issue. Thats an idea. I'll ponder it for awhile. Thanks.

---

Ty < finally.. thinks he's got it fixed now

On the subject of "Force Task", could it be implemented to operate on only one task. So that once that chosen task has completed everything returns to normal.

I see it as;
select task.
click Force button,
Force button is now greyed out for other tasks, but can be used to un-force the selected task.
task finishes,
BOINC returns to normal operation and Force button is free to be used for another task.

Of course if you really wanted to get complicated then it could be expanded to one "Force"/cpu.

Andy

edit] I would probably want to see the "Force" button greyed out if BOINC was in EDF. [/edit

I think that feature could be very useful for a box that's over committed with lots of projects. Consider the case of a small mix of projects though (my case)(i.e. a few more than the number of cpu's say). Then, IF we have a "ceiling on the number of tasks any one project could have open" feature I think a BOINC would simply meet its targets without any need for further human intervention once the pool is initially set up.

For the case there are lots of work units pulled down I've seen a few go to sleep for a little while even in running state. They are all low priority in XP. I get the impression XP may actually be what's responsible for putting some of them to sleep instead of BOINC. They run as separate tasks in XP after all.

If you have a whole lot of projects in the execution pool the feature to put a ceiling on the number of wu's open per project like I have proposed isn't going to help much. For that case the box is already over committed with projects. The best a ceiling feature might do for the "tons-of-projects" case would be to help keep the work pool balanced when some projects are manually suspended or perhaps when a bunch of them run out of out of work at the same time.

---

Ty < finally.. thinks he's got it fixed now

In my priorities concept, I'd assign some base (e.g. 0) priority to all "Normal" tasks and a higher (e.g. 1) priority to all "Force" tasks. The "EDF" tasks would be asigned an even higher (e.g. 2) priority.

Boinc would only do usual RR scheduling among the tasks with highest priority (OK, EDF tasks posibly do some sort of EDF scheduling), but (as usual) checking all tasks for posible deadline problems.

On the subject of "Force Task", could it be implemented to operate on only one task. So that once that chosen task has completed everything returns to normal.

I see it as; select task. click Force button, Force button is now greyed out for other tasks, but can be used to un-force the selected task.

Why not make it arbitrarily on any number of tasks? If it would be limited to one task only, those requiring the functionality would for sure either need to babysit until the single task is finished and continue on another one, or need again to suspend some projects.

I would probably want to see the "Force" button greyed out if BOINC was in EDF.

This would be accomplished by asigning the "EDF" tasks the highest priority. This way any task(s) with possible deadline miss would automatically take precedence, thus the system would not be user-error-prone (to forgetting (un)suspending the projects and switching network off/on).

Peter

Could the 'Jump to unread posts' function please be made to work again on this forum? Has a recent forum software upgrade messed this function up?

---