Posts by Kellen

1) Message boards : Number crunching : GPU version requirements for the search up to 10^20 (Message 1322) Posted 11 Dec 2019 by Kellen Post: Hi, Just wondering what the actual system requirements are... Today I added 2 machines (S3PC-S04 and S3PC-S25) to this project, both machines are running 1 GPU WU each, and seems to run out of memory; after about 30 secs to a minute, the WU gets status "Waiting for memory". Both machines have 8GB system memory, and running Ubuntu, which does not take much resources. Based on BOINC memory settings, the GPU application takes more then 6GB (75%) of system memory...? Ridiculous! If these are the real specifications, then application need some serious optimization/redesign, this is not workable. Presently the GPU workunits require 8GB memory. If you do not have enough RAM, you can increase the pagefile size and enable more pagefile usage in BOINC to compensate for the shortfall (this may require a restart of the system to take effect). Beware though that this will read and write an enormous amount of data. If you have a hard drive it will be unlikely to keep up and would be very taxing on it, and an SSD will incur a significant number of writes. On my system with a GTX 1650 and 8GB RAM, I had 28TBW over the month or so I ran Amicable Numbers tasks. Regards, Kellen
2) Message boards : Number crunching : GPU version: kernel size tuning and less UI lags (Message 1300) Posted 12 Nov 2019 by Kellen Post: Turing really is that much better for these tasks :)
3) Message boards : Number crunching : GPU version: kernel size tuning and less UI lags (Message 1299) Posted 12 Nov 2019 by Kellen Post: Turing really is that much better for these tasks :)
4) Message boards : Number crunching : 2 graphic cards, 8 gig of system memory and a huge pagefile... (Message 1294) Posted 9 Nov 2019 by Kellen Post: Just out of curiosity; what are your BOINC preferences settings for memory usage? That is quite a bit of wear on the SSD, although from my experience they usually go well past their TBW lifespan before any serious errors develop. I've got a 60GB OCZ Vertex 3 from 2011 with over 180TBW in one of my BOINC-only systems and (if I recall correctly) the warranty was for 75TBW. A few bad blocks, but nothing showstopping :) I set the memory usage to 95%/95%. The result is that the computer becomes very irresponsive when the tables are read into memory. In other words it was crunching and nothing else. I doubt i will ever wear a SSD down, reaching or exeeding the TBW lifespan. So far i've only lost 2 SSD's due to the SATAFIRM 11 issue that can happen with SSD's with the Phison 11 controller. Exeeding TBW by more than 100% and still going strong is quite good value for the money :) Br Fred Hi Fred, That's awesome; thanks for the info! I will try to get some of my 8GB systems running with these settings too towards the end of the year and we will see how they do :) You and I have very similar SSD experiences. I've never worn one out, but I've certainly had a few controller/firmware failures. Thanks again, Kellen
5) Message boards : Number crunching : 2 graphic cards, 8 gig of system memory and a huge pagefile... (Message 1292) Posted 8 Nov 2019 by Kellen Post: Hi Soulfly, Thank you for posting this information! Just out of curiosity; what are your BOINC preferences settings for memory usage? That is quite a bit of wear on the SSD, although from my experience they usually go well past their TBW lifespan before any serious errors develop. I've got a 60GB OCZ Vertex 3 from 2011 with over 180TBW in one of my BOINC-only systems and (if I recall correctly) the warranty was for 75TBW. A few bad blocks, but nothing showstopping :) Regards, Kellen
6) Message boards : News : The search up to 10^20 (Message 1287) Posted 1 Nov 2019 by Kellen Post: Fantastic! That is quite the achievement. Congratulations to both yourself, Sergei, for organizing and operating this project, and to everyone who participated!
7) Message boards : News : The search up to 10^20 (Message 1285) Posted 1 Nov 2019 by Kellen Post: Hi Sergei, The 10²⁰ stats are gone from the Server Status page. Is the search to 10²⁰ officially complete now? Thank you, Kellen
8) Message boards : News : The search up to 10^20 (Message 1266) Posted 27 Oct 2019 by Kellen Post: Glad to see them out for processing now and even happier to see that you've initiated the accelerated cleanup protocol! The remaining workunits for 10²⁰ should go pretty quick now :)
9) Message boards : News : The search up to 10^20 (Message 1264) Posted 27 Oct 2019 by Kellen Post: Hi Sergei, I've noticed that there are 8 perpetually unsent tasks for 10²⁰. Anything special with those? I can't seem to grab them and it looks like no one else is getting them either.
10) Message boards : News : The search up to 10^20 (Message 1257) Posted 26 Oct 2019 by Kellen Post: Nice workaround! Hopefully that does the trick for everyone else who is having problems too. It does seem like BOINC and Windows can't handle the virtual memory on their own, so I am glad there is another option.
11) Message boards : News : The search up to 10^20 (Message 1251) Posted 25 Oct 2019 by Kellen Post: I repeat: these 8 GB can mostly go into swap file without hurting performance. You don't need physical 8 GB RAM per task, OS will swap out unused parts of memory if you have not enough RAM. BOINC won't allow the memory usage to get high enough for the OS to do this unless the Memory settings in the Computing preferences Options window are set very high. I am not sure how high they would need to be set, but I think that the issue people are having is that BOINC will suspend a running task when the memory usage goes above a certain threshold. I think that the default is 50%, but I have mine set at 95% and right now my physical memory usage is 80% with little to no page file usage. Lowering the memory usage percentages just results in suspended tasks on my computer (Windows 10, BOINC version 7.8.3). Ultimately I believe this to be a BOINC issue and not a Windows or Amicable Numbers issue. To fix it people could try setting the memory usage to 100% and seeing what happens when another task begins running. It could work, but it could also result in a suspended task or a crash of some sort. I'm not brave enough to try in case I break something :)
12) Message boards : News : The search up to 10^20 (Message 1243) Posted 24 Oct 2019 by Kellen Post: Hi Allen, I have found that suspending tasks and restarting them often leads to errors for this project in the past, so I recommend just letting all tasks run to completion when at all possible. Due to the nature of this search it is likely very difficult to implement a reliable checkpoint system without the checkpoints being extremely large (several GB), holding a huge amount of data in RAM (also several GB), or requiring re-initialization of the prime tables (a minute or two) upon resuming calculation. I know this doesn't really solve the problem, but it is the best advice I can give. Regards, Kellen
13) Message boards : Number crunching : Only 1 GPU running on 10^21 (Message 1240) Posted 24 Oct 2019 by Kellen Post: Hi AT Hiker, Your computer has 16GB RAM so you are able to run a single GPU task only. You will require 24GB to run 2 tasks and 8GB more for each additional GPU task you run. This is because each task uses 8GB system RAM and your system will be using a few GB during normal operation, along with usage from other programs you may open. Regards, Kellen
14) Message boards : News : The search up to 10^20 (Message 1228) Posted 19 Oct 2019 by Kellen Post: Awesome! Then the problem will not be a problem for very long, lol. Everything is looking good now on my end, so unless you find any more bugs then I think it is all running smoothly. Looks like about 15,000 more workunits for 10²⁰ and then we are all onto 10²¹ full time! Nice work getting this all together Sergei. Well done, and thanks for all of the effort!
15) Message boards : News : The search up to 10^20 (Message 1226) Posted 19 Oct 2019 by Kellen Post: It seems as though some of the /lpp tasks are much more CPU intensive than others. I just had one that was CPU-only for 48 minutes and another that was CPU-only for 32 minutes. During this time the GPU is completely idle. Would it be possible to separate the /lpp tasks from normal tasks such that the /lpp tasks get sent out only to CPUs?
16) Message boards : News : The search up to 10^20 (Message 1225) Posted 19 Oct 2019 by Kellen Post: Ah! Good to know! Will there be a lot of these /lpp tasks throughout the search for 10²¹, or are they primarily just in this initial test? If there will be a significant number of them, I will run 3 tasks concurrently to make sure that the GPU is being used as much as possible (to prevent thermal cycling).
17) Message boards : News : The search up to 10^20 (Message 1223) Posted 19 Oct 2019 by Kellen Post: Edit: I forgot to add; the task that took the longest ended up dropping at least a portion of the prime tables as memory usage dropped by about 400MB towards the end. Watching closely now and I have two tasks in this state, with memory usages of 7499.4 and 5473.5 MB, so whatever is happening during this time is not using the full tables.
18) Message boards : News : The search up to 10^20 (Message 1222) Posted 19 Oct 2019 by Kellen Post: Here are two more to check out, on the extremes of run times for me so far with the new app Short runtime: https://sech.me/boinc/Amicable/workunit.php?wuid=11573704 Long runtime: https://sech.me/boinc/Amicable/workunit.php?wuid=11573658 The first one uploaded almost immediately after reaching 100% (690 seconds), but the second one spent about 16 minutes at 100% before uploading, with a total run time of 2412 seconds. I have also received a task without the /lpp command and it uploaded almost immediately as well; https://sech.me/boinc/Amicable/workunit.php?wuid=11571426 I should note that I switched to kernel size 21 to see if it changed anything, so that may slightly impact the run times (although core usage is pretty constant so I think that the impact is small). Edit: I forgot to add; the task that took the longest ended up dropping at least a portion of the prime tables as memory usage dropped by about 400MB towards the end.
19) Message boards : News : The search up to 10^20 (Message 1220) Posted 19 Oct 2019 by Kellen Post: Testing the new app now :) The same thing happened as yesterday with the task not completing after it reached 100%, but I let it just keep running this time and, after 13 minutes at 100% CPU usage on a single thread and 0% GPU usage, it did upload. The Progress percentage in BOINC reached 100% after 7 minutes and the total task time was just over 20 minutes. This is the task: https://sech.me/boinc/Amicable/workunit.php?wuid=11573695 Something similar happens with the Einstein@Home FGRPB1G tasks, where the bulk of the calculations are performed by the GPU, then CPU is involved afterwards (for those units the CPU double-checks the GPU work with double-precision calculations). They have it set up so that the GPU component goes from 0-90% in BOINC Manager, and that the CPU portion occurs from 90-100%, to avoid people thinking that the task has frozen. Would be it be possible to implement such a thing here?
20) Message boards : News : The search up to 10^20 (Message 1217) Posted 18 Oct 2019 by Kellen Post: This is the task that wouldn't finish; https://sech.me/boinc/Amicable/workunit.php?wuid=11570806, but I really do think that the problem was on my end. I've been checking the outputs for the tasks and it looks like there have been quite a few new pairs found!
21) Message boards : News : The search up to 10^20 (Message 1215) Posted 18 Oct 2019 by Kellen Post: Well; I found the source of the problem and it is a BOINC problem and not an Amicable Numbers problem. Using the app_config tag <fraction_done_exact\> is causing the task state to update incorrectly, so as far as BOINC is concerned the task is complete when in fact it is not and is still trying to run. Removing the <fraction_done_exact\> tag has resolved the issue for all newly downloaded tasks. I have deleted the checkpoint and task state files in the task slot for the one that is really stuck on my system and the output file in the project data folder and will see if it resolves the issue completely (I am expecting that it will). Looking forward to finding some pairs now!
22) Message boards : News : The search up to 10^20 (Message 1214) Posted 18 Oct 2019 by Kellen Post: And two of them just finished and uploaded, seemingly successfully. I didn't do anything to make them upload so I'm not sure what it was that nudged them to the completed state. The reported run times on the task summary are very much shorter than what the actual Elapsed times are on my computer though.
23) Message boards : News : The search up to 10^20 (Message 1213) Posted 18 Oct 2019 by Kellen Post: I should also note that suspending then resuming the 100% tasks that are still running results in the re-setting of the elapsed time clock to the value at completion of the task (7 minutes 40 seconds on a 1080ti), then re-initialization of the prime tables, then the progress resets to just under 90%, then it gets to 100% and freezes again. Hope this helps with the troubleshooting!
24) Message boards : News : The search up to 10^20 (Message 1212) Posted 18 Oct 2019 by Kellen Post: I've added applications for 10²¹, set it as a beta for now and added 1000 first work units for testing. We'll see how it goes. P.S. But all amicable pairs found during this test will be counted as usual. Awesome! Glad to see it up and running! I've downloaded 3 tasks, but have run into a problem in that the tasks are running and getting to 100%, but then they remain "running" with CPU usage of a full thread and the prime tables still loaded into RAM. GPU usage is 0 during this stage. A few additional observations; on a GTX1080ti the core utilization bounces between 50 and 80% most of the time, so running two tasks seems to be needed for full utilization. Additionally; initialization and generation of the prime tables takes ~56 seconds on a Ryzen 5 1600X with 32GB 3200MHz RAM (although I had 6 threads active on another project when initialization started, so it may be less than 56 seconds if I wasn't running anything else). Because the GPU is idle during this initialization it will definitely be good to run two concurrent workunits and try to offset them by 50% so that one can continue to run while the other initializes. The recommendation to run more than one task does deserve a warning though; each task will use just over 8GB of system memory, so a 16GB system will only be able to run a single task. Regards, Kellen
25) Message boards : News : The search up to 10^20 (Message 1210) Posted 17 Oct 2019 by Kellen Post: Hi Sergei, Thanks for the good description of the task generation process. And I can see now why it can't be distributed; pretty tough to distribute sequential work, lol. Good luck with getting the memory sharing between threads working! Regards, Kellen
26) Message boards : News : The search up to 10^20 (Message 1208) Posted 16 Oct 2019 by Kellen Post: Nice! Glad to hear it is all ready! Just noticed the validator and assimilator for 10²¹ up and running too! Re-running a suite of workunits is a good double-check anyway. It has happened a few times through the project so having a final double-check right near the end seems like a good idea. For task generation; is that something that could be made into an application so that users could generate tasks, or would that be too complicated/inefficient?
27) Message boards : News : The search up to 10^20 (Message 1206) Posted 16 Oct 2019 by Kellen Post: Hi Sergei, I just noticed that the work units went backwards a bit, from about 4.91×10¹⁸ yesterday to 4.85x10¹⁸ this morning. Just wondering if this was intentional or a bug? Thank you, Kellen
28) Message boards : News : The search up to 10^20 (Message 1196) Posted 7 Sep 2019 by Kellen Post: Hi Andy_taximan, The search to 10²⁰ should be completed sometime in mid-to-late October, with the search to 10²¹ beginning either at that time or maybe a little earlier. You can find the predicted completion date of 10²⁰ here: https://sech.me/boinc/Amicable/server_status.php Regards, Kellen
29) Message boards : Number crunching : A few questions regarding my hardware. (Message 1193) Posted 1 Sep 2019 by Kellen Post: Hello. I do have one question. In The Amicable Numbers preferences, there is an option for number of CPUs. Does this equate to how many cores get used per task? E.g. if I set it to 8 CPUs 8 out of 16 threads will be used on this Ryzen? thanks. Hi wolfman1360, You are correct that it is the number of cores used per task. If you set it to 8 CPUs, but leave BOINC's CPU usage at 100%, it will have the effect of running two tasks at the same time with 8 threads each. I do this on my Ryzen 5 1600X so that I can pause tasks if I need some CPU power for something else, without having to stop all crunching for Amicable Numbers. I have my 1600X set up to run tasks with 3 threads each, so that I can easily change how much of my CPU is being used (0%, 25%, 50%, 75% or 100%) whenever convenient. If you would like to limit your computer to running just a single task with 8 threads you can do that in the options here by limiting that computer to only having 1 workunit at a time, setting CPU usage to 50% in BOINC, or by making an app_config file with the following in it; <app_config> <app> <name>amicable_10_20</name> <max_concurrent>1</max_concurrent> </app> </app_config> Hope this helps! Regards, Kellen
30) Message boards : Number crunching : A few questions regarding my hardware. (Message 1191) Posted 30 Aug 2019 by Kellen Post: would it be possible/difficult to switch this over to a number of days remaining? Awesome, thanks!! Nice to see the date in full form :) Regards, Kellen
31) Message boards : Number crunching : A few questions regarding my hardware. (Message 1190) Posted 29 Aug 2019 by Kellen Post: I plan to add 10²¹ app before October, I just haven't figured out the optimal way to run 10²¹ search yet. I need to go through current search results and find the most juicy subsets of tasks to run first. I think something like "searching through all odd numbers with largest prime factor < 10¹¹" can yield over a million new pairs in a year or two. Nice! Definitely looking forward to this! And I like the search methodology too; the first portion of the search up to 10²⁰ was quite exciting with the frequency of amicable pair finds. Once the large prime workunits started the excitement died down quite a bit, lol. I've been stuck at 24,311 pairs for a very long time; can't wait to bump that up! On a somewhat unrelated topic, now that we have gotten very close to the "ETA at current speed (search up to 10²⁰)" stat on the Project Status page, would it be possible/difficult to switch this over to a number of days remaining? It will bounce around a bit, but should be relatively stable now that we are so close. Regards, Kellen
32) Message boards : Number crunching : A few questions regarding my hardware. (Message 1187) Posted 28 Aug 2019 by Kellen Post: Hi wolfman1360, You are definitely correct about the RAM usage right now! The total RAM used is approximately 650MB per thread, so if you are running 16 threads on you 1800X that would get you into the 10GB neighborhood. This is also a by-product of the present search stage, where we are looking at candidates containing very large prime numbers. RAM usage will continue to climb gradually until the end of the search to 10^20, but will drop significantly once 10^21 search begins. To the best of my knowledge there are presently no test applications running, so I don't think enabling that would do anything right now. It might if Sergei gets the 10^21 app loaded and tested before 10^20 is complete, but I would expect that is some time off and would only be for a short while. Nothing really to keep in mind with multi-threading for this project. The multi-threading implementation is pretty straightforward and tends to work well with default settings. Something to note though is that if you are running a task with a set number of threads, lets say 16, and you set CPU usage in BOINC to 50% on your 1800X, the 16-thread task will continue to run with 16 threads, using 100% of your CPU, until it is complete, then the next task you receive will be an 8-thread task. Over at PrimeGrid you are correct that many Intel CPUs have a clear advantage over Ryzen and that is predominantly related to the AVX portion of the CPU. Intel CPUs have a 256-bit width for the AVX processing and 1st and 2nd generation Ryzen CPUs only have 128-bit width. The 3rd generation Ryzen CPUs have 256-bits though, so they are comparable with most Intel CPUs (well; except for the high end Intel CPUs which have AVX512 support, which are in a league of their own for the LLR tasks). Thankfully, this does not affect the processing speed here at Amicable Numbers :D Hope this helps! Enjoy crunching! :) Regards, Kellen
33) Message boards : Number crunching : A few questions regarding my hardware. (Message 1183) Posted 28 Aug 2019 by Kellen Post: Hi wolfman1360! And welcome to Amicable Numbers! Unfortunately for your new GTX 1080 GPU workunits are extremely inefficient at the moment as the vast majority (99%+) of the calculations performed for each workunit are done by the CPU. This will change in a month or two when we finish searching up to 10^20 and begin the search up to 10^21. Until that time it is still possible to run GPU workunits, however you will not be able to fully utilize the GTX 1080 even with a very powerful CPU and as many workunits as you have threads on that CPU. Instead; you can run the CPU version of the program here and it has an excellent credit/day throughput compared to almost any other project. If you would like to participate in Amicable Numbers to help finish the search to 10^20 faster and get to those GPU-efficient 10^21 workunits faster my recommendation would be to run CPU workunits here, and then put the GPU power towards something like Collatz or the AP27 or GFN-21/22 workunits over at PrimeGrid. Those use very little CPU to run efficiently on a GTX 1080. Then, once we begin the search to 10^21, switch the GTX 1080 over to here and watch the credits pile in :) Regards, Kellen
34) Message boards : Number crunching : Maximum Prime Size for Large Prime Workunits (Message 1176) Posted 20 Jun 2019 by Kellen Post: Hi Speedy, The server page is accurate with the percentage complete, but the completion date is probably closer to your estimate. My guess for completion date, assuming participation remains the same, is sometime on the week of September 2, 2019. :) Regards, Kellen
35) Message boards : Number crunching : Question About The Ranges Tested Multiple Times (Message 1173) Posted 19 Jun 2019 by Kellen Post: Nice! Glad to see it was an easy fix! That should more than double the speed of the rest of the search to 1.0E20. Thanks again for the very fast replies! Regards, Kellen
36) Message boards : Number crunching : Question About The Ranges Tested Multiple Times (Message 1172) Posted 19 Jun 2019 by Kellen Post: Great! Thanks for the quick reply! I was wondering why all of the computers crunching those tasks were owned by "Anonymous". I just took a bit of a closer look and it seems as though batches of 100 workunits are generated, starting from where the large sequential batch of 1000 workunits ended, and repeated small batches are generated over that same range. Then, the next sequential batch of 1000 is generated from the end range of the previous one. Something else to note is that the /task_size parameter is different even when the same range is tested. Regards, Kellen
37) Message boards : Number crunching : Question About The Ranges Tested Multiple Times (Message 1170) Posted 19 Jun 2019 by Kellen Post: Hi Sergei, I've noticed that workunits are usually generated in groups of 1000, with the last digits of the workunit name indicating which workunit of that particular batch it is. A while ago I also noticed that there are groups of ranges tested twice, where the last digits in the workunit name are not in numerical order and the workunits not generated in batches of 1000. Just curious what the additional workunits are for, as it appears to test the same range as the sequentially generated workunits. Here is an example of some workunits with the same range tested; Normal, sequentially-generated workunit: https://sech.me/boinc/Amicable/workunit.php?wuid=10971671 Workunit generated out of sequence that tests the same range: https://sech.me/boinc/Amicable/workunit.php?wuid=10971468 Another workunit generated out of sequence that tests the same range: https://sech.me/boinc/Amicable/workunit.php?wuid=10971256 I have also noticed that the workunits generated out of sequence are not all generated at the same time like the sequential workunits, but instead they are gradually generated between the batches of 1000 sequential workunits. Thank you, Kellen
38) Message boards : Number crunching : WU freeze (Message 1169) Posted 16 Jun 2019 by Kellen Post: Hi Marsinph, I took a look at the error outputs for those tasks and it looks like BOINC is having trouble loading some necessary files. Did you do any updates to Windows while BOINC was running, or move any files? Also; make sure that BOINC is allowed to have enough memory. The tasks are growing in memory usage still and you may have just crossed a threshold where there isn't enough to run properly. With 8 cores they need over 4GB RAM now. No matter the cause, I think that the solution to this problem will be as simple as removing Amicable Numbers from BOINC, restarting your computer, then adding Amicable Numbers back. My guess is that everything will work just fine afterwards. Just don't forget to copy your app_config.xml before deleting Amicable Numbers, then you can copy it back after ;) Regards, Kellen
39) Message boards : Number crunching : Somethings must be faulty -> AMD gpu usage at nearby 1-2 % ? Clueless.. (Message 1165) Posted 13 Jun 2019 by Kellen Post: Hi Rantaplan, This is normal behaviour for the workunits at this stage of the search to 1.0E20. The majority of the work is being performed by the CPU and is focused on generating a list of prime numbers over a range of approximately 5.5E12 which are then tested to determine whether they are the largest prime factor in an amicable pair. That test is what is done on the GPU and takes a very, very small amount of time compared to the amount of time required to find the large prime number. For a long time the GPU tasks were increasing in runtime, however over the next few months they should begin to decrease in runtime slightly as the large prime range per task decreases in size. The CPU tasks are also becoming more efficient and should become significantly faster towards the end of the current search. Until the search up to 1.0E21 begins, GPUs will not be fully utilized. Regards, Kellen
40) Message boards : Number crunching : Amicable is this weekends FB Sprint (Message 1160) Posted 31 May 2019 by Kellen Post: About when is that due to happen? Hi Beyond, That is somewhat of a difficult question to answer, as there are a lot of variables, but we can calculate it based on present values and it will probably be fairly close to reality, as long as there are no major changes. To reach the end of this stage we need to get the Large Prime Workunits to 5.00E18, and we are presently at approximately 1.77E18, leaving 3.23E18 to go. In the past 48 hours we have moved 5.95E16, for a rate of ~3E16/day. Assuming that participation stays the same and that there are no significant changes in workunit efficiency, this leaves us with 108 days of crunching to reach 5.00E18. I am expecting a trend towards greater CPU efficiency, although I am also expecting that participation levels will decline slightly. With luck, these two predictions will balance out. In summary; best guess: somewhere around Sept. 13, 2019. Hope this helps. Regards, Kellen P.S. There is a projected month of completion on the Project Status page, and it does seem to be in line with these calculations; predicting sometime in August 2019.
41) Message boards : Number crunching : Amicable is this weekends FB Sprint (Message 1157) Posted 26 May 2019 by Kellen Post: A giant thank you to everyone who participated in this Formula Boinc sprint! You have given the project a very nice boost towards the end of 10^20 and the beginning of 10^21. For anyone interested in sticking around; the CPU applications should trend towards greater efficiency as we approach the end of the 10^20 portion of the project, however the GPU applications will not change significantly from where they are now until we reach 10^21. Once we reach the end of this stage and begin the search up to 10^21 the GPU applications should once again be very efficient (I was at approximately 4,000,000 credit per day with an RTX 2070 before it became CPU-bound), and a single task should fully utilize any GPU with only a fraction of a CPU core to support it. Thanks again! Kellen
42) Message boards : Number crunching : GPU version: kernel size tuning and less UI lags (Message 1151) Posted 24 May 2019 by Kellen Post: Hi MagicEye04, There is nothing wrong with your computer, so please do not worry about that :) Presently; the calculations performed for this project are almost exclusively performed with the CPU and almost nothing is done on the GPU. You can run multi-threaded CPU tasks and, with your CPU, your run-time should be approximately 30 minutes per task if you are using all threads. Regards, Kellen
43) Message boards : News : GPU version bugfix release (Message 1149) Posted 24 May 2019 by Kellen Post: Hi bcavnaugh, The GPU version is now severely limited by CPU and even a GTX 1050 will not achieve full utilization without a very powerful CPU to provide prime numbers for testing. At this stage, I recommend switching to CPU tasks and using GPU for other projects where there is minimal CPU overhead (Collatz, AP27 on PrimeGrid, etc.). I recently ran some tests with a GTX 1080 and GTX 1080ti and compared them to CPU tasks and the total CPU time per task was almost identical. Effectively; the GPU is doing almost nothing right now. As an example of a potential configuration; I am presently using 9 threads for multi-threaded CPU tasks on my Ryzen 5 1600X and using the remaining 3 CPU threads to run GPU units for another project and for general computer use. Regards, Kellen
44) Message boards : Number crunching : Maximum Prime Size for Large Prime Workunits (Message 1147) Posted 24 May 2019 by Kellen Post: Hi Sergei, Many thanks for this information! Looking forward to getting into those early 10^21 ranges with lots of amicable pairs, so it is nice to have the remaining 10^20 work quantified like this. Thank you, Kellen
45) Message boards : Number crunching : Maximum Prime Size for Large Prime Workunits (Message 1145) Posted 24 May 2019 by Kellen Post: Hi All, The tested range per workunit is now 5.84E12, so the progress towards 5E18 has once again accelerated. The increase occurred at 1.42587E18 and there are now approximately 600,000 workunits left between our present leading edge Large Prime task and 5E18 assuming no further range improvements. To follow up with the predictions in my previous post; I am no longer expecting another speedup at 1.5625E18, but the one at 1.6667E18 is still very likely, so we will probably see further improvements in the range for these Large Prime workunits. On another note, to anyone who stopped crunching Amicable Numbers on CPU due to the very long run times of the CPU tasks; this issue is a thing of the distant past. The CPU application is about as efficient as it has ever been now that we are in this very high range. Best of luck to all! Regards, Kellen
46) Message boards : Number crunching : Maximum Prime Size for Large Prime Workunits (Message 1138) Posted 19 May 2019 by Kellen Post: Hi Sergei, Thank you very much for this information. I became curious when noticing the very large drop in the "/task_size" parameter when we passed 1.25E18 and the corresponding reduction in run times, despite the fact that each workunit now moves through a range of ~4.38E12 instead of the ~3.58E12 range prior to passing 1.25E18. On a side note, this increased range and the fact that we need only reach 5E18 means that we now have less than a million workunits left! [(5E18-1.31E18)/(4.38E12)=842,466] I anticipate another large drop in the "/task_size" parameter at 2.5E18 (and maybe also one at 1.5625E18, 1.6667E18 and a few other spots, although I'm not as confident about those values being related to a large task size decrease), so this number of workunits is likely much smaller and could be closer to 500,000. With the decreased run times (on CPU) and the small number of workunits left, we may progress through the final 10% quite quickly, compared to recent progress speed. Regards, Kellen
47) Message boards : Number crunching : Maximum Prime Size for Large Prime Workunits (Message 1136) Posted 19 May 2019 by Kellen Post: Hi Sergei, Just out of curiosity; what will the largest prime number be for these current large prime workunits? We are now at approximately 1.3E18. Will we go all the way to 1.0E20, or will the /lpr units stop at some lower value? Thank you, Kellen Edit: Corrected "10E20" to "1.0E20".
48) Message boards : Number crunching : Countermeasures for Increased CPU Time (Message 1036) Posted 17 Dec 2018 by Kellen Post: This is quite the conundrum! I have never received that error before and from what you describe I can't think of any reason why the app_config wouldn't be recognized by BOINC. Everything you copied into the message checks out. The only possibility that I can think of is that one of the characters is some kind of Unicode weirdness and isn't being recognized properly. I would try deleting the contents of the file and then re-typing it all manually to see if that fixes it, or copying your functional .xml from the Windows 7 machine and replacing the old one on your Windows 10 machine with it. I have tried it on Windows 7 Home and Professional and Windows 10 Home and Professional and did not encounter this error. Good luck with it and keep us posted! Regards, Kellen
49) Message boards : Number crunching : Countermeasures for Increased CPU Time (Message 1031) Posted 15 Dec 2018 by Kellen Post: Hi The Sarge, I do not believe that there are multiple locations for the file. Do you mind copying and pasting the contents of your app_config file here so that I can double-check everything? The most common reason an app_config file doesn't work properly is that it is not actually an XML file, but if you saved it as one then that is unlikely to be the problem. To get the contents of the XML file, right click on it and select "edit" and that should open it with notepad. Opening it with Microsoft Word can sometimes hide text and that may be causing the issue. Thank you, Kellen
50) Message boards : Number crunching : Countermeasures for Increased CPU Time (Message 1024) Posted 13 Dec 2018 by Kellen Post: The GTX 1080 ti and RTX 2080 ti both have 11GB RAM, but only 4GB shows up in BOINC data ;)

Next 50