That would be great - I'll keep an eye on things when I get back from lunch.

Some hours are longer than others. Might not be till this evening I get back to it after the current LHC task finishes.

Thu 01 Jun 2023 07:12:51 BST | Einstein@Home | work fetch resumed by user
Thu 01 Jun 2023 07:13:14 BST |  | [cpu_sched_debug] preliminary job list:
Thu 01 Jun 2023 07:13:14 BST | Einstein@Home | [cpu_sched_debug] 0: guppi_57886_GBT820-01822_0031_0001_dms_3752_3152_0 (MD: no; UTS: no)
Thu 01 Jun 2023 07:13:14 BST |  | [cpu_sched_debug] final job list:
Thu 01 Jun 2023 07:13:14 BST | Einstein@Home | [cpu_sched_debug] 0: guppi_57886_GBT820-01822_0031_0001_dms_3752_3152_0 (MD: no; UTS: no)
Thu 01 Jun 2023 07:13:14 BST | Einstein@Home | [cpu_sched_debug] scheduling guppi_57886_GBT820-01822_0031_0001_dms_3752_3152_0
Thu 01 Jun 2023 07:13:14 BST |  | [cpu_sched_debug] using 1.00 out of 6 CPUs
Thu 01 Jun 2023 07:13:14 BST | Einstein@Home | Starting task guppi_57886_GBT820-01822_0031_0001_dms_3752_3152_0
Thu 01 Jun 2023 07:13:14 BST |  | [cpu_sched_debug] enforce_run_list: end
Thu 01 Jun 2023 07:13:55 BST | Einstein@Home | Sending scheduler request: To fetch work.
Thu 01 Jun 2023 07:13:55 BST | Einstein@Home | Requesting new tasks for CPU and NVIDIA GPU
Thu 01 Jun 2023 07:13:56 BST | Einstein@Home | Scheduler request completed: got 1 new tasks
Thu 01 Jun 2023 07:13:56 BST | Einstein@Home | BOINC will delete file stochastic_fullG.bank (no longer needed)
Thu 01 Jun 2023 07:13:56 BST | Einstein@Home | Project requested delay of 60 seconds
Thu 01 Jun 2023 07:13:56 BST | World Community Grid | General prefs: from World Community Grid (last modified 20-Sep-2022 18:49:24)
Thu 01 Jun 2023 07:13:56 BST | World Community Grid | Computer location: home
Thu 01 Jun 2023 07:13:56 BST |  | General prefs: using separate prefs for home
Thu 01 Jun 2023 07:13:56 BST |  | Reading preferences override file
Thu 01 Jun 2023 07:13:56 BST |  | Preferences:
Thu 01 Jun 2023 07:13:56 BST |  | -  When computer is in use
Thu 01 Jun 2023 07:13:56 BST |  | -     'In use' means mouse/keyboard input in last 3.0 minutes
Thu 01 Jun 2023 07:13:56 BST |  | -     max CPUs used: 2
Thu 01 Jun 2023 07:13:56 BST |  | -     Use at most 100% of the CPU time
Thu 01 Jun 2023 07:13:56 BST |  | -     max memory usage: 24.92 GB
Thu 01 Jun 2023 07:13:56 BST |  | -  When computer is not in use
Thu 01 Jun 2023 07:13:56 BST |  | -     max CPUs used: 6
Thu 01 Jun 2023 07:13:56 BST |  | -     Use at most 100% of the CPU time
Thu 01 Jun 2023 07:13:56 BST |  | -     max memory usage: 28.04 GB
Thu 01 Jun 2023 07:13:56 BST |  | -  Leave apps in memory if not running
Thu 01 Jun 2023 07:13:56 BST |  | -  Store at least 0.10 days of work
Thu 01 Jun 2023 07:13:56 BST |  | -  Store up to an additional 0.00 days of work
Thu 01 Jun 2023 07:13:56 BST |  | -  max disk usage: 542.01 GB
Thu 01 Jun 2023 07:13:56 BST |  | -  (to change preferences, visit a project web site or select Preferences in the Manager)
Thu 01 Jun 2023 07:13:56 BST |  | [cpu_sched_debug] Request CPU reschedule: Prefs update
Thu 01 Jun 2023 07:13:56 BST |  | [cpu_sched_debug] schedule_cpus(): start
Thu 01 Jun 2023 07:13:56 BST | Einstein@Home | [cpu_sched_debug] add to run list: guppi_57886_GBT820-01822_0031_0001_dms_3752_3152_0 (CPU, FIFO) (prio -1.000000)
Thu 01 Jun 2023 07:13:56 BST |  | [cpu_sched_debug] enforce_run_list(): start
Thu 01 Jun 2023 07:13:56 BST |  | [cpu_sched_debug] preliminary job list:
Thu 01 Jun 2023 07:13:56 BST | Einstein@Home | [cpu_sched_debug] 0: guppi_57886_GBT820-01822_0031_0001_dms_3752_3152_0 (MD: no; UTS: no)
Thu 01 Jun 2023 07:13:56 BST |  | [cpu_sched_debug] final job list:
Thu 01 Jun 2023 07:13:56 BST | Einstein@Home | [cpu_sched_debug] 0: guppi_57886_GBT820-01822_0031_0001_dms_3752_3152_0 (MD: no; UTS: yes)
Thu 01 Jun 2023 07:13:56 BST | Einstein@Home | [cpu_sched_debug] scheduling guppi_57886_GBT820-01822_0031_0001_dms_3752_3152_0
Thu 01 Jun 2023 07:13:56 BST |  | [cpu_sched_debug] using 1.00 out of 6 CPUs
Thu 01 Jun 2023 07:13:56 BST |  | [cpu_sched_debug] enforce_run_list: end
Thu 01 Jun 2023 07:14:02 BST | Einstein@Home | work fetch suspended by user
Thu 01 Jun 2023 07:14:16 BST |  | [cpu_sched_debug] Request CPU reschedule: files downloaded
Thu 01 Jun 2023 07:14:16 BST |  | [cpu_sched_debug] schedule_cpus(): start
Thu 01 Jun 2023 07:14:16 BST | Einstein@Home | [cpu_sched_debug] add to run list: guppi_57886_GBT820-01822_0031_0001_dms_3752_3152_0 (CPU, FIFO) (prio -1.000000)
Thu 01 Jun 2023 07:14:16 BST | Einstein@Home | [cpu_sched_debug] add to run list: guppi_57886_GBT820-01822_0031_0001_dms_3752_3184_0 (CPU, FIFO) (prio -1.001754)
Thu 01 Jun 2023 07:14:16 BST |  | [cpu_sched_debug] enforce_run_list(): start
Thu 01 Jun 2023 07:14:16 BST |  | [cpu_sched_debug] preliminary job list:
Thu 01 Jun 2023 07:14:16 BST | Einstein@Home | [cpu_sched_debug] 0: guppi_57886_GBT820-01822_0031_0001_dms_3752_3152_0 (MD: no; UTS: yes)
Thu 01 Jun 2023 07:14:16 BST | Einstein@Home | [cpu_sched_debug] 1: guppi_57886_GBT820-01822_0031_0001_dms_3752_3184_0 (MD: no; UTS: no)
Thu 01 Jun 2023 07:14:16 BST |  | [cpu_sched_debug] final job list:
Thu 01 Jun 2023 07:14:16 BST | Einstein@Home | [cpu_sched_debug] 0: guppi_57886_GBT820-01822_0031_0001_dms_3752_3152_0 (MD: no; UTS: yes)
Thu 01 Jun 2023 07:14:16 BST | Einstein@Home | [cpu_sched_debug] 1: guppi_57886_GBT820-01822_0031_0001_dms_3752_3184_0 (MD: no; UTS: no)
Thu 01 Jun 2023 07:14:16 BST | Einstein@Home | [cpu_sched_debug] scheduling guppi_57886_GBT820-01822_0031_0001_dms_3752_3152_0
Thu 01 Jun 2023 07:14:16 BST | Einstein@Home | [cpu_sched_debug] scheduling guppi_57886_GBT820-01822_0031_0001_dms_3752_3184_0
Thu 01 Jun 2023 07:14:16 BST |  | [cpu_sched_debug] using 2.00 out of 6 CPUs
Thu 01 Jun 2023 07:14:16 BST | Einstein@Home | Starting task guppi_57886_GBT820-01822_0031_0001_dms_3752_3184_0
Thu 01 Jun 2023 07:14:16 BST |  | [cpu_sched_debug] enforce_run_list: end
Thu 01 Jun 2023 07:14:23 BST | World Community Grid | General prefs: from World Community Grid (last modified 20-Sep-2022 18:49:24)
Thu 01 Jun 2023 07:14:23 BST | World Community Grid | Computer location: home
Thu 01 Jun 2023 07:14:23 BST |  | General prefs: using separate prefs for home
Thu 01 Jun 2023 07:14:23 BST |  | Reading preferences override file
Thu 01 Jun 2023 07:14:23 BST |  | Preferences:
Thu 01 Jun 2023 07:14:23 BST |  | -  When computer is in use
Thu 01 Jun 2023 07:14:23 BST |  | -     'In use' means mouse/keyboard input in last 3.0 minutes
Thu 01 Jun 2023 07:14:23 BST |  | -     max CPUs used: 8
Thu 01 Jun 2023 07:14:23 BST |  | -     Use at most 100% of the CPU time
Thu 01 Jun 2023 07:14:23 BST |  | -     max memory usage: 24.92 GB
Thu 01 Jun 2023 07:14:23 BST |  | -  When computer is not in use
Thu 01 Jun 2023 07:14:23 BST |  | -     max CPUs used: 6
Thu 01 Jun 2023 07:14:23 BST |  | -     Use at most 100% of the CPU time
Thu 01 Jun 2023 07:14:23 BST |  | -     max memory usage: 28.04 GB
Thu 01 Jun 2023 07:14:23 BST |  | -  Leave apps in memory if not running
Thu 01 Jun 2023 07:14:23 BST |  | -  Store at least 0.10 days of work
Thu 01 Jun 2023 07:14:23 BST |  | -  Store up to an additional 0.00 days of work
Thu 01 Jun 2023 07:14:23 BST |  | -  max disk usage: 542.02 GB
Thu 01 Jun 2023 07:14:23 BST |  | -  (to change preferences, visit a project web site or select Preferences in the Manager)
Thu 01 Jun 2023 07:14:23 BST |  | [cpu_sched_debug] Request CPU reschedule: Prefs update
Thu 01 Jun 2023 07:14:23 BST |  | [cpu_sched_debug] Request CPU reschedule: Preferences override
Thu 01 Jun 2023 07:14:23 BST |  | [cpu_sched_debug] schedule_cpus(): start
Thu 01 Jun 2023 07:14:23 BST | Einstein@Home | [cpu_sched_debug] add to run list: guppi_57886_GBT820-01822_0031_0001_dms_3752_3152_0 (CPU, FIFO) (prio -1.000000)
Thu 01 Jun 2023 07:14:23 BST | Einstein@Home | [cpu_sched_debug] add to run list: guppi_57886_GBT820-01822_0031_0001_dms_3752_3184_0 (CPU, FIFO) (prio -1.001754)
Thu 01 Jun 2023 07:14:23 BST |  | [cpu_sched_debug] enforce_run_list(): start
Thu 01 Jun 2023 07:14:23 BST |  | [cpu_sched_debug] preliminary job list:
Thu 01 Jun 2023 07:14:23 BST | Einstein@Home | [cpu_sched_debug] 0: guppi_57886_GBT820-01822_0031_0001_dms_3752_3152_0 (MD: no; UTS: yes)
Thu 01 Jun 2023 07:14:23 BST | Einstein@Home | [cpu_sched_debug] 1: guppi_57886_GBT820-01822_0031_0001_dms_3752_3184_0 (MD: no; UTS: no)
Thu 01 Jun 2023 07:14:23 BST |  | [cpu_sched_debug] final job list:
Thu 01 Jun 2023 07:14:23 BST | Einstein@Home | [cpu_sched_debug] 0: guppi_57886_GBT820-01822_0031_0001_dms_3752_3152_0 (MD: no; UTS: yes)
Thu 01 Jun 2023 07:14:23 BST | Einstein@Home | [cpu_sched_debug] 1: guppi_57886_GBT820-01822_0031_0001_dms_3752_3184_0 (MD: no; UTS: yes)
Thu 01 Jun 2023 07:14:23 BST | Einstein@Home | [cpu_sched_debug] scheduling guppi_57886_GBT820-01822_0031_0001_dms_3752_3152_0
Thu 01 Jun 2023 07:14:23 BST | Einstein@Home | [cpu_sched_debug] scheduling guppi_57886_GBT820-01822_0031_0001_dms_3752_3184_0
Thu 01 Jun 2023 07:14:23 BST |  | [cpu_sched_debug] using 2.00 out of 6 CPUs
Thu 01 Jun 2023 07:14:23 BST |  | [cpu_sched_debug] enforce_run_list: end
Thu 01 Jun 2023 07:14:33 BST | LHC@home | work fetch resumed by user
Thu 01 Jun 2023 07:14:37 BST | LHC@home | Sending scheduler request: Requested by project.
Thu 01 Jun 2023 07:14:37 BST | LHC@home | Requesting new tasks for CPU
Thu 01 Jun 2023 07:14:39 BST | LHC@home | Scheduler request completed: got 1 new tasks
Thu 01 Jun 2023 07:14:39 BST | LHC@home | Project requested delay of 6 seconds
Thu 01 Jun 2023 07:15:23 BST |  | [cpu_sched_debug] Request CPU reschedule: periodic CPU scheduling
Thu 01 Jun 2023 07:15:23 BST |  | [cpu_sched_debug] schedule_cpus(): start
Thu 01 Jun 2023 07:15:23 BST | Einstein@Home | [cpu_sched_debug] add to run list: guppi_57886_GBT820-01822_0031_0001_dms_3752_3152_0 (CPU, FIFO) (prio -1.000000)
Thu 01 Jun 2023 07:15:23 BST | Einstein@Home | [cpu_sched_debug] add to run list: guppi_57886_GBT820-01822_0031_0001_dms_3752_3184_0 (CPU, FIFO) (prio -1.001754)
Thu 01 Jun 2023 07:15:23 BST |  | [cpu_sched_debug] enforce_run_list(): start
Thu 01 Jun 2023 07:15:23 BST |  | [cpu_sched_debug] preliminary job list:

The LHC task started using 8 threads as expected. Core count increased to 16 ad basically, nothing has changed. The LHC task continues and the Einstein ones remain with the status, "Waiting to run."

Thu 01 Jun 2023 07:14:23 BST | | - When computer is in use
Thu 01 Jun 2023 07:14:23 BST | | - 'In use' means mouse/keyboard input in last 3.0 minutes
Thu 01 Jun 2023 07:14:23 BST | | - max CPUs used: 8
Thu 01 Jun 2023 07:14:23 BST | | - Use at most 100% of the CPU time
Thu 01 Jun 2023 07:14:23 BST | | - max memory usage: 24.92 GB
Thu 01 Jun 2023 07:14:23 BST | | - When computer is not in use
Thu 01 Jun 2023 07:14:23 BST | | - max CPUs used: 6

I see you've changed the 'in use' settings, but not the "new this time" not in use settings. Could that be the problem - your machine is one of the ones that has difficulty detecting mouse and keyboard activity? If the subsequent changes from 8 towards 16 were also applied the same way, it would behave as you describe.

That raises significant questions for the v7.22 release: if people are going to use the new preferences (and they will), we have to ensure that the detection problems are also fixed.

Correction: it's the 'in use' figures which are new this time, but the basic distinction remains. You have to change the settings that match what your computer thinks is happening, not what you think is happening! I've been changing both, because I'm not sure whether my machines handle the detection: I suppose I'd better find out sometime.

I see you've changed the 'in use' settings, but not the "new this time" not in use settings.

My in use settings are all the same as my not in use settings. On the rare occasions I do something intensive where BOINC might cause issues, I suspend computation.

oops. That will teach me to pay attention. Going to rerun test. - Meant to change the not in use settings.

Mystery solved. Changing settings without swapping to my computer glasses is not a good idea!

But in the extract I quoted, the numbers are different - 8 for 'in use', 6 for 'not in use'. That's prompted me to look at this new feature in more detail, and I think I'm seeing some more serious problems. I need to get my head awake, clear and focussed: then I'll do a comprehensive round-up here, for checking and comment, with a view to starting a new issue on github. But I get we have to get a move on, and keep DA on topic - otherwise he'll wander off for another two months (or three, or four), leaving the release in limbo.

But in the extract I quoted, the numbers are different - 8 for 'in use', 6 for 'not in use'. That's prompted me to look at this new feature in more detail, and I think I'm seeing some more serious problems. I need to get my head awake, clear and focussed: then I'll do a comprehensive round-up here, for checking and comment, with a view to starting a new issue on github. But I get we have to get a move on, and keep DA on topic - otherwise he'll wander off for another two months (or three, or four), leaving the release in limbo.

I can do some more playing. Pretty certain the over commit problem is still there with mt tasks. The way I would like it is if I had two tasks running and8 cores enabled, BOINC would download a task to run using 6 threads but obviously not everyone would do things that way.

I think I'm going to (temporarily) park the specific MT aspects of this discussion - the other ones I saw this morning worry me more. The MT issues - and there are many - should be sorted out with a comprehensive re-think: when to fetch, when to run, how many to run concurrently, what else to run alongside, how many threads to use initially, how to set that figure, whether and how to make that variable during the run. That'll do for an agenda ....

But those decisions should be made by a collective design process, ideally including the projects using or thinking of using the MT model. It shouldn't be done by David alone tinkering with careless patches to his own careless code.

how many threads to use initially, how to set that figure, whether and how to make that variable during the run.

Changing the number of threads during a run sounds to me like a recipe for tasks crashing if the apps are not written with that in mind.

Alternatively, if it works under WINE I can ask ChatGPT5 to sort it out.

LOL.

Having gone through some slow, methodical testing, I think I'm less worried about the new 'in use' / 'not in use' preferences then I was this morning. But I find the new interface non-intuitive and confusing, especially with the font used by my version of Linux.

Here are the new ones.
Windows 7:

Linux Mint:

For comparison, this is the old version under Windows:

The Linux version has swallowed several words, doesn't allow enough space for all possible numbers, and has horribly uneven vertical alignment. It's a mess.

And the old version separated out 'Usage limits' in the top box (they are always applied immediately), from 'When to suspend' in the second box (which require '... based on preferences' in the Activity menu). The new one jumbles them all together.

But it does seem to work. This morning, I thought I saw a problem when using a 'new' Manager to modify the settings on a'old' client remotely, but I was mistaken.

But I find the new interface non-intuitive and confusing, especially with the font used by my version of Linux.

I agree 100% that the layout is confusing and not at all intuitive.I can see myself making quite a few mistakes at least till I get more used to it given that I fiddle with things a lot depending on what combination I am running.

BTW, I should have mentioned yesterday that during testing I verified that both my Linux machines can't detect mouse or keyboard activity - so they never enter the 'computer is in use' state. So everything has to be controlled using the 'not in use' settings.

BTW, I should have mentioned yesterday that during testing I verified that both my Linux machines can't detect mouse or keyboard activity - so they never enter the 'computer is in use' state. So everything has to be controlled using the 'not in use' settings.

I will check whether that that happens for me too. Doesn't affect me as I never tick the boxes to make it different.

Edit:That didn't take long. Suspend when computer is in use checked. mouse moving around and I can see progress percentage of screen continues to increase. Case proven m'lud.

over commit is still clearly an issue.
I have BOINC set to alow 5 cores, 0.1 of a day's work plus 0 additional and it downloads 2 LHC tasks which BOINC is estimating at 15 hours each. (They will take quite a bit less than that but 0.1 of a day even at the real time should only have allowed one to download.

For Dave and Richard

Thank you for all that the two of you do. I am a reasonably non-technical cruncher that has never moved past Windows and Android but I really appreciate your time, effort and attention to detail.

As I don't have the skill set to contribute the way you gentlemen do I try to focus on longevity.

Thank you again

Crunching since 1999
Bill F

The current ATLAS batch from LHC@home has significantly longer runtimes than the previous batch but the rsc_fpops_est value didn't change. The calculated flops value connected to your computer also represent the "speed" for the old batch. It needs a couple of valid tasks returned to the server to adjust that.

As a result your computer requests too much work at the beginning of the batch and server sends too much work.
At the end it also affects credit calculation (usually low credits).
Once this is balanced you will see the behaviour you are familiar with.
If another new batch will hand out shorter tasks you will see the opposite picture - less work and usually high credit values - until this is balanced again.


If you didn't ran ATLAS before the initial flops value is usually also not in balance.

Thanks for that. I did notice the change in length of the tasks. I will have to check with Amicable numbers to see if their MT tasks cause over-commit. or not.

Hmm. My experience seems to be different. The estimated time to completion for my tasks seems to be going up despite them taking substantially less time than the estimate. Though I don't know my way around the LHC task naming system to tell if they are all from the same batch or not?

Tasks typically taking between 5 and 5.5 hours. It seems the estimate shown for MT tasks is the total CPU time rather than the actual time they are expected to take.so on my current settings about 5 times as long as things should be taking. Still getting even if the estimate were only the actual time, 2 tasks is vastly over-committing and even more so if the estimate is total CPU time.

Happy to hear a different analysis from others as always.

Depends where you're reading "estimated". There was a server bug (#4151) which did exactly that, which is now fixed - we fixed it for the forthcoming CPDN MT tasks - but most servers won't yet have the fix.

Bit the client - I think - has always recorded elapsed time accurately, and once the initial ropey estimates have worked their way out of the system, they should be accurate, too. Even the "[sched_op] estimated total CPU task duration: 12221 seconds" in the Event Log should be OK.