Posts by Brian Nixon

1) Message boards : Questions and problems : boinc-client reports wrong disk size (Message 111826) Posted 16 May 2023 by Brian Nixon Post: BOINC reports the size of the filesystem it is running from (which is where its data directory resides). 97.87GB disk size and 53.76GB free looks like a pretty good match for /dev/mapper/ubuntu--vg-ubuntu--lv ext4 98G 40G 54G 43% /
2) Message boards : Questions and problems : Please publish release notes for BOINC 7.20.7 for MacOs (Message 111811) Posted 15 May 2023 by Brian Nixon Post: BOINC for Mac is not released through GitHub. It’s built and uploaded separately by Charlie Fenton. 7.20.7 is a hotfix for a display bug (mentioned in threads here and here). Search different: https://github.com/BOINC/boinc/issues?q=7.20.7
3) Message boards : Questions and problems : "Use at most N % CPU time" does not seem to have any effect (Message 111776) Posted 9 May 2023 by Brian Nixon Post: further experiments don't really back By now I should have learned to test before inventing answers… The act of changing the preferences triggers the client to reschedule, which will resume tasks that were suspended by the previous throttling. This is why CPU usage goes back up to 100% immediately. However, it does not change the fact that the thottler thread is asleep for a duration based on the previous setting, so the desired CPU usage will still not happen until that thread wakes up. This is why further changes appear to have no effect. (Though given enough time, it will start to work again.)
4) Message boards : Questions and problems : "Use at most N % CPU time" does not seem to have any effect (Message 111767) Posted 9 May 2023 by Brian Nixon Post: <options> <Read local preferences file>? It won’t help, because the client’s throttler thread has already decided to sleep for as long as it needs to fulfil the earlier preference (which in the extreme case is 9999 seconds), and there’s no way to wake it from its slumber.
5) Message boards : Questions and problems : "Use at most N % CPU time" does not seem to have any effect (Message 111765) Posted 9 May 2023 by Brian Nixon Post: it doesn't seem to activate reliably while on the run This is a side-effect of the way the throttling is implemented. Setting the preference to 0.01% is the same as asking BOINC to do nothing for 2¾ hours (1 second running to 9999 seconds suspended). It will wait that long before it applies the changed value. You might want to raise that as a bug…
6) Message boards : Questions and problems : "Use at most N % CPU time" does not seem to have any effect (Message 111758) Posted 9 May 2023 by Brian Nixon Post: Ah, yes – 7.22 introduced the ‘not in use’ settings, so there are now two pairs of CPU % preferences to take into account. Could it be that you’re seeing the ‘in use’ values getting applied rather than the ‘not in use’ ones (or vice versa)?
7) Message boards : Questions and problems : Effect of suspending and limiting on checkpoints (Message 111756) Posted 9 May 2023 by Brian Nixon Post: You’re right: tasks are not removed from memory when they are suspended by the % of CPU time preference [source]. Thanks for the correction!
8) Message boards : Questions and problems : Effect of suspending and limiting on checkpoints (Message 111754) Posted 9 May 2023 by Brian Nixon Post: For CPU apps: Whether or not work is lost when tasks are suspended depends on the setting Leave non-GPU tasks in memory while suspended. If that is checked, no work should be lost, because the task processes continue to exist and just pick up where they left off when preferences later allow them to run again. If it is not checked, task processes will exit when they are suspended, so it depends on the individual app: if it is able to capture the exit request and checkpoint immediately, no work is lost. Otherwise it will simply get killed and have to restore from its previous checkpoint when restarted. The effect is the same in all three cases: the only difference is in the number of tasks that are either suspended or allowed to run (for the % of CPUs case), and the frequency at which suspension and resumption occur (for the % of time case). This is not true: see correction below.
9) Message boards : Questions and problems : "Use at most N % CPU time" does not seem to have any effect (Message 111748) Posted 9 May 2023 by Brian Nixon Post: The CPU throttling setting was inadvertently broken in 7.22.0. It should be fixed again in 7.22.1, which has just been released for testing.
10) Message boards : Questions and problems : High priority mode? (Message 111723) Posted 3 May 2023 by Brian Nixon Post: You said earlier "the WCG tasks will become the ones most likely to miss their deadline" “Most likely” is perhaps inaccurate. At every scheduling point, BOINC predicts whether each task will miss its deadline. There is no relative grading of probability; it’s 0 or 100%. Right now, your PrimeGrid tasks get priority because under all conceivable scheduling choices, they will miss their deadline. In that situation, the client’s policy is to give them the chance to run – it allows for the remaining-time and achieved-performance estimates to be wrong (and perhaps to improve over time), and it is not permitted to abort the tasks simply because it believes it has no chance of finishing them. The WCG tasks do not get priority yet, because there is still plenty of time before the deadline to do the remaining work; the client does not need to favour them over the PrimeGrid tasks now, because it can reschedule later. WCG with 15 minutes to go on a 2 minute deadline It should never get that close to the wire. With a work buffer of 1 day, the scheduler applies 1 day of padding to task deadlines (because it could run for that long before next contacting a server). So 1 day before the WCG tasks are due, the scheduler will predict that all tasks will miss their deadline, at which point they get prioritised in deadline order (the intuitive interpretation of “earliest deadline first”). I've seen it fail many times. If you can get a concrete example of that, please capture the client state, feed it in to the Client Emulator, and raise a bug. I'm sure WCG would appreciate their tasks getting done sooner If a project wants its tasks returned sooner, it needs to set earlier deadlines. BOINC is not a race; it does not care whether tasks finish 1 second or 1 week before their deadline.
11) Message boards : Questions and problems : High priority mode? (Message 111721) Posted 3 May 2023 by Brian Nixon Post: until some point where WCG is also behind With a 1-⁠day work buffer, that shouldn’t happen. The client will realise WCG needs prioritising before it gets behind, not once it gets behind – so (assuming the remaining-time estimates aren’t wildly wrong) the tasks will finish by their deadline.
12) Message boards : Questions and problems : High priority mode? (Message 111719) Posted 3 May 2023 by Brian Nixon Post: Especially when you then don't do things you could have But it will do them. (Or at least it should…) Under the existing policy, and all else remaining equal: at some point during the next 3 days, the WCG tasks will become the ones most likely to miss their deadline (even with the others still in progress), and they will be given priority such that they complete in time.
13) Message boards : Questions and problems : High priority mode? (Message 111716) Posted 3 May 2023 by Brian Nixon Post: In the world of the BOINC client scheduler, “earliest deadline” doesn’t mean “the deadline occurring first in the calendar”; it means “the task most likely to miss its deadline”. In your case, then (as Richard has already explained), “earliest deadline first” policy (which BoincTasks labels “high priority”) means the “50-⁠day” tasks get to run, because they are projected to miss their deadline. Everything else is lower priority. The prioritisation algorithm is: favor jobs in danger of deadline miss favor coproc jobs, so that e.g. if we're RAM-limited we'll use the GPU instead of the CPU favor jobs in the middle of time slice, or that haven't checkpointed since start of time slice for CPU jobs, favor jobs that use more CPUs favor jobs selected first by schedule_cpus() (e.g., because their project has high sched priority) If you speak C++, you can see the implementation here.
14) Message boards : Questions and problems : How to get Flatpak BOINC manager to let the client run when the manager window is closed? (Message 111616) Posted 20 Apr 2023 by Brian Nixon Post: that latter, presumably, is the one I want to set up to run on system start, but there is no /app folder -- not even inside ~/.var. The /app folder is part of the Flatpak bundle. The thing is that with Flatpak, you don’t explicitly run things inside it; you just run the Flatpak. And the BOINC Flatpak is configured to start the Manager. The Manager starts the client, and the client starts the project science apps. I’m not sure the Flatpak arrangement lends itself to running as a system service, either, as the whole infrastructure seems to expect an interactive desktop session to be available.
15) Message boards : Questions and problems : Old way doesn't work -- how do I change where BOINC looks for its data directory (Kubuntu 22.04)? (Message 111610) Posted 19 Apr 2023 by Brian Nixon Post: why isn't this an option in the BOINC manager? Because the location of the data directory is not decided by BOINC. It’s decided by however the client is installed/invoked. The data directory is simply the working directory in which the BOINC client is executed. On Linux systems that use the BOINC-supplied scripts, this is set by the variable BOINCDIR. On Windows, it’s in the Registry value HKLM\SOFTWARE\Space Sciences Laboratory, U.C. Berkeley\BOINC Setup\DATADIR. (Also: if the directory were a client preference, there’d be a chicken-and-egg problem to resolve because for the Manager to be able to set client preferences, it needs to be connected to a running client. And if the client is running, its data directory has already been decided…)
16) Message boards : Questions and problems : How to get Flatpak BOINC manager to let the client run when the manager window is closed? (Message 111609) Posted 19 Apr 2023 by Brian Nixon Post: The Flatpak build patches BOINC to set the default for Stop running tasks when exiting the BOINC Manager to ‘on’. The only place to unset that option in the GUI is in the confirmation dialog that appears when you Exit (not Close) the manager via File » Exit BOINC Manager. You only see that dialog if you have checked Enable Manager exit dialog? in Options » Other options.

Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.