Minor bug:
While checking the implementation of
QuoteFixed: Task Properties doesn't show elapsed and CPU time, when a task is completed,
which appears to be working fine, I noticed that "Fraction done" in Task Properties for a completed task reads 0.000%. It may have been that way since the task property sheet was implemented, and I just never noticed before. Fraction done for tasks in progress appears to be tracking OK.
Not exactly the end of the world, but... :)
This isn't specifically a BT 0.83 comment, but I'm wondering how often the "debt" column is updated. It seems like the update is never, but I'm guessing it's really a long time. I've had to restart BT to get an update on the number. I've seen this behavior since it was added as a feature. I haven't been able to Grok the logic of this :)
Can it be updated a bit sooner than it is at the moment? Or at least tell me what causes it to be updated.
Rick
Quote from: Purple Rabbit on October 24, 2010, 09:24:26 PM
This isn't specifically a BT 0.83 comment, but I'm wondering how often the "debt" column is updated. It seems like the update is never, but I'm guessing it's really a long time. I've had to restart BT to get an update on the number. I've seen this behavior since it was added as a feature. I haven't been able to Grok the logic of this :)
Can it be updated a bit sooner than it is at the moment? Or at least tell me what causes it to be updated.
Rick
I put it in the to do list to check.
The value comes out of the results, they are normally completely updated by the BOINC client on a complete client state refresh.
This happens only when there is new work arriving from any project. Or on a restart of BoincTasks.
Quote from: jjwhalen on October 24, 2010, 06:18:40 PM
I noticed that "Fraction done" in Task Properties for a completed task reads 0.000%....
While speaking about "Task properties", I've tried to check it and got an empty Properties window. Then I've noticed that the selected "task" is a filtered item consisting of multiple tasks, waiting to be reported.
Maybe if only such filtered tasks are selected, where the output would be an empty Properties window, then the "Properties" context menu entry could be grayed out and not selectable (if it could be distinguished that early).
Quote from: Pepo on October 25, 2010, 09:00:23 AM
Quote from: jjwhalen on October 24, 2010, 06:18:40 PM
I noticed that "Fraction done" in Task Properties for a completed task reads 0.000%....
While speaking about "Task properties", I've tried to check it and got an empty Properties window. Then I've noticed that the selected "task" is a filtered item consisting of multiple tasks, waiting to be reported.
Maybe if only such filtered tasks are selected, where the output would be an empty Properties window, then the "Properties" context menu entry could be grayed out and not selectable (if it could be distinguished that early).
I'm getting sometimes a blank windows when pointed to a finished task, but closed window and task properties again and data appear in the window.
always the fraction done in the case of the ended tasks are 0,00%, should be 100,00%??
Quote from: Corsair on October 25, 2010, 10:01:20 AM
1) I'm getting sometimes a blank windows when pointed to a finished task, but closed window and task properties again and data appear in the window.
2) always the fraction done in the case of the ended tasks are 0,00%, should be 100,00%??
1) Closing does nothing, but it may some time for the properties data appears.
2) Bug.
BT connectivity issue on linux when changing BOINC prefs ????
I got 2 machines (windows and linux) on remote location, when I tried to change boinc prefs on linux box, it start on disappearing and reappearing on BT resulting in uncontrollable host (like the game whack-a-mole). I have to deselect the host and select it again so BT will be back in normal operation. In the said remote location, changing boinc prefs on windows box doesn't have any issues.
anyone ideas?
Interesting observation: I have a partially crunched MW task, which was apparently preempted just after a checkpoint. From its Properties:
Name de_separation_82_2s_10_1_423223_1287757472_0
Application MilkyWay@Home 40 <--
State Waiting to run
Received 22.10.10 16:25
Report deadline 30.10.10 16:25
Resources
CPU time at last checkpoint 01d,10:03:45 <--
CPU time 01d,10:03:46 <--
Elapsed time 01d,12:09:16
Estimated time remaining 00:27:52
Fraction done 98.732 %
Because of the CPU times difference, the "Checkpoint" column shows 00:00:01.
It is the only MW task. When I set "Filter (combine) tasks on -> Waiting to run", this one CPU second since the last checkpoint suddenly gets highlighted, IMO erroneously.
As it is my only task in "Waiting to run" state, I can not compare it to other tasks... No, I can. I've let one more Ready task run and then I've got also a WCG task with 8 second checkpoint CPU time difference highlighted. But just in the filtered mode.
(A bit later, a running ibercivis task got highlighted too, but correctly, the value is already 10, later 17 minutes.)
Another Properties-related question: the application's version is stored as a pure integer:
<app_version>
<version_num>40</version_num>
</app_version>
The Properties seem to display exactly the same number, but the GUI shows user-friendly "0.40 MilkyWay@Home". That's fine. How is the user-friendly version number built? Simply as a float divided by 100? Because I wondered how would be a sixtrack app with <version_num>420900</version_num> displayed - as "4209.00 SixTrack"?
Quote from: Pepo on October 28, 2010, 08:11:51 AM
Because of the CPU times difference, the "Checkpoint" column shows 00:00:01.
It is the only MW task. When I set "Filter (combine) tasks on -> Waiting to run", this one CPU second since the last checkpoint suddenly gets highlighted, IMO erroneously.
As it is my only task in "Waiting to run" state, I can not compare it to other tasks... No, I can. I've let one more Ready task run and then I've got also a WCG task with 8 second checkpoint CPU time difference highlighted. But just in the filtered mode.
(A bit later, a running ibercivis task got highlighted too, but correctly, the value is already 10, later 17 minutes.)
The Properties seem to display exactly the same number, but the GUI shows user-friendly "0.40 MilkyWay@Home". That's fine. How is the user-friendly version number built? Simply as a float divided by 100? Because I wondered how would be a sixtrack app with <version_num>420900</version_num> displayed - as "4209.00 SixTrack"?
MW doesn't checkpoint much. I see the GPU version not checkpointing at all. Or not reporting it.
The version number is an integer and is always divided by 100 to get the real version number.
In the task properties it's a bug.... is should be 0.40
Quote from: fred on October 28, 2010, 10:31:35 AM
MW doesn't checkpoint much. I see the GPU version not checkpointing at all. Or not reporting it.
(It was CPU version of MW.)
Since I've noticed and am monitoring it, I'm confident it is not about MW (seen on a dozen of different projects' tasks), it is about
ANY waiting task and filtering switched on.
Quote from: fred on October 28, 2010, 10:31:35 AM
MW doesn't checkpoint much. I see the GPU version not checkpointing at all. Or not reporting it.
Correct, the MW app for GPU does not checkpoint. For newer GPUs the WUs are so short it's not an issue. Not sure about the CPU version as I wouldn't think of running it.
Quote from: Beyond on October 28, 2010, 05:04:08 PM
Quote from: fred on October 28, 2010, 10:31:35 AM
MW doesn't checkpoint much. I see the GPU version not checkpointing at all. Or not reporting it.
Correct, the MW app for GPU does not checkpoint. For newer GPUs the WUs are so short it's not an issue. Not sure about the CPU version as I wouldn't think of running it.
Ok MW CPU does checkpoint normally. The GPU doesn't checkpoint but does store the results, so it resumes after a suspend.
I will remove the checkpoint value from the filtered tasks.
Quote from: fred on October 28, 2010, 05:37:24 PM
I will remove the checkpoint value from the filtered tasks.
Hold on, why? The checkpoint value is fine and necessary, the highlighting of
any waiting task is wrong (and wishing to be corrected).
Quote from: Pepo on October 28, 2010, 08:17:46 PM
Hold on, why? The checkpoint value is fine and necessary, the highlighting of any waiting task is wrong (and wishing to be corrected).
Meaning when the filter is on a checkpoint value is not very meaningful as it is a checkpoint from some WU.
Removing the filter shows the checkpoints.
Quote from: fred on October 29, 2010, 05:36:05 AM
Meaning when the filter is on a checkpoint value is not very meaningful as it is a checkpoint from some WU.
Removing the filter shows the checkpoints.
Oops I see that this is already taken care of.
Can you give me a screen shot of the problem.
Quote from: fred on October 29, 2010, 05:36:05 AM
Quote from: Pepo on October 28, 2010, 08:17:46 PM
Hold on, why? The checkpoint value is fine and necessary, the highlighting of any waiting task is wrong (and wishing to be corrected).
Meaning when the filter is on a checkpoint value is not very meaningful as it is a checkpoint from some WU.
Removing the filter shows the checkpoints.
Ah, got it. Sure, when multiple waiting tasks are filtered together into a single line, then it is questionable, whether to simply hide the time since the last checkpoint, or (similar to meaningfully showing the soonest deadline (as a worst-case) from a group of filtered tasks) to equally meaningfully show the highest time since the last checkpoint (as a worst-case) from a group of filtered tasks.
In my case there were always single tasks of a project, so no grouping happened. Thus there was/is nothing to hide. Just the incorrect highlighting, which happened prior to exceeding the threshold time for a warning.
BTW if such worst-case checkpointing time would be shown for a filtered group of tasks, then it could be highlighted according to the same threshold time like when a task is running.
Quote from: fred on October 29, 2010, 06:45:31 AM
Quote from: fred on October 29, 2010, 05:36:05 AM
Meaning when the filter is on a checkpoint value is not very meaningful as it is a checkpoint from some WU.
Removing the filter shows the checkpoints.
Oops I see that this is already taken care of.
Can you give me a screen shot of the problem.
(http://i488.photobucket.com/albums/rr244/peposobr/TThrottle%20BoincTasks/Waitingtasksfilteredhighlightedcheckpoint.png)
Maybe this screenshot is not an excellent example because of the time over 6 minutes (I've simply paused and resumed the two tasks), but tasks with just a few seconds are equally highlighted (but a zero time seems to be not highlighted).
(http://i488.photobucket.com/albums/rr244/peposobr/TThrottle%20BoincTasks/Waitingtasksnotfilterednothighlightedcheckpoint.png)
After disabling the filtering of waiting tasks, the (wrong) warnings vanish, but the correct (for AQUA and DNETC) stays.
Quote from: fred on October 28, 2010, 05:37:24 PM
Quote from: Beyond on October 28, 2010, 05:04:08 PM
Quote from: fred on October 28, 2010, 10:31:35 AM
MW doesn't checkpoint much. I see the GPU version not checkpointing at all. Or not reporting it.
Correct, the MW app for GPU does not checkpoint. For newer GPUs the WUs are so short it's not an issue. Not sure about the CPU version as I wouldn't think of running it.
The GPU doesn't checkpoint but does store the results, so it resumes after a suspend.
On all my machines the GPU WUs start over from the beginning after a suspend.
Quote from: Pepo on October 29, 2010, 07:50:16 AM
[...] tasks with just a few seconds are equally highlighted (but a zero time seems to be not highlighted).
Not exactly. I just can see an AQUA task with highlighted "00:00:00" checkpoint time. Thus, correctly said, "it depends" or "a zero time seems to be sometimes highlighted too". Fred would have to find out "from what it depends" 8)