Quote from: fred on November 18, 2010, 11:58:42 AM
Add: Projects: Extra counter for non CPU intensive tasks like FreeHAL. Format CPU/GPU/LOW, LOW only shown when > 0.
The third value, if displayed, is often some huge random number like 544 372 079 or 1 869 182 049.
Quote from: Pepo on November 18, 2010, 03:02:22 PM
Quote from: fred on November 18, 2010, 11:58:42 AM
Add: Projects: Extra counter for non CPU intensive tasks like FreeHAL. Format CPU/GPU/LOW, LOW only shown when > 0.
The third value, if displayed, is often some huge random number like 544 372 079 or 1 869 182 049.
On my machines this happens if and only if the first 2 values are 0/0.
Another anomaly is that for FreeHAL 8 of my 9 my machines are reporting 0/0/2 even though there is only 1 task running and none uploading or waiting to report either. For WUProp, 1 of the 9 machines is also reporting 0/0/2 when it should be 0/0/1. Interesting that the one reporting 0/0/2 for WUProp is also the only one correctly reporting FreeHAL as 0/0/1.
Quote from: Pepo on November 18, 2010, 03:02:22 PM
Quote from: fred on November 18, 2010, 11:58:42 AM
Add: Projects: Extra counter for non CPU intensive tasks like FreeHAL. Format CPU/GPU/LOW, LOW only shown when > 0.
The third value, if displayed, is often some huge random number like 544 372 079 or 1 869 182 049.
Already on the to do list. ;D
Quote from: fred on November 18, 2010, 03:55:01 PM
Quote from: Pepo on November 18, 2010, 03:02:22 PM
Quote from: fred on November 18, 2010, 11:58:42 AM
Add: Projects: Extra counter for non CPU intensive tasks like FreeHAL. Format CPU/GPU/LOW, LOW only shown when > 0.
The third value, if displayed, is often some huge random number like 544 372 079 or 1 869 182 049.
Already on the to do list. ;D
BTW, thanks for adding the 3rd value, helps a lot here.
QuoteV 0.88
Add: Projects: Menu Set debt.
Add: Projects: Extra counter for non CPU intensive tasks like FreeHAL. Format CPU/GPU/LOW, LOW only shown when > 0.
Add: Tasks: Extra column: Received.
All very useful additions!
QuoteFixed: Tasks: The checkpoint value is sometimes incorrect, when a task isn't running.
Still reports a very high value sometimes at the end of a WU (again, mostly seen in MW).
Quote from: Beyond on November 18, 2010, 03:49:40 PMOn my machines this happens if and only if the first 2 values are 0/0.
Another anomaly is that for FreeHAL 8 of my 9 my machines are reporting 0/0/2 even though there is only 1 task running and none uploading or waiting to report either. For WUProp, 1 of the 9 machines is also reporting 0/0/2 when it should be 0/0/1. Interesting that the one reporting 0/0/2 for WUProp is also the only one correctly reporting FreeHAL as 0/0/1.
Here's another hint if you need it. Now all 9 of the FreeHAL clients are reporting 0/0/2 and all of the WUProp clients 0/0/1. When the one FreeHAL client that was reporting 0/0/1 changed to 0/0/2, it's WUProp values changed from 0/0/2 to 0/0/1.
Quote from: Beyond on November 18, 2010, 04:51:52 PM
Quote from: Beyond on November 18, 2010, 03:49:40 PMOn my machines this happens if and only if the first 2 values are 0/0.
Another anomaly is that for FreeHAL 8 of my 9 my machines are reporting 0/0/2 even though there is only 1 task running and none uploading or waiting to report either. For WUProp, 1 of the 9 machines is also reporting 0/0/2 when it should be 0/0/1. Interesting that the one reporting 0/0/2 for WUProp is also the only one correctly reporting FreeHAL as 0/0/1.
Here's another hint if you need it. Now all 9 of the FreeHAL clients are reporting 0/0/2 and all of the WUProp clients 0/0/1. When the one FreeHAL client that was reporting 0/0/1 changed to 0/0/2, it's WUProp values changed from 0/0/2 to 0/0/1.
That should be enough to find it. It's only a small piece of programming.
Quote from: fred on November 18, 2010, 05:13:55 PM
Quote from: Beyond on November 18, 2010, 04:51:52 PM
Here's another hint if you need it. Now all 9 of the FreeHAL clients are reporting 0/0/2 and all of the WUProp clients 0/0/1. When the one FreeHAL client that was reporting 0/0/1 changed to 0/0/2, it's WUProp values changed from 0/0/2 to 0/0/1.
That should be enough to find it. It's only a small piece of programming.
Well here's some more. When a WUProp WU finishes and reports a WU the field value drops to 0/0. Then WUProp DLs a WU and the field jumps to 0/0/2 while FreeHAL drops to 0/0/1. It looks like between the 2 projects the one with the most recent completed WU shows 0/0/2 while the other shows 0/0/1. Kind of magical ;D. Since both FreeHAL and WUProp have 12 hour WUs it takes a while to test this though.
Quote from: Beyond on November 18, 2010, 07:18:57 PM
When a WUProp WU finishes and reports a WU the field value drops to 0/0. Then WUProp DLs a WU and the field jumps to 0/0/2 while FreeHAL drops to 0/0/1. It looks like between the 2 projects the one with the most recent completed WU shows 0/0/2 while the other shows 0/0/1.
I can confirm Beyond his observation. I have a QCN task from 14:36 and a WUprop task from 20:30, QCN's task count is 0/0/1, WUprop's is 0/0/2, other busy projects with work are x/y, idle projects are 0/0/??
??
??
??
??. Should have been really easy to find.
Strangely, I am getting the "huge random number" on DNETC@HOME, which
a) is a Reserve Project (resource share 0) with no work onboard, and
b) does NOT do NCI in any case.
DNETC currently reads "0/0/1 769 105 279", which only appeared after I aborted a FreeHAL task, bringing its count to 0/0/0.
Also on the same machine (a quad/GPU), FreeHAL currently reads "0/0/1" even though there are 2 NCI WUs onboard & processing (one per two cores selected at the FreeHAL server).
As Fred says, should be an easy fix ;D
Quote from: jjwhalen on November 19, 2010, 12:12:43 AM
Strangely, I am getting the "huge random number" on DNETC@HOME, which
a) is a Reserve Project (resource share 0) with no work onboard, and
b) does NOT do NCI in any case.
DNETC currently reads "0/0/1 769 105 279", which only appeared after I aborted a FreeHAL task, bringing its count to 0/0/0.
The huge random number appears if and only if the first 2 values are 0/0, which is the case for your DNETC (mine too). Any project with no work will show a huge random number :)
The nci issue that we're talking about is different and doesn't show the huge number in field 3.
Even after running benchmarks twice, on localhost, using menu Extra / Run CPU benchmarks / localhost's name - Last time: date+time, the "last time run" value does not get updated - still the same value from benchmark run prior to last BT's restart.
Does it get read just upon the startup?
Quote from: Pepo on November 19, 2010, 05:21:51 PM
Even after running benchmarks twice, on localhost, using menu Extra / Run CPU benchmarks / localhost's name - Last time: date+time, the "last time run" value does not get updated - still the same value from benchmark run prior to last BT's restart.
Does it get read just upon the startup?
It gets reread, but the client takes it's time to report the new time. At my computer it takes up to 30 seconds to report the actual value.
Quote from: fred on November 19, 2010, 05:33:53 PM
Quote from: Pepo on November 19, 2010, 05:21:51 PM
Even after running benchmarks twice, on localhost, using menu Extra / Run CPU benchmarks / localhost's name - Last time: date+time, the "last time run" value does not get updated - still the same value from benchmark run prior to last BT's restart.
Does it get read just upon the startup?
It gets reread, but the client takes it's time to report the new time. At my computer it takes up to 30 seconds to report the actual value.
The first benchmark happened at 17:59, the second at 18:06, I've restarted BT at 18:18 (to read new language file), but the entry was still outdated few seconds prior to the restart.
Quote from: Pepo on November 19, 2010, 05:38:42 PM
Quote from: fred on November 19, 2010, 05:33:53 PM
Quote from: Pepo on November 19, 2010, 05:21:51 PM
Even after running benchmarks twice, on localhost, using menu Extra / Run CPU benchmarks / localhost's name - Last time: date+time, the "last time run" value does not get updated - still the same value from benchmark run prior to last BT's restart.
Does it get read just upon the startup?
It gets reread, but the client takes it's time to report the new time. At my computer it takes up to 30 seconds to report the actual value.
The first benchmark happened at 17:59, the second at 18:06, I've restarted BT at 18:18 (to read new language file), but the entry was still outdated few seconds prior to the restart.
I made a note to do some checking.
I've tried once (twice) more - 2 minutes after the first benchmark nothing happened, but shortly after second benchmark the time was noted. ???
[rant]Damned GPU Collatz, it has no problem to continue to run and then checkpoint even 28 seconds after being suspended for benchmarks. If nCi tasks do stop, then it should too >:([/rant]
Quote from: Beyond on November 19, 2010, 03:31:33 AM
The huge random number appears if and only if the first 2 values are 0/0, which is the case for your DNETC (mine too). Any project with no work will show a huge random number :)
The nci issue that we're talking about is different and doesn't show the huge number in field 3.
Thanks for the clarification, Beyond. The point I was trying to make is that after updating to BT 0.88, DNETC correctly read "0/0/0"
until the FreeHAL task on that host was aborted bringing
its count to 0/0/0, after which both projects displayed the random number. This is the strange behavior I was talking about, related to your NCI issue or otherwise.
Best wishes.
Fred,
Back around v0.56 or so we got a Status "Aborted by project" implemented in Tasks & History, to differentiate from a user abort. Yoyo, for one, uses project abort a lot to keep the server workload down.
That change is still displaying on the History tab, but Tasks has gone back to just plain Status "Aborted" for a project abort. Did you maybe go back to an earlier version of the code in that area?
Quote from: jjwhalen on November 20, 2010, 02:55:15 AM
Fred,
Back around v0.56 or so we got a Status "Aborted by project" implemented in Tasks & History, to differentiate from a user abort. Yoyo, for one, uses project abort a lot to keep the server workload down.
That change is still displaying on the History tab, but Tasks has gone back to just plain Status "Aborted" for a project abort. Did you maybe go back to an earlier version of the code in that area?
I have to check.
Quote from: Pepo on November 19, 2010, 05:44:47 PM
I've tried once (twice) more - 2 minutes after the first benchmark nothing happened, but shortly after second benchmark the time was noted. ???
I checked everything, nothing wrong that I can find.
It may be that the BOINC client rejected the Benchmark result, sometimes it's invalid.
it this get_host_info(HOST_INFO&) that gives the benchmark time. Looks like client problem, if there is a problem. Maybe a too frequent benchmark is rejected as well.
Quote from: jjwhalen on November 20, 2010, 02:55:15 AM
Fred,
Back around v0.56 or so we got a Status "Aborted by project" implemented in Tasks & History, to differentiate from a user abort. Yoyo, for one, uses project abort a lot to keep the server workload down.
That change is still displaying on the History tab, but Tasks has gone back to just plain Status "Aborted" for a project abort. Did you maybe go back to an earlier version of the code in that area?
You can switch off the filter for aborted.
Fixed a bug in V 0.89 to show the real status on 1 filtered task.
Quote from: fred on November 21, 2010, 11:31:43 AM
Quote from: jjwhalen on November 20, 2010, 02:55:15 AM
Fred,
Back around v0.56 or so we got a Status "Aborted by project" implemented in Tasks & History, to differentiate from a user abort. Yoyo, for one, uses project abort a lot to keep the server workload down.
That change is still displaying on the History tab, but Tasks has gone back to just plain Status "Aborted" for a project abort. Did you maybe go back to an earlier version of the code in that area?
You can switch off the filter for aborted.
Fixed a bug in V 0.89 to show the real status on 1 filtered task.
Great; I guess it never occurred to me that the filter acts on just a single line entry that matches the filter criteria -- but why not.
But this raises a new question: if the filter option "Aborted" is checked and the computer has multiple aborts, some
user and some
project, does this mean that the filter will combine them all into a single line entry? I would expect "Aborted by project" to be treated as a completely different Status and not touched by filter criterion "Aborted" ??? I may user-abort 100+ tasks and want them to be filtered. But project aborts are relatively rare and I want them to stand out ;)
Regarding "Set debt":
I agree with Beyond that this is a useful addition. A few points...
1) Projects>Set debt only works if "All computers" is selected & a project is highlighted. If a single computer is selected the menu item is active (not grayed out) but does nothing. Either (in descending order of desirability)
a) Let it call the dialog for that computer, or
b) Make it inactive when a single computer is selected.
2) If the dialog is opened, a project is selected, the data entry fields are left blank, and "Apply" is clicked, this causes debts to be zeroed out for that project. It is very easy to accidentally zero debts that you don't want/can't afford to. Nulls in the data entry fields should not be read in as zeros, and hitting Apply on null fields should result in either no action or an error message. To zero debts, the user should have to deliberately enter "0" "0.0" or some permutation into the data entry field(s) and then click "Apply".
3) Numbers entered into the data entry fields stay there, even after the dialog is closed, until BT is restarted. Data entry fields should be cleared whenever
a) Apply is clicked,
b) A different project is highlighted on the selection list, or
c) The dialog is closed.
Feature request: request the Set debt menu item be added to the Context Menu of the Projects tab, with the same functionality as Projects>Set debt.
Question: will you be adding capability to adjust GPU debts at a later date?
Quote from: jjwhalen on November 22, 2010, 12:27:32 AM
Regarding "Set debt":
I will not improve much on the debt dialog.
The whole debt concept will be gone sooner than later.
I tested, selection a single computer and this seems to work just fine.
Usage go to the project tab, select a project on the right computer and select set debt.
The computer shown in the dialog title is the one that is used
GPU debt is not supported by the client and will never be as the whole debt concept will be gone soon.
In the next version, the apply button will only function only, when there is a number filled out, for both fields.
I would also expect that just matching groups of tasks be put together, including their state. And also not that it would kick in on a single one :)