Posts by Keith Myers
|
1)
Message boards :
Number crunching :
New 1.95 app fails task immediately
(Message 77879)
Posted 28 Jan 2026 by  Keith Myers
Post: https://milkyway.cs.rpi.edu/milkyway/result.php?resultid=1043331278 Wed 28 Jan 2026 10:44:02 AM PST | Milkyway@home | Started download of milkyway_nbody_orbit_fitting_1.95_x86_64-pc-linux-gnu Wed 28 Jan 2026 10:44:02 AM PST | Milkyway@home | Started download of EMD_v195_OCS_north_orbit_fitting_MW2014.lua Wed 28 Jan 2026 10:44:03 AM PST | Milkyway@home | Finished download of EMD_v195_OCS_north_orbit_fitting_MW2014.lua (25813 bytes) Wed 28 Jan 2026 10:44:04 AM PST | Milkyway@home | Finished download of milkyway_nbody_orbit_fitting_1.95_x86_64-pc-linux-gnu (7749144 bytes) Wed 28 Jan 2026 10:44:04 AM PST | Milkyway@home | Starting task de_nbody_orbit_fitting_01_28_2026_v195_OCS_north_MW2014__data__02_1769623791_3977_0 Wed 28 Jan 2026 10:44:06 AM PST | Milkyway@home | Computation for task de_nbody_orbit_fitting_01_28_2026_v195_OCS_north_MW2014__data__02_1769623791_3977_0 finished Wed 28 Jan 2026 10:46:00 AM PST | Milkyway@home | [sched_op] Starting scheduler request Wed 28 Jan 2026 10:46:00 AM PST | Milkyway@home | Sending scheduler request: To fetch work. Wed 28 Jan 2026 10:46:00 AM PST | Milkyway@home | Reporting 1 completed tasks Wed 28 Jan 2026 10:46:00 AM PST | Milkyway@home | Requesting new tasks for CPU Wed 28 Jan 2026 10:46:00 AM PST | Milkyway@home | [sched_op] CPU work request: 1.00 seconds; 1.00 devices Wed 28 Jan 2026 10:46:00 AM PST | Milkyway@home | [sched_op] NVIDIA GPU work request: 0.00 seconds; 0.00 devices Wed 28 Jan 2026 10:46:02 AM PST | Milkyway@home | Scheduler request completed: got 1 new tasks Wed 28 Jan 2026 10:46:02 AM PST | Milkyway@home | [sched_op] Server version 721 Wed 28 Jan 2026 10:46:02 AM PST | Milkyway@home | Project requested delay of 91 seconds Wed 28 Jan 2026 10:46:02 AM PST | Milkyway@home | [sched_op] estimated total CPU task duration: 10378 seconds Wed 28 Jan 2026 10:46:02 AM PST | Milkyway@home | [sched_op] estimated total NVIDIA GPU task duration: 0 seconds Wed 28 Jan 2026 10:46:02 AM PST | Milkyway@home | [sched_op] handle_scheduler_reply(): got ack for task de_nbody_orbit_fitting_01_28_2026_v195_OCS_north_MW2014__data__02_1769623791_3977_0 https://milkyway.cs.rpi.edu/milkyway/show_user.php?userid=7601514 gimmyk You need to look into this. You asked for input on the new app deployment. Here it is. [EDIT] Well maybe it takes at least one scheduler connection after receiving a new app to sort things out. The next task received for the 1.95 app seems to be running correctly. If it validates, I'll consider this post just an exercise in not having enough patience to wait for things to settle down. [EDIT2] Now that I look more closely at the task output, I can see the input files were minimal and didn't require any processing. That is why the task only took 1 second to run. |
|
2)
Message boards :
Number crunching :
GFLOPS backwards
(Message 77696)
Posted 31 Oct 2025 by Keith Myers
Post: Well, maybe it's different on Linux. For me, on Windows, it was running always on lowest priority IIRC. It didn't matter much with the old CAL-applications for my HD3850 here, but later with OpenCL or CUDA on my GTX275 there was a significant difference and since than I stick to high priority for "special" applications as it doesn't have any negative effects so far. Looking at the code again, the special_priority tag for cc_config.xml to raise the gpu task priority is only defined for Win32, not for Linux. Guess that is why it never worked for me since I've always been a Boinc Linux user. |
|
3)
Message boards :
Number crunching :
GFLOPS backwards
(Message 77695)
Posted 31 Oct 2025 by Keith Myers
Post: Well the client gets compiled differently for Linux clients compared to Windows clients. If you care to investigate, you can peruse the /client directory on the Boinc Github repo site and look through the differences in what is compiled and integrated into the client at the platform level. And apps run at slightly different priorities depending on whether the host is Windows or Linux because the priority definitions in Boinc use Windows vernacular in the header definitions and need to be transposed for LInux niceness. https://github.com/search?q=repo%3ABOINC%2Fboinc+PROCESS_MEDIUM_PRIORITY&type=code This was commented on in the past https://boinc.berkeley.edu/forum_thread.php?id=8607&postid=50452 https://boinc.berkeley.edu/forum_thread.php?id=10296&postid=62286 |
|
4)
Message boards :
Number crunching :
GFLOPS backwards
(Message 77693)
Posted 31 Oct 2025 by Keith Myers
Post: I've never seen any gpu task from any project run at anything other than nice 10. The only time I ever manually changed the process priority was back at Seti with the special apps and the schedtool utility. I used to run this script to bump gpu tasks to highest priority. #Run in root terminal, NOT sudo nvidia-smi -pm 1 for (( ; ; )) do # Assign CPU Priority (19=Nice/LowPriority, 0=Normal, -20=HighPriority) # This was code Petri gave out # GPU Tasks get high Priority schedtool -n -20 `pidof setiathome_x41p_V0.97b2_Linux-Pascal+_cuda92` schedtool -n -20 `pidof astropulse_7.08_x86_64-pc-linux-gnu__opencl_nvidia_100` # CPU Tasks get (a little) Below Normal Priority (0 being normal) to make sure it doesn't choke the OS schedtool -n 5 `pidof ap_7.05r2728_sse3_linux64` schedtool -n 5 `pidof MBv8_8.22r3711_sse41_x86_64-pc-linux-gnu` # Assign CPU Usage Threads (0-7) # Brent added this to Petri's code # Keep GPU tasks on threads 1 3 5 7 9 11 13 15 schedtool -a 1,3,5,7,9,11,13,15 `pidof setiathome_x41p_V0.97b2_Linux-Pascal+_cuda92` schedtool -a 1,3,5,7,9,11,13,15 `pidof astropulse_7.08_x86_64-pc-linux-gnu__opencl_nvidia_100` # Keep CPU tasks on threads 0 2 4 6 8 10 12 14 schedtool -a 0,2,4,6,8,10,12,14 `pidof MBv8_8.22r3711_sse41_x86_64-pc-linux-gnu` schedtool -a 0,2,4,6,8,10,12,14 `pidof ap_7.05r2728_sse3_linux64` # CPU Priority Assignment Script date # lscpu | grep MHz sleep 5 echo " CPU Priority and Assignment Script (8 Threads)" done I never could get the process priority tags in cc_config.xml to work. The schedtool utility always worked. |
|
5)
Message boards :
Number crunching :
GFLOPS backwards
(Message 77691)
Posted 30 Oct 2025 by Keith Myers
Post: I don't know what process level Windows runs things. But it is easy to see the various task and app process priority levels in Linux. The Boinc client runs at system level, nice 0 all the time on my Linux hosts. The various project cpu tasks run at process priority 19 which is the lowest priority. Gpu task run at process prioriity level 10 which is equivalent to "below_normal priority" in Windows lingo if I remember correctly. Those process levels are actually coded in the client somewhere. |
|
6)
Message boards :
Number crunching :
GFLOPS backwards
(Message 77682)
Posted 27 Oct 2025 by Keith Myers
Post: Thanks for the update on the timeline. Looking forward to a new app. |
|
7)
Message boards :
Number crunching :
GFLOPS backwards
(Message 77679)
Posted 25 Oct 2025 by Keith Myers
Post: A new app that fixes this long running problem will be most appreciated. |
|
8)
Message boards :
Number crunching :
Truly Invalid or Application Difference ???
(Message 77595)
Posted 17 Aug 2025 by Keith Myers
Post: This is a well-known issue and commented on a lot. The devs have not considered the issue to be critical and aren't willing to expend the resources for a fix. It only amounts to about 1-2% invalid rate among hosts. You will run into this when your returned result is matched with a different client platform than yours. It's just because of the difference in math calculation between gpus, cpus and OS'. The devs would have to set a lot more permissive result variance allowance which they decided would impact the science negatively. This is just the cost of doing business with this project. Either accept it and move on or look for a different project that doesn't have this kind of issue. |
|
9)
Questions and Answers :
Unix/Linux :
What is "Waiting for Shared Memory" and why is it hurting my production?
(Message 77593)
Posted 13 Aug 2025 by Keith Myers
Post: When all else fails . . . . . . . turn it off . . . then turn it back on! |
|
10)
Message boards :
Number crunching :
N-Body Simulation Deadline
(Message 77559)
Posted 13 Jul 2025 by Keith Myers
Post: The more concurrent projects you run on your hosts, the less cache you need. Set a 0.1 day cache and no extra to begin with. If you find your host is sitting idle, slowly increase the cache size by small increments of 0.1. You will likely find that a 0.5 day cache is totally sufficient and allow all your projects to get and process work and return work well within all the different project timelines and allow the Boinc client to efficiently round-robin service all your projects in timely fashion. |
|
11)
Message boards :
Number crunching :
N-Body Simulation Deadline
(Message 77554)
Posted 11 Jul 2025 by Keith Myers
Post: The project managers don't feel any pressing need for getting results any sooner. Plus, for most Boinc users that aren't exclusively running this one project all by itself, having a 14 day deadline is normal so the Boinc client can perform normal round-robin processing among multiple projects. It all works out very well in the end normally. |
|
12)
Questions and Answers :
Windows :
Memory LEAK and Faulty Code (Both Linux and Windows)
(Message 77551)
Posted 8 Jul 2025 by Keith Myers
Post: As mentioned earlier in this thread, it is more efficient and more productive to only run 1T tasks and just run more tasks on more cores. I've never had any memory issues on any of my hosts. |
|
13)
Message boards :
News :
Admin Updates Discussion
(Message 77527)
Posted 28 Jun 2025 by Keith Myers
Post: More of those: Getting errors for the 1.90 applications for missing parameters. <core_client_version>8.3.0</core_client_version> <![CDATA[ <message> process exited with code 13 (0xd, -243)</message> <stderr_txt> <search_application> milkyway_nbody 1.90 Linux x86_64 double OpenMP, Crlibm </search_application> Using OpenMP 1 max threads on a system with 32 processors Running MilkyWay@home Nbody v1.90 Optimal Softening Length = 0.010487539811713 kpc Error evaluating NBodyCtx: [string "-- /* Copyright (c) 2016 - 2018 Siddhartha ..."]:108: Unknown named argument 'PMCorrect' Unknown named argument 'PMSigma' Unknown named argument 'usePropMot' 3 bad named arguments found Failed to read input parameters file 2025-06-27 05:19:47 (346627): called boinc_finish(13) </stderr_txt> ]]> |
|
14)
Message boards :
Number crunching :
196 (0x000000C4) EXIT_DISK_LIMIT_EXCEEDED
(Message 77457)
Posted 28 May 2025 by Keith Myers
Post: I've set NNT and will work through what's on board and let some other projects have the newly available threads. Just wasting too much computer runtime for tasks that end up errored out. |
|
15)
Message boards :
News :
Admin Updates Discussion
(Message 77412)
Posted 6 May 2025 by Keith Myers
Post: Still seeing the errors. I have very low caches on each host but the older resends are still coming through with the misconfiguration. It will probably take a fairly long while to clear all the bad work with 8 possible resends for each task. |
|
16)
Message boards :
Number crunching :
Not getting MT tasks
(Message 77407)
Posted 3 May 2025 by Keith Myers
Post: Not getting MT tasks is not an issue, it's actually something good. MT seems very inefficient, so unless you want MT tasks for some special reason, I'd recommend to run Milkyway in single thread mode. This also makes it a lot easier to run Milkyway tasks together with other projects, which are usually ST too. +1 |
|
17)
Message boards :
Number crunching :
196 (0x000000C4) EXIT_DISK_LIMIT_EXCEEDED
(Message 77405)
Posted 3 May 2025 by Keith Myers
Post: Looks like we have resurrected a task error type from 2014. Shouldn't be getting these. Admins need to adjust the task generator template to increase the rsc_disk_bound value. |
|
18)
Message boards :
Number crunching :
New Benchmark Thread - times wanted for any hardware, CPU or GPU, old or new!
(Message 77394)
Posted 20 Apr 2025 by Keith Myers
Post: I believe only the originator of the thread can unpin it. That looks to be user https://milkyway.cs.rpi.edu/milkyway/show_user.php?userid=146600 |
|
19)
Message boards :
Number crunching :
New Benchmark Thread - times wanted for any hardware, CPU or GPU, old or new!
(Message 77390)
Posted 18 Apr 2025 by Keith Myers
Post: You can't. There are no gpu applications here. |
|
20)
Message boards :
Number crunching :
New to MW--- is this normal? If so what should I do?
(Message 77385)
Posted 13 Apr 2025 by Keith Myers
Post: Boinc converges CPIDs to the oldest attached project on a host. A real pain in the butt at times. Just use the same email for all projects and hit update for all projects in the Manager and it should converge eventually. Don't remove the WCG project since it is your originally attached project. |
Next 20
©2026 Astroinformatics Group