Displayed time to complete a project.

Message boards : Questions and problems : Displayed time to complete a project.
Message board moderation

To post messages, you must log in.

AuthorMessage
Cruncher Pete

Send message
Joined: 21 Jun 18
Posts: 16
Message 88558 - Posted: 21 Oct 2018, 6:19:07 UTC

Could we not have a more realistic display of how long we have crunched a WU and how long will it take to complete. The current example is as follows but it is not an isolated instance:

7.762% completed after 02d:13:25:12 hours. Time to complete will take another 02d:19:08:32 in Universe@home. I started this WU 2 days ago and that suggest to me that it will take another two days to complete. That is not so. If it is true than I will detach from Universe especially so since the log does not indicate a check point.

There could be all sorts of excuses for this but the fact is it is unrealistic.. Personally, all I am interested is what percent I completed to date, how long it took since I started it and how long it will take before it is completed. If this can't be displayed in Real wall clock time than the rest is confusing and is irrelevant. If the Real time of how long it took can't be worked out using a standard clock, I suggest to discontinue using the options how long it takes and how long it will be before it finish and just rely on percent completed. Even so, I would like to see when it started.
ID: 88558 · Report as offensive
Profile Dave
Help desk expert

Send message
Joined: 28 Jun 10
Posts: 2516
United Kingdom
Message 88559 - Posted: 21 Oct 2018, 6:33:42 UTC - in response to Message 88558.  

I have often wondered why the mechanism to calculate remaining time isn't based on percentage completed and the time taken to reach that percentage.

It wouldn't solve the problem of the initial estimate being wildly out on occasion, especially running under WINE where at least with CPDN a massively different Gflops value is reported compared to running BOINC natively under Linux. Is it because tasks for some projects are in two or more sections and the second section may require more or less computing power?
ID: 88559 · Report as offensive
jglrogujgv

Send message
Joined: 6 Jul 18
Posts: 49
Barbados
Message 88577 - Posted: 22 Oct 2018, 19:51:36 UTC - in response to Message 88559.  

I have often wondered why the mechanism to calculate remaining time isn't based on percentage completed and the time taken to reach that percentage.
What makes you think the percent complete number is reliable? Sometimes it is. Sometimes it isn't. Sometimes it is so inaccurate the only useful thing it provides is an indication that the computation hasn't crashed. Sometimes it isn't possible to make it more accuirate than that.

At the heart of the problem is the fact that for some computations it is impossible to determine (with any accuracy) how many CPU cycles the computation will require. If you don't know how many are required then you can't calculate % complete.

For some computations the best you can do is run a few hundred/thousand/million of them in pre-production, watch how long they take and then choose some arbitrary limit after which BOINC will terminate the task. If too many tasks exceed that limit when you go into production then you make an educated guess and increase the limit. Rinse and repeat.

It's a problem that has plagued computing science ever since the first computing machines. There is no solution. There will never be any solution. There will only better/revised estimates.
ID: 88577 · Report as offensive
Profile Dave
Help desk expert

Send message
Joined: 28 Jun 10
Posts: 2516
United Kingdom
Message 88584 - Posted: 23 Oct 2018, 6:13:33 UTC - in response to Message 88577.  

I guess it depends on the project. My usual project, time taken to get to present percentage completed gives a completely accurate estimate once it is two or three percent in.

I get that there may be projects where the complexity increases or decreases as computation progresses causing the problem you describe.
ID: 88584 · Report as offensive
Cruncher Pete

Send message
Joined: 21 Jun 18
Posts: 16
Message 88587 - Posted: 23 Oct 2018, 10:02:00 UTC - in response to Message 88558.  

OK. I agree that there might never be an accurate estimate of How much time elapsed and how long before completion. Surely, it would be better not to show it in real time rather than just give an arbitrary number that has nothing to do with those times. I am clueless as to how to program but would it be too hard to just show the time the WU started. It would be more accurate for us to estimate how long the WU took to complete by the log that states Tasks completed and or reported than compare it with start time.. We than could check the project to see how long it took to completed each unit. No need to be confused by unrealistic times. Just a wish nothing else.
ID: 88587 · Report as offensive
jglrogujgv

Send message
Joined: 6 Jul 18
Posts: 49
Barbados
Message 88592 - Posted: 23 Oct 2018, 13:23:25 UTC - in response to Message 88587.  
Last modified: 23 Oct 2018, 13:23:43 UTC

OK. I agree that there might never be an accurate estimate of How much time elapsed and how long before completion.
The elapsed time is very accurate for ALL projects as it is based on system time. Only time to completion and % complete are problematic and they are problematic only for some project's apps. For other projects those numbers are fairly accurate.

No need to be confused by unrealistic times. Just a wish nothing else.
Click Options -> Select Columns to hide info that gets under your skin. No column for start time because it isn't useful info.
ID: 88592 · Report as offensive
Cruncher Pete

Send message
Joined: 21 Jun 18
Posts: 16
Message 88634 - Posted: 26 Oct 2018, 8:18:11 UTC - in response to Message 88577.  

I have often wondered why the mechanism to calculate remaining time isn't based on percentage completed and the time taken to reach that percentage.
What makes you think the percent complete number is reliable? Sometimes it is. Sometimes it isn't. Sometimes it is so inaccurate the only useful thing it provides is an indication that the computation hasn't crashed. Sometimes it isn't possible to make it more accuirate than that.

At the heart of the problem is the fact that for some computations it is impossible to determine (with any accuracy) how many CPU cycles the computation will require. If you don't know how many are required then you can't calculate % complete.

I agree. This is why I maintain that it would be better to do away with those useless column and give us something that is more accurate. i.e a "Start Time" column based on a wall clock, instead of inaccurate assumptions

If it is impossible to determine than why do we have a column that states Time to Complete. My point is it should not be shown as it is inaccurate in most cases. The fact that it is correct in some cases does not change the fact.

For some computations the best you can do is run a few hundred/thousand/million of them in pre-production, watch how long they take and then choose some arbitrary limit after which BOINC will terminate the task. If too many tasks exceed that limit when you go into production then you make an educated guess and increase the limit. Rinse and repeat.

Another reason not to have a column that states Time to completion. If you have a Start Time you can work out from available sources how long the WU took.

It's a problem that has plagued computing science ever since the first computing machines. There is no solution. There will never be any solution. There will only better/revised estimates.


Than I repeat why do we need a column that states Estimated time etc when it is completely inaccurate accept in a few cases. A start time column would serve a more useful feature as after a few WU's we can see how long it took to complete a WU even though that varies as well but it would be more accurate because you can check the completed time on a wall clock or in your account if need be how long each WU took.
ID: 88634 · Report as offensive
jglrogujgv

Send message
Joined: 6 Jul 18
Posts: 49
Barbados
Message 88641 - Posted: 26 Oct 2018, 20:58:23 UTC - in response to Message 88634.  
Last modified: 26 Oct 2018, 21:26:54 UTC

Than I repeat why do we need a column that states Estimated time etc when it is completely inaccurate accept in a few cases. A start time column would serve a more useful feature as after a few WU's we can see how long it took to complete a WU even though that varies as well but it would be more accurate because you can check the completed time on a wall clock or in your account if need be how long each WU took.

Not sure what you hope to gain out of a start time column. It sounds like you want to know task duration (run time). Well that is provided in your list of results.

It sounds like you want a start time column so you can then subtract the start time from the finish time given in your list of results. That column shows time reported not finish time. And the duration is given in the adjacent column.
ID: 88641 · Report as offensive
Profile Peter Shane

Send message
Joined: 22 Jul 15
Posts: 6
Australia
Message 88644 - Posted: 27 Oct 2018, 7:08:44 UTC - in response to Message 88641.  

Than I repeat why do we need a column that states Estimated time etc when it is completely inaccurate accept in a few cases. A start time column would serve a more useful feature as after a few WU's we can see how long it took to complete a WU even though that varies as well but it would be more accurate because you can check the completed time on a wall clock or in your account if need be how long each WU took.

Not sure what you hope to gain out of a start time column. It sounds like you want to know task duration (run time). Well that is provided in your list of results.

It sounds like you want a start time column so you can then subtract the start time from the finish time given in your list of results. That column shows time reported not finish time. And the duration is given in the adjacent column.


To answer some of your specific points jglrogujgv: I think I have illustrated what columns we are talking about. We both agreed what they are doing and they are highly unreliable and in your words impossible to predict. I hope that this reply of mine will be a bit clearer.

The "list of results" as mentioned by you are not in Boinc Manager and has nothing to do with existing columns. But YES, I would like to see accurate run time as in a Wall clock from the start of the Task.

My apologies for not explaining clearly that the "Elapsed Time", "Percentage Completed" and the "Time to Complete" are completely useless. You, seemed to have agreed with me for you have stated that they are impossible to predict. Accordingly, I am simply saying Do Not Include those columns for you can not rely on them as any help. I am only suggesting to include something like a Wall Clock when you have started the WU. If in a few hours I note that the Task have not finished when I have ascertained that the average completion time is 20 minutes, than I can Abort the Tasks as it is costing me money to run it and more than likely it is no use for the project either.

The answer to me is simple. I am running BOINCTasks and I have an option what columns to show. I have opted Not to show those columns. But is that the right solution.? Would it not be a better one if the Devs could come up with a better suggestion than mine. After all, it is only a suggestion and I am seeking peoples point of view..

I hope that clarifies the situation unless I need more clarification I have nothing more to add.

ID: 88644 · Report as offensive
robsmith
Volunteer tester
Help desk expert

Send message
Joined: 25 May 09
Posts: 1283
United Kingdom
Message 88645 - Posted: 27 Oct 2018, 7:32:44 UTC

OK, so you are frustrated by the way the times are displayed, and are blaming BOINC for it.
There are two sets of times:
First, and the most accurate (and certainly the easiest to calculate) is the "elapsed time - this is the amount of actual calculation time that a task has been doing - if the task get suspended that clock stops, if you turn the computer off, that clock stops.
All the others rely on the application as well as BOINC for their accuracy.
Percent complete comes from the application. While this may be a very simple calculation for one project where the task is a simple linear one, it can be very difficult for another where the task can branch off wildly or dive into a deep iterative loop.
Time to completion is a BOINC and application estimate: the application tells BOINC that this is a type-x task; BOINC looks back in its records (mostly on your computer) and, provided you've done enough type-x tasks (about a dozen), it will use those to give an estimated time, obviously the more type-x tasks run and the more consistent they have been the better the estimate.
ID: 88645 · Report as offensive
Richard Haselgrove
Volunteer tester
Help desk expert

Send message
Joined: 5 Oct 06
Posts: 5077
United Kingdom
Message 88646 - Posted: 27 Oct 2018, 9:23:24 UTC - in response to Message 88644.  

I am running BOINCTasks and I have an option what columns to show.
That option also exists in the standard Manager shipped with BOINC. Options --> Select columns.
ID: 88646 · Report as offensive
jglrogujgv

Send message
Joined: 6 Jul 18
Posts: 49
Barbados
Message 88647 - Posted: 27 Oct 2018, 10:53:36 UTC - in response to Message 88644.  

My apologies for not explaining clearly that the "Elapsed Time", "Percentage Completed" and the "Time to Complete" are completely useless. You, seemed to have agreed with me for you have stated that they are impossible to predict.
Wrong. I have not agreed with any of your confused ramblings and I expect that any attempt to correct your misinterpretation will only lead to more confused ramblings from you.

Would it not be a better one if the Devs could come up with a better suggestion than mine.
I think they would suggest that you should spend less time typing and more time reading.
ID: 88647 · Report as offensive

Message boards : Questions and problems : Displayed time to complete a project.

Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.