cpu_usage_limit not working as expected

[Seven-709]

Hi all,

I'm running BOINC (SETI and WCG) on my MBP Mid-2105 since quite some time (several years) now. However, one behavior of the client is confusing me almost the whole time. When limiting the percentage of CPU Time the actual average CPU load caused by BOINC might be totally different ... examples: At 1% the actual load is ~70%, at 12,5% it's ~12%, at 30% it's ~9% and at 50% it's ~50% (all loads are 10 minute averages). My expectation is that when I configure a certain max CPU load percentage then BOINC is indeed only using that load, give or take 5% ... But in fact it seems that only certain values are producing a "correct" load, whereas all other values in between have a more or less random effect on the actual load.

Of course, it's always possible that either my expectation is wrong or I did something wrong in the configuration. In any other case, I'm more than happy to provide further information to get this issue solved.

regards
Seven

[AenBleidd]

I'm afraid, your calculations are a little bit wrong. Limiting CPU time means limiting a time when application actually run.
E.g. we have 1 second.
So if we set CPU usage to 50%, BOINC will run 0,5 seconds at 100% of CPU giving in total 50% of CPU usage.
If you set CPU usage to 30%, BOINC will run 0.3 seconds at 100% giving in total 30% of CPU usage.
But!
There is no way to tell OS to run some thread some particular amount of time, for example 0.5 seconds. Because of the scheduling policy, thread could run less that 0.5 seconds because there was more prioritized thread in the system, or it could run a little bit more than 0.5 seconds, because OS missed the exact moment to put the thread on sleep mode.
And even more: there is no clear way to see exact CPU usage of some particular process, at least with standard tools of OS.

I hope I answered your question.

[Seven-709]

Hi Vitali, thank you very much for your quick response. I understand that there is a certain … uncertainty and you cannot expect an exact one-to-one of the actual measured CPU Load and the configured CPU usage in BOINC … But … I have an MBP mid-2015 running macOS Mojave 10.14.6 with an eight core i7, 16GB RAM, BOINC 7.16.6, three projects and all cores allowed to be used resulting in currently 8 tasks. Just today I configured BOINC with 1% CPU usage to test my suspicion. Let’s assume a 100 second window … if I understand you right, BOINC will run a given task for 1 second within that 100 second window and obviously we cannot predict at which point in time this will happen exactly. So, as far as my humble knowledge of hardware goes, even in a worst case the CPU should be 100% busy only one second out of 100 in case all eight BOINC tasks will be processed at the very same time. Very likely the actual load is less since the eight threads will be executed not all at the same time. In other words, we can safely assume that the CPU should be idling at least 90% of the time with this setting. However, what I really measured was a 70% CPU load over 10 minutes in average. Right now I’m running BOINC with 30% cpu_usage_limit and my actual CPU load is 12% .. so it’s actually using only half of what it should use, which is quite the opposite of the 1% setting. Again, I would agree in a +/- 5% difference of the configured value due to the technical reasons you described. My actual experience is, that for almost all configured values „cpu_usage_limit" the actual load is more or less out of scope and only very few settings will really hit the spot … I have to admit the I only have this one MPB for „testing“ so it might be a „local“ problem of my particular configuration. regards Seven

…

Am 09.04.2020 um 17:15 schrieb Vitalii Koshura ***@***.***>: I'm afraid, your calculations are a little bit wrong. Limiting CPU time means limiting a time when application actually run. E.g. we have 1 second. So if we set CPU usage to 50%, BOINC will run 0,5 seconds at 100% of CPU giving in total 50% of CPU usage. If you set CPU usage to 30%, BOINC will run 0.3 seconds at 100% giving in total 30% of CPU usage. But! There is no way to tell OS to run some thread some particular amount of time, for example 0.5 seconds. Because of the scheduling policy, thread could run less that 0.5 seconds because there was more prioritized thread in the system, or it could run a little bit more than 0.5 seconds, because OS missed the exact moment to put the thread on sleep mode. And even more: there is no clear way to see exact CPU usage of some particular process, at least with standard tools of OS. I hope I answered your question. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3583 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL6BD32JPLX7C2QMOAXE6CLRLXRBDANCNFSM4MEZULKQ>.

[SETIguy]

What tool are you using to measure CPU time? Many tools are inconsistent about what they measure and how they average over time. A grab or copy/paste from "top -d 120" showing per process CPU stats after a couple minutes for the apps would help.

…

On Thu, Apr 9, 2020 at 9:21 AM Seven-709 ***@***.***> wrote: Hi Vitali, thank you very much for your quick response. I understand that there is a certain … uncertainty and you cannot expect an exact one-to-one of the actual measured CPU Load and the configured CPU usage in BOINC … But … I have an MBP mid-2015 running macOS Mojave 10.14.6 with an eight core i7, 16GB RAM, BOINC 7.16.6, three projects and all cores allowed to be used resulting in currently 8 tasks. Just today I configured BOINC with 1% CPU usage to test my suspicion. Let’s assume a 100 second window … if I understand you right, BOINC will run a given task for 1 second within that 100 second window and obviously we cannot predict at which point in time this will happen exactly. So, as far as my humble knowledge of hardware goes, even in a worst case the CPU should be 100% busy only one second out of 100 in case all eight BOINC tasks will be processed at the very same time. Very likely the actual load is less since the eight threads will be executed not all at the same time. In other words, we can safely assume that the CPU should be idling at least 90% of the time with this setting. However, what I really measured was a 70% CPU load over 10 minutes in average. Right now I’m running BOINC with 30% cpu_usage_limit and my actual CPU load is 12% .. so it’s actually using only half of what it should use, which is quite the opposite of the 1% setting. Again, I would agree in a +/- 5% difference of the configured value due to the technical reasons you described. My actual experience is, that for almost all configured values „cpu_usage_limit" the actual load is more or less out of scope and only very few settings will really hit the spot … I have to admit the I only have this one MPB for „testing“ so it might be a „local“ problem of my particular configuration. regards Seven > Am 09.04.2020 um 17:15 schrieb Vitalii Koshura ***@***.*** >: > > > I'm afraid, your calculations are a little bit wrong. Limiting CPU time means limiting a time when application actually run. > E.g. we have 1 second. > So if we set CPU usage to 50%, BOINC will run 0,5 seconds at 100% of CPU giving in total 50% of CPU usage. > If you set CPU usage to 30%, BOINC will run 0.3 seconds at 100% giving in total 30% of CPU usage. > But! > There is no way to tell OS to run some thread some particular amount of time, for example 0.5 seconds. Because of the scheduling policy, thread could run less that 0.5 seconds because there was more prioritized thread in the system, or it could run a little bit more than 0.5 seconds, because OS missed the exact moment to put the thread on sleep mode. > And even more: there is no clear way to see exact CPU usage of some particular process, at least with standard tools of OS. > > I hope I answered your question. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub < #3583 (comment)>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AL6BD32JPLX7C2QMOAXE6CLRLXRBDANCNFSM4MEZULKQ >. > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3583 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACS5ZMWYIG2MUSDN4GMCDILRLXYY5ANCNFSM4MEZULKQ> .

-- Eric Korpela korpela@ssl.berkeley.edu AST:7731^29u18e3

[Seven-709]

Hi, for my measures I used only top, during my longer sessions yesterday top -l 0 -s 600 | grep --line-buffered -i 'CPU usage' for the purpose of this e-mail top -s 120 -o cpu Please note that the ‚top‘ parameters are slightly different for macOS and Linux. Attached you’ll find two screenshots showing the output of top, the activity monitor from apple and the actual configuration GUI from BOINC. regards Seven

…

Am 09.04.2020 um 21:11 schrieb SETIguy ***@***.***>: What tool are you using to measure CPU time? Many tools are inconsistent about what they measure and how they average over time. A grab or copy/paste from "top -d 120" showing per process CPU stats after a couple minutes for the apps would help. On Thu, Apr 9, 2020 at 9:21 AM Seven-709 ***@***.***> wrote: > Hi Vitali, > > thank you very much for your quick response. > > I understand that there is a certain … uncertainty and you cannot expect > an exact one-to-one of the actual measured CPU Load and the configured CPU > usage in BOINC … But … > > I have an MBP mid-2015 running macOS Mojave 10.14.6 with an eight core i7, > 16GB RAM, BOINC 7.16.6, three projects and all cores allowed to be used > resulting in currently 8 tasks. > > Just today I configured BOINC with 1% CPU usage to test my suspicion. > Let’s assume a 100 second window … if I understand you right, BOINC will > run a given task for 1 second within that 100 second window and obviously > we cannot predict at which point in time this will happen exactly. So, as > far as my humble knowledge of hardware goes, even in a worst case the CPU > should be 100% busy only one second out of 100 in case all eight BOINC > tasks will be processed at the very same time. Very likely the actual load > is less since the eight threads will be executed not all at the same time. > In other words, we can safely assume that the CPU should be idling at least > 90% of the time with this setting. > > However, what I really measured was a 70% CPU load over 10 minutes in > average. Right now I’m running BOINC with 30% cpu_usage_limit and my actual > CPU load is 12% .. so it’s actually using only half of what it should use, > which is quite the opposite of the 1% setting. > > Again, I would agree in a +/- 5% difference of the configured value due to > the technical reasons you described. My actual experience is, that for > almost all configured values „cpu_usage_limit" the actual load is more or > less out of scope and only very few settings will really hit the spot … I > have to admit the I only have this one MPB for „testing“ so it might be a > „local“ problem of my particular configuration. > > regards > Seven > > > > > > > > > Am 09.04.2020 um 17:15 schrieb Vitalii Koshura ***@***.*** > >: > > > > > > I'm afraid, your calculations are a little bit wrong. Limiting CPU time > means limiting a time when application actually run. > > E.g. we have 1 second. > > So if we set CPU usage to 50%, BOINC will run 0,5 seconds at 100% of CPU > giving in total 50% of CPU usage. > > If you set CPU usage to 30%, BOINC will run 0.3 seconds at 100% giving > in total 30% of CPU usage. > > But! > > There is no way to tell OS to run some thread some particular amount of > time, for example 0.5 seconds. Because of the scheduling policy, thread > could run less that 0.5 seconds because there was more prioritized thread > in the system, or it could run a little bit more than 0.5 seconds, because > OS missed the exact moment to put the thread on sleep mode. > > And even more: there is no clear way to see exact CPU usage of some > particular process, at least with standard tools of OS. > > > > I hope I answered your question. > > > > — > > You are receiving this because you authored the thread. > > Reply to this email directly, view it on GitHub < > #3583 (comment)>, or > unsubscribe < > https://github.com/notifications/unsubscribe-auth/AL6BD32JPLX7C2QMOAXE6CLRLXRBDANCNFSM4MEZULKQ > >. > > > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#3583 (comment)>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACS5ZMWYIG2MUSDN4GMCDILRLXYY5ANCNFSM4MEZULKQ> > . > -- Eric Korpela ***@***.*** AST:7731^29u18e3 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3583 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL6BD35HK2HJYR3FH6A5E4LRLYMWPANCNFSM4MEZULKQ>.

[Seven-709]

I’m very sorry, I just noticed that the actual figures can’t barely be seen on the reduced screenshots, I hope that’s better now :-) Hi, for my measures I used only top, during my longer sessions yesterday top -l 0 -s 600 | grep --line-buffered -i 'CPU usage' for the purpose of this e-mail top -s 120 -o cpu Please note that the ‚top‘ parameters are slightly different for macOS and Linux. Attached you’ll find two screenshots showing the output of top, the activity monitor from apple and the actual configuration GUI from BOINC. regards Seven

…

Am 09.04.2020 um 21:11 schrieb SETIguy ***@***.*** ***@***.***>>: What tool are you using to measure CPU time? Many tools are inconsistent about what they measure and how they average over time. A grab or copy/paste from "top -d 120" showing per process CPU stats after a couple minutes for the apps would help. On Thu, Apr 9, 2020 at 9:21 AM Seven-709 ***@***.*** ***@***.***>> wrote: > Hi Vitali, > > thank you very much for your quick response. > > I understand that there is a certain … uncertainty and you cannot expect > an exact one-to-one of the actual measured CPU Load and the configured CPU > usage in BOINC … But … > > I have an MBP mid-2015 running macOS Mojave 10.14.6 with an eight core i7, > 16GB RAM, BOINC 7.16.6, three projects and all cores allowed to be used > resulting in currently 8 tasks. > > Just today I configured BOINC with 1% CPU usage to test my suspicion. > Let’s assume a 100 second window … if I understand you right, BOINC will > run a given task for 1 second within that 100 second window and obviously > we cannot predict at which point in time this will happen exactly. So, as > far as my humble knowledge of hardware goes, even in a worst case the CPU > should be 100% busy only one second out of 100 in case all eight BOINC > tasks will be processed at the very same time. Very likely the actual load > is less since the eight threads will be executed not all at the same time. > In other words, we can safely assume that the CPU should be idling at least > 90% of the time with this setting. > > However, what I really measured was a 70% CPU load over 10 minutes in > average. Right now I’m running BOINC with 30% cpu_usage_limit and my actual > CPU load is 12% .. so it’s actually using only half of what it should use, > which is quite the opposite of the 1% setting. > > Again, I would agree in a +/- 5% difference of the configured value due to > the technical reasons you described. My actual experience is, that for > almost all configured values „cpu_usage_limit" the actual load is more or > less out of scope and only very few settings will really hit the spot … I > have to admit the I only have this one MPB for „testing“ so it might be a > „local“ problem of my particular configuration. > > regards > Seven > > > > > > > > > Am 09.04.2020 um 17:15 schrieb Vitalii Koshura ***@***.*** ***@***.***> > >: > > > > > > I'm afraid, your calculations are a little bit wrong. Limiting CPU time > means limiting a time when application actually run. > > E.g. we have 1 second. > > So if we set CPU usage to 50%, BOINC will run 0,5 seconds at 100% of CPU > giving in total 50% of CPU usage. > > If you set CPU usage to 30%, BOINC will run 0.3 seconds at 100% giving > in total 30% of CPU usage. > > But! > > There is no way to tell OS to run some thread some particular amount of > time, for example 0.5 seconds. Because of the scheduling policy, thread > could run less that 0.5 seconds because there was more prioritized thread > in the system, or it could run a little bit more than 0.5 seconds, because > OS missed the exact moment to put the thread on sleep mode. > > And even more: there is no clear way to see exact CPU usage of some > particular process, at least with standard tools of OS. > > > > I hope I answered your question. > > > > — > > You are receiving this because you authored the thread. > > Reply to this email directly, view it on GitHub < > #3583 (comment) <#3583 (comment)>>, or > unsubscribe < > https://github.com/notifications/unsubscribe-auth/AL6BD32JPLX7C2QMOAXE6CLRLXRBDANCNFSM4MEZULKQ <https://github.com/notifications/unsubscribe-auth/AL6BD32JPLX7C2QMOAXE6CLRLXRBDANCNFSM4MEZULKQ> > >. > > > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#3583 (comment) <#3583 (comment)>>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACS5ZMWYIG2MUSDN4GMCDILRLXYY5ANCNFSM4MEZULKQ <https://github.com/notifications/unsubscribe-auth/ACS5ZMWYIG2MUSDN4GMCDILRLXYY5ANCNFSM4MEZULKQ>> > . > -- Eric Korpela ***@***.*** ***@***.***> AST:7731^29u18e3 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3583 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL6BD35HK2HJYR3FH6A5E4LRLYMWPANCNFSM4MEZULKQ>.

[davidpanderson]

BTW: CPU throttling has 1-second granularity.
If you have it set to 25% it will do (1s on, 3s off)*

I'll test this on my Mac.

[SETIguy]

Looks like the list trims attachments. Maybe a pasteboard or google photos link?

[Seven-709]

Hi, yes, most unfortunately this sometimes happens when sending attachments with „Mail“ from macOS .. I’ve compressed both screenshots. Can you extract them from the ZIP archive? regards Seven

…

Am 10.04.2020 um 23:00 schrieb SETIguy ***@***.***>: Looks like the list trims attachments. Maybe a pasteboard or google photos link? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3583 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL6BD36TALIIVS5QX6YDL7LRL6CHVANCNFSM4MEZULKQ>.

[Ageless93]

The list you post to drops attachments. Better post the images to an external site and put the links to them here. Or use Dropbox.

…

On Sat, 11 Apr 2020, 09:26 Seven-709 ***@***.***> wrote: Hi, yes, most unfortunately this sometimes happens when sending attachments with „Mail“ from macOS .. I’ve compressed both screenshots. Can you extract them from the ZIP archive? regards Seven > Am 10.04.2020 um 23:00 schrieb SETIguy ***@***.***>: > > > Looks like the list trims attachments. Maybe a pasteboard or google photos > link? > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub < #3583 (comment)>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AL6BD36TALIIVS5QX6YDL7LRL6CHVANCNFSM4MEZULKQ >. > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3583 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACS5WU6CAUDANUK7SMJHNPLRMALSTANCNFSM4MEZULKQ> .

[Seven-709]

Ahhh … sorry for the misunderstanding … now I understand :-) However, due to security and privacy concerns I have no account for any of the usual suspects in this matter … I will think about a way to let you access it .. Would be FTP an alternative? I have a private cloud at my disposal and can grant you access via FTP with a dedicated username/password? This way, we can also exchange other data you might be interested in :-) regards Seven

…

Am 11.04.2020 um 09:31 schrieb Jord van der Elst ***@***.***>: The list you post to drops attachments. Better post the images to an external site and put the links to them here. Or use Dropbox. On Sat, 11 Apr 2020, 09:26 Seven-709 ***@***.***> wrote: > > > Hi, > > yes, most unfortunately this sometimes happens when sending attachments > with „Mail“ from macOS .. I’ve compressed both screenshots. Can you extract > them from the ZIP archive? > > regards > Seven > > > > Am 10.04.2020 um 23:00 schrieb SETIguy ***@***.***>: > > > > > > Looks like the list trims attachments. Maybe a pasteboard or google > photos > > link? > > — > > You are receiving this because you authored the thread. > > Reply to this email directly, view it on GitHub < > #3583 (comment)>, or > unsubscribe < > https://github.com/notifications/unsubscribe-auth/AL6BD36TALIIVS5QX6YDL7LRL6CHVANCNFSM4MEZULKQ > >. > > > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#3583 (comment)>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACS5WU6CAUDANUK7SMJHNPLRMALSTANCNFSM4MEZULKQ> > . > — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3583 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL6BD36KB7QTVMY5JCOMV5LRMAMGDANCNFSM4MEZULKQ>.

[Seven-709]

Ahhh … good to know … then for 30% that would be 3s on, 7s off then? … for 35% it would be 7s on, 20s off, for 33% 33s on, 67s off and so on ?

…

Am 10.04.2020 um 21:24 schrieb David Anderson ***@***.***>: BTW: CPU throttling has 1-second granularity. If you have it set to 25% it will do (1s on, 3s off)* I'll test this on my Mac. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3583 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL6BD34ICIKY7UHPHT5JENTRL5W7XANCNFSM4MEZULKQ>.

[Seven-709]

Hi all, I’m not sure if I made it right :-) Please try to download the file from google drive https://drive.google.com/file/d/1sb8qaUlv1AkJJ98WTThlAtilH5nKtlmZ/view?usp=sharing <https://drive.google.com/file/d/1sb8qaUlv1AkJJ98WTThlAtilH5nKtlmZ/view?usp=sharing> regards Seven

…

Am 11.04.2020 um 09:31 schrieb Jord van der Elst ***@***.***>: The list you post to drops attachments. Better post the images to an external site and put the links to them here. Or use Dropbox. On Sat, 11 Apr 2020, 09:26 Seven-709 ***@***.***> wrote: > > > Hi, > > yes, most unfortunately this sometimes happens when sending attachments > with „Mail“ from macOS .. I’ve compressed both screenshots. Can you extract > them from the ZIP archive? > > regards > Seven > > > > Am 10.04.2020 um 23:00 schrieb SETIguy ***@***.***>: > > > > > > Looks like the list trims attachments. Maybe a pasteboard or google > photos > > link? > > — > > You are receiving this because you authored the thread. > > Reply to this email directly, view it on GitHub < > #3583 (comment)>, or > unsubscribe < > https://github.com/notifications/unsubscribe-auth/AL6BD36TALIIVS5QX6YDL7LRL6CHVANCNFSM4MEZULKQ > >. > > > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#3583 (comment)>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACS5WU6CAUDANUK7SMJHNPLRMALSTANCNFSM4MEZULKQ> > . > — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3583 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL6BD36KB7QTVMY5JCOMV5LRMAMGDANCNFSM4MEZULKQ>.

[Seven-709]

HI all, just as an update and for your information. In the last days I found the time, thanks to Home-Office due to Corona, and made some semi-scientific experiment and measures the actual CPU usage for a given configured CPU Limit. https://drive.google.com/open?id=1O92UUPjrG4uK_MFT69_X3P1t9gdzuZuI <https://drive.google.com/open?id=1O92UUPjrG4uK_MFT69_X3P1t9gdzuZuI> Please refer to the PDF document linked in the URL above. I found the graph most astounding, frankly speaking. The x-axis refers to the configured CPU limit, while the y-axis refers to the actual measured CPU usage … So, a CPU Limit of 1% in BOINC ended up in a real CPU usage of 65% and so on. Basically the cpu usage was measured with top, limiting to processes from the „boinc“ user, so this is „the real“ Boinc usage. I wrote a small script to compute the average usage over the runtime of the script to get somewhat reliable and re-producable figures. Maybe this will give you a hint what is going wrong at least up to 50%. regards Seven Hi all, I’m not sure if I made it right :-) Please try to download the file from google drive https://drive.google.com/file/d/1sb8qaUlv1AkJJ98WTThlAtilH5nKtlmZ/view?usp=sharing <https://drive.google.com/file/d/1sb8qaUlv1AkJJ98WTThlAtilH5nKtlmZ/view?usp=sharing> regards Seven

…

Am 11.04.2020 um 09:31 schrieb Jord van der Elst ***@***.*** ***@***.***>>: The list you post to drops attachments. Better post the images to an external site and put the links to them here. Or use Dropbox. On Sat, 11 Apr 2020, 09:26 Seven-709 ***@***.*** ***@***.***>> wrote: > > > Hi, > > yes, most unfortunately this sometimes happens when sending attachments > with „Mail“ from macOS .. I’ve compressed both screenshots. Can you extract > them from the ZIP archive? > > regards > Seven > > > > Am 10.04.2020 um 23:00 schrieb SETIguy ***@***.*** ***@***.***>>: > > > > > > Looks like the list trims attachments. Maybe a pasteboard or google > photos > > link? > > — > > You are receiving this because you authored the thread. > > Reply to this email directly, view it on GitHub < > #3583 (comment) <#3583 (comment)>>, or > unsubscribe < > https://github.com/notifications/unsubscribe-auth/AL6BD36TALIIVS5QX6YDL7LRL6CHVANCNFSM4MEZULKQ <https://github.com/notifications/unsubscribe-auth/AL6BD36TALIIVS5QX6YDL7LRL6CHVANCNFSM4MEZULKQ> > >. > > > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#3583 (comment) <#3583 (comment)>>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACS5WU6CAUDANUK7SMJHNPLRMALSTANCNFSM4MEZULKQ <https://github.com/notifications/unsubscribe-auth/ACS5WU6CAUDANUK7SMJHNPLRMALSTANCNFSM4MEZULKQ>> > . > — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3583 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL6BD36KB7QTVMY5JCOMV5LRMAMGDANCNFSM4MEZULKQ>.

[davidpanderson]

I'm seeing BOINC behave as expected; e.g. with 10% CPU usage it computes for 1 second, sleeps for 9, repeat.

…

[Seven-709]

Hi David, interesting … I’ve measured a CPU overall average usage ( 8 BOINC Tasks, 8-Core Intel CPU, 100% CPU, 10% CPU Usage Limit, Rosetta project only) of 15% percent for the BOINC processes. What do you get when you configure 1% CPU usage limit? I would expect 1 second compute and 99 seconds sleep? Since I have measured an actual CPU usage of 65% that would be most interesting. By the way, I also tested some values on a virtual machine running on Debian Buster with 8 assigned cores but with an AMD Ryzen processor and the BOINC command line program. Basically the actual average CPU usage matches the figures from my Mac. Would the CPU usage be related in some form of the project BOINC is running? So, you configure 10% in BOINC and with Seti@Home it will result in 50% and in Rosetta@Home it would result in 5%,? But I don’t want to make to much a fuss on the matter. After I run all the tests I have now a matching table at my disposal. So I can predictable adjust the CPU usage of BOIN as I need it. Maybe it’s just an issue of my „environment“. regards Seven

…

Am 29.04.2020 um 08:43 schrieb David Anderson ***@***.***>: I'm seeing BOINC behave as expected; e.g. with 10% CPU usage it computes for 1 second, sleeps for 9, repeat. > — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3583 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL6BD3ZR27DLVW3VWBS4JUTRO7EC5ANCNFSM4MEZULKQ>.

[sirzooro]

On Linux you can use cgroups to limit cpu usage for process. They are implemented in kernel, so it should work better than code used by BOINC now.
https://en.wikipedia.org/wiki/Cgroups

According to linked Wikipedia page Windows also has similar feature called Job Objects. Not sure if other systems have something similar. For them you could keep existing throttling code.