According to the server status https://sech.me/boinc/Amicable/server_status.php, the 10^20 search will be completed by Feb 2019 based on current run rate. I think it is a good time to decide if we can start 10^21. The new Nvidia RTX cards are so much faster in AN project. For e.g. RTX 2080 can finish a task in 4 mins avg http://wuprop.boinc-af.org/results/projet.py?projet=Amicable+Numbers&application=Amicable+Numbers+up+to+10%5E20&plateforme=all&cpu_family=%2C&gpu_family=NVIDIA%2CGeForce+2000+Series when compare to 1080Ti of about 7-7.3 mins average.

I think it makes sense now to start the search up to 10²¹ once current search completes. We can start it from "rich" ranges of numbers and find 2-3 millions new amicable pairs within first year, according to my estimations.

Any new estimate of when 10^21 will start? Cant wait to find a pair or 2, not found any so far?

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

Ah thanks, thats were it is, I will keep my 56 thread tasks going then until its done.

Hi, any news about 10^21?? now is only 0,50% to - 100%

Yes, I'll prepare CPU and GPU applications for 10^21 this week. GPU version will need a bit of refactoring because as of now it requires more than 8 GB of GPU memory for 10^21. I'll have to split workunits into 8 stages (1 GB each) for GPU.

Yes, I'll prepare CPU and GPU applications for 10^21 this week. GPU version will need a bit of refactoring because as of now it requires more than 8 GB of GPU memory for 10^21. I'll have to split workunits into 8 stages (1 GB each) for GPU.

We are in the starting blocks. Thank you Sergei for making us live this adventure ... :-)

---

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

Yes, it was intentional. I need a bit more time to generate work units for 10²¹. Everything is ready, but task generation is sloooow.... I hope I'll be able to provide around 10,000 WUs next week when the new search starts.

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?

Right now it takes 5-10 seconds to generate a task and it's a sequential algorithm - every next range must start where the previous range ended, and I have no way to determine range borders until I run a quick emulation of the search. I can split it into several parallel processes however - for example, N processes for ranges starting with 3^N, but each process is also taking 8.5 GB of memory for storing prime numbers. I'll see if I can share these 8.5 GB between processes and run task generators on all 16 threads.

P.S. I think that even now I'm able to generate tasks faster than the crunchers will be able to consume them, so it's not really a problem.

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

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.

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

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!

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.

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!

If there is some task that doesn't finish on GPU, give me a link to it and I'll check it. And I see that there are already some new pairs found.

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!