That reference asserts this function was first supported in 7.3.13
If you are not already using an app_config.xml, you may wish to bear in mind recent observations by Gary Roberts regarding the incomplete reversion of state of a system from which an app_config.xml file has been removed.
I did not have an app_config.xml in use. In case it may be useful, here is the one I just made, and installed to the einstein project directory within the BOINC data directory (which is in ProgramData on my windows 10 machine)
I've included both the Hi and Lo variants, to allow me to use a single app_config.xml on my three machines. This means I get a warning message when I force reading of the configuration file using Options|Read config files advising me that an application name in my file which has never run on my machine is an unknown application.
If you are interested in our debugging assistance, some additional detail might help.
1. I suggest you post here by cut and past the exact text of the app_config.xml you are using.
2. I suggest you check by review in Windows Explorer what the exact file name and file location is (many folks have accidentally saved a file with the wrong extension--Windows makes that all too easy).
3. I suggest you stop boincmgr again. Then restart it. then check the Event log (as found at Tools|Event log) to see what if any references to app_config.xml appear.
Mine, for example, has these two lines:
18 Einstein@Home 5/25/2017 9:11:39 PM Found app_config.xml
19 Einstein@Home 5/25/2017 9:11:39 PM Your app_config.xml file refers to an unknown application 'einstein_O1Spot1TLo'. Known applications: 'einstein_O1AS20-100F', 'einsteinbinary_BRP6', 'hsgamma_FGRPB1', 'einsteinbinary_BRP4G', 'einstein_O1MD1TCV', 'einstein_O1MD1CV', 'hsgamma_FGRPB1G', 'ein
I have minimum work buffer of 0.50 days and max additional work buffer of 1.0 days.
The problem with that type of settings mix is that when BOINC decides to get work it will try to fill up to a total of 1.5 days worth. After that it won't ask for any more work until what remains is less than 0.5 days. The best way to think about those two numbers is that the minimum work buffer is really a 'low water mark'. The minimum plus the additional is a 'high water mark'. BOINC tries to fill to the high water mark and not ask again until what remains is less than the low water mark. Do you really want that 'oscillating' type of behaviour? If you want to aim for a nice constant supply, set it in the minimum setting and use zero for the other.
MarkHNC wrote:
I assumed I would have to do so in order to receive larger/longer running work units (both here and at WCG). Wouldn't a tiny buffer prevent me from getting longer running units? It doesn't appear to have downloaded any new work units since it went into panic mode.
Let's say CPU tasks take 100 hours (14 day deadline and you are only doing CPU tasks) and you have 16 available cores and you set your minimum setting to 0.1 and the additional to 0.0. How many tasks do you think BOINC would request in this purely hypothetical situation?
Answer: Exactly 16 because BOINC would not allow any of the 16 available cores to remain idle.
Let's also assume these 16 tasks all crunch equally and evenly and that you crunch 24/7 and there has been no break in crunching for months (so that BOINC knows it has 100% availability). When would BOINC request more work and how much would it ask for?
Answer: When the 16 running tasks showed just 2.4 hours estimated time remaining, BOINC would ask for another 16 - not all at once - probably one per minute for 16 minutes would be my guess. BOINC tends to get one at a time if the deficiency is small (seconds rather than hours) and if no CPU core is idle.
I hope you can really understand that a tiny buffer doesn't prevent BOINC from asking for huge tasks if that's all there is to get. It would only be a problem for BOINC if the estimated crunch time was longer than the deadline allowed.
<fraction_done_exact/>That'
)
<fraction_done_exact/>
That's an unknown tag option in app_config.xml
Can you show an example of it's use?
Nick_43 wrote: Can you show
)
This works, or at least doesn't fail. I don't normally need to use it on Einstein.
<app_config>
<app>
<name>hsgamma_FGRPB1G</name>
<fraction_done_exact/>
<gpu_versions>
<gpu_usage>1.0</gpu_usage>
<cpu_usage>1.0</cpu_usage>
</gpu_versions>
</app>
</app_config>
Regarding
)
Regarding fraction_done_exact,
You can find some "official" documentation here:
http://boinc.berkeley.edu/wiki/Client_configuration
That reference asserts this function was first supported in 7.3.13
If you are not already using an app_config.xml, you may wish to bear in mind recent observations by Gary Roberts regarding the incomplete reversion of state of a system from which an app_config.xml file has been removed.
Jim, that example shows me
)
Jim, that example shows me where to put it. Thanks. It now works.
Nick
I did not have an
)
<app_config> <app> <name>hsgamma_FGRPB1G</name> <fraction_done_exact/> </app> <app> <name>einstein_O1Spot1THi</name> <fraction_done_exact/> </app> <app> <name>einstein_O1Spot1TLo</name> <fraction_done_exact/> </app> </app_config>I just noticed this isn't
)
I just noticed this isn't working at all.
Typically:
51.224% completed in 06:29:07 with 13:24:59 remaining.
Did you restart BOINC? In
)
Did you restart BOINC? In the Event Log, it should show for Einstein@home: "Found app_config.xml".
I just checked mine on an FGRPopencl1K-nvidia, and it works fine.
6:15 elapsed, 36.8% progress, 11:00 minutes left
EDIT: By the way, that was down from an initial estimate of 1 hour 59 minutes (I just started up on the GPU again), and it was a rapid correction.
Jim Yes I restarted BOINC.
)
Jim
Yes I restarted BOINC. It just doesn't work.
Nick_43 wrote:Jim Yes I
)
If you are interested in our debugging assistance, some additional detail might help.
MarkHNC wrote:I have minimum
)
The problem with that type of settings mix is that when BOINC decides to get work it will try to fill up to a total of 1.5 days worth. After that it won't ask for any more work until what remains is less than 0.5 days. The best way to think about those two numbers is that the minimum work buffer is really a 'low water mark'. The minimum plus the additional is a 'high water mark'. BOINC tries to fill to the high water mark and not ask again until what remains is less than the low water mark. Do you really want that 'oscillating' type of behaviour? If you want to aim for a nice constant supply, set it in the minimum setting and use zero for the other.
Let's say CPU tasks take 100 hours (14 day deadline and you are only doing CPU tasks) and you have 16 available cores and you set your minimum setting to 0.1 and the additional to 0.0. How many tasks do you think BOINC would request in this purely hypothetical situation?
Answer: Exactly 16 because BOINC would not allow any of the 16 available cores to remain idle.
Let's also assume these 16 tasks all crunch equally and evenly and that you crunch 24/7 and there has been no break in crunching for months (so that BOINC knows it has 100% availability). When would BOINC request more work and how much would it ask for?
Answer: When the 16 running tasks showed just 2.4 hours estimated time remaining, BOINC would ask for another 16 - not all at once - probably one per minute for 16 minutes would be my guess. BOINC tends to get one at a time if the deficiency is small (seconds rather than hours) and if no CPU core is idle.
I hope you can really understand that a tiny buffer doesn't prevent BOINC from asking for huge tasks if that's all there is to get. It would only be a problem for BOINC if the estimated crunch time was longer than the deadline allowed.
Cheers,
Gary.