On one of my systems (running 5.10.20), it appears that the active_frac multiplier is not being modified. This was leading to symptoms that I attributed to a scheduler bug in a previous post. (client was not requesting enough work becaouse the active_frac was very low.)

What is the active_frac? I interpret it as the amount of time when boinc is running that work is enabled. If my assumption is correct, that would indicate that this was a bug.

If that is the case, not only is the active_frac not being modified it is also incorrect...

If I manually modify the active_frac, then my work fetch policy becomes more in line with what it should be, but the active_frac still never changes. If the original value was correct (a very low number, something like 2%) you would expect my artificially high number to trend back towards the old number. (I first watched the old number, and found that it was not trending higher as boinc ran uninterrupted for a day or so, including for testing at the end of the period stopping and restarting the boinc service, both with and without processing enabled.

Any help would be most appreciated!

Edit: I also have a connected_frac of -1; I'm assuming that this is because I am always connected, but maybe I'm wrong and this is a problem instead.

---

The -1 in the connected_frac is a known bug that has resisted extermination for a long time. The number is not used because of this.

The rest of my time stats seem to be working ok. This host has recently changed it's usage pattern so it seems a decent test.

---

BOINC WIKI

BOINCing since 2002/12/8

The -1 in the connected_frac is a known bug that has resisted extermination for a long time. The number is not used because of this.

The rest of my time stats seem to be working ok. This host has recently changed it's usage pattern so it seems a decent test.

Just since you didn't state it explicitly, you have noticed that your activ_frac has changed as your actual usage pattern changed?

---

active_frac corresponds to "While BOINC running, % of time work is allowed" on the host page.

I just checked my numbers on my dual booting host (running 5.10.8 for Linux) for a couple of cases.

1. A project where the host hasn't contacted the server for a few days:
While BOINC running, % of time work is allowed 99.9887 %

2. A project where the host contacted the scheduler a few hours ago:
While BOINC running, % of time work is allowed 99.9398 %

3. The current value from client_state:
[boinc@localhost ~]$ cat client_state.xml | grep active_frac
<active_frac>0.999404</active_frac>


I can also say the other values are updating as well, especially noticeable is <on_frac>

1. % of time BOINC client is running 66.2002 %

2. % of time BOINC client is running 73.9536 %

3. [boinc@localhost ~]$ cat client_state.xml | grep on_frac
<on_frac>0.742335</on_frac>


And for what it's worth, my connected_frac is also -1

[boinc@localhost ~]$ cat client_state.xml | grep connected_frac
<connected_frac>-1.000000</connected_frac>

---

Kathryn :o)

The -1 in the connected_frac is a known bug that has resisted extermination for a long time. The number is not used because of this.

The rest of my time stats seem to be working ok. This host has recently changed it's usage pattern so it seems a decent test.

Just since you didn't state it explicitly, you have noticed that your activ_frac has changed as your actual usage pattern changed?

My active_frac has stayed at ~98%, the on_frac has dropped from ~90% to ~13%. Both are as expected based on the new usage patterns on this host.

---

BOINC WIKI

BOINCing since 2002/12/8

Well, it seems to be working on your other computers and also on a test multicore system that I just installed boinc on.

That field is definitely not being updated on the system in question though. Who knows why. This is a system that has had several BOINC upgrades, though, so perhaps something got hosed once upon a time.

If anyone has any ideas what I should do, let me know. For now I manually modified the value to something that prevents the queue from running dry, so I guess I have a workaround.

Thanks for everyne's help on this weird issue.

---

Thank you. This exact same problem has been driving me nuts for about a week or two now.

I'm running a dual core that is on 24 hours a day, 7 days a week and I recently noticed that it was only running two projects at a time with no additional work being downloaded until the ones that were running completed. I tried increasing the minimum work and additional work buffers to no avail.

I ran across this thread today and set my active_frac to 0.900000 and instantly got new work units. Unfortunately, both my minimum work and additional work buffers were both set to 10 and I got just a wee bit more work than I wanted to so I reset them both, aborted the unwanted work units and now everything is operating the way I would expect it to.

I think I've now tracked down this bug to line 69 in time_stats.C: details and reasoning in Benchmarking bug - indefinite suspension of computing.

The problem is initiated if the computer user inadvertently sets the computer's clock to some time/date in the future, and then resets it to a more accurate time/date. All updating of time_stats metrics is then inhibited until ten (?)seconds(?) after the maximum time/date ever set on that computer's clock while BOINC is running.