BT 0.88

[Pepo]

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.

[Beyond]

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.

[fred]

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. 

[Beyond]

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. 

BTW, thanks for adding the 3rd value, helps a lot here.

V 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!

Fixed: 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).

[Beyond]

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.

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.

[fred]

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.

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.

[Beyond]

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 .  Since both FreeHAL and WUProp have 12 hour WUs it takes a while to test this though. 

[Pepo]

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.

[jjwhalen]

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

[Beyond]

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.

[Pepo]

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?

[fred]

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.

[Pepo]

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.

[fred]

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.

[Pepo]

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]