BT 0.69 Observations

[tlsi2000]

Some observations (these may have been there before current version 0.69 )

1) I had pulled 4 days of SETI to cover me for the coming outage, and then I tried to do some parsing out of the different tasks received.  I ran into a limitation of only being allowed to highlight 200 tasks at a time. -- This may be one of those arbitrary 'should-never-have-been-hit' values.

2) The loss of he right-click context menu on the new Projects tab (already mentioned elsewhere)

3) On the Projects tab, if one has multi-cores, if there is quantity of tasks less than the the number of cores, the this estimated value is shown lower than the task's estimated values -- this is not 'precisely' accurate, as a single task of 1 hour / 4 cores does need more than 15 minutes to complete.  I leave this up to you to determine the best way to handle this.   (this actually has been out there for a while, but while you are in that code...)

Otherwise --

The addition of the new Task columns and the ability to do the column changing is great.

Good job on the recent versions in expanding the appearance and user-friendliness of the program !

Thanks.

[fred]

Some observations (these may have been there before current version 0.69 )

1) I had pulled 4 days of SETI to cover me for the coming outage, and then I tried to do some parsing out of the different tasks received.  I ran into a limitation of only being allowed to highlight 200 tasks at a time. -- This may be one of those arbitrary 'should-never-have-been-hit' values.

2) The loss of he right-click context menu on the new Projects tab (already mentioned elsewhere)

3) On the Projects tab, if one has multi-cores, if there is quantity of tasks less than the the number of cores, the this estimated value is shown lower than the task's estimated values -- this is not 'precisely' accurate, as a single task of 1 hour / 4 cores does need more than 15 minutes to complete.  I leave this up to you to determine the best way to handle this.   (this actually has been out there for a while, but while you are in that code...)

Otherwise --

The addition of the new Task columns and the ability to do the column changing is great.

Good job on the recent versions in expanding the appearance and user-friendliness of the program !

Thanks.

1) There is indeed a limitation as there always is one.
But 200 at once should be more than enough in normal life. You can always select a filtered group.
2) Solved.
3) This should be there, for only a minute or so. Because the number of cores is determined by how many tasks, are actually running.
So when out of work, the number of cores should drop as well and the times should correct itself as accordingly.

[Pepo]

3) On the Projects tab, if one has multi-cores, if there is quantity of tasks less than the the number of cores, the this estimated value is shown lower than the task's estimated values -- this is not 'precisely' accurate, as a single task of 1 hour / 4 cores does need more than 15 minutes to complete.

3) This should be there, for only a minute or so. Because the number of cores is determined by how many tasks, are actually running.
So when out of work, the number of cores should drop as well and the times should correct itself as accordingly.

I also think that if my CPDN has e.g. 1 long 12-day-task available and the machine is crunching with full 8 cores, the Projects tab should not try to convince me that there is just "01d,12h (" of work available for the project (I've mentioned it in Re: BT 0.57).

I'm merely understanding this notation as to help me summing the (uniquely divided with available CPUs) numbers together, as if I would like to know, after summing it altogether, how much work is available for my (8) CPUs.

I'd vote for displaying each project's value divided with real max(availCPUs,availTasks) and add 2 more lines into Project properties dialog:

• complete Work available (or Time left) - e.g. 12d05:24:17
• the same value, but divided with the number of currently crunching (=now available) CPUs, like it is now - e.g. 01d12:40:32

[fred]

I also think that if my CPDN has e.g. 1 long 12-day-task available and the machine is crunching with full 8 cores, the Projects tab should not try to convince me that there is just "01d,12h (" of work available for the project (I've mentioned it in Re: BT 0.57).

I'm merely understanding this notation as to help me summing the (uniquely divided with available CPUs) numbers together, as if I would like to know, after summing it altogether, how much work is available for my (8) CPUs.

I'd vote for displaying each project's value divided with real max(availCPUs,availTasks) and add 2 more lines into Project properties dialog:

• complete Work available (or Time left) - e.g. 12d05:24:17
• the same value, but divided with the number of currently crunching (=now available) CPUs, like it is now - e.g. 01d12:40:32

The value is now time/number of actual BOINC cpu's (crunching).
If you see 1d it means the total CPU has only 1d work left. There may be one core that has 12d of work. But practically the 1d is more accurate.
And if the other cores are out of work the value will change to 12d.

[Pepo]

[The value is now time/number of actual BOINC cpu's (crunching).
And if the other cores are out of work the value will change to 12d.

Other cores are crunching other projects' work, so I'm expecting to see the value divided (by the mentioned 8 (not that I do have such CPU )).

[fred]

Other cores are crunching other projects' work, so I'm expecting to see the value divided (by the mentioned 8 (not that I do have such CPU )).

Like project time / cpu's actively crunching the project.

[Pepo]

Other cores are crunching other projects' work, so I'm expecting to see the value divided (by the mentioned 8 (not that I do have such CPU )).

Like project time / cpu's actively crunching the project.

Hmmm... maybe I'm confused now?
While there are still at least nCPUs tasks from other projects available, any project with less than nCPUs tasks will still show up its time divided by (nCPUs) and not (nTasks).

(One day to go, as I read?)

[fred]

Hmmm... maybe I'm confused now?
While there are still at least nCPUs tasks from other projects available, any project with less than nCPUs tasks will still show up its time divided by (nCPUs) and not (nTasks).

(One day to go, as I read?)

It's more like a probability.
I can adjust the following, when there are less tasks than cores on a project. The time for the project is divided by the actual tasks.
So one 1d tasks will give 1d. Two tasks with a total of 10 days will give 5 days.

[Pepo]

While there are still at least nCPUs tasks from other projects available, any project with less than nCPUs tasks will still show up its time divided by (nCPUs) and not (nTasks).

I can adjust the following, when there are less tasks than cores on a project. The time for the project is divided by the actual tasks.
So one 1d tasks will give 1d. Two tasks with a total of 10 days will give 5 days.

(until someone will blame)

[Pepo]

I'm merely understanding this notation as to help me summing the (uniquely divided with available CPUs) numbers together, as if I would like to know, after summing it altogether, how much work is available for my (8) CPUs.

I've just gladly realized that the computer's sums for all projects { Cpu:  nTasks / DDd,HH:MM:SS (nCPUs)  |  Gpu:  nTasks / DDd,HH:MM:SS (nGPUs) } can be displayed in the Gadget window, after letting it display all computers instead of running tasks!

[fred]

I've just gladly realized that the computer's sums for all projects { Cpu:  nTasks / DDd,HH:MM:SS (nCPUs)  |  Gpu:  nTasks / DDd,HH:MM:SS (nGPUs) } can be displayed in the Gadget window, after letting it display all computers instead of running tasks!

Yep, that's my preferred one, so I can do a quick check.