BOINC, ver 6.4.5, is ignoring "Additional work buffer" settings. mine is set at 8 days but i'm only able to get enough work for one day, client stops requesting for more work. please don't reply with the server is out of work because that is not the problem.

---

First and foremost, the "additional work buffer" is not a flat number, there are many factors that can affect the "additional work buffer".

The amount of uptime a host has, the amount of time a host is allowed to crunch (if you suspend while active), the efficiency of the particular platform, how many worknits are returned in error (if any), and most importantly deadlines of the workunits themselves.

With SETI, the deadlines are typically 7 days, which means you're telling the scheduler, "make sure I have enough work for 8 days" and the scheduler sees work that is due in 7, it tries not to download too many for fear of missing a deadline (since the scheduler's main job is to ensure all work is turned in on time).

This is why its best to keep a minimal buffer with projects that have short deadlines such as SETI. Try keeping a 3 or 4 day buffer and, assuming all other stats are in order, it should smooth itself out.

I'm going to have to agree with 6.4.5 not asking for enough work. I tried it for about 16 hours, and it was running tasks that were due in 3 weeks in panic mode and my cache shrank to about a quarter of what it was, and 6.4.5 decided I didn't need any more work.

Re-installed 6.2.19 and it immediately asked for 800,000 seconds of work, and I got 60-something shorties.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

I'm going to have to agree with 6.4.5 not asking for enough work. I tried it for about 16 hours, and it was running tasks that were due in 3 weeks in panic mode and my cache shrank to about a quarter of what it was, and 6.4.5 decided I didn't need any more work.

Re-installed 6.2.19 and it immediately asked for 800,000 seconds of work, and I got 60-something shorties.

Well, in fairness, that wouldn't be "ignoring" the "additional work buffer". Instead, it would be that the scheduler is too "panic-y" and is too scared to download more work, indicating incorrect logic in the scheduler. I've read many notes on this and it seems it is acknowledged by the developers and planned to be fixed in the next release.

---

I'm going to have to agree with 6.4.5 not asking for enough work. I tried it for about 16 hours, and it was running tasks that were due in 3 weeks in panic mode and my cache shrank to about a quarter of what it was, and 6.4.5 decided I didn't need any more work.

Re-installed 6.2.19 and it immediately asked for 800,000 seconds of work, and I got 60-something shorties.

Well, in fairness, that wouldn't be "ignoring" the "additional work buffer". Instead, it would be that the scheduler is too "panic-y" and is too scared to download more work, indicating incorrect logic in the scheduler. I've read many notes on this and it seems it is acknowledged by the developers and planned to be fixed in the next release.

I have to agree with the complaints about 6.4.5.

This version is not downloading any new work, while work units that are not due for over 2 weeks are "Running, high priority", as if they would otherwise not be done in time.

24 of the S@H Enhanced 6.03 work units were started and completed today as well as 3 Astropulse 5.00 work units! Still Boinc will not ask for even 1 more second of work.

At this rate, in less than 5 days my queue will be empty, but still Boinc 6.4.5 is thinking that the work will not be done in time for work units with due dates at least 16 days away.

Something is really messed up with the way that Boinc 6.4.5 estimates the wall clock time required to complete the work in the queue.

And, I am still waiting for Boinc 6.4.5 to take advantage of the fact that I have a GPU that can be processing some of these work units. It has detected the CUDA, but is still not using it.

1/14/2009 11:33:52 PM||Starting BOINC client version 6.4.5 for windows_intelx86
1/14/2009 11:33:52 PM||CUDA devices found
1/14/2009 11:33:52 PM||Coprocessor: GeForce 8800 GT (1)

Hi, since a month or so, I updated 3 QUADs from BOINC 5.10.45 to 6.4.5, only in the first days, it didn't ask for enough work. I changed the cache settings (Additional work buffer)from 2 to 5 days, since then I'll get just enough work to maintain crunching.
But I DO get a lot of AP WU's, but they process within a reasonable time, that is, 10 hours for X9650 (@ 3.7GHz and 411MHz DDR2 with 4-4-4-12 & 2T timings), an Q6600 (@ 3GHZ) does them in 14 hours and stock Q6600 in about 16 hours. I DO use the SSE3 optimized AP app.
But I do get very little MB work and AP WU's take a long time to validate and my pending has risen from 30K to 73K. They will eventually be validated, I hope :)
Also noticed, this morning, again, that AP_Validator is switched off. Why is that?
And 4 MB Splitters are also turned of. Going through some big changes or something else, I am not aware of?
But it is still impossible to use CUDA, when using optimized MB{SSSE3} & AP, if I am correct.
Keep On Crunching

---

The "high priority" running is meant to get the WU's through so they don't expire. It's not the 1st WU that you are running that may expire but the last one on the list. Boinc does the calculations figures out the deadlines and processes accordingly. High priority doesnt mean that the WU you are on is about to expire it means that you have so much work on board that BOinc has taken measures to insure that the work gets reported on time. This doesnt guaranty the work will complete on time but BOINC is making an effort to get all available work done by the deadlines set by the projects

---

In a rich man's house there is no place to spit but his face.
Diogenes Of Sinope

Well like I pointed out earlier on in the thread, 6.2.19 does just fine with not missing deadlines, and is almost perfect for the 4-day cache I have set.

6.4.5 dropped me down to less than a day of cache because it didn't think I would finish WUs with a 3 week deadline that I just got a few hours before. It's calculations of how much work you can do and keep in cache are not quite right. Going back to 6.2.19 immediately requested 3 days worth of work.

That's all I was getting at. I think someone pointed out that it thinks APs will take hundreds of days or something like that instead of something more reasonable.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

Well like I pointed out earlier on in the thread, 6.2.19 does just fine with not missing deadlines, and is almost perfect for the 4-day cache I have set.

6.4.5 dropped me down to less than a day of cache because it didn't think I would finish WUs with a 3 week deadline that I just got a few hours before. It's calculations of how much work you can do and keep in cache are not quite right. Going back to 6.2.19 immediately requested 3 days worth of work.

That's all I was getting at. I think someone pointed out that it thinks APs will take hundreds of days or something like that instead of something more reasonable.

I had the same problem with 6.4.5, although I crunch Seti MB ONLY.(No CUDA)
Went back to 6.1.0 from Crunch3r - No more probs since then.

Regards

Kurt

---

Well like I pointed out earlier on in the thread, 6.2.19 does just fine with not missing deadlines, and is almost perfect for the 4-day cache I have set.

6.4.5 dropped me down to less than a day of cache because it didn't think I would finish WUs with a 3 week deadline that I just got a few hours before. It's calculations of how much work you can do and keep in cache are not quite right. Going back to 6.2.19 immediately requested 3 days worth of work.

That's all I was getting at. I think someone pointed out that it thinks APs will take hundreds of days or something like that instead of something more reasonable.

I haven't seen this with 6.4.5.

One of the issues here is that there is only one Duration Correction Factor per project and a project with two applications really needs two.

If you are running a particularly fast Multibeam app., that will raise the DCF, and then apply that (large) DCF to Astropulse, giving a long completion time.

Then, a run of Astropulse will under-request (because the estimates are very high), as Astropulse runs the DCF will shrink, and when you get more Multibeam you'll get more than you ought.

The short reason why your cache will always be wrong is that this is all based on estimates -- on predicting the future. This is just one of the places where then estimates can be pretty off.

I have "extra days" set to four, and my machines don't run out of work. I don't actually care if has 4 days or not, as long as there is one WU in the cache when a work unit finishes.

---

I have the same problem with this computer. http://setiweb.ssl.berkeley.edu/show_host_detail.php?hostid=3508634 It was running fine then started running all WU's in high priority even though it was working on WU's due in two weeks and completed them in one day. I've updated Bonic an it still will only give me WU's one for one but it did stop it running in high priority. I've tried everything I can think of but it still only will download a WU just before one finished or has been uploaded. The Tasks shows no problems all are good.

---

http://www.teamstarfire.org/

I have the same problem with this computer. http://setiweb.ssl.berkeley.edu/show_host_detail.php?hostid=3508634 It was running fine then started running all WU's in high priority even though it was working on WU's due in two weeks and completed them in one day. I've updated Bonic an it still will only give me WU's one for one but it did stop it running in high priority. I've tried everything I can think of but it still only will download a WU just before one finished or has been uploaded. The Tasks shows no problems all are good.

Why do you think this is an error?

---

I have the same problem with this computer. http://setiweb.ssl.berkeley.edu/show_host_detail.php?hostid=3508634 It was running fine then started running all WU's in high priority even though it was working on WU's due in two weeks and completed them in one day. I've updated Bonic an it still will only give me WU's one for one but it did stop it running in high priority. I've tried everything I can think of but it still only will download a WU just before one finished or has been uploaded. The Tasks shows no problems all are good.

When you look at that page on your own account, what do you see for the last four lines? Mine look something like

% of time BOINC client is running 99.9364 % 
While BOINC running, % of time work is allowed 99.991 % 
Average CPU efficiency 0.98533 
Task duration correction factor 0.160647 

If any of those 99% are significantly out of line, it would have the effect you describe.

I have the same problem with this computer. http://setiweb.ssl.berkeley.edu/show_host_detail.php?hostid=3508634 It was running fine then started running all WU's in high priority even though it was working on WU's due in two weeks and completed them in one day. I've updated Bonic an it still will only give me WU's one for one but it did stop it running in high priority. I've tried everything I can think of but it still only will download a WU just before one finished or has been uploaded. The Tasks shows no problems all are good.

Why do you think this is an error?

Why do you think it's not? It started running all WU's in High Priority without a need to and stopped downloading the cache. Tuesday updates will cause this computer to be idle since I won't have any WU's to run.

---

http://www.teamstarfire.org/

I have the same problem with this computer. http://setiweb.ssl.berkeley.edu/show_host_detail.php?hostid=3508634 It was running fine then started running all WU's in high priority even though it was working on WU's due in two weeks and completed them in one day. I've updated Bonic an it still will only give me WU's one for one but it did stop it running in high priority. I've tried everything I can think of but it still only will download a WU just before one finished or has been uploaded. The Tasks shows no problems all are good.

When you look at that page on your own account, what do you see for the last four lines? Mine look something like

% of time BOINC client is running 99.9364 % 
While BOINC running, % of time work is allowed 99.991 % 
Average CPU efficiency 0.98533 
Task duration correction factor 0.160647 

If any of those 99% are significantly out of line, it would have the effect you describe.

You are right.

% of time BOINC client is running 100 %
While BOINC running, % of time work is allowed 0.005 %
Average CPU efficiency 0.909987
Task duration correction factor 0.137391

I don't know what happened but I haven't had any down time with the computer and haven't reported any bad WU's. A few days ago I noticed it running in High Priority and had a full cache. But the problem is it's not refilling the cache.

---

http://www.teamstarfire.org/

I have the same problem with this computer. http://setiweb.ssl.berkeley.edu/show_host_detail.php?hostid=3508634 It was running fine then started running all WU's in high priority even though it was working on WU's due in two weeks and completed them in one day. I've updated Bonic an it still will only give me WU's one for one but it did stop it running in high priority. I've tried everything I can think of but it still only will download a WU just before one finished or has been uploaded. The Tasks shows no problems all are good.

When you look at that page on your own account, what do you see for the last four lines? Mine look something like

% of time BOINC client is running 99.9364 % 
While BOINC running, % of time work is allowed 99.991 % 
Average CPU efficiency 0.98533 
Task duration correction factor 0.160647 

If any of those 99% are significantly out of line, it would have the effect you describe.

You are right.

% of time BOINC client is running 100 %
While BOINC running, % of time work is allowed 0.005 %
Average CPU efficiency 0.909987
Task duration correction factor 0.137391

I don't know what happened but I haven't had any down time with the computer and haven't reported any bad WU's. A few days ago I noticed it running in High Priority and had a full cache. But the problem is it's not refilling the cache.

Probably because your clock changed -- perhaps you accidentally clicked on the calendar and re-set the system date by accident, then set it back.

Stop BOINC and edit the client_state.xml file to correct that value.

---

I have the same problem with this computer. http://setiweb.ssl.berkeley.edu/show_host_detail.php?hostid=3508634 It was running fine then started running all WU's in high priority even though it was working on WU's due in two weeks and completed them in one day. I've updated Bonic an it still will only give me WU's one for one but it did stop it running in high priority. I've tried everything I can think of but it still only will download a WU just before one finished or has been uploaded. The Tasks shows no problems all are good.

Why do you think this is an error?

Why do you think it's not? It started running all WU's in High Priority without a need to and stopped downloading the cache. Tuesday updates will cause this computer to be idle since I won't have any WU's to run.

I read the forums a lot, and I see a common complaint that "work is being done in high-priority" and that is the only complaint.

People say "Why is it doing this horrible thing?" and it is neither horrible, or a problem.

The problem you are having is not "high priority" -- it is the small work fetch, and we've identified the reason for it.

If you leave BOINC alone, it will (eventually) correct itself as BOINC sees that it can do work more than 0.005% of the time -- but it will take a while. Most of us are not that patient.

---

Mine is using high priority as an excuse to goof off. It's going through and doing all the easy little low credit ones first! :)


(actually it is doing WUs due on the 20th that all just happen to be low credit WUs)

---

PROUD MEMBER OF Team Starfire World BOINC

Hi, I've had this 'problem', when I UPdated from BOINC 5.10.45 to 6.4.5, but only in the first 2 weeks, now after more then a month, it works correct*.
No more tasks that went in high priority mode!
I did have to increase my extra WU cache from 2 to 5 days.
Also run EINSTEIN and LHC as back-up and out of interrest.
My 3 QUADs have also an updated app_info.xml for optimized AP WU's And I DO get a lot off them, it's a pitty it takes quite a long time to validate, mostly due to 'slow'-- or wingmen who aborted their AP WU's, that's a shame, I think. It's better to set your preferences to not receive AP WU's, in the first place.
So I'am content with this BOINC version, after all ;)
It gives not too much and not too little work, that's most important, IMHO.
* The time of UPdate, was before the X'mas holidays, so 'troubles' in the first week, also had other reasons, such as outage and unforeseen downtime of the SETI-servers!

Keep On Crunching, though.

---

Mine is using high priority as an excuse to goof off. It's going through and doing all the easy little low credit ones first! :)


(actually it is doing WUs due on the 20th that all just happen to be low credit WUs)

Those are "shorties", and that is completely common. They are only 7- or 10-day deadlines on those WUs, so they have a tendency to run high priority anyway.

Regarding the percentages..

% of time BOINC client is running	99.9727 %
While BOINC running, % of time host has an Internet connection	100 %
While BOINC running, % of time work is allowed	99.8522 %
Average CPU efficiency	0.974155
Task duration correction factor	0.272447

Yet mine ran the 4-day cache just about dry and ran everything in high priority mode. That's not the way it's supposed to work.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)