DNETC's Progress%

[Pepo]

My DNETC task dnetc_gpu_NV_normal_832414_0 is now, after 18:36:11 elapsed and 15:48:03 CPU time (although it claims 0.05C+1NV ), at 136.409% progress (according to BT 1.00's Tasks tab, although both its Task Properties dialog and BOINC Manager and client_state.xml tell 0.000%).

Also the Remaining time is being estimated (in the Task Properties dialog) to -04:56:47, although Tasks tab and BOINC Manager show "---" estimate.

How are these values calculated? Could/should the negative ETA estimate be also displayed on the Tasks tab (with highlighted background?)?

When trying to add corresponding rules, a rule for {Remaining time < 0:00:01} is catching the negative time and highlights the task, but a rule for {Progress % > 99.99} does not match it. Should it? Should a rule {Progress % > 100.00} be allowed? (Value 100.00 is invalid). Should a rule {Remaining time < 0:00:00} be allowed? (Values HHH:MM:SS are also not allowed (just d,HH:MM:SS), although they can be preferably selected in the View tab.)

[fred]

My DNETC task dnetc_gpu_NV_normal_832414_0 is now, after 18:36:11 elapsed and 15:48:03 CPU time (although it claims 0.05C+1NV ), at 136.409% progress (according to BT 1.00's Tasks tab, although both its Task Properties dialog and BOINC Manager and client_state.xml tell 0.000%).

Also the Remaining time is being estimated (in the Task Properties dialog) to -04:56:47, although Tasks tab and BOINC Manager show "---" estimate.

How are these values calculated? Could/should the negative ETA estimate be also displayed on the Tasks tab (with highlighted background?)?

When trying to add corresponding rules, a rule for {Remaining time < 0:00:01} is catching the negative time and highlights the task, but a rule for {Progress % > 99.99} does not match it. Should it? Should a rule {Progress % > 100.00} be allowed? (Value 100.00 is invalid). Should a rule {Remaining time < 0:00:00} be allowed? (Values HHH:MM:SS are also not allowed (just d,HH:MM:SS), although they can be preferably selected in the View tab.)

The client reports the est time left, so there is little to calculate.
Probably DNETC as it's not a real BOINC application, reports the wrong estimates, or no estimates at all.
And as you can see the 0.05C+1NV is way of the chart.
A value above 100% is normally invalid but BT allows it, because with some project like this one is handy.

[Pepo]

The tasks already approached 300% Not sure anymore with the negative ETA. Never mind. But I've noticed that BT 1.00 is pretty busy (~10 CPU% on 4-core, 0.26 MB/s I/O writes (not sure which exactly)). After a BT restart, the new instance behaved identically. Then I've snoozed GPU - as this DNETC task disappeared, BT immediately fell back to normal. Starting any other GPU task or the same DNETC task again (surely from zero, as they do not checkpoint) was fine.

Any ideas?

[wicked]

snoozed GPU - as this DNETC task disappeared, BT immediately fell back to normal. Starting any other GPU task or the same DNETC task again (surely from zero, as they do not checkpoint) was fine.

No, not from zero. DNETC tasks have been using the checkpoint feature of Distributed.net clients. Although, they don't seem to always report this correctly to BOINC Client (via their wrapper). Also, there have been some known bugs in their wrapper implementation that can cause erratic reporting of progress. I've fixed them myself (and rewritten the wrapper logic quite a bit, including handling a hang during start) and BT has been behaving for me.

Maybe BT goes overdrive when it sees strange progress numbers or things "closing to 100%" readiness?

[fred]

Maybe BT goes overdrive when it sees strange progress numbers or things "closing to 100%" readiness?

The history fetcher probably, when a tasks nears completion it fetches the history more rapidly.
The only way around this is by disabling the smart mode.

[Pepo]

No, not from zero. DNETC tasks have been using the checkpoint feature of Distributed.net clients. Although, they don't seem to always report this correctly to BOINC Client (via their wrapper). Also, there have been some known bugs in their wrapper implementation that can cause erratic reporting of progress. I've fixed them myself (and rewritten the wrapper logic quite a bit, including handling a hang during start) and BT has been behaving for me.

It was the first time I've noticed a DNETC task going over 100%. And I've never ever noticed DNETC tasks reporting any (BOINC-)official checkpoints. Maybe they really do checkpoint internally, but for me as unaware observer... you understand 

Maybe BT goes overdrive when it sees strange progress numbers or things "closing to 100%" readiness?

The history fetcher probably, when a tasks nears completion it fetches the history more rapidly.
The only way around this is by disabling the smart mode.

Good idea, maybe it was indeed the History fetcher, noticing the task is at around 100%... If, then it should get smart enough to ignore the Smart mode after seeing the task's progress unexpectedly coming over 100%?

[fred]

Good idea, maybe it was indeed the History fetcher, noticing the task is at around 100%... If, then it should get smart enough to ignore the Smart mode after seeing the task's progress unexpectedly coming over 100%?

BT is checking on the remaining time.
A well behaved project should never have a - minus remaining time.
Maybe a request for the project, to update their application.

[Pepo]

Good idea, maybe it was indeed the History fetcher, noticing the task is at around 100%... If, then it should get smart enough to ignore the Smart mode after seeing the task's progress unexpectedly coming over 100%?

BT is checking on the remaining time.
A well behaved project should never have a - minus remaining time.

Yes. Sure. Just that I was not clear on this, where comes remaining time estimate. You wrote that

The client reports the est time left, so there is little to calculate.
Probably DNETC as it's not a real BOINC application, reports the wrong estimates, or no estimates at all.

thus it is coming directly from the application, or is calculated from the client = ((100% - progress%) x elapsed time)?

Maybe a request for the project, to update their application.

Maybe wicked could also know something about...

[wicked]

Maybe a request for the project, to update their application.

Maybe wicked could also know something about...

Sorry, I'm not sure I follow you. About what?

I think I added checkpoint notifications from the wrapper to BOINC Client. I based my work on the sample wrapper provided in BOINC because DNETC wrapper code is not public, AFAICS. So I don't know what they do or don't do these days. However, looking at their latest control file at http://dnetc.net/download/job_2.56.xml they enable Distributed.net checkpoints but not the automatic wrapper checkpoint feature.

You could try to enable <app_msg_receive> logging in BOINC Client and see what numbers DNETC wrapper reports (sometimes funky ones) to the BOINC Client. There's also one value that's not reported from it but rather BOINC Client calculates it on behalf of the wrapper/application. Unfortunately, I don't remember what each of these values were out of my head.

I do remember that there has been a bug in BOINC Client (on the application API part, I think) that affected it's calcuation whenever a task is restarted after checkpointing.