BT 0.62

[John C]

The "Progress % / min"  rule event is exactly what I needed, but though it isn't really using a minute as its sampling and therefore it is firing prematurely.  DNETC only updates the % complete every 15 seconds or so, but then it will jump a couple of %.  Right now, BT is noticing that it goes 3-5 seconds with no progress and then is extrapolating that to be 0% per minute, which is causing the rule to fire when it shouldn't.

Is this tied to the refresh rate?  Any way we can make this rule sample over a longer time period?  Would prefer that it be a full minute between comparisons.
It is now sampled over 28 seconds, you can set a time. This will cause the rule to trigger only if the rule stays valid for a longer period of time. E.g. 5 minutes.

[jjwhalen]

- Add: Show tooltips when the text in a column is too small and the text is truncated.

Thanks for adding the tooltips--they appear to be working well on all tabs/columns.  Especially helpful for task names, some of which are almost laughably long (World Community Grid comes to mind).

[fred]

- Add: Show tooltips when the text in a column is too small and the text is truncated.

Thanks for adding the tooltips--they appear to be working well on all tabs/columns.  Especially helpful for task names, some of which are almost laughably long (World Community Grid comes to mind).

Yep, took some time, this was one of the more complicated ones. Found a lot of solutions that are complex beyond believe and take up a lot of resources.
Finally came up with a rather simple solution that works and has no memory or resource impact. Simple means no more that 200 lines of code.

[fred]

The "Progress % / min"  rule event is exactly what I needed, but though it isn't really using a minute as its sampling and therefore it is firing prematurely.  DNETC only updates the % complete every 15 seconds or so, but then it will jump a couple of %.  Right now, BT is noticing that it goes 3-5 seconds with no progress and then is extrapolating that to be 0% per minute, which is causing the rule to fire when it shouldn't.

Is this tied to the refresh rate?  Any way we can make this rule sample over a longer time period?  Would prefer that it be a full minute between comparisons.

In 0.63 changed to a time base of about 1 minute instead of the 0.5 minute as it is now.
The time window will move along at a pace of about 15 seconds.
I will test this on DNETC@Home

[fred]

The "Progress % / min"  rule event is exactly what I needed, but though it isn't really using a minute as its sampling and therefore it is firing prematurely.  DNETC only updates the % complete every 15 seconds or so, but then it will jump a couple of %.  Right now, BT is noticing that it goes 3-5 seconds with no progress and then is extrapolating that to be 0% per minute, which is causing the rule to fire when it shouldn't.

Is this tied to the refresh rate?  Any way we can make this rule sample over a longer time period?  Would prefer that it be a full minute between comparisons.

In 0.63 changed to a time base of about 1 minute instead of the 0.5 minute as it is now.
The time window will move along at a pace of about 15 seconds.
I will test this on DNETC@Home

And the test..... Another project that is not using the progress at all. Stays at the same progress forever.
Then jumps over to another value and stays there forever.
So the rule won't work because there is no progress at all, for a long long time.
BoincTasks shows progress, because it uses a fall-back mode, when progress is close to 0. It uses the Time left to get a progress anyway.

The only way for this rule to work is to set a very long time like 45:00 (45 minutes)

[Pepo]

The "Progress % / min"  rule event is exactly what I needed, but though it isn't really using a minute as its sampling and therefore it is firing prematurely.  DNETC only updates the % complete every 15 seconds or so, but then it will jump a couple of %.  Right now, BT is noticing that it goes 3-5 seconds with no progress and then is extrapolating that to be 0% per minute, which is causing the rule to fire when it shouldn't.

Is this tied to the refresh rate?  Any way we can make this rule sample over a longer time period?  Would prefer that it be a full minute between comparisons.

...the rule won't work because there is no progress at all, for a long long time.
The only way for this rule to work is to set a very long time like 45:00 (45 minutes)

So the only option for those willing to check it anyway would be a user-settable sampling period. Even though 45 minutes is already far in the region of the "time to switch between projects". Has no sense for such app.

[John C]

The "Progress % / min"  rule event is exactly what I needed, but though it isn't really using a minute as its sampling and therefore it is firing prematurely.  DNETC only updates the % complete every 15 seconds or so, but then it will jump a couple of %.  Right now, BT is noticing that it goes 3-5 seconds with no progress and then is extrapolating that to be 0% per minute, which is causing the rule to fire when it shouldn't.

Is this tied to the refresh rate?  Any way we can make this rule sample over a longer time period?  Would prefer that it be a full minute between comparisons.

In 0.63 changed to a time base of about 1 minute instead of the 0.5 minute as it is now.
The time window will move along at a pace of about 15 seconds.
I will test this on DNETC@Home

And the test..... Another project that is not using the progress at all. Stays at the same progress forever.
Then jumps over to another value and stays there forever.
So the rule won't work because there is no progress at all, for a long long time.
BoincTasks shows progress, because it uses a fall-back mode, when progress is close to 0. It uses the Time left to get a progress anyway.

The only way for this rule to work is to set a very long time like 45:00 (45 minutes)

Drat!  That wouldn't work.  OK, for now I guess I'll just have to monitor total time elapsed.

But the project does report time left?  I wonder if that could tell me something.  I haven't been watching that closely.  Guess I need to start paying closer attention and see if we could do something like time left reduction / minute.

Thanks.

[fred]

So the only option for those willing to check it anyway would be a user-settable sampling period. Even though 45 minutes is already far in the region of the "time to switch between projects". Has no sense for such app.

Indeed 45 min is way too long, but a task that is not reporting any progress for 40 minutes is something strange. But most of the tasks do it on this project.
A one minute sample should should be more than enough for any well behaving project.

[fred]

Drat!  That wouldn't work.  OK, for now I guess I'll just have to monitor total time elapsed.

But the project does report time left?  I wonder if that could tell me something.  I haven't been watching that closely.  Guess I need to start paying closer attention and see if we could do something like time left reduction / minute.

Thanks.

See if you can find a task that is not behaving properly and check what it is doing. A combination of elapsed time and time left.

[jjwhalen]

The "Progress % / min"  rule event is exactly what I needed, but though it isn't really using a minute as its sampling and therefore it is firing prematurely.  DNETC only updates the % complete every 15 seconds or so, but then it will jump a couple of %.  Right now, BT is noticing that it goes 3-5 seconds with no progress and then is extrapolating that to be 0% per minute, which is causing the rule to fire when it shouldn't.

Is this tied to the refresh rate?  Any way we can make this rule sample over a longer time period?  Would prefer that it be a full minute between comparisons.

In 0.63 changed to a time base of about 1 minute instead of the 0.5 minute as it is now.
The time window will move along at a pace of about 15 seconds.
I will test this on DNETC@Home

And the test..... Another project that is not using the progress at all. Stays at the same progress forever.
Then jumps over to another value and stays there forever.
So the rule won't work because there is no progress at all, for a long long time.
BoincTasks shows progress, because it uses a fall-back mode, when progress is close to 0. It uses the Time left to get a progress anyway.

The only way for this rule to work is to set a very long time like 45:00 (45 minutes)

Drat!  That wouldn't work.  OK, for now I guess I'll just have to monitor total time elapsed.

But the project does report time left?  I wonder if that could tell me something.  I haven't been watching that closely.  Guess I need to start paying closer attention and see if we could do something like time left reduction / minute.

Thanks.

DNETC is actually a port of a project from distributed.net to BOINC using the BOINCWrapper package  Typically there are several WUs from the original environment bundled into one BOINC WU.  The BOINC wrapper app only updates "our" completion percentage as each internal task run is completed (or when checkpointing occurs, if it ever does).

Over at Yoyo@home, which also wraps from distributed.net et al, (but with CPU apps only) it can take several hours for percentage done to increment (by 16.5 or 33 percent at a jump)  Time remaining is just an estimate, and may be wildly inaccurate.

I guess when you're porting from one DC environment to another, you can't have everything.  On the other hand, you can always go over to distributed.net and crunch there in the first person.

[jjwhalen]

- Changed: If the IP Address has anything with 127.0.0.1, or anything with localhost the IP Address is changed to localhost.

I tested this parser and it appears to be working fine.  Nice touch for dummies such as myself lol

[jjwhalen]

(from BT v0.60)- Fixed: History: Should be fixed, but it wasn't: Einstein@Home/3.02 Global Correlations S5 search #1 (S5GCESSE2) still showed as GPU task.

I'm sorry to be a pest about this but I never noticed before:

Whatever bug was causing those Einstein (S5GCESSE2) WUs to appear as GPU tasks in History, they also show up in GPU color in the Gadget (still do).  They are definitely OK in History now though   I just reattached Einstein & started running this application again.

[fred]

(from BT v0.60)- Fixed: History: Should be fixed, but it wasn't: Einstein@Home/3.02 Global Correlations S5 search #1 (S5GCESSE2) still showed as GPU task.

I'm sorry to be a pest about this but I never noticed before:

Whatever bug was causing those Einstein (S5GCESSE2) WUs to appear as GPU tasks in History, they also show up in GPU color in the Gadget (still do).  They are definitely OK in History now though   I just reattached Einstein & started running this application again.

Oeps another one.
Plan to change some things with the Gadget as it does it's own works gathering.
Should be picked up from the history, thus eliminating a log to unnecessary traffic.