Zero (0) resource share or other limit to WU sent

Alles zum Projekt yoyo@home
Everything about the project yoyo@home
Nachricht
Autor
mister.marmot
PDA-Benutzer
PDA-Benutzer
Beiträge: 34
Registriert: 15.07.2016 00:53

Zero (0) resource share or other limit to WU sent

#1 Ungelesener Beitrag von mister.marmot » 23.05.2019 06:25

YoYo preferences won't accept 0 resource share for limiting WU's.

ECM sends thousands of WU to my machines and only need 8 at a time.

If ECM is flooded work cache then can't get BURP (some showed today after 45 days), and other rare projects.

How can we limit ECM to 8 WU's on the computer at any moment?

app_config.xml can only control max_concurrent and gpu_usage / cpu_usage.

Benutzeravatar
yoyo
Vereinsvorstand
Vereinsvorstand
Beiträge: 8045
Registriert: 17.12.2002 14:09
Wohnort: Berlin
Kontaktdaten:

Re: Zero (0) resource share or other limit to WU sent

#2 Ungelesener Beitrag von yoyo » 23.05.2019 07:05

Yes, ressource share of 0 is not supported.

It is basically your BOINC client which requests the amount of work, it is NOT the yoyo server.
Your client sends a get work for X seconds to the yoyo server together with the number of cpu and FLOPS a cpu can handle. And the server fullfills the request and sends back workunits for the required time.

So to reduce the requested working time request:
- use a small ressource share for yoyo, e.g. 1 while all other projects have 100
- reduce your working cache size to e.g. 0 days.

yoyo
HILF mit im Rechenkraft-WiKi, dies gibts zu tun.
Wiki - FAQ - Verein - Chat

Bild Bild

mister.marmot
PDA-Benutzer
PDA-Benutzer
Beiträge: 34
Registriert: 15.07.2016 00:53

Re: Zero (0) resource share or other limit to WU sent

#3 Ungelesener Beitrag von mister.marmot » 23.05.2019 17:11

yoyo hat geschrieben:
23.05.2019 07:05
So to reduce the requested working time request:
- use a small ressource share for yoyo, e.g. 1 while all other projects have 100
I have many years of BOINC project managing experience.
The things you stated are nothing new to me.

YoYo is set to resource share 1, the critical projects with rare work are set to 250, the projects with plentiful work or that ignore resource shares, and behave badly, are set to 0.

Not every project has work available when requested and so YoYo sends hundreds of ECM, filling the cache, and then BOINC doesn't request work for hours, possibly missing out on rare work units (RNA World) even though those projects have resources share of 100, 200 or 250.
Also, BOINC client will reduce it's frequency of requests from every 15 minutes up to 6 hours if the cache is almost full.

Leaving cores open, or cores full with absolutely no extra WU in the cache, is the only way to get BOINC to ask for work every 15 minutes from rare work (according to the setting 0.01 in Store up to Additional), like RNA World.
yoyo hat geschrieben:
23.05.2019 07:05

- reduce your working cache size to e.g. 0 days.
The other projects, when rare work becomes available (like Sixtrack at LHC, Einstein LOGO work), needs to have 3 days requested as a buffer to deal with projects that only batch limited work units once a day.

This unsupported resource share 0 issue is why I moved ECM into a Virtual Machine, isolating it from other projects; but ECM Wrapper sits doing nothing for days if the VM's RTC desyncs from the host RTC.
:uhoh: I'll have to create a 2nd BOINC data directory and run ECM alone in it's own BOINC client.

Antworten

Zurück zu „Number crunching“