Message boards : The Lounge : Grumbles, Glory and All Your Off Topic Discussions
Message board moderation
Previous · 1 . . . 125 · 126 · 127 · 128
Author | Message |
---|---|
Send message Joined: 7 Dec 24 Posts: 74 |
In reply to Dave's message of 26 May 2025: My impression though is that not only is the true progress not reported but also BOINC doesn't learn about the speed the tasks progress and learn from it.That would depend on the project, and how it has things set up. Projects using Credit New (or some sort of version of it), each application on each system keeps track of how long it takes to process a Task, and that is reported back to the Scheduler. Each time work is requested for a particular application on a particular system, the Estimated Remaining time for the new Tasks is updated based on the previously reported processing times (this was brought about by the fight between processing work on CPUs and GPUs. The CPU would finish a Task, the Estimated time would shoot up. The GPU would then return a bunch of work and the Estimated times plummet. Another COU Task returned... and BOINC tended to have a bit of melt-down trying to work out the Scheduling when the Estimated and actual Processing times kept moving around all over the place; hence basing the initial Estimated Remaining time initially on the device benchmarks/GFLOPS reported by BOINC, and then updating it on past actual processing times for each application). Even if the amount of Credit per Task is fixed, as long as they're using the underlying mechanism, the initial Estimated Remaining times will vary as the processing times for completed and Validated work vary. In the case of Rosetta, where Tasks are set to run for a fixed length of time, the initial Estimated Remaining time fixed at 8 hours, after issues when new applications were released with FLOPS estimates that resulted in systems downloading hundreds (even thousands) of Tasks until 10 Tasks had been returned & Validated & then the actual processing times were used to set the initial Remaining time (this is regardless of the setting for the Target Runtime which can be from 2 to 36 hours. The best option would have been to set Estimated Remaining time to match the persons selected Target CPU time, but they didn't take that route...). As for what other projects may implement in relation to initial processing time estimates, and how they are updated, the sky's the limit. Grant Darwin NT. |
![]() Send message Joined: 28 Jun 10 Posts: 2885 ![]() |
I noticed in top cpu usage for a VM with one ARP task from WCG running in BOINC is about 180% in a VM running Windows but only about 105% in one running Linux and it would sometimes spike to over 400% so 3 cores on top of what BOINC was using. Going to task manager and closing the app store reduced the CPU usage to about 110% but there would still be times when the fans speeded up and then checking in top the VM usage had again spiked at over 400%. And this is running Tiny10 a cut down version of Windows in the VM. I shudder to think what would be happening if I had a full install of Windows. |
Send message Joined: 30 Dec 05 Posts: 482 ![]() |
Bet you never knew he has a colour Jordy Blue |
![]() ![]() Send message Joined: 29 Aug 05 Posts: 15644 ![]() |
Yippee, new elections. 😤 |
![]() Send message Joined: 30 Mar 20 Posts: 478 ![]() |
In reply to Jord's message of 3 Jun 2025: Yippee, new elections. 😤Vote early Jord, vote often 😤 |
Copyright © 2025 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.