Message boards : BOINC client : Multi core tasks alongside single core tasks.
Message board moderation
Previous · 1 · 2 · 3 · 4 · 5 · Next
Author | Message |
---|---|
Send message Joined: 28 Jun 10 Posts: 2710 |
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. |
Send message Joined: 28 Jun 10 Posts: 2710 |
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." |
Send message Joined: 5 Oct 06 Posts: 5130 |
Thu 01 Jun 2023 07:14:23 BST | | - When computer is in useI 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. |
Send message Joined: 28 Jun 10 Posts: 2710 |
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! |
Send message Joined: 5 Oct 06 Posts: 5130 |
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. |
Send message Joined: 28 Jun 10 Posts: 2710 |
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. |
Send message Joined: 5 Oct 06 Posts: 5130 |
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. |
Send message Joined: 28 Jun 10 Posts: 2710 |
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. |
Send message Joined: 28 Jun 10 Posts: 2710 |
Alternatively, if it works under WINE I can ask ChatGPT5 to sort it out. |
Send message Joined: 5 Oct 06 Posts: 5130 |
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. |
Send message Joined: 28 Jun 10 Posts: 2710 |
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. |
Send message Joined: 5 Oct 06 Posts: 5130 |
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. |
Send message Joined: 28 Jun 10 Posts: 2710 |
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. |
Send message Joined: 28 Jun 10 Posts: 2710 |
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. |
Send message Joined: 26 Mar 11 Posts: 193 |
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 |
Send message Joined: 2 Feb 22 Posts: 84 |
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. |
Send message Joined: 28 Jun 10 Posts: 2710 |
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. |
Send message Joined: 28 Jun 10 Posts: 2710 |
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? |
Send message Joined: 28 Jun 10 Posts: 2710 |
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. |
Send message Joined: 5 Oct 06 Posts: 5130 |
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. |
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.