Posts by Keith Myers
|
1)
(Message 8348)
Posted 4 days ago by 
Keith Myers
Post: This is my status of current tasks. I agree. There is no reason not to clear out the database by moving old results into the science database. It takes almost a minute most times for any host account web page to populate because it has to parse through 500K worth of results. Other projects do this regularly. Why doesn't this project?? |
|
2)
(Message 8342)
Posted 19 days ago by
Keith Myers
Post: Read this thread. https://asteroidsathome.net/boinc/forum_thread.php?id=967#7970 Seems the 280X is only OpenCL 1.1 capable. Check your Boinc startup log for the gpu detection output. If it only reports OpenCL 1.1 you'll have to use it elsewhere. |
|
3)
(Message 8334)
Posted 28 days ago by
Keith Myers
Post: Your post statement is correct. Best to use an app_info.xml file to get the avx-512 tasks right now. |
|
4)
(Message 8329)
Posted 29 days ago by
Keith Myers
Post: Any reason why you MUST run the 8.0 alpha? Or just testing for S&G's. If I were you, I'd just fall back to an earlier Boinc release that was working with your original app_info.xml. I would want the host to still be productive instead of just idling. |
|
5)
(Message 8328)
Posted 29 days ago by
Keith Myers
Post: It's not as if the Boinc client isn't detecting all the cpu feature capabilities, it's instead that it can't DISPLAY all the cpu feature capabilities reported by the host OS. Depending on where the avx tag is placed in the system detected cpu feature output, it could truncate the avx code if it is on the end of the cpu capability output text string that Boinc reads. All the client releases prior to 7.26 or 8.0 alpha only could display a string length of only 1024 characters. So any feature tag in the string past 1024 characters was truncated. So the client was unaware of the true cpu feature capabilities. In the new 7.26 AKA 8.0 alpha release the string length for P_FEATURES_SIZE is now 8192 characters. So the client should now report all the features of even server cpus like my AMD Epycs and Intel Xeons. After looking at the merged code fix for https://github.com/BOINC/boinc/pull/5397 I'd guess that the issue lies with the defined plan_class for the avx-512 app. This issue took several tries to work it all out as the detection code was hooked into a lot more modules than the devs initially realized. One of the modules needing the code fix on the server side code was the plan_class_spec.cpp module. But as I mentioned earlier, the new code has to run on both the client and the server. The client 8.0 alpha is just too far ahead of the server code. |
|
6)
(Message 8326)
Posted 29 days ago by
Keith Myers
Post: Would set work_fetch_debug in the Event Log for more information about the client request to the scheduler and the scheduler's reply. The standard reply of no work to send is not much help here. I'd guess that the new client code is having an unexpected result with the project server software. I don't see any changes in the project preferences. I'd get rid of any API statement in the app_info. That and plan_class will be the things that will prevent the scheduler from thinking your host worthy of being sent tasks. Post your app_info file so I can look at it. |
|
7)
(Message 8324)
Posted 29 days ago by
Keith Myers
Post: The contents of the app_info.xml should be exactly the same as what I posted prior EXCEPT for the change to the application name in the file in the two places where the binary is defined. You need to change the binary name to match the AVX-512 binary name in the file from my example. For the Linux version, this is my app_info.xml <app_info> <app> <name>period_search</name> <user_friendly_name>Period Search Application</user_friendly_name> <non_cpu_intensive>0</non_cpu_intensive> </app> <file> <name>AST_period_search_10215_x86_64-pc-linux-gnu__avx512_linux</name> <executable/> </file> <app_version> <app_name>period_search</app_name> <version_num>10215</version_num> <platform>x86_64-pc-linux-gnu</platform> <avg_ncpus>1.000000</avg_ncpus> <plan_class>avx512_linux</plan_class> <api_version>7.17.0</api_version> <file_ref> <file_name>AST_period_search_10215_x86_64-pc-linux-gnu__avx512_linux</file_name> <main_program/> </file_ref> </app_version> </app_info> |
|
8)
(Message 8317)
Posted 25 Mar 2024 by
Keith Myers
Post: Hello all, Which host? I only see one AVX-512 capable host and that is your 7950X. I also see that it IS processing tasks using the avx-512 binary application. <core_client_version>8.0.0</core_client_version> <![CDATA[ <stderr_txt> BOINC client version 8.0.0 Application: ../../projects/asteroidsathome.net_boinc/period_search_10215_x86_64-pc-linux-gnu__avx512_linux Version: 102.15.0.1 CPU: AMD Ryzen 9 7950X 16-Core Processor Target instruction set: AVX512 2024-03-24 18:00:55 (1279531): called boinc_finish(0) </stderr_txt> ]]> |
|
9)
(Message 8310)
Posted 19 Mar 2024 by
Keith Myers
Post: Hard to say what is happening. I see you've returned plenty of work today that is either already validated or awaiting validation. The only errored tasks I see are ones that you abandoned when you reset the project. |
|
10)
(Message 8307)
Posted 18 Mar 2024 by
Keith Myers
Post: Read the first post in this thread by the admin. The BOINC issue will not be solved until the BOINC maintainers release version 7.26 of the BOINC code which contains the fix for properly detecting all AVX capabilities of the host processor. Only then will you get the correct cpu application sent to your host automatically. You can sidestep and get around this issue right NOW by simply configuring a anonymous host. A anonymous app_info.xml file example was posted early in this thread by the admin. It is a simple thing to configure accordingly for your particular desired outcome. As long as you still have the avx_linux application in the Asteroids project folder, which you still should have unless you reset the project, then it is a simple issue of editing the avx_linux appname into the app_info.xml file example listed. Here. I'll save you the effort. <app_info>
<app>
<name>period_search</name>
<user_friendly_name>Period Search Application</user_friendly_name>
<non_cpu_intensive>0</non_cpu_intensive>
</app>
<file>
<name>AST_period_search_10215_x86_64-pc-linux-gnu__avx_linux</name>
<executable/>
</file>
<app_version>
<app_name>period_search</app_name>
<version_num>10215</version_num>
<platform>x86_64-pc-linux-gnu</platform>
<avg_ncpus>1.000000</avg_ncpus>
<plan_class>avx_linux</plan_class>
<api_version>7.17.0</api_version>
<file_ref>
<file_name>AST_period_search_10215_x86_64-pc-linux-gnu__avx_linux</file_name>
<main_program/>
</file_ref>
</app_version>
</app_info>
|
|
11)
Posted 14 Mar 2024 by
Keith Myers
Post: Just ran a new task with the updated app. All is fine now. Thanks Petri. |
|
12)
Posted 14 Mar 2024 by
Keith Myers
Post: I just blew through 80 or so apparently badly formatted gpu work units on five different hosts. Not seen this type of error before on any of my hosts. Seems similar to the type mentioned in the OP. https://asteroidsathome.net/boinc/result.php?resultid=454929153 https://asteroidsathome.net/boinc/result.php?resultid=454930944 Looks that is all that is going out now is bad work. |
|
13)
(Message 8302)
Posted 14 Mar 2024 by
Keith Myers
Post: Yes, switch to anonymous. Puts you in control over what tasks get sent to you. |
|
14)
(Message 8288)
Posted 9 Mar 2024 by
Keith Myers
Post: Nobody knows. I get the same thing. Half a dozen requests for work and get nothing and finally one succeeds. Doesn't help the project was chosen for a Formula Boinc contest the other day either. Scheduler is getting hammered more than usual. |
|
15)
(Message 8175)
Posted 18 Dec 2023 by
Keith Myers
Post: About the same as the avx and fma apps though. |
|
16)
(Message 8172)
Posted 12 Dec 2023 by
Keith Myers
Post: Almost certainly your gpu is insufficient in both memory and compute capability for the gpu apps being that old. If you look at each task result itself, the output tells you the reason for erroring out. - Unhandled Exception Record - Reason: Out Of Memory (C++ Exception)\ Just disable use of the gpu in your project preferences and only run the cpu tasks. |
|
17)
(Message 8160)
Posted 1 Dec 2023 by
Keith Myers
Post: You could try adding or editing this cc_config.xml parameter: <max_file_xfers>2</max_file_xfers> to try and only upload a small quantity at a time. Most projects have an upload limit of 250 tasks or less. By keeping the upload small, the project database doesn't have to search through 400 records for what you have been attempting. This has helped in the past as with projects like Seti which had a very high return rate and got bogged down when attempting to report a large amount of tasks at each scheduler connection. If this change does not help I would suggest setting http_debug in the logging to see if there are any reported errors in the connection. |
|
18)
(Message 8157)
Posted 29 Nov 2023 by
Keith Myers
Post: 348K RTS now |
|
19)
(Message 8125)
Posted 1 Nov 2023 by
Keith Myers
Post: Your welcome. It is a common misconception that any setting we use in various projects settings or app_config or app_info files actually have any control over cpu resource usage when crunching any gpu task. Only the gpu application as coded itself, has any influence or control of how much cpu resource is needed to support the gpu task running. It will use as much or as little cpu support as needed. Only the developer can control that. Some gpu tasks at project need very minimal cpu support. And some projects need massive gpu support and can use commonly 1-2 cpu cores to support each gpu task. On the extreme end are the PythonGPU tasks at GPUGrid project which even though they are released as gpu tasks, and do use the gpu occasionally, they are in principle a cpu task in reality and consume as many cpu cores as the host has. The cpu_usage values in app_config files, for example, are only used by the project scheduler for determining the host loading so the scheduler can decide if there is room to run more cpu tasks. |
|
20)
(Message 8123)
Posted 1 Nov 2023 by
Keith Myers
Post: No it will not stop running the gpu tasks when you disable the cpu tasks. The gpu application uses whatever cpu resources it needs regardless of settings. |
Next 20