Posts by Sergei Chernykh

1) Message boards : Number crunching : Long running work units now, but sitting at 100% and not uploading? (Message 662)
Posted 8 days ago by Sergei Chernykh
Post:
Yes, something was definitely wrong with these two WUs. Let's hope it doesn't happen again.
2) Message boards : Number crunching : Long running work units now, but sitting at 100% and not uploading? (Message 660)
Posted 8 days ago by Sergei Chernykh
Post:
You should also check your PC - one of the tasks finished with message "Disk usage limit exceeded".[/url]
3) Message boards : Number crunching : Long running work units now, but sitting at 100% and not uploading? (Message 659)
Posted 8 days ago by Sergei Chernykh
Post:
Current work units are actually shorter than average. Just cancel WUs that can't finish.
4) Message boards : Number crunching : Interesting distribution of numbers - my discoveries stopped. (Message 657)
Posted 10 days ago by Sergei Chernykh
Post:
Read the last two messages here: https://sech.me/boinc/Amicable/forum_thread.php?id=95&postid=639#639
5) Message boards : Bug tracker : Using too much memory... (Message 655)
Posted 10 days ago by Sergei Chernykh
Post:
Try to reduce kernel size for AMD GPUs in project preferences: https://sech.me/boinc/Amicable/prefs.php?subset=project
It should reduce memory size used by GPU tasks.
6) Message boards : Bug tracker : Using too much memory... (Message 652)
Posted 11 days ago by Sergei Chernykh
Post:
Current applications use ~440 MB per one CPU task and ~2 GB per one GPU task. Don't run many tasks at the same time: one CPU + one GPU task is enough.
7) Message boards : Bug tracker : "Show names" in Task list - only shows task numbers. (Message 650)
Posted 22 days ago by Sergei Chernykh
Post:
It was turned off because of performance issues.
8) Message boards : Bug tracker : AMD mesa OpenCL kernel compilation error, fix suggestion (Message 645)
Posted 28 days ago by Sergei Chernykh
Post:
It looks like it just crashes on your PC now when it tries to compile OpenCL code:

SIGSEGV: segmentation violation
Stack trace (19 frames):
../../projects/sech.me_boinc_Amicable/amicable_OpenCL_v_2_06(boinc_catch_signal+0x65)[0x4373a5]
/usr/lib/libpthread.so.0(+0x117e0)[0x7f967051a7e0]
/usr/lib/libLLVM-4.0.so(_ZN4llvm11Instruction15eraseFromParentEv+0x2c)[0x7f961c4b4b9c]
/usr/lib/libLLVM-4.0.so(+0x1938224)[0x7f961d60b224]
/usr/lib/libLLVM-4.0.so(+0x1937c3b)[0x7f961d60ac3b]
/usr/lib/libLLVM-4.0.so(+0x1939890)[0x7f961d60c890]
/usr/lib/libLLVM-4.0.so(_ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE+0x311)[0x7f961c4df791]
/usr/lib/libLLVM-4.0.so(_ZN4llvm13FPPassManager11runOnModuleERNS_6ModuleE+0x32)[0x7f961c4df7d2]
/usr/lib/libLLVM-4.0.so(_ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE+0x312)[0x7f961c4def62]
/usr/lib/libMesaOpenCL.so.1(+0x1ddb4e)[0x7f961faf8b4e]
/usr/lib/libMesaOpenCL.so.1(+0x1de160)[0x7f961faf9160]
/usr/lib/libMesaOpenCL.so.1(+0x1d9862)[0x7f961faf4862]
/usr/lib/libMesaOpenCL.so.1(+0x1cac04)[0x7f961fae5c04]
/usr/lib/libMesaOpenCL.so.1(+0x1aa16f)[0x7f961fac516f]
/usr/lib/libOpenCL.so.1(clBuildProgram+0x4b)[0x7f96700ed65b]
../../projects/sech.me_boinc_Amicable/amicable_OpenCL_v_2_06[0x411629]
../../projects/sech.me_boinc_Amicable/amicable_OpenCL_v_2_06[0x406a21]
/usr/lib/libc.so.6(__libc_start_main+0xea)[0x7f966fa4a4ca]
../../projects/sech.me_boinc_Amicable/amicable_OpenCL_v_2_06[0x407855]
9) Message boards : Bug tracker : AMD mesa OpenCL kernel compilation error, fix suggestion (Message 644)
Posted 29 days ago by Sergei Chernykh
Post:
Fixed it in version 2.06: https://sech.me/boinc/Amicable/apps.php
https://github.com/SChernykh/Amicable/commit/b7cbf824d13774f85e0b53c00bbacc6757bb9293
10) Message boards : Bug tracker : AMD mesa OpenCL kernel compilation error, fix suggestion (Message 643)
Posted 29 days ago by Sergei Chernykh
Post:
You don't need to edit the binary, source code is here: https://github.com/SChernykh/Amicable/tree/boinc-opencl-version-128-bit
You can edit and compile it yourself or wait for me. I'll update the GPU version tomorrow.
11) Message boards : Number crunching : WU size or difficulty change? (Message 640)
Posted 14 Oct 2017 by Sergei Chernykh
Post:
Judging by the distribution of known pairs in "2^2*..." range, I don't expect many new pairs until we start "2^2*11*..." subrange which we'll reach somewhere in the beginning of December at current speed. But I plan to request adding Amicable Numbers to main BOINC projects list (both on BOINC web-site and in BOINC client), so it'll hopefully attract some more users.

P.S. Don't worry, there are still ~1,388,000 amicable pairs below 1020 left undiscovered, so they will add ~2,776,000 to user counters of found pairs (each pair is found by two users).
12) Message boards : Bug tracker : Amicable pairs discovered not updating... (Message 635)
Posted 11 Oct 2017 by Sergei Chernykh
Post:
Yes, it's related to the change from "2*..." to "2^2*...". The distribution of amicable pairs is not uniform, they tend to come in waves - each range has a lot of small waves (distributed seemingly randomly) and one big wave in the end. There are still new pairs being found currently - just not that many, you can see today's new pairs here.

P.S. It's definitely not a bug because the search didn't miss any known pair in the range "2*..."
13) Message boards : Number crunching : WU size or difficulty change? (Message 629)
Posted 3 Oct 2017 by Sergei Chernykh
Post:
Yes, WUs changed a few days ago. The project was running through "2*..." range, but it's running through "2^2*..." range now and run times per WU can be 30-40% higher than before.
14) Message boards : News : MacOS GPU version released (Message 625)
Posted 16 Sep 2017 by Sergei Chernykh
Post:
GPU requirements are the same as for Windows and Linux versions: AMD (HD 5xxx or newer) or NVIDIA (GTX 4xx or newer) GPU with OpenCL support and at least 2 GB of video memory.

The MacOS GPU version has been confirmed to work on OS X El Capitan and MacOS Sierra. Older MacOS versions have poor OpenCL support and may fail to run the GPU version.
15) Message boards : Bug tracker : Total number of tasks falls (Message 624)
Posted 13 Sep 2017 by Sergei Chernykh
Post:
Work units that were completed and validated more than one week ago are automatically deleted.
16) Message boards : Number crunching : GPU version requirements for the search up to 10^20 (Message 622)
Posted 13 Sep 2017 by Sergei Chernykh
Post:
I know this is a low priority - I just got my (modified) MacPro up on Amic, and CPU tasks are running now. It appears there is no Mac version of the GPU applications... :-/

(Yeah, I know, I may be the ONLY one on this project with a Mac with an AMD card in it...)

I finally figured out how to compile OpenCL version for MacOS and added AMD and NVIDIA OpenCL application versions for MacOS 10.7 or newer: https://sech.me/boinc/Amicable/apps.php
17) Message boards : Number crunching : How are the APs sorted? (Message 621)
Posted 11 Sep 2017 by Sergei Chernykh
Post:
The project discovered a first example of type (10,4) amicable pair:
10,4 "BOINC: Cautilus, Hooker63" 2017
60839375973463962290=2*5*13*17*41*59*73*83*109*127*241*563
75707483892585778510=2*5*503*77549*261071*743423

Finding new types of amicable pairs is a rare event.

It was also close to beat the lowest m/n ratio for known amicable pairs, but didn't break the record yet.
18) Message boards : Number crunching : How are the APs sorted? (Message 619)
Posted 11 Sep 2017 by Sergei Chernykh
Post:
They're sorted by the smaller member in a pair. The number "65" is type of amicable pair. In short, first digit is how many prime factors are there in the smaller member that don't divide the larger member, second digit is how many prime factors are there in the larger member that don't divide the smaller member. You can find strict definition here: http://mathworld.wolfram.com/AmicablePair.html
19) Message boards : Number crunching : GPU version requirements for the search up to 10^20 (Message 617)
Posted 1 Sep 2017 by Sergei Chernykh
Post:
I'll look into making Mac GPU version next week.
20) Message boards : News : The search up to 10^20 (Message 614)
Posted 16 Aug 2017 by Sergei Chernykh
Post:
I haven't decided yet. The search up to 10^20 will take more than 4 years at current speed, so 10^21 will take more than 40 years which is just too much. So it all depends on how many volunteers will be running the project in 4 years from now.
21) Message boards : News : The search up to 2^64 is complete! (Message 612)
Posted 16 Aug 2017 by Sergei Chernykh
Post:
Congratulations to everyone who took part in this search!

- There are 2,390,655 amicable pairs with smaller member below 2^64 in total
- BOINC volunteers found 552,874 new amicable pairs below 2^64

A more detailed analysis of amicable pairs distribution will follow later this month. And don't forget to edit your preferences and check that you're all set up to run the current search up to 10^20.
22) Message boards : News : Credits for the old application (search up to 2^64) doubled (Message 609)
Posted 13 Aug 2017 by Sergei Chernykh
Post:
There are no new WUs, I've just spawned more tasks for existing WUs to speed up things. Check https://sech.me/boinc/Amicable/workunit.php?wuid=2591144 for example. It has 3 tasks "In progress" now, so it should finish as soon as any of these 3 tasks is finished.
23) Message boards : News : Credits for the old application (search up to 2^64) doubled (Message 607)
Posted 12 Aug 2017 by Sergei Chernykh
Post:
Are we all done with 2^64?

Yes, all WUs are out, we're now waiting for current tasks in progress to complete.
24) Message boards : Number crunching : Extend deadline fpr 10^20 WU? (Message 604)
Posted 9 Aug 2017 by Sergei Chernykh
Post:
Would it lead to issues on the server side when extending the deadline a few days?

The problem is that the project uses replication: each workunit is sent to two volunteers, and if one of them holds it, the other one will have to wait until he gets credit for it.

Even if you miss deadline for some workunits, they'll just be sent to someone else. Just make sure that if you're already running a workunit, wait until it completes if you're going to switch to other projects for a few days.
25) Message boards : Bug tracker : RAM problem (Message 601)
Posted 7 Aug 2017 by Sergei Chernykh
Post:
Nothing is wrong, the last batches for the 2^64 application need a lot of RAM: https://sech.me/boinc/Amicable/forum_thread.php?id=88
26) Message boards : Number crunching : Extend deadline fpr 10^20 WU? (Message 600)
Posted 7 Aug 2017 by Sergei Chernykh
Post:
The deadline is 3 days, current workunits finish in only ~3 hours on your PC. I don't see a big issue here.
27) Message boards : Getting started : A note to the Project Dev/Lead (Message 596)
Posted 3 Aug 2017 by Sergei Chernykh
Post:
1) 2^64 app needs a lot of memory per thread now, it can't be avoided at this stage of the search.
2) 10^20 is not supposed to run on GPUs with less than 2 GB memory. It's probably a bug that BOINC assigned it to your GT 440 OEM 1.5 GB.
3) 10^20 app uses only integer arithmetic, you can look at performance comparison here: https://sech.me/boinc/Amicable/gpu_list.php

P.S. 10^20 app does use 32-bit floats in a few places outside of main loops, but they take a negligible amount of total execution time. It can even run on GPUs that don't support double precision at all.
28) Message boards : Bug tracker : Daily quota error in event log? (Message 593)
Posted 26 Jul 2017 by Sergei Chernykh
Post:
looks like host #2209 decided to take its turn at getting blacklisted. lol
i replaced the RAM today, and set up dual channel properly (not colour-coded on this board). hopefully this clears things up for the future. :)

You set kernel size = 23 for NVIDIA cards. Host #2209 has GTX 750 ti and it just doesn't have enough memory to run kernerl size = 23. Try to decrease it.
29) Message boards : Number crunching : GPU version requirements for the search up to 10^20 (Message 590)
Posted 21 Jul 2017 by Sergei Chernykh
Post:
I've checked BOINC client source code, and found this in "client/gpu_nvidia.cpp":
// return 1/-1/0 if device 1 is more/less/same capable than device 2.
// factors (decreasing priority):
// - compute capability
// - software version
// - available memory
// - speed
//
// If "loose", ignore FLOPS and tolerate small memory diff
//
int nvidia_compare(COPROC_NVIDIA& c1, COPROC_NVIDIA& c2, bool loose) {
    if (c1.prop.major > c2.prop.major) return 1;
    if (c1.prop.major < c2.prop.major) return -1;
    if (c1.prop.minor > c2.prop.minor) return 1;
    if (c1.prop.minor < c2.prop.minor) return -1;
    if (c1.cuda_version > c2.cuda_version) return 1;
    if (c1.cuda_version < c2.cuda_version) return -1;
    if (loose) {
        if (c1.available_ram> 1.4*c2.available_ram) return 1;
        if (c1.available_ram < .7* c2.available_ram) return -1;
        return 0;
    }
    if (c1.available_ram > c2.available_ram) return 1;
    if (c1.available_ram < c2.available_ram) return -1;
    double s1 = c1.peak_flops;
    double s2 = c2.peak_flops;
    if (s1 > s2) return 1;
    if (s1 < s2) return -1;
    return 0;
}


You can try to move this into the beginning of "nvidia_compare":
    if (c1.available_ram > c2.available_ram) return 1;
    if (c1.available_ram < c2.available_ram) return -1;

and then build BOINC client from source.
30) Message boards : Number crunching : GPU version requirements for the search up to 10^20 (Message 587)
Posted 20 Jul 2017 by Sergei Chernykh
Post:
BOINC ver 7.6, however, wrongfully detects it as GPU0 and reports ONLY this card to the Amicable Numbers Server. The Monitor is NOT connected to this card.

I think the problem is that it doesn't detect other cards. GPU detection is 100% on client side, so you should try to wipe BOINC configs and then check client logs (Tools -> Event log in BOINC Manager) to see why it ignores some GPUs.
31) Message boards : News : Finish line of the current search and next steps (Message 583)
Posted 19 Jul 2017 by Sergei Chernykh
Post:
I am curious to know if anyone knows how many more tasks there are for 2_64? Before it is finished

Approx. 83,000 work units left, or 4 weeks more work at current speed.

P.S. Server status page
32) Message boards : Bug tracker : Formal credit for new APs - how is it handled? (Message 581)
Posted 17 Jul 2017 by Sergei Chernykh
Post:
Everything is fixed now. There were others with the same bug.
33) Message boards : Bug tracker : Formal credit for new APs - how is it handled? (Message 580)
Posted 17 Jul 2017 by Sergei Chernykh
Post:
Both pairs were also found by you, and they should've been "BOINC: Henrik Nilsson, jamezz". There was a bug in the code that writes names to the database, I've fixed it. I'll also write a script today that checks names on the pairs found before. Luckily, all needed data is in the database, so it can be restored.
34) Message boards : Number crunching : Daily limit on WU's (Message 577)
Posted 15 Jul 2017 by Sergei Chernykh
Post:
What machine? Can you give me host id?
35) Message boards : Random stuff : Amicable pairs and what must be a stupid question (Message 575)
Posted 12 Jul 2017 by Sergei Chernykh
Post:
I see. Thanks!

Is there, then, an easy way to list all the proper divisors of these numbers? (But yes, I can see why you choose to list only the factors.)

There is a formula to calculate sum of all proper divisors based on factorization: https://en.wikipedia.org/wiki/Divisor_function#Properties
For your case, s(22559194686624505630) = (2+1)*(5+1)*(7+1)*(23+1)*(61+1)*(99643+1)*(2305266221+1) - 22559194686624505630 = 26660358080018237666
36) Message boards : Random stuff : Amicable pairs and what must be a stupid question (Message 573)
Posted 12 Jul 2017 by Sergei Chernykh
Post:
You need to sum up all proper divisors of a number, not just factors: https://en.wikipedia.org/wiki/Aliquot_sum

To quickly check that it's indeed an amicable pair:
http://www.wolframalpha.com/input/?i=sigma(22559194686624505630)-22559194686624505630
http://www.wolframalpha.com/input/?i=sigma(26660358080018237666)-26660358080018237666
37) Message boards : News : Credits for the old application (search up to 2^64) doubled (Message 571)
Posted 11 Jul 2017 by Sergei Chernykh
Post:
Hi,
How many task left ?

You can always look at the server status page (Computing -> Server status in the top menu of the site). Right now it says "ETA at current speed (2^64) 4 Aug 2017".
38) Message boards : Number crunching : 2^64 WU peak memory usage now too high for my Odroid C2s (Message 568)
Posted 7 Jul 2017 by Sergei Chernykh
Post:
Yes, it looks like the 2^64 app requires more memory per thread now.
39) Message boards : Number crunching : very long GPU work units from the search up to 10^20 (Message 566)
Posted 7 Jul 2017 by Sergei Chernykh
Post:
Typically one of those work units that should be done by CPUs.
Same as we had in the end with the smaller search.
But I will have to pull my GPU from AN this way.

Edit: A solution could be variable credits.

No it's not. You set kernel size to 16 on GTX 1080, of course it's using all CPU. The other GTX 1080 finished in 1502 seconds with 64.36 seconds CPU time on the same WU. Set kernel size to 22 or 23.
40) Message boards : Bug tracker : Timed out 10 minutes after being sent (Message 563)
Posted 6 Jul 2017 by Sergei Chernykh
Post:
You are the only one with this error, and only one of your hosts had this error on 4 WUs. Maybe it's incorrect time/date set on that host?
41) Message boards : News : Credits for the old application (search up to 2^64) doubled (Message 556)
Posted 3 Jul 2017 by Sergei Chernykh
Post:
It's sad to see everyone leave the old (and unfinished) application "Amicable Numbers up to 2^64" so I decided to double credit points for it.

Everyone can switch their CPUs back to gain some more credits.

Note that you can run "Amicable Numbers up to 2^64" on CPU and "Amicable Numbers up to 10^20" on GPU on the same PC at the same time!

Here's what you need to set in project preferences:
Use CPU, AMD/ATI GPU, NVIDIA GPU = yes
Run application 2^64 = yes
Run application 10^20 = no
Accept work from other applications = yes


With these settings your CPU will get tasks (and more credits in general) from "2^64" only, and your GPU will get tasks from "10^20" thanks to "Accept work from other applications = yes" selected.
42) Message boards : Number crunching : GPU version requirements for the search up to 10^20 (Message 555)
Posted 3 Jul 2017 by Sergei Chernykh
Post:
i used to be able to crunch on my GTX560ti but am no longer getting work units since the switch to 10^20. anyway to fix this?

No, it can't be fixed with a major rewrite of the GPU version. It just doesn't fit in 1024 MB.
43) Message boards : News : The search up to 10^20 (Message 553)
Posted 3 Jul 2017 by Sergei Chernykh
Post:
One more sad Boincer here. I have to give up my Amicable Numbers contribution because of the 2GB memory requirement. Is this because the computing becomes more complex now? Or can we expect this limit getting lower again somewhere in the future?

The algorithm has to store and use all prime numbers up to square root of N*2 where N is the search limit. After we switched to 10^20, this prime numbers table requires ~1208 MB alone, other internal buffers also increased in size a bit, so the program doesn't even fit in 1.5 GB anymore.
44) Message boards : Number crunching : Very long WUs? (Message 548)
Posted 2 Jul 2017 by Sergei Chernykh
Post:
You can change preferences to use max. 4 threads per WU. They'll take more time to complete, but the total CPU load will always be good.
45) Message boards : Number crunching : Very long WUs? (Message 547)
Posted 2 Jul 2017 by Sergei Chernykh
Post:
A small portion of WUs can't be parallelized to many threads. The one that you aborted had command line /from 2*5*7*11*389*31249 /to 2*5*7*11*389*31271 /task_size 1938395193 which means it could run only 4 threads in parallel (31249, 31253, 31259, 31267 as the last prime number in factorization). But such WUs are rare.
46) Message boards : News : The search up to 10^20 (Message 544)
Posted 2 Jul 2017 by Sergei Chernykh
Post:
Is there any way I could convince you to reduce the required VRAM back to 1.5gb? I've had to switch projects on a bunch of my boxes because I saw that they were no longer acceptable by only 375 mb or so....

I can reduce it, but the problem is that the GPU version will still try to use more than 1.5GB when it runs.
47) Message boards : Number crunching : GPU version requirements for the search up to 10^20 (Message 542)
Posted 2 Jul 2017 by Sergei Chernykh
Post:
Fixed it, version 2.02 should work fine.
48) Message boards : Number crunching : GPU version requirements for the search up to 10^20 (Message 541)
Posted 2 Jul 2017 by Sergei Chernykh
Post:
Not all hosts AMD Radeon have this issue. I can find only 14 hosts out of more than 140 which were active since yesterday.

Regarding the error: I only found this, so it's definitely driver issue.

P.S. Yes, I can rewrite the code and remove that "goto", but it will slow down significantly for everyone else.

P.P.S. I actually have an idea how to solve it, I'll try it now.
49) Message boards : Number crunching : GPU version requirements for the search up to 10^20 (Message 535)
Posted 1 Jul 2017 by Sergei Chernykh
Post:
Current GPU version's requirements: any AMD (HD 5xxx or newer) or NVIDIA (GTX 4xx or newer) GPU with OpenCL support and at least 2 GB of video memory

If you run an AMD card on Windows, make sure you use driver version 14.12 or newer, otherwise it may fail at startup because of OpenCL code compilation error.
50) Message boards : Number crunching : GPU version tweaking for current WUs (Message 534)
Posted 1 Jul 2017 by Sergei Chernykh
Post:
Since this morning, I get no WU's at all. I'm guessing my GPU RAM is not sufficient for the 10^20 tasks. Could that be it?

Sorry, but they require at least 1600 MB RAM each (depending on your kernel size setting). I did my best to fit them into 1024 MB, but it was impossible: prime numbers table alone is ~1208 MB in size (all primes up to 14142135624 => 633521375 primes, 2 bytes per each prime number).


Next 50


©2017 Sergei Chernykh