Thank you for the update. I figured there was still a good amount of work happening behind the scenes. Looking forward to using the new process..

Since it has restarted, I have had one machine on this exclusively and have experienced no issues with a shortage of work units. I run it with a 1.25 day cache and the units have been taking 28 to 32 hours apiece. A xeon 5320 1.8ghz with Linux Mint.
Cheers

On your "My Contribution" page click the "Settings" (upper right hand area). This will bring you to a screen with some tabs on the left hand side. One of these is "Device Profiles". Click this. You will see four separate profiles. You can customize these to your taste. Once you customize the profiles, you can assign these to any machine. Go to the "Device Manager" tab and click it. This will show you whatever machines you have on WCG. If you click the machine name, it will show a drop down box where you can assign one of the four profiles to that machine. If you have any problems with this, let us know.
Cheers

As far as I know, the job requesting part of BOINC client doesn't know what's in app_config.xml - it's only used by the work scheduler! For example, at the moment any of my machines that will accept FAHV tasks are being swamped with FAHV(!) regardless of what's in my app_config.xml...

I moderate the workload on my systems by not running large job caches. For instance, my 8-thread Linux box has a work queue of less than a day: I've got "Store at least 0.5 days of work" and "Store up to an additional 0.3 days of work" and provided I have a reasonable mix of jobs I've never had a problem. (And if there's a sudden glut of FAH2 work I'd just reduce the 0.5 and 0.3 to the 0.3 and 0.2 I use for my laptop!)

I have 75% CPU allocation (6 threads) because I want one thread spare to feed my (low-power) GPU for Milkyway and Einstein, and one thread is given over to a VirtualBox 32-bit Linux VM in which I run FAH2 and/or HST1 tasks (which are faster by about 25% compiled for 32-bit!) or perform odd tests. So the downloader will only fetch CPU tasks for 6 cores. And I appear to have just under 120 hours (estimated) work for my CPU at the moment, which is almost exactly 0.8 days-worth for each of 6 cores!

So assume it gets (roughly) the amount of work specified for each core/thread and pick numbers to suit - and if you also take ZIKA or OET tasks I doubt you'll get swamped anyway (but if you also take FAHV tasks you might not get any FAH2 at the moment!)

(Of course, the above breaks down when the estimates bear no resemblance to the actual times needed, but there's not much we can do about that, is there?)

I assume you've got an "always on" network (the current FAH2 trickle mechanism doesn't appreciate being delayed!) so I hope the above helps

Cheers - Al.

[Edited: note about "always on" and trickles.]

Thanks alanb1951, that's the conclusion I had come to as well -- but it just seemed rather a major oversight!

I've seen messages before to the effect that work was not being resuested as the BOINC client had estimated that it would not complete before the deadline. To have that logic in there, which clearly has to do a scheduling simulation under the covers in order to provide an estimate, but to then not have that simulation take account of app_config, just seems to me to be a blunder.

Oh well, I can live with it.