The work units with "/lpp" in command line are special ones, they're more hard on CPU, so 100% GPU load is not guaranteed. But there is only a few of them.

And yes, new pairs: https://sech.me/ap/log/2019/2019-10-19/VOLUNTEERS%40BOINC.txt

And there is a bug in OpenCL version: https://sech.me/boinc/Amicable/workunit.php?wuid=11571043
I reproduced it locally. Kernel size = 23 skips some numbers, kernel size = 21 works fine. But other work units might behave differently, i.e. kernel size 21 will skip numbers.

P.S. Fixed in version 3.01. It was a bug introduced during refactoring, so 10²⁰ search wasn't affected.

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?

Probably task_size parameter was calculated incorrectly, so it can count to 100% before the actual work is done. I'll check this task.

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.

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.

I've checked it. Tasks with "/lpp" in command line iterate over many more ranges than normal tasks and many of these ranges end up with 0 numbers for GPU. This is why it uses only CPU in the end and is at 100% - it counts only how many numbers to check on GPU.

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).

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?

There's literally only 310 such tasks for the entire search. lpp stands for "largest prime power" and when it's 2 or 3, you only get to check sqrt(N) or cuberoot(N) numbers. So we shouldn't bother with them at all. But they are also good for testing and finding bugs, so I added them for the beta test.

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!

What would the RAM requirement be for the search to 10^21? I would guess that it wouldn't quite be a 10x jump to 15GB, but it could still be quite substantial.

The memory required is O(sqrt(N)), so it will not be a 10x jump:
CPU version would require ~1400 MB of memory.
GPU version would require ~3700 MB of GPU memory.

Great! Thank you for the quick reply! That is better than I thought. 3700MB for GPU would still leave a large portion of GPUs capable of participating and only 1400MB for CPU is quite low so I doubt anyone would be left out of the search up to 10^21 if it occurs.

1400MB seems to be about right for 2 cpus.
Up to 1000MB is released and re-allocated every minute.
While 'used memory' is reasonably stable, allocated memory gradually increases.
This might be Windows' fault - but it might also be forgetfulness by Amicable.
Answers please - on a postcard - to - boinc'ers with small machines !

I pushed search limits for 10²¹ a bit further into large primes territory, so memory requirements are higher now (all primes up to 10¹¹ are checked). CPU version requires 2.85 GB of system memory. GPU version fits in 1 GB on GPU, but requires 8 GB of system memory after refactoring.

I pushed search limits for 10²¹ a bit further into large primes territory, so memory requirements are higher now (all primes up to 10¹¹ are checked). CPU version requires 2.85 GB of system memory. GPU version fits in 1 GB on GPU, but requires 8 GB of system memory after refactoring.

I ran a few of the 10^21 beta tasks (CPU) on a 4GB Win 7 laptop. The tasks ran happily, using about 2.83 GB on 4 cores..

---

Want to find one of the largest known primes? Try PrimeGrid. Or help cure disease at WCG.

When can we expect more of the 10^21 tasks?

---

Reno, NV
Team: SETI.USA

When can we expect more of the 10^21 tasks?

As soon as 10^20 tasks run out or a bit before that for a smooth transition.

Hello,
Does this mean I should be good on adding my gtx 1080 and rx570 in here now that we're starting a different search? i know previously, quite a lot of tasks depended almost entirely on the CPU and so I ran with CPU specifically.
What's the correct (and recommended method) of running 2-3 tasks at once without using too much, or too little, CPU at the same time? I guess an example app config for specific applications would be appreciated. Ram requirements will be a bit higher than usual?

Is it recommended to stick with GPU only or can I run CPU tasks at the same time?

sorry for all the questions!

Running GPU on 10²¹ is fine now. Even 1 task per GPU will get you almost 100% GPU load (except for when task starts), 2 tasks per GPU will guarantee you 100% load all the time. CPU usage of GPU tasks is low, so you can run CPU tasks on the same machine.

Hello!

Well, I ran a few of the new 10^21 WUs on CPU also meanwhile, but found a little runtime discrepancy now.
While the first tasks were finished in a bit more than an hour (like this or this, I just finished one which took more than two days!
Yet both tasks got the same credit! How is this?
Also, I have more than one another task which is already running over 6 hours, looks like they will also take a lot of time... doesn't it need a credit adjustment then?

---

Life is Science, and Science rules. To the universe and beyond
Proud member of BOINC@Heidelberg
My BOINC-Stats

I am running 10^21 using CPU (3 CPUs). BOINC decided to stop an Amicable Numbers task that was 95% completed to run something else, and when BOINC restarted the Amicable Numbers task, I immediately got an "Error while Computing" abort.

Has anyone else had problems when a partially completed Amicable Numbers CPU task has been restarted by BOINC?