PrimeGrid Races 2018

Ken g6

Programming Moderator, Elite Member
Moderator
Dec 11, 1999
16,250
3,845
75
Current race: GFN-21 (and only 21!), December 11-21 (22:23 UTC)

Now that Christmas is over, it's time to think about the new year...of PrimeGrid races! Here's the (tentative) list of all races for this year (thanks to @StefanR5R):
Code:
    Date            Time UTC    Project    Challenge                                  Duration
----------------------------------------------------------------------------------------------
1    1-16 January   00:00:00    SoB-LLR    Happy New Year Challenge                    15 days
2   16-23 March     18:00:00    321-LLR    Year of the Dog Challenge                    7 days
3    3- 8 April     12:00:00    ESP-LLR    Mathematics Awareness Month Challenge        5 days
4   14-19 June      00:00:00    SR5-LLR    World Cup Challenge                          5 days
5   10-13 August    18:00:00    PPS-LLR    Solar Eclipse Challenge                      3 days
6   15-22 September 18:00:00    CUL-LLR    Oktoberfest Challenge                        7 days
7   24-31 October   23:59:59    WOO-LLR    Halloween Challenge                          7 days
8   17-20 November  12:00:00    AP27       Conjunction of Venus and Jupiter Challenge   3 days
9   11-21 December  22:23:00    GFN-21     Winter Solstice Challenge                   10 days

What you need:
  • One or more fast x86 processors, preferably with lots of cores. (Even slow ones might do!)
  • Windows (Vista or later 64-bit, or XP or later 32-bit), Linux, or MacOS 10.4+.
  • BOINC, attached to PrimeGrid (http://www.primegrid.com/).
  • Your PrimeGrid Preferences with only the above project(s) selected in the Projects section.

What may help LLR (the first seven races):
  • An Intel Sandy Bridge or later ("Core series" other than first-generation) processor with AVX may be 20-70% faster than with the default application. Sadly, that does not include Pentium or Celeron processors, or AMD processors.
  • In most races, usually those with longer WUs, it helps to enable multi-core processing with app_config.xml. Leave hyper-threading on if you do this!
  • Faster RAM might help on many races, as long as it's stable.
  • Turning off hyper-threading helps with shorter WUs on older processors.
What may help in other races:
  • A GPU helps in the last two races.
  • Juggling in some extra WUs may help in races where you run single-core WUs on the CPU.
  • Turning on hyper-threading may help.
  • A 64-bit OS may help.

What won't help (but won't hurt either):
  • A large amount of RAM.
  • Any Android devices.

What won't help (and will hurt, sort of):
  • Unstable processors. (Invalid work will be deducted! :eek: If Prime95 worked recently on your processor, it should be stable.)
  • Work not downloaded and uploaded within the challenge. (It's not counted.) Should you not be able to be in front of one or more computers at that time, there are several options:
    • You can often set BOINC's network connection preferences to wait until a minute or two after race time.
    • And for short work units, you can just set the queue level very low (0.01 days). This also makes it more likely that you will be a prime finder rather than a double-checker. But you might want to raise their queue size after the challenge is underway.

Welcome and good luck to all! :)

P.S. If no one has posted stats lately, try tracking your stats with my user script. With that installed, visit the current race's Team stats link for TeAm stats.
 
Last edited:

Howdy

Senior member
Nov 12, 2017
572
480
136
Well, I ran a "test" project on SoB-LLR.....came in at 23.5hrs (running only 1 using the app_config posted in the Challenge thread) Unfortunately it has come up "validation inconclusive" on my machine and another. It has since been sent again to another machine. Hopefully this doesn't come up often in this challenge, running 23.5hrs with no points for the results will really skew the challenge in a bad way.

Maybe SoB has another meaning?;)
 

Ken g6

Programming Moderator, Elite Member
Moderator
Dec 11, 1999
16,250
3,845
75
Yeah, they're big work units. And they're going to get bigger over the course of the race. You should verify your system's stability with Prime 95 and/or PPSE LLR work.
 

Howdy

Senior member
Nov 12, 2017
572
480
136
Yeah, they're big work units. And they're going to get bigger over the course of the race. You should verify your system's stability with Prime 95 and/or PPSE LLR work.

Will do, pretty much why I shy away from CPU challenges. Not much CPU HP and they take foreverrrrrrrrrr.....
 

Ken g6

Programming Moderator, Elite Member
Moderator
Dec 11, 1999
16,250
3,845
75
It might still be 2017, but the first 2018 race has started!
 
  • Like
Reactions: Orange Kid

StefanR5R

Elite Member
Dec 10, 2016
5,514
7,820
136
I can put only one dual-socket host towards this.
Will add all spare threads of my folding GPU hosts later today.
 

TennesseeTony

Elite Member
Aug 2, 2003
4,209
3,634
136
www.google.com
"Use LLR's multithreaded mode. It requires a little bit of setup, but it's worth the effort. Follow these steps:
  • Create a app_config.xml file in the directory C:\ProgramData\BOINC\projects\www.primegrid.com\ (or wherever your BOINC data directory is located). For a quad core CPU, the file should contain the following contents. Change the two occurrences of "4" to the number of actual cores your computer has.

    Code:
    <app_config>
    <app>
    <name>llrSOB</name>
    <fraction_done_exact/>
    <max_concurrent>1</max_concurrent>
    </app>
    <app_version>
    <app_name>llrSOB</app_name>
    <cmdline>-t 4</cmdline> <avg_ncpus>4</avg_ncpus>
    </app_version>
    </app_config>
  • (again, change the "4's" above to suit however many threads you wish to contribute-Tony)
  • After creating the file, click on "Options/Read config files". It's not necessary to restart BOINC or reboot.
  • The first time BOINC downloads an SoB task, it may act a little strange and download 4 tasks instead of 1. The run times on this first set of tasks may look a bit strange too. This is normal.
  • Some people have observed that when using multithreaded LLR, hyperthreading is actually beneficial. We encourage you to experiment and see what works best for you."
 
  • Like
Reactions: ao_ika_red

TennesseeTony

Elite Member
Aug 2, 2003
4,209
3,634
136
www.google.com
You are welcomed friend! Now....I just need to find (again) where linux has hidden my BOINC files.....

Oh good golly, found the folder again, but not about to mess with superuser mode right now so I can access my own F*@$$%&! files....:mad:

Sorry, what I meant to say was how much I love having converted to Linux...it's wonderful. :p
 
Last edited:

ao_ika_red

Golden Member
Aug 11, 2016
1,679
715
136
According to windows' resource monitor, I have two primegrid background process. First one is called "primegrid_llr_wrapper_8.00_windows_x86_64" that has 3 threads but 0% CPU usage. The second one is called "primegrid_cllr" that only has 1 thread but a constant 25% CPU usage.
I am running 3 threads/task right now, and I assume that it will use 75% of CPU resources, but why does it only use 25% ?
 

Ken g6

Programming Moderator, Elite Member
Moderator
Dec 11, 1999
16,250
3,845
75
According to windows' resource monitor, I have two primegrid background process. First one is called "primegrid_llr_wrapper_8.00_windows_x86_64" that has 3 threads but 0% CPU usage. The second one is called "primegrid_cllr" that only has 1 thread but a constant 25% CPU usage.
I am running 3 threads/task right now, and I assume that it will use 75% of CPU resources, but why does it only use 25% ?
Something went wrong. When initially setting up app config that can happen. Stop and restart the boinc service or reboot and it should be fixed.
 
  • Like
Reactions: ao_ika_red

ao_ika_red

Golden Member
Aug 11, 2016
1,679
715
136
Something went wrong. When initially setting up app config that can happen. Stop and restart the boinc service or reboot and it should be fixed.
Thanks Ken. It works like a charm. My cpu fan starts to purring again after rebooting boinc.
 

StefanR5R

Elite Member
Dec 10, 2016
5,514
7,820
136
Now....I just need to find (again) where linux has hidden my BOINC files.....
The default location of boinc-client's data directory on Linux Mint and many (but not all) other Linux distributions is /var/lib/boinc-client. PrimeGrid's appconfig file is then called /var/lib/boinc-client/projects/www.primegrid.com/app_config.xml.
Oh good golly, found the folder again, but not about to mess with superuser mode right now so I can access my own F*@$$%&! files...
$ gksudo xed /var/lib/boinc-client/projects/www.primegrid.com/app_config.xml
or
$ sudo nano -w /var/lib/boinc-client/projects/www.primegrid.com/app_config.xml

Or make all directories and files in /var/lib/boinc-client group-writable
$ sudo chmod -R g+w /var/lib/boinc-client
add your account to the boinc group
$ sudo usermod -a -G boinc youraccountname
and then access the boinc-client data with file manager, editor, etc. without gksudo or sudo.
(Edit: fixed incomplete copy+paste.)
(Edit, January 3: For the usermod command to take effect, you need to log in again. For the command line interface, start a new terminal, or run su - youraccountname in an existing terminal. For the desktop GUI, log out and log in again.)

<max_concurrent>1</max_concurrent>
Omit this, unless you really know you want this.**

Something went wrong. When initially setting up app config that can happen. Stop and restart the boinc service or reboot and it should be fixed.
In case of the app_config.xml changes that we are discussing here, it is sufficient to use boincmgr's menu item "Options"/ "Read config files". Tags like <max_concurrent> and <avg_cpus> will become effective immediately. The important tag <cmdline> will become effective on any task which is either started or resumed* after reading the config file.

*) This works with resumption after shutdown and restart of the client. It also works with resumption by suspend+resume of just the project or just the task if the option "Leave non-GPU tasks in memory while suspended" is off.

Edit:
I'm running no more than 22 threads per task.
With an 8-threaded task on a 4C/8T Linux machine, "top" shows only 705...720 % CPU usage (while the machine is occupied by nothing else besides the PrimeGrid task), not the ideal maximum of 800 %. With 8 11-threaded tasks on a 44C/88T Linux machine, "top" shows 900...1050 % CPU usage per LLR worker, instead of ideal 1100 %. This indicates that multithreading does not scale linearly to very high thread counts, like we already know from other LLR applications. A mixture of multithreading and multiprocessing may be the optimum on high core count hosts. However, multiprocessing does not scale linearly either, because of some contention for memory bandwidth and caches.

Edit 2:
**) If you delete lines from app_config.xml or <!-- comment --> them out, it is not sufficient to reread the config files via boincmgr's menu. You need to restart the client in order to make it forget about the removed lines. For the primary client instance on Linux Mint:
$ sudo /etc/init.d/boinc-client stop
$ sudo /etc/init.d/boinc-client start
(These two steps can be combined into sudo /etc/init.d/boinc-client restart, but it's good to know how the steps can be performed separately.)
 
Last edited:
  • Like
Reactions: ao_ika_red

Howdy

Senior member
Nov 12, 2017
572
480
136
You are welcomed friend! Now....I just need to find (again) where linux has hidden my BOINC files.....

Oh good golly, found the folder again, but not about to mess with superuser mode right now so I can access my own F*@$$%&! files....:mad:

Sorry, what I meant to say was how much I love having converted to Linux...it's wonderful. :p

I'm pretty sure if you check this THREAD that some guy started BTN of @TennesseeTony you will find your answer/s. Yes it states F@H, but there is some BOINC stuff in there too. ;)
OR just refer to @StefanR5R 's post since it's right here :)
 

StefanR5R

Elite Member
Dec 10, 2016
5,514
7,820
136
Performance measurements of llrSOB are pretty much out of the question:
  1. Even highly threaded tasks can still take much longer than a day.
  2. Task durations are highly variable on the same machine + app_config, which means one would need to measure many tasks for meaningful averages. I don't know if credits per CPU time are variable too.
  3. From what I understand, the general trend is that task durations slowly increase over time while the PrimeGrid project is progressing in the dataset, hence having several identical hosts available for comparative measurements of different app_configs in parallel is advisable.
In addition, the PrimeGrid website says they have some quicker SOB tasks due to double-checking of older results going on. This will mess up measurements even more. (At least run-time measurements, if not credit per CPU time.)

The first time BOINC downloads an SoB task, it may act a little strange and download 4 tasks instead of 1. The run times on this first set of tasks may look a bit strange too. This is normal.
This can be avoided by setting "Use at most [ 1 ] % of the CPUs" before you download llrSOB tasks. After one task was downloaded, increase the percentage. (In case of the dual-socket host on which I am running 8 tasks in parallel currently, I increased the percentage in 8 steps until I arrived at 100 %, such that only 1 llrSOB task was downloaded by the client in each step. But seeing that I won't have time for performance measurements anyway, this precaution was overkill.)
The run times on this first set of tasks may look a bit strange too.
No, every time when more than one task is downloaded at a time, their runtimes which will be reported later on the PrimeGrid website will be corrupted.
 
Last edited:

crashtech

Lifer
Jan 4, 2013
10,524
2,111
146
...With an 8-threaded task on a 4C/8T Linux machine, "top" shows only 705...720 % CPU usage (while the machine is occupied by nothing else besides the PrimeGrid task), not the ideal maximum of 800 %. With 8 11-threaded tasks on a 44C/88T Linux machine, "top" shows 900...1050 % CPU usage per LLR worker, instead of ideal 1100 %. This indicates that multithreading does not scale linearly to very high thread counts, like we already know from other LLR applications. A mixture of multithreading and multiprocessing may be the optimum on high core count hosts. However, multiprocessing does not scale linearly either, because of some contention for memory bandwidth and caches...
Is it possible to determine a sweet spot? From the numbers you present, it seems the 11 thread task may only regress slightly compared to the 8 thread task, at least when your high/low numbers are averaged.
 

crashtech

Lifer
Jan 4, 2013
10,524
2,111
146
So this app is killing my F@H performance, even when I set the number of threads to allow F@H the use of several logical cores (even though it only wants one), and increase the priority of FahCore_21 to "High." Not sure what to do, it could be that the Folding rigs will have to sit this one out.
 

StefanR5R

Elite Member
Dec 10, 2016
5,514
7,820
136
Is it possible to determine a sweet spot?
Sure: I estimate it would take to run maybe 2...4 really high-throughput computers with same hardware and different configs for about a week at least, then wait another one or two weeks for validations to complete. (The only sensible measure for comparison is PPD.) If you want to measure on slower computers, it would take respectively longer, or more computers with same hardware.
From the numbers you present, it seems the 11 thread task may only regress slightly compared to the 8 thread task, at least when your high/low numbers are averaged.
It looks like that, especially considering that the 8-thread task has got a dual-channel memory controller all for itself (Xeon E3 v3), while the 8 11-thread tasks are sharing 4 dual-channel memory controllers (2 × E5 v4, HCC die). But on the other hand, the E3 is clocked higher than the E5 (3.4 GHz : 2.6 GHz), which should be the main reason for the higher core utilization on the E5 compared with the E3.

--------

As it happens, this is the first LLR race in which I use 14 nm CPUs from Intel which are not soldered to their heatspreader, but buried under the infamous mountain of toothpaste (i7-7700K). It's a travesty how hot they run. They are in the same waterloop with two Pascal GPUs, but the latter are of course direct-die cooled, which makes them 35...40 K cooler than the Intel hot-heads.

... OK, I went into the BIOS and found an AVX clock offset option. The default "auto" setting did not apply any offset at all, making the i7 run at 4.4 GHz. I am now trying an offset of 4 (giving a clock of 4.0 GHz), which results in much better CPU temperatures. But I'll have to watch F@H PPD; don't want them to suffer from this.

--------

Will add all spare threads of my folding GPU hosts later today.
At first I occupied all available processor threads, minus the number of GPUs, with PrimeGrid llrSOB. Not entirely unexpected, F@H estimated PPD took a noticeable hit from this. On my 4C/8T CPUs with dual GPUs, I now reduced PrimeGrid to 1 task × 4 threads, and on a 22C/44T CPU with triple GPUs, I limited PrimeGrid to 2 tasks × 10 threads.

Besides the RAM bandwidth requirement of PrimeGrid LLR, the other problem on recent Intel CPUs at least is the lower turbo clock due to AVX usage, which may impact the F@H GPU feeders too depending on processor model and number of occupied physical cores. (The hit to F@H PPD is at least true with the Nvidia Fermi version of FahCore_21, which is always occupying one logical CPU for 100 %).

For good measure, I also added the following in FAHControl -> Configure -> Expert -> Extra core options -> Add:
-nice 0
Then "Save". On Linux, this results in FAHCore running at priority 30/ niceness 10, compared with primegrid_llr's priority 39, niceness 19. Windows may need a different option there but I can't test this for the time being. It may be necessary to shut down and restart FAHClient for extra core options to take effect. On Mint: sudo /etc/init.d/FAHClient restart

Reference: https://fah.stanford.edu/projects/FAHClient/wiki/ClientUserGuide#ExtraCoreOptions
Relevant options are -nice and -priority. Try -priority low or -priority normal on Windows...
So this app is killing my F@H performance, even when I set the number of threads to allow F@H the use of several logical cores (even though it only wants one), and increase the priority of FahCore_21 to "High." Not sure what to do, it could be that the Folding rigs will have to sit this one out.
...Hmm, OK, then this higher process scheduler prio will not help, or at least not much. Reducing the BOINC load is key, obviously.
 
Last edited:

crashtech

Lifer
Jan 4, 2013
10,524
2,111
146
...Hmm, OK, then this higher process scheduler prio will not help, or at least not much. Reducing the BOINC load is key, obviously.
I did check to see if an AVX offset was occurring on my 8700K, it is not. It's manually clocked at 4.6GHz at ~1.18v, and stays there at all times. Just for fun, I set the Fah task priority to "Real Time," something noobs like me are warned against, it's ineffective. This is with 8 out of 12 threads doing Primegrid. GPU usage goes from ~89% to ~72% with llrSoB running, it was even worse with 10 threads. Next I'll go down to 6, I guess. Seems a shame.

Edit: Some ongoing observations: An R9 290 running F@H is totally unaffected by llrSoB (E3 1230v5).
Ryzen seems far less affected than Coffeelake...? I'm able to run 14 threads of llrSoB on a 1700X with only a few percent GPU impact (GTX 1070).
 
Last edited:

StefanR5R

Elite Member
Dec 10, 2016
5,514
7,820
136
I did check to see if an AVX offset was occurring on my 8700K, it is not. It's manually clocked at 4.6GHz at ~1.18v, and stays there at all times.
AFAIK Kabylake and Coffeelake have AVX offsets = 0 per default, which is silly. People need to go into the BIOS and need to configure a sensible value there themselves, i.e. mess with very advanced options that they shouldn't have to mess with in the first place.

IIRC, Haswell-E/EP which introduced the AVX offset, as well as Broadwell-E/EP and Skylake-X/SP, have nonzero offsets per default (E and X) or hardwired (EP and SP).

Just for fun, I set the Fah task priority to "Real Time," something noobs like me are warned against, it's ineffective. This is with 8 out of 12 threads doing Primegrid. GPU usage goes from ~89% to ~72% with llrSoB running, it was even worse with 10 threads. Next I'll go down to 6, I guess. Seems a shame.
This all sounds like cache, or more likely RAM bandwidth, is the constraining factor. As I mentioned, for now I settled with # PG threads = # physical cores on i7, and # PG threads slightly less than # physical cores on E5-2696v4, of course with HT enabled on i7 and E5. (Edit: I specifically mean F@H hosts here. On the one host on which I run PG exclusively, I use all processor threads for PG.)
 
Last edited: