Posts by Ian&Steve C.
|
1)
(Message 8640)
Posted 14 hours ago by Ian&Steve C. Post: Hello. it's a BOINCstats problem. |
|
2)
(Message 8639)
Posted 14 hours ago by Ian&Steve C. Post: On my GPU card Nvidia RTX 4070 Super when I am running primegrid tasks GPU and Power usage is nearly on 100%. the Asteroids GPU application is heavily constrained by random memory access. this slows down overall computation A LOT. your GPU is waiting around for memory transfers more than it's actually computing, that's why the power used is so low, because it's not working that hard. it's not a problem, its just the nature of the application. Primegrid is just crunching numbers, and doesnt have the same reliance on VRAM transfers, primegrid tasks mostly fit within the L2 cache on the 40-series cards from what i remember, and they are more optimized than the apps here. you basically can't compare two apps that are doing two totally different things. |
|
3)
(Message 8575)
Posted 25 Sep 2024 by Ian&Steve C. Post: Please do like the BOINC projects "Amicable numbers" and "RakeSearch", and add a "percentage completed" line to the server status page, either for the whole project, or for each application, as well as a completion estimate (year and month), based on the current speed. probably not possible. there's new data coming in all the time. this project does not have a set defined "end" and new data comes in from many different sources, it will likely keep running as long as there are resources/budget allotted to administration and development. |
|
4)
(Message 8569)
Posted 11 Sep 2024 by Ian&Steve C. Post: it's a common issue/bug. just have to keep trying and you will eventually get work. |
|
5)
(Message 8565)
Posted 6 Sep 2024 by Ian&Steve C. Post: The AVX512 unit in ZEN5 is supposed to be significantly more powerful than in ZEN4. In my test 7950X vs. 9950X, both 105W ECO, the 9950X was only as fast the 7950X, often even 1-2 minutes slower. Same with Windows 11 (with new AMD patch) as with Linux Mint 22, . Does the app for ZEN5 require special optimization or do the improvements simply not work for BOINC projects? just having the app compiled to use the avx512 pipeline wont automatically mean faster processing. the data needs to be packaged appropriately to truly increase throughput. the axv512 app here is only a little bit faster than the avx/fma app, which tells you that the data isnt structured in a way that takes much advantage of it. imagine you have a conveyor of buckets moving water from one place to another place. the conveyor moves at a constant speed at first your buckets are too small, and some water is overflowing from the buckets. restricting how much water is moved at a time then you increase the bucket size and now the buckets are not overflowing and you can move the max rate of water since you are limited to how much you fill each bucket. then you double the size of the bucket, this does nothing for overall throughput since you are still only putting the same amount in each bucket. that's essentially whats happening here. |
|
6)
(Message 8558)
Posted 2 Sep 2024 by Ian&Steve C. Post: two things: the rpi5 can use the NEON SIMD optimizations, which work the CPU harder. your rpi3 tasks are not using this. I'm not sure if that's a limitation of the 32-bit app or the specific implementation of NEON SIMD with the asteroids app with armv7. the other factor is that the rpi5 runs at like twice the clock speed of a rpi3. which generates more heat. the asteroids app does generate more heat than other projects from my experience, this is normal due to the SIMD optimizations. my rpi5 does see fairly high temps at about 75C running asteroids. you said you have a heatsink on it, but do you have a fan on it too? you'll probably need some airflow over it. |
|
7)
(Message 8544)
Posted 21 Aug 2024 by Ian&Steve C. Post:
no that's not correct at all. any info you find about FP64 TFlops on ARC GPUs was pre-launch speculation that never got corrected. you will never get 4-5 TFlop from emulated FP64. that's faster than a Radeon VII which has strong hardware FP64 performance. the ARC Alchemist cards do not support FP64 in hardware at all. the emulation only works for Linux in terms of GPGPU compute (and it's very slow), and where it "works" in Windows is to handle the very very few instances in some games that need it (but the slow performance doesn't hinder the overall processing of the game). sorry, it's not going to happen until Intel includes hardware FP64. maybe they will in the next generation of ARC with Battlemage |
|
8)
(Message 8534)
Posted 18 Aug 2024 by Ian&Steve C. Post: see https://asteroidsathome.net/boinc/forum_thread.php?id=228 I know someone who actually already ported it for Xeon Phi. let me point them to this thread. but I don't know how to get BOINC to detect it and use it properly. but they were able to run the app offline at least. spoiler: it's pretty slow. i think a more modern CPU will still be a few times more productive. |
|
9)
Posted 8 Aug 2024 by Ian&Steve C. Post: it probably is because of the inherent differences in the GPUs. you can see that the app custom tailors the grid size to the GPU architecture. and i don't think it can restart from a checkpoint where the grid size changes. the way all the previous work was complete becomes not compatible with the change. the problem will only happen when the task restarts on a different GPU, if it restarts on the same GPU, or never has to pause/restart, then you wont see the problem. you can increase the length of time for task switching to try to prevent this. also not stopping BOINC in the middle of task execution if possible. |
|
10)
(Message 8520)
Posted 7 Aug 2024 by Ian&Steve C. Post: Any additions are welcome. for the GPU app I'm talking about the VRAM. but the same concept applies to the CPU app too, with RAM speed/bandwidth having a big impact on the performance. |
|
11)
(Message 8518)
Posted 7 Aug 2024 by Ian&Steve C. Post: to add on, even though the app makes heavy use of FP64 for GPU, it is not the determining factor for performance. IE, a GPU with twice the FP64 Flops will not necessarily be twice as fast in processing Asteroids tasks. 4090s are still faster than Titan Vs, despite the Tian V being many times faster in FP64 compute. memory speed/bandwidth seems to be the biggest limiting factor. |
|
12)
(Message 8509)
Posted 3 Aug 2024 by Ian&Steve C. Post: NO tasks for over 24 hours read here: https://asteroidsathome.net/boinc/forum_thread.php?id=911&postid=8078 |
|
13)
(Message 8507)
Posted 2 Aug 2024 by Ian&Steve C. Post: as with your post on Einstein, this project does not use neural networks, so an NPU has no use here either. any project that could potentially use an NPU would have to be doing neural network type work. the only project that I know doing this kind of work is GPUGRID on their ATMML app. |
|
14)
(Message 8501)
Posted 30 Jul 2024 by Ian&Steve C. Post: OK, so we know the work generation is out of the hands of the admin. it IS in the hands of the Project Scientist. they made the deliberate decision to not automate it to have more control over the process and which data gets priority in generation. a few posts up: https://asteroidsathome.net/boinc/forum_thread.php?id=911&postid=8078 |
|
15)
(Message 8457)
Posted 1 Jul 2024 by Ian&Steve C. Post: the second option you tried would not limit the number of tasks, that's why it didnt work. that command line argument is for telling the app which optimization to use (SSE3/AVX/etc). has nothing to do with task limiting. go back to your previous config. but do it this way instead: <app_config> <project_max_concurrent>7</project_max_concurrent> </app_config> you need to add these into an app_config.xml file located in your project folder, wherever that is (maybe /var/lib/boinc or something similar, look for a directory like /var/lib/boinc/projects/asteroidsathome.net_boinc/). put the app_config.xml there. then re-read config files. |
|
16)
(Message 8453)
Posted 29 Jun 2024 by Ian&Steve C. Post: Under Boinc Manager project properties for Asteroids it says "Don't request tasks for cpu", Account Manager preference. I never set any parameter to not request cpu tasks. I don't know how this changed. How do I reset it to request cpu tasks? Thanks- remove your account manager and manage the host by yourself. |
|
17)
(Message 8432)
Posted 5 Jun 2024 by Ian&Steve C. Post: your GLIBC version is too old. this is usually tied to the OS version on Ubuntu. upgrade to 20.04 to fix the problem. |
|
18)
(Message 8300)
Posted 13 Mar 2024 by Ian&Steve C. Post: resource share is handled by BOINC client. it is only set at the project level. once set, the client does all the calculation for which projects to run and when and overall how that resource share setting is actually applied. that said, BOINC doesnt always do a great job, and there are many variables. resource share of 10% doesnt mean that it will use 10% of your cpu utilization. is means 10% of "work done without missing deadlines" or something along those lines. with wildly varying deadlines, computational size, and other knobs to turn on BOINC, it often acts strangely or not as desired. over a long term it should "even out" but it could take a while. if you havent run one project for a while, it will prioritize that project for a bit to bring it's REC value back to where it thinks it should be. you can force BOINC to not run more than X amount of tasks for any one project by setting an app_config.xml file and adding the <project_max_concurrent>X</project_max_concurrent> statement to it. see here for specific usage/configuration: https://boinc.berkeley.edu/wiki/Client_configuration |
|
19)
(Message 8277)
Posted 7 Mar 2024 by Ian&Steve C. Post: It’s how much of a single CPU core that the GPU application is projected to use while the GPU app runs. So 0.01 means essentially that 1% of a single CPU core is needed to run the GPU task. Theres always some element of CPU computation needed for any GPU task. Some applications require more CPU than others. This is also not in any way determining the CPU use. Changing this value does not actually change what the GPU applications will do. This value is only there for the purposes of BOINC to figure out how much systems resources are used in total. It needs to know this so it can best determine how many other tasks to run on the CPU. For example if you had four GPU tasks running, and each one needed 0.5 CPU, that tells BOINC that running these four tasks will need two CPU threads for support. If you have an 8-thread CPU, and you are allowing the CPU to work 100%, then BOINC would run 6 more CPU tasks. |
|
20)
(Message 8230)
Posted 21 Jan 2024 by Ian&Steve C. Post: Running the CPU aps is burning up my CPUs. The sse2 and sse3 aps are the most energy efficient and run cooler. There's no way to allow one to control which of these dangerous aps gets DLed. Best way is to mitigate the problem is eliminate the cause. Run this command after starting BOINC: just run anonymous platform like you did on TN-Grid. add only the sse3 app if thats what you want to run. calling the app "dangerous" is quite hyperbolic. if you have temp problems, look into your cooling solution. |
Next 20