Too many work units

[orpy]

Host: 431125

I've temporarily set my windows boxes to accept siever WUs only to see if they will all observe the storage limits set in the preferences for one type of WU.

But, that host can't download any from the server as it has reached a "daily quota of 40 results" and communication has been deferred for 11 hours.

I've noticed that both Mac and Windows Yoyo projects request GPU tasks from the server even though none exist and (even if they did) have been disabled via BAM.

[orpy]

That host is currently crunching 6 SRBase CPU work units and has downloaded a further 17. This seems reasonable as, even if all cores were busy with BOINC, there would be less than 60 work units stored in total.

[orpy]

Just noticed that another host has downloaded an unexpected number of long work units: ID 430461

Preferences were set to 0.1 day's storage + an additional 0.5 days and it will only ever process a maximum of 4 work units at a time.

It now has 389 work units queued to start.

Most of them appear to have an estimated time of 16 hours!

[yoyo]

You see, that host 431125 was still requesting work:

Code: Alles auswählen

2020-11-02 15:08:37.9713 [PID=11648] [normal  ]  Request: [USER#314581] [HOST#431125] [IP xx.xx.xx.xx] client 7.16.11, work req 36390 sec
2020-11-02 15:08:37.9984 [PID=11648] [normal  ]   Daily result quota exceeded for host 431125

The other host and other requests from this host were before I switched on logging.

[orpy]

As I said above:

I've temporarily set my windows boxes to accept siever WUs only to see if they will all observe the storage limits set in the preferences for one type of WU.

But, that host can't download any from the server as it has reached a "daily quota of 40 results" and communication has been deferred for 11 hours.

I wanted to see if it (and all of the other Windows hosts) would download the correct number of work units if it was restricted to a single type with relatively uniform processing times?

[orpy]

I left host 431125 to "allow new tasks" for a couple of hours last night and it downloaded over 900 WUs!

I'll let it work through as many as possible over the next week without aborting.

I couldn't restart as many of the existing units were M Queens which seem to start again from scratch if you reboot?

This morning the Mac host also has 997 tasks waiting to be processed. 230 have Nov 7th deadlines that won't be met.

[orpy]

Another observation:

Both of the troublesome hosts have app_config.xml files in the project folder that were limiting ECM tasks to 3 concurrent and to report tasks immediately.

The other hosts that I've checked don't have this config file, but most also use the cc_config to force reporting tasks immediately.

I'm going to remove the app_config.xml files and see what happens...

[mister.marmot]

Was there a determination of the final cause of this issue?

I had set my clients in cc_config.xml to stop doing benchmarks in order to save time but (if I remember correctly) some of them had a similar issue downloading way too many of YoYo WU's.

Maybe a simple solution would be to use the advanced BOINC menu item 'tools' -> 'run CPU benchmarks' may have fixed the issue as the client may have corrupted or extremely over rated CPU benchmarks stored.

[gemini8]

After your question I read the whole thread again.
Only thing I noticed was the Boinc version, 7.16.xx.
There has been quite a lot of discussion about 7.16.xx on PrimeGrid Discord, as it does things different from earlier versions - most notable is an earlier prefetch of new work, which is bad on PrimeGrid.
Maybe another client, at latest 7.14.xx, would be helping.

[mister.marmot]

This was happening to me all last year, even when setting rss share to 0.
But the 2700x and 1090t machines are now just getting 1 WU per core.

The 0 resource share setting appears to be honored by YoYo now.

So a solution is to set rss share to 0 if YoYo isn't in competition with other projects with higher rss share.