| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Active Research
Forum: Mapping Cancer Markers Forum
Thread: x86 task |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 28
|
|
| Author |
|
|
alanb1951
Veteran Cruncher Joined: Jan 20, 2006 Post Count: 966 Status: Offline Project Badges: 
|
I wonder whether WCG sets the scheduler's prefer_primary_platform flag? If that is set, it shouldn't do that "which is faster" dance [unless there are multiple applications for the primary platform!] :-) -- the rarity with which I see 32-bit tasks suggests that the flag is set! Shouldn't in this case 64-bit hosts get only 64-bit tasks without any 32-bit experiments by the server?Do you happen to know how often will it try testing application performance like that? I'm naturally inquisitive about things like that :-) Cheers - Al. P.S. I have looked at parts of the server code in the past, but the scheduler wasn't one of them... |
||
|
|
hchc
Veteran Cruncher USA Joined: Aug 15, 2006 Post Count: 802 Status: Offline Project Badges:
|
When running 7 tasks at a time, my i7-5800X3D typically runs 64 bit tasks in < 0.9 hrs, and the occasional i686 task in about 1.15 hours. Today I saw a task in boinc's task list over 2 hours. Looking at the properties, it was an i86 task. I can't say for sure I've never run one of these before, but I've looked at a lot of tasks in my results list over the years and never saw one like that. For those of you who have run MCM for a long time, this may not be new to you, but I thought it an oddity to see this after running MCM for more than a few years. This used to drive me nuts, since the tasks would take much longer to complete. Here's some threads I remember posting in:
Few different root causes here. Sometimes the science application binary was actually 32-bit. But in some cases the wingman was an older 32-bit client (like an ancient Windows XP x86 machine). But then you'd also get some of the hoard of Windows 8.1 Enterprise machines on BOINC 7.2 (?) or whatever that would immediately error out, then the 2 repair work units would run as 32-bit even if both repair wingmen were 64-bit machines. Like BOINC just defaulted to 32-bit for repair work. I haven't seen MCM1 32-bit work in a while, but I've mostly switched all my machines to Linux. I mostly ran into this on Windows.
[Edit 1 times, last edit by hchc at Feb 6, 2025 7:11:45 AM] |
||
|
|
Link64
Advanced Cruncher Joined: Feb 19, 2021 Post Count: 129 Status: Offline Project Badges: 
|
I wonder whether WCG sets the scheduler's prefer_primary_platform flag? If that is set, it shouldn't do that "which is faster" dance [unless there are multiple applications for the primary platform!] :-) -- the rarity with which I see 32-bit tasks suggests that the flag is set! Shouldn't in this case 64-bit hosts get only 64-bit tasks without any 32-bit experiments by the server?Do you happen to know how often will it try testing application performance like that? I'm naturally inquisitive about things like that :-) No idea actually, best guess is something around 1 out of 50-100, depending also on how close the performance is. I simply disabled alt_platform when I saw them here, problem solved since I don't run any 32-bit-only projects/applications right now. [Edit 2 times, last edit by Link64 at Feb 6, 2025 3:35:17 PM] |
||
|
|
alanb1951
Veteran Cruncher Joined: Jan 20, 2006 Post Count: 966 Status: Offline Project Badges:
|
Link64 - thanks for the response - Al.
|
||
|
|
AgrFan
Senior Cruncher USA Joined: Apr 17, 2008 Post Count: 376 Status: Offline Project Badges: 
|
My last 32-bit unit validated yesterday. Wingman completed it in 7+ hours on Windows XP.
----------------------------------------Do we really need a 32-bit version of MCM or any other project for that matter? We've had 64-bit CPUs since the early 2000s. It seems like this is just slowing projects down. MCM1_0230715_8280_0 Microsoft Windows XP Home x86 Edition, Service Pack 3, (05.01.2600.00) Valid 2025-02-01 15:48:25 UTC 2025-02-06 17:31:41 UTC 7.19 / 7.23 75.6 / 75.9 MCM1_0230715_8280_1 Microsoft Windows 10 Professional x64 Edition, (10.00.19045.00) Valid 2025-02-01 15:48:36 UTC 2025-02-02 07:18:36 UTC 1.97 / 1.97 76.2 / 75.9 I've added <no_alt_platform> to cc_config.xml on my machines to stop getting 32-bit work. [Edit 8 times, last edit by AgrFan at Feb 7, 2025 9:10:16 PM] |
||
|
|
Link64
Advanced Cruncher Joined: Feb 19, 2021 Post Count: 129 Status: Offline Project Badges:
|
Do we really need a 32-bit version of MCM or any other project for that matter? We've had 64-bit CPUs since the early 2000s. It seems like this is just slowing projects down. How exactly is having more total computing power slowing the project down? As long as those computers complete the tasks before the deadline, they increase the amount of total tasks processed per day. Many of those 32-bit Computers should still be faster than most of the ARM devices, in particular since some of them might be a 32-bit os on a 64-bit CPU. |
||
|
|
AgrFan
Senior Cruncher USA Joined: Apr 17, 2008 Post Count: 376 Status: Offline Project Badges:
|
How exactly is having more total computing power slowing the project down? I was referring to higher elapsed times slowing how fast the results are returned to the researchers. 7+ hours of CPU time is 4-5x longer than usual. This unit was returned after 5 days and barely made the deadline. This is obviously not a 24/7 cruncher. I hope the user is putting the extra power/heat to good use. Windows XP ended over 10 years ago. Time to move on ... [Edit 4 times, last edit by AgrFan at Feb 8, 2025 3:59:17 PM] |
||
|
|
Link64
Advanced Cruncher Joined: Feb 19, 2021 Post Count: 129 Status: Offline Project Badges:
|
I was referring to higher elapsed times slowing how fast the results are returned to the researchers. The researchers are not sitting in front of their computers and watching the results coming in, they wait for the whole batch or more likely hundreds or thousands of them before they do anything with the results. And the last results of a batch are not those, which are crunched successfully on a slow computer, but those, which time out.7+ hours of CPU time is 4-5x longer than usual. Doesn't matter at all. ARM devices might need even longer.This unit was returned after 5 days and barely made the deadline. This is obviously not a 24/7 cruncher. Well, it made before the deadline and that's all that matters, if there was need for a faster turnaround time, they would make the deadline shorter like they do for resend tasks. The turnaround time depends anyway mostly on the cache size and not CPU speed, for example I use 1 day cache, so my results are returned after about a day no matter how fast my CPU is. 5 day cache is perhaps a bit larger than necessry, but still well below the deadline and therefore completely OK.Sorry, but you are completely wrong, every device, which returns valid results before the deadline, speeds up the project, no matter how slow it is. |
||
|
|
|