Purpose of fraction_done_exact

Message boards : Questions and problems : Purpose of fraction_done_exact
Message board moderation

To post messages, you must log in.

AuthorMessage
additude
Avatar

Send message
Joined: 3 Dec 17
Posts: 19
United States
Message 90228 - Posted: 23 Feb 2019, 13:27:59 UTC

Hello,
I pretty much understand how the scheduler works and uses "estimated" values.
I've read from forums that references to those "estimated" values are referencing "Estimated RAC" when I do think that those "estimations" are in time (seconds), not in RAC.
Is it correct that the scheduler is estimating time and not RAC?

I'm also exploring the use of <fraction_done_exact\> in the app_config.xml file. Enabling this causes the scheduler to use the fraction completed value of running tasks in progress to base the estimates on.

I'm curious to why this is an "option" and not a default. I'm assuming that this is a more exact and precise measurement for the scheduler to use and I think the use of accuracy scheduling is a better option than using estimate scheduling.

Can someone explain the pro's and cons?

Thanks,

-Wes
ID: 90228 · Report as offensive
Jim1348

Send message
Joined: 8 Nov 10
Posts: 310
United States
Message 90233 - Posted: 23 Feb 2019, 20:40:01 UTC - in response to Message 90228.  

I normally use "fraction done exact", but occasionally it can cause problems. That is, some projects do not show much if any increase in "Progress %" for several minutes. For example, they can hang at 10% for an hour and then jump to 50% or whatever. In that case, the estimated time to complete will be too long if "fraction done exact" is used. Then, the work unit will be forced to run in panic mode, and take precedence over other projects. There may be other problems with it, but that is the one I remember. Otherwise, it works OK, if the progress value is relatively accurate.
ID: 90233 · Report as offensive
additude
Avatar

Send message
Joined: 3 Dec 17
Posts: 19
United States
Message 90251 - Posted: 25 Feb 2019, 15:01:34 UTC - in response to Message 90233.  

Thanks Jim,

I can understand where those project tasks that were influenced that way would tend to become marked at higher priority.

I would think that a continued superficial "panic" mode would be valid until the scheduler started compensating for "overworked" and the scheduler adjusted accordingly in an attempt to balance the work-load based on resource allocation.

Do you think it would tend to work itself out after some time?
ID: 90251 · Report as offensive
Jim1348

Send message
Joined: 8 Nov 10
Posts: 310
United States
Message 90252 - Posted: 25 Feb 2019, 15:11:57 UTC - in response to Message 90251.  
Last modified: 25 Feb 2019, 15:14:30 UTC

I would think that a continued superficial "panic" mode would be valid until the scheduler started compensating for "overworked" and the scheduler adjusted accordingly in an attempt to balance the work-load based on resource allocation.

Do you think it would tend to work itself out after some time?

I don't recall that the BOINC scheduler ever did figure that out. The BOINC scheduler also does not compensate for limiting the number of cores with an app_config.xml file for example, at least initially. It will continue to give estimates based on the assumption that you are using all the cores, though I think once you reach the buffer size limit it will prevent downloads beyond that. You need to keep an eye on it if you do anything out of the ordinary.
ID: 90252 · Report as offensive

Message boards : Questions and problems : Purpose of fraction_done_exact

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.