Quote from: fredAdd: Graphic presentation of received tasks. Menu Show -> Tasks graphic.
Is it a list of tasks, currently available on-board - how many of them were received at which point of time? I suppose.
The graph contains a lot of spikes from 0 to 1, just one goes to 2. Like a rainbow grass on a lawn. Maybe I should have seen a screenshot from someone else, who gets a lot of smaller tasks...
Could there be one more display mode, which would not show the receive moments as spikes (going to number of received tasks and then immediately back to zero), but the lines would go between different levels as number of tasks, available on-board from some project at the moment of time. I understand that some history of task-received-datetime should be kept in order to display it, in addition to the moments when a task was reported...
Quote from: fredChanged: Tasks and History, added walking ..... to updating...
What is this "walking"?
Quote from: Pepo on December 17, 2010, 04:39:09 PM
The graph contains a lot of spikes from 0 to 1, just one goes to 2. Like a rainbow grass on a lawn. Maybe I should have seen a screenshot from someone else, who gets a lot of smaller tasks...
The resolution seems to be a bit ... coarse. Just something like 1 hour?
If I select two projects, which received per one task on the same day, 1/2 hour apart, and have no other tasks aboard, then the graph displays just this one particular day. The dialog can be resized over say 3000 points horizontally, yet the "spikes" (now rather wide, equilateral triangles) still do overlap themselves, point to the same moment in timeline and can not be distinguished.
Quote from: Pepo on December 17, 2010, 04:39:09 PM
Is it a list of tasks, currently available on-board - how many of them were received at which point of time? I suppose.
The graph contains a lot of spikes from 0 to 1, just one goes to 2. Like a rainbow grass on a lawn. Maybe I should have seen a screenshot from someone else, who gets a lot of smaller tasks...
Could there be one more display mode, which would not show the receive moments as spikes (going to number of received tasks and then immediately back to zero), but the lines would go between different levels as number of tasks, available on-board from some project at the moment of time. I understand that some history of task-received-datetime should be kept in order to display it, in addition to the moments when a task was reported...
What is this "walking"?
The tasks graph is an experiment. ;D
I used to check the log for downloads, but that's an annoying and difficult task.
The received tasks are placed in a 1 hour window. So every spike you see are the number of tasks you got in one hour.
But this is very difficult to display for more than one computer. The way it's now shows the most.
Walking is like . .. ... .... ..... ......
updating.... updating..... updating...... updating....... One more countdown number was one bridge too far for me.
Quote from: fred on December 17, 2010, 04:55:11 PM
Quote from: Pepo on December 17, 2010, 04:39:09 PM
What is this "walking"?
Walking is like . .. ... .... ..... ......
updating.... updating..... updating...... updating....... One more countdown number was one bridge too far for me.
Got it. But I do not see it....... My update is always with just the same 5 dots. For a brief moment - it can be observed just with a huge number of tasks? (I have just 24 ATM.)
Quote from: Pepo on December 17, 2010, 05:11:07 PM
Got it. But I do not see it....... My update is always with just the same 5 dots. For a brief moment - it can be observed just with a huge number of tasks? (I have just 24 ATM.)
Indeed, You only see this with computers where BOINC is slow in reacting (busy, huge number of tasks), or over slower connections.
With 23 WU its way too quick.
I've noticed a couple of discrepancies in few tasks' Elapsed time. Namely the value in Tasks tab's Elapsed column does not match (is less than) the value in the Task properties window. Usually much smaller, so I could notice it. And also smaller than the CPU time. A few examples (a lot of such tasks, thus not as screenshots), parts of the Properties dialog:
Application AstroPulse 5.05
CPU time at last checkpoint 01d,23:16:27
CPU time 01d,23:16:40
Elapsed time 02d,02:27:04 (17:15:26)
Estimated time remaining 09:28:02
Application Prime Sierpinski Problem (LLR) 5.11
CPU time at last checkpoint 06d,21:15:01
CPU time 06d,21:15:02
Elapsed time 07d,04:54:45 (05:32:10)
Estimated time remaining 02d,02:42:39
Application D-Wave's Iterative QUANtum Algorithms : Multi-Threaded 1.14 (mt1)
Resources 3.00 CPUs
CPU time at last checkpoint 02d,17:21:15
CPU time 02d,17:21:17
Elapsed time 01d,00:43:59 (03:46:14)
Estimated time remaining 10:00:41
Application UK Met Office FAMOUS 6.11
CPU time at last checkpoint 04d,18:48:20
CPU time 04d,18:50:37
Elapsed time 05d,03:23:16 (02d,13:45:12)
Estimated time remaining 11d,22:06:01
One more CPDN task, which just finished, was switching between 9 and 15 days. At the point it got ready to report, the time was again correct.
Each time such task was preempted, the elapsed time (in main window) fell back to the (bold) value. After resuming such task, displayed Elapsed time was suddenly correct.
And I've noticed it just on tasks with Elapsed time > 1 day.
Quote from: Pepo on December 20, 2010, 06:30:11 PM
I've noticed a couple of discrepancies in few tasks' Elapsed time. Namely the value in Tasks tab's Elapsed column does not match (is less than) the value in the Task properties window. Usually much smaller, so I could notice it. And also smaller than the CPU time. A few examples (a lot of such tasks, thus not as screenshots), parts of the Properties dialog:
Ok on the list to investigate.
I've caused BT to crash repeatedly (much more than 10 times)using a longer string (than maybe expected) in
<GroupViewTasks> / <StatusRunning>.
Details in
Quote from: Pepo on December 21, 2010, 11:38:38 AMRe: Slovak
Quote from: Pepo on December 21, 2010, 11:42:18 AM
I've caused BT to crash repeatedly (much more than 10 times)using a longer string (than maybe expected) in <GroupViewTasks> / <StatusRunning>.
Details in Quote from: Pepo on December 21, 2010, 11:38:38 AMRe: Slovak
The strings can only have a limited length. The buffer lengths are checked and result in a buffer too short error. Not very serious, but they cause the program to loop in the error catching.
I on my to do list.
Quote from: Pepo on December 20, 2010, 06:30:11 PM
I've noticed a couple of discrepancies in few tasks' Elapsed time. Namely the value in Tasks tab's Elapsed column does not match (is less than) the value in the Task properties window. Usually much smaller, so I could notice it. And also smaller than the CPU time. A few examples (a lot of such tasks, thus not as screenshots), parts of the Properties dialog:
In V 0.97 the elapsed times, should be the same, in the tasks properties dialog & Tasks view.