so the server isn't sending you WU's for your CUDA if you have the AP checked? that would be odd behavior on the server.

It is, but not often enough to keep the balance right.

NB I'm using BOINC v6.4.5 for the time being, and it doesn't ask for separate allocations for CUDA and CPU - it still just asks for one big chunk of work, and accepts whatever mixture the server chooses to send.

Over the past week or so the only WUs sent to my laptop have been AP WUs. No biggie, they take about 3 1/2 days each to run (dual core processor). Fortunately I leave it locked in a cabinet where it can run unmolested at night. And, as others have noted, more credit per hour with AP WUs.

---

Ive just left mine off the tick for apv5 but with accept work for other apps ticked. Ive downloaded since doing this, 10 5.03s a few 5.0 and a few hundred mbs. When i have v5 option ticked i got 30 v5s in quick succession and nothing else.

---

I'm wondering about your long runtime of 3 1/2 days per ap wu.
I'm running a 5.03 astropulse wu in ca. 12 to 14 hours with a 2GHz Xeon
Try our optimized version from lunatics. http://lunatics.kwsn.net/index.php
happy crunching

---

D5400XS V8-Xeon

It is, but not often enough to keep the balance right.

NB I'm using BOINC v6.4.5 for the time being, and it doesn't ask for separate allocations for CUDA and CPU - it still just asks for one big chunk of work, and accepts whatever mixture the server chooses to send.

I'm in the same boat. One thing that I've noticed is that with 6.4.5, for me it is only requesting sufficient work for one processor on my 2 dual processor systems (my laptop, and a cheap cruncher box that I just built with a 9800GT). This makes for more micromanagement since I have two single processor machines also. This only started happening when I installed boinc 6.4.5. Is this a "feechur" in 6.4.5 or is there something I've overlooked? Prefs are set to use 100% of the processors.

---

The scheduler in 6.4.x is buggy. A very simple case: I am sending this from a dual quad core Xeon machine. Eight real cores. I have "connect every" set to five and "additional work" set to five. There is nothing but AP 5.03 WUs on the machine. Boinc manager is slightly overestimating their time to completion at 17:52:05. Even if they took 24 hours each, 8 cores x 1 WU per core per day x 10 day buffer = 80 WUs on the machine at any given time. Why then are there a total of 35 WUs on the machine, eight of which are >50% complete? Furthermore, if I make a scheduler request by clicking on update, why does the scheduler request zero seconds of work? Rhetorical questions, of course. I have four other eight core systems which show the same behavior.

As a result of this scheduler arithmetic, I ran dry on most such systems during the recent bandwidth saturation, when I was maintaining a more reasonable zero "connect every", three "additional work" buffer

This is a simple case; the scheduler arithmetic on CUDA systems is much more problematic.

---

--
Classic 82353 WU / 400979 h

Andy:

I have a few dual quad Xeon's with only a few AP WU's as well. Seems to only be keeping few extra WU's even though the cache setting is high.

---

The scheduler in 6.4.x is buggy. A very simple case: I am sending this from a dual quad core Xeon machine. Eight real cores. I have "connect every" set to five and "additional work" set to five. There is nothing but AP 5.03 WUs on the machine. Boinc manager is slightly overestimating their time to completion at 17:52:05. Even if they took 24 hours each, 8 cores x 1 WU per core per day x 10 day buffer = 80 WUs on the machine at any given time. Why then are there a total of 35 WUs on the machine, eight of which are >50% complete? Furthermore, if I make a scheduler request by clicking on update, why does the scheduler request zero seconds of work? Rhetorical questions, of course. I have four other eight core systems which show the same behavior.

As a result of this scheduler arithmetic, I ran dry on most such systems during the recent bandwidth saturation, when I was maintaining a more reasonable zero "connect every", three "additional work" buffer

This is a simple case; the scheduler arithmetic on CUDA systems is much more problematic.

If you can, or if you feel compelled to, give 6.2.19 a try and see what kind of cache build-up you get. The problem I had with 6.4.5 for the three days I tried it was that it ran my ~4-day cache on a twin-dual rig down to less than one day's worth of work for one CPU/core, and would not ask for more work since tasks were still being run in high-priority. Switching back to 6.2.19 immediately requested ~2.5M seconds of work and filled the cache back up with ~4 days' worth of work...per CPU/core. That was my observation. Besides, no need for >6.2.19 anyway..no CUDA.

---

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

I only used that dual quad Xeon box as an example because it is very simple. In my experience, the scheduler in 6.4.5 - 6.4.6 works in the same (buggy) manner on all machines. I'm used to it now. I can live with it until a version with a smarter scheduler is available.

It's not good for a new or inexperienced user, though. It really only keeps a cache about 30-35% of the target for non-CUDA work. CUDA is much worse.

---

--
Classic 82353 WU / 400979 h

I now how had three AP v5 on the trot and no MBs, just unlucky. Will see what the next one is , if it is an AP will untick the V5 box and run MBs for awhile

---

I've had to juggle between AP and MB on the Setiathome Preferences page in order to keep my CUDA pc stocked with the right amount of AP and MB for CUDA and AK_v8. When I start running low on MB, I just deselect all AP work on the preferences page till I get enough MB, and then reselect AP. When I finish the AP I have, I deselect MB til I get the amount of AP I want, and then allow MB again. After a couple of days I start the process oever again. This is with Boinc 6.4.6 (was the same for 6.4.5).

I have had to do exactly the same thing. When I had no AP work units BOINC downloaded 300+ CUDA WU's and no AP. Now they are done it decided to download 20 AP's and no CUDA.

What has changed? It used to work so well......

---

Bambi