Hey all, I've currently got my 2 laptops set to connect to the network only between 3a and 5a, but they pretty much always wait until 4:30a (exactly, it seems) to request work for the whole day, which for them takes longer than 30 minutes to download (Rosetta)

Is there any way I can tell them to request work earlier in the specified network window so they don't run out of network time? Like preferably at 3a?

If BOINC 7.0 or 7.2, BOINC will only request more work when it's going under the minimum work mark of Maintain enough tasks to keep busy for at least X days. It will then fill the cache for the minimum + the amount of ... and up to an additional Y days amount. So if you find that BOINC only does this at 4.30am, perhaps you should try to play with the values there.

---

Currently X is 0.9 and Y is 2. Of course the extra work cached is less than Y almost immediately, and the total work on hand is rarely less than X. There are a few ways I could be adjusting the values for X and Y here; should X be even lower and Y higher to compensate?

Also, until I find the boinc-specific setting I'm looking for, I just set up a systemd job (running Arch linux; we shun cron):

/etc/systemd/system/boinc-scheduler-update.service

[Unit]
Description=For Rosetta@Home, forces a scheduler request.

[Service]
Type=oneshot
ExecStart=/usr/bin/boinccmd --passwd [from /var/lib/boinc/gui_auth_rpc.cfg] --project http://boinc.bakerlab.org/rosetta/ update

/etc/systemd/system/boinc-scheduler-update.timer

[Unit]
Description=the timer for daily BOINC project updates (currently pegged to the start of the network availability window at slightly after 3am)

[Timer]
OnCalendar=*-*-* 03:01:00
Unit=boinc-scheduler-update.service

[Install]
WantedBy=basic.target

Then of course in bash:

sudo systemctl enable boinc-scheduler-update.timer
sudo systemctl start boinc-scheduler-update.timer

Ageless, I concede that a problem exists between the keyboard and chair here;

Your terms

Maintain enough tasks to keep busy for at least X days

and

the amount of ... and up to an additional Y days

Are not used as such on either WCG or Rosetta@Home, where the terms used are something like:
(1) Connect to network about every … days / Computer is connected to the internet every … days; and
(2) Cache … extra days of work / Maintain enough work for an addition … days

I presume that your x is their (1), and that your y is their (2), but that is unclear to me (and a project-specific question, I realize)

I presume that your x is their (1), and that your y is their (2), but that is unclear to me (and a project-specific question, I realize)

Newer BOINC versions (all BOINC 7) have these same options in their local advanced computing preferences. But when the project still uses the old values, you'll have to turn them around. So no, in your case then, my X is 2, and Y is 1.

---

Setting

Connect to network about every … days / Computer is connected to the internet every … days

to 0 and setting

Cache … extra days of work / Maintain enough work for an addition … days

to 2 did not produce the desired result (i.e. contrary to my wishes, the client did not send scheduler update request until 4:30a, when there were only 30 minutes remaining in the allotted network window.)

My cron-like systemd script below though works fine (except I changed 3:01a to 4:00a since Rosetta@home was refusing to download until it got some uploads out of the way), and is a functional fix if slightly more jury-rigged than I would like, so I probably won't be conducting the obverse test (reversing 2 and 0 above).

Thanks for your time ageless, I was definitely confused by my project's network connectivity terminology

Wouldn't you know, the obverse was just what I was looking for.

That is, (in World Community Grid),

Connect to network about every [2.0] days
Cache [0] extra days of work

And (in Rosetta@Home),

Computer is connected to the Internet about every [2.0] days
Maintain enough work for an additional [0.0] days

Sends scheduler requests at (well, really near) the beginning of the network availability window.
It's exactly the setup I was looking for, and was the one I hadn't yet tried.
Also, this setup renders obsolete the systemd setup mentioned below, which I turned off (disable; stop)