Thanks all for the help, that was a direct solution to a simple problem, with a side trip through the possibilities...;)

Be good, be safe, be smart; all.

So far, I've tried a few things.

using the panel below :



I have tried several things.

1). set the buffer size to 10 days. Got a slug of WU's and after having set it back to my previous 0.01 days additional buffer, I continually get significantly more WU's than I should.

2). Tried to set the connect every n days to 10. This is simply useless, the client / server do what they want without respect for this setting. Either fix it or get rid of the setting. One or the other.

3). Connect daily between the hours of xx:xx - xx:xx - again this seems to be a nice knob which appears to do absolutely nothing. I ran an experiment where I permitted connectivity between 23:30 - 23:31 and the client / server still communicated whenever they chose.

If you really want only to allow the client / server to communicate when you want them to, the only thing you can do is to use things like IPCONFIG /RELEASE and drop the connection for your whole system. Kind of silly this seems to be the only way to force WCG / Bionic / whatever to behave itself.

I'm fixin' to uninstall this stupid program and reinstall it and see if that will result in getting the application to work the way I want it to within my parameters.

Well, I can't use v6.2.28 myself, so I'm (blissfully) ignorant on most of the bugs present in this client.

But, I've not seen anything to excess work-requests in v6.6.xx atleast (don't have CUDA so don't know about any CUDA-specific bugs).


This setting works, but the effects is probably unexpected for you due to WCG-tasks having a 10-day deadline. Due to the WCG-deadline, the effects very likely is:
1; Asks for a lot of WCG-work, and gets assigned some tasks.
2; Then tasks has been downloaded, client immediately starts running them in "high-priority"-mode. As long as WCG is in this mode, v6.2.xx will block all work-requests to WCG, except idle cpu.

If you tries "Connect..." either with a BOINC-project with longer deadlines, or if this setting is max 9 days then running WCG, it will most likely work more along your expectations.


Well, in a quick test I can't find any problems with these settings, but there's 3 possible reasons it doesn't work for you:
1; Easily overlooked, if client is set to "Network activity always available", any preference-settings is overridden.
2; In case you've done something manually like hitting "update", or "Retry" or attaching to a project or something, this will enable network-connection even if disabled, and will be kept open for 5 minutes.
3; You've hit a bug. I'm aware there's been one or more bugs with the network-preferences, but don't remember which BOINC-clients was effected, so don't know if v6.2.28 is one of them.

If #3 is your problem, either upgrade to a current BOINC-client (not the WCG 'recommended'), or work-around this bug.

Good to know, wasn't sure with v6.2.xx, but did test both v5.10.45 and v6.6.37.

This is a common belief but it is simply wrong.
It seems to be true when the client switches to high priority mode because the estimated duration of all queued jobs has been suddenly increased after an exceptionally longer job completes. But in this case this is simply because the total estimated duration of all queud jobs has jumped by several hours at once and there is no reason to request new work before a while.

When it is only because you have several days of work queued the client goes on requesting new work as running tasks complete or progress, although all running tasks are in high priority mode, even with normal deadlines and without no risk of completing too late.
I have seen it these last days on three different devices, whether with 6.2.28 for the XP devices or with 6.2.18 under Ubuntu, until I decided to revert my extra work setting from 5 days to 0.5 yesterday.

Cheers. Jean.