Posts by Cautilus

1) Message boards : Number crunching : Finally getting new tasks only seconds after running out. May not be worth the hassle. (Message 69712) Posted 15 Apr 2020 by Cautilus Post: Not all AMD suck at Einstein. I have four 280X which like either project. I bought them because they produced the most double flops per Â£, and they're almost the best at single flops per Â£. If it's Firepro S9000 boards you have, they should be just as happy with Einstein as mine are. Both our cards have a 1:4 ratio of DP:SP. I agree that I would think the S9100's that Joeseph has should be theoretically fine for Einstein, but I just want to point out that they're not the same GPU as your 280X's. The S9100's are based on Hawaii, the core inside the 290/290X, but since they're server cards they have a DP ratio of 1:2.
2) Message boards : Number crunching : Finally getting new tasks only seconds after running out. May not be worth the hassle. (Message 69684) Posted 11 Apr 2020 by Cautilus Post: You don't need to use coproc_info, you just need to download Joseph's modified BOINC client and make the edits to the cc_config.xml file. These are the instructions Joseph gave: http://stateson.net/bthistory/boinc_x64_for_milkyway.zip The following procedure assumes that your original boinc.exe is at "/Program Files/boinc" I do not have an install procedure so it must be installed manually Extract the boinc.exe file from the zip archive and save it at /Downloads or where convenient It can only be executed from the program directory so trying "boinc.exe --version" will tell you files are missing You must stop boinc from executing before replacing it. To stop boinc, First bring up the boinc manager, then exit the boinc manager and specify to stop programs from executing After stopping boinc you should rename the original program from boinc.exe to old_boinc.exe Copy the new program into the /Program Files/boinc folder Starting up the boinc manager should also start up boinc. Check to see if the version is 7.15.0 for the new program. After a few minutes of looking at the event message you should notice a download of a few files. Eventually the number of work units waiting to be processed will rise up and hover near the maximum. The only time it will drop to 0 is when the project goes off-line. On my system the count stays between 850 - 890 all the time. On the 7.15.0 version use the following cc_config.xml <cc_config> <log_flags> <task>0</task> <work_fetch_debug>0</work_fetch_debug> <sched_ops>1</sched_ops> <file_xfer>1</file_xfer> <file_xfer_debug>0</file_xfer_debug> <mw_debug>0</mw_debug> </log_flags> <options> <use_all_gpus>1</use_all_gpus> <allow_remote_gui_rpc>1</allow_remote_gui_rpc> <mw_low_water_pct>1</mw_low_water_pct> <mw_high_water_pct>16</mw_high_water_pct> <mw_wait_interval >512</mw_wait_interval> </options> </cc_config>
3) Message boards : Number crunching : "Application has been blocked from accessing graphics hardware." in Windows 10 notifications. (Message 69569) Posted 25 Feb 2020 by Cautilus Post: I've just installed a newer Radeon driver I didn't know was available (autoupdate seemed to have forgotten!), if that still fails, I'll try a much older one (in another forum it's been suggested the 2020 ones are unstable). Most times I've seen it crash, only Einstein is running. Due to the weird MW server thing of not handing out work while work is being returned, it tends to give up getting MW and download huge amounts of Einstein and work on that, hence when it does get MW, it concentrates solely on that as it's not been doing enough of it. I rarely see both projects running at once, and I don't recall ever seeing a crash while it was. When it crashes, the screen usually stays on, so I can see what it was doing at the time of the crash. About to install a better PSU which might help. All GPUs are running at stock settings, but I can't guarantee they were with the previous owner as they're second hand. It does tend to be one card more often that crashes, maybe it's faulty? Thanks for suggesting Enterprise, I'll try that. I'd check out this thread regarding MW not requesting tasks properly, it's a long-standing bug with Milkyway, but if you use this guy's modified boinc client, it beautifully fixes the problem. https://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=4532 If the cards were faulty I would think they would crash instantly upon putting any sort of load on them, so I don't think they're faulty. You could try underclocking the offending cards by 50 or 100MHz to see if that resolves the issues. I'd probably try the Enterprise drivers first though.
4) Message boards : Number crunching : "Application has been blocked from accessing graphics hardware." in Windows 10 notifications. (Message 69567) Posted 25 Feb 2020 by Cautilus Post: Windows will block apps if it detects that the applications are causing your GPU drivers to crash. So, that notification is just a by-product of your GPUs crashing. I would recommend only running one project or the other on your GPUs at once, I believe running both Milkyway and Einstein work units on the same card simultaneously could be causing the crashing. Obviously if you've got your GPUs overclocked or undervolted that could also be the source of the crashing. Also for AMD cards the latest drivers are not very stable, I would recommend the "Pro Software for Enterprise" drivers instead, they are much more stable and better suited for compute workloads like BOINC tasks. I know for my Radeon VIIs, the latest 2020 Adrenalin drivers caused them to crash every couple of hours at complete stock, once I switched to the Pro drivers I had no issues.
5) Message boards : Number crunching : Finally getting new tasks only seconds after running out. May not be worth the hassle. (Message 69563) Posted 23 Feb 2020 by Cautilus Post: Thank you so much Joseph, worked like a treat. Now my Radeon VIIs will never run idle. I was using 7.16.3 with Ubuntu 18.04, so I can confirm that your modified boinc works with that setup.
6) Message boards : Number crunching : Finally getting new tasks only seconds after running out. May not be worth the hassle. (Message 69561) Posted 22 Feb 2020 by Cautilus Post: Hi I see you guys mentioning editing "coproc" or something like that to download 900 WUs at a time instead of 150 - 300? I was wondering how you go about doing that, because I've been searching around for a bit and I can't find any instructions. Also how do you install the ubuntu version? I'm a complete novice with Linux and you mention you need to "use 0751 on program and 0664 on the xml" but I have no idea what that means.
7) Message boards : Number crunching : multithread (Message 68944) Posted 2 Aug 2019 by Cautilus Post: You can just run multiple single-threaded WUs concurrently to use more threads, which BOINC should be doing automatically unless you've changed your CPU utilisation parameters.
8) Message boards : News : New Separation Runs [UPDATE] (Message 68934) Posted 28 Jul 2019 by Cautilus Post: Vester those aren't "bgset_2" work units. Those are the bugged "bgset" work units. "bgset_2" work units have the "_2" right next to the "bgset", like this: de_modfit_84_bundle4_4s_south4s_bgset_2_1564052102_378831_1
9) Message boards : News : New Separation Runs [UPDATE] (Message 68913) Posted 25 Jul 2019 by Cautilus Post: Is this from a "...bgset" run, or a "...bgset_2" run? The new "...bgset_2" runs ran fine on my client. This looks identical to the last error for the previous bugged runs. Thank you for the input, though! Tom Oh right yes my mistake, that was from a bgset run, not a bgset_2 run. Looks like bgset_2 is running all good on my end.
10) Message boards : News : New Separation Runs [UPDATE] (Message 68910) Posted 25 Jul 2019 by Cautilus Post: This is what I got: <core_client_version>7.14.2</core_client_version> <![CDATA[ <message> Incorrect function. (0x1) - exit code 1 (0x1)</message> <stderr_txt> <search_application> milkyway_separation 1.46 Windows x86 double OpenCL </search_application> Reading preferences ended prematurely BOINC GPU type suggests using OpenCL vendor 'Advanced Micro Devices, Inc.' Error loading Lua script 'astronomy_parameters.txt': [string "number_parameters: 4..."]:1: '<name>' expected near '4' Switching to Parameter File 'astronomy_parameters.txt' <number_WUs> 4 </number_WUs> <number_params_per_WU> 25 </number_params_per_WU> Number of streams does not match 06:50:25 (6780): called boinc_finish(1) </stderr_txt> ]]>
11) Message boards : Application Code Discussion : GPU RAM Requirements (Message 67322) Posted 11 Apr 2018 by Cautilus Post: Yeah it seems like the work units use up to 1.5GB of VRAM on NVIDIA cards for whatever reason. On AMD cards they only use like 100MB per work unit, I'm not sure why NVIDIA work units use so much more VRAM. But I would also like to know if there's a way to reduce the VRAM usage for NVIDIA cards.
12) Message boards : Number crunching : Can't get work for NVIDIA GPU (Message 67275) Posted 25 Mar 2018 by Cautilus Post: I will mention that the developers are reducing work units to GPUs without very high double precision capability. Pretty much all of the NVIDIA GPUs mentioned in this thread have very low FP64 (double precision) capability, which would explain why you haven't been getting many work units. You should allocate your GPUs elsewhere.
13) Message boards : Number crunching : How to reduce VRAM usage for NVIDIA GPU tasks? (Message 67101) Posted 18 Feb 2018 by Cautilus Post: Well maybe that's how it's set out in NVIDIA's guidelines, but Milkyway still allocates up to 12GB of VRAM. Here's a graph from HWiNFO64 that shows my VRAM usage with 8 WUs running simultaneously, clearly showing it's above the 3GB threshold (Y-axis is from 0 to 12500MB of VRAM allocation). https://i.imgur.com/665amcH.png
14) Message boards : Number crunching : MW@H DBase problems (Message 67092) Posted 16 Feb 2018 by Cautilus Post: Great to hear a permanent solution is on the way, thanks Jake!
15) Message boards : Number crunching : How to reduce VRAM usage for NVIDIA GPU tasks? (Message 67086) Posted 15 Feb 2018 by Cautilus Post: Yeah look trust me, I'd need probably 16 WUs simultaneously to saturate the TITAN V's FP64. I know on 280X's the VRAM usage is significantly lower, for some reason on the TITAN, each WU uses about 1.5GB of VRAM. I'm not sure if this is because of the new architecture or if it's just an NVIDIA thing. The WUs process in about 55 - 65 seconds even with 10 WUs running simultaneously, and that's still peaking at only 70 - 75% usage, indicating there's still headroom left.
16) Message boards : Number crunching : How to reduce VRAM usage for NVIDIA GPU tasks? (Message 67084) Posted 15 Feb 2018 by Cautilus Post: So I have a TITAN V that I want to use on this project while it's not doing anything important. The problem is I can't max out its usage by running more WUs simultaneously because I max out the VRAM on the TITAN and all of the work units end in 'computation error'. I can run about 8 or so WUs simultaneously if I micromanage them so they don't hit 12GB VRAM usage, but surely there's a way to set the WUs to use less VRAM somehow right?
17) Message boards : Number crunching : Is anybody going to buy a TITAN V? (Message 66920) Posted 2 Jan 2018 by Cautilus Post: Just gunna bump this because it'd actually be ridiculous the amount of RAC you'd get on a Titan V boosting up to ~1800 MHz if someone was willing to try it. Probably get something like 3 - 4 million RAC off a single card.
18) Message boards : Number crunching : I have pages of completed work units but (Message 66888) Posted 27 Dec 2017 by Cautilus Post: Yeah I've got a 50/50 ratio of validation inconclusive and valid aswell on my machines, and my RAC is dropping. Probably something's gone wrong on their end.
19) Message boards : Number crunching : Errors (Message 66620) Posted 16 Sep 2017 by Cautilus Post: I'm getting errors on these work units as well: "de_modfit_fast_18_3s_146_bundle5_ModfitConstraintsWithDisk_Bouncy" "de_modfit_fast_20_3s_146_bundle5_ModfitConstraintsWithDisk_Bouncy" Running a 290X and 280X, both of them seem to get errors only with these units, no others.