PrimeGrid Races 2017

[StefanR5R]

Oh and by the way, 2ch and RKN have each been producing 800 k today.

 

[Orange Kid]

Thanks for the updates. I'll get back on this tomorrow

 

[Ken g6]

Day 9.15 stats:

Rank___Credits____Username
9______4543160____xii5ku
136____356365___10esseeTony
171____281372_____Ken_g6
234____152271_____Orange Kid
266____114464_____zzuupp
285____100133_____SlangNRox
295____94000______GLeeM

Rank__Credits____Team
5_____9986582____Crunching@EVGA
6_____8737547____BOINC@Poland
7_____5646102____BOINC@MIXI
8_____5641768____TeAm AnandTech
9_____5332419____Rechenkraft.net
10____5281230____Team 2ch
11____4784465____US Navy

MIXI passed us! Gotta get done with this NF@H race and get back to some other math project.

 

[StefanR5R]

Thanks, Ken g6. I said I stick with PG, but...

Spoiler: graphs

 

[petrusbroder]

Nice graphs! Thanks!

 

[StefanR5R]

Everything rebooted with HT off, and back on the more predictable sort of math race.

Edit: I suspect tomorrow's stats will look bleak. Ken g6's new i7 to the rescue!

 

[Ken g6]

Everything rebooted with HT off, and back on the more predictable sort of math race.

Edit: I suspect tomorrow's stats will look bleak. Ken g6's new i7 to the rescue!

I was having trouble with my new i7 for awhile. It kept throttling when running PrimeGrid. But I finally found a way to keep it at 3.3GHz, and it's stable that way. I'll look into a new cooler later.

 

[StefanR5R]

Oh yes, PSP-LLR draws a serious amount of power, and constantly tries to bring those little heat spots in modern CPUs to melt.

 

[TennesseeTony]

Remember, NO OVERCLOCKING, don't even allow the MotherBoard to use "performance" setting in BIOS if it has such a setting. It has to be COMPLETELY stock speeds, or AVX will draw as much power as your motherboard can provide. In my case 300 watts for the poor 5820K, for days on end before I noticed the temp.

 

[StefanR5R]

It's a good thing that Broadwell-E and Kaby Lake have a negative AVX clock offset. That way you can dial in suitable clocks for normal workload and for AVX workloads separately. I like that a lot on my Broadwell-E.

 

[Ken g6]

I suspect tomorrow's stats will look bleak.

Well, Day 10.06 stats aren't that bad:

Rank___Credits____Username
9______4949487____xii5ku
114____472053___10esseeTony
174____297869_____Ken_g6
253____152271_____Orange Kid
266____129555_____zzuupp
287____115305_____SlangNRox
319____94000______GLeeM

Rank__Credits____Team
5_____11112626___Crunching@EVGA
6_____9679627____BOINC@Poland
7_____6284515____BOINC@MIXI
8_____6210544____TeAm AnandTech
9_____6006601____Team 2ch
10____5766824____Rechenkraft.net
11____5550994____US Navy

We're still very close to BOINC@MIXI.

 

[StefanR5R]

I think I had bugs in my daily production graph. Maybe this one is more correct, maybe not.

Spoiler: per-user production

Today's production still shows effects of the Formula sprint, as expected.

Spoiler: teams at ranks 7 - 10

We're still very close to BOINC@MIXI.

Let's go get them!

 

[StefanR5R]

Anybody else still not tired of math races and wants to join?

• Add "PrimeGrid" in boincmgr.
• At www.primegrid.com, "Your account", join Team AnandTech of course.
• Still at "Your account", go to PrimeGrid preferences, click "Edit PrimeGrid preferences". There, enable the "Prime Sierpinski Problem LLR (PSP)" CPU application, and disable all other applications for the duration of this challenge.

Haswell and newer perform well in LLR. PSP-LLR tasks are very long; they can easily take 2 days or so. Some tips on running fewer but faster tasks on multiple cores are further up this thread. General info on the challenge is in Ken g6's post at the beginning of the thread of course.

Edit:
Caveat though is that LLR is not the best "paying" type of PrimeGrid CPU applications, credit-wise. And the GPU applications give a lot more credit anyway, but are not included in this and the next few PrimeGrid challenges.

 

[TennesseeTony]

.....Haswell and newer perform well in LLR....

Decided to run three quad-threaded tasks on each of my 2nd gen i7 Xeon boxes....and 6 hours they were at less than 5% each. Nah, no thanks. So I'm only in with the 4 modern Xeons in my sig.

 

[StefanR5R]

I had a few tasks on the 4.5 GHz Ivy Bridge-E. The reports in the task list are confusing, but it seems the tasks that I ran dual-threaded needed 20 hours, and a quad-threaded one 10 hours. No guarantee though; these reported times have deceived me before.

 

[StefanR5R]

We passed BOINC@MIXI again even earlier than I hoped.
But the twist in the story is that Team 2ch did so too.

 

[crashtech]

I have a Haswell and Skylake quad, both with AMD GPUs, entered into PrimeGrid production. I haven't had time to research app_config files or which GPUs do best, but I hope I can contribute something in time to make a difference.

Both the 280x and the R9 Fury seem well saturated with just 1 task each...

 

[StefanR5R]

@crashtech, only results from the "Prime Sierpinski Problem LLR (PSP)" subproject, which is a CPU application, are counted in this challenge.

@Ken g6, post #1 says GCW sieve currently, you could edit this.

Edit:
At this point in the challenge, there is no time anymore to find an app_config.xml with best throughput for a given processor. But don't worry, throughput does probably not differ very much between N*M processes * threads and M*N processes * threads.
Perhaps 1 or 2 days before the end of the challenge on Saturday, April 22 12:00 UTC, it may simply be best to configure for running 1 job at a time, and the job having as many threads as there are physical cores (on a single-socket machine). Unless you want to do a lot of hand-holding with "task juggling".

 

[Ken g6]

@Ken g6, post #1 says GCW sieve currently, you could edit this.

Done. Thanks.

Day 11.05 stats:

Rank___Credits____Username
9______5636688____xii5ku
74_____869784___10esseeTony
164____378290_____Ken_g6
235____195895_____Orange Kid
260____161049_____zzuupp
307____115305_____SlangNRox
332____94000______GLeeM
540____15035______markfw

Rank__Credits____Team
4_____28781540___Sicituradastra.
5_____12775482___Crunching@EVGA
6_____10627812___BOINC@Poland
7_____7466048____TeAm AnandTech
8_____6923620____BOINC@MIXI
9_____6861677____Team 2ch
10____6371754____Rechenkraft.net

Looks like we're in a good spot, but unlikely to catch Poland.

@Markfw, one done already?! On Ryzen? I think you're rewriting the rules of PrimeGrid as we speak!

 

[Markfw]

6 hours 35 minutes on 1800x@3850, second one going.

And Tony, I saw your post on overclocking and AVX. I have it overclocked to 3850, and its running 60c, same as before.

 

[crashtech]

Dumb question here guys, if I can't disable HT, will setting the process affinity for even numbered cores help at all? (app_config has number of real cores)

 

[StefanR5R]

6 hours 35 minutes on 1800x@3850, second one going.
[...]
And Tony, I saw your post on overclocking and AVX. I have it overclocked to 3850, and its running 60c, same as before.

Absolutely impressive. I didn't expect that at all from what I knew about the LLR applications and what I had read about the Zen microarchitecture and its Ryzen implementation.

Dumb question here guys, if I can't disable HT, will setting the process affinity for even numbered cores help at all? (app_config has number of real cores)

I have seen at least Windows 7 automatically spread the worker threads over all physical cores. Or at least that's how I interpreted task manager's utilization timeline. The power profile ("balanced" or "performance") may have an impact on this too, but I don't recall for sure which one I had set at the time. But I see you have Windows 10, so that's different again.

 

[crashtech]

I have seen at least Windows 7 automatically spread the worker threads over all physical cores. Or at least that's how I interpreted task manager's utilization timeline. The power profile ("balanced" or "performance") may have an impact on this too, but I don't recall for sure which one I had set at the time. But I see you have Windows 10, so that's different again.

It's hard to tell, but it looks as if using an app_config like this for my dual hexacore (HT on) system:

<app_config>
   <app>
      <name>llrPSP</name>
      <max_concurrent>1</max_concurrent>
      <fraction_done_exact/>
    </app>
   <app_version>
       <app_name>llrPSP</app_name>
       <cmdline>-t 12</cmdline>
       <avg_ncpus>12</avg_ncpus>
       <max_ncpus>12</max_ncpus>
   </app_version>
</app_config>

And then setting the process affinity for even numbered cores seems to be helping. But I'm not sure because there isn't really time to experiment...

BTW, the machine is being remote controlled and I can't physically get a monitor on it to disable HT, hence my desire for a workaround.

Edit: I guess what I'll need to check next is if affinity will need to be set each time a WU gets finished and another begins, or if the main process just stays open.

 

[StefanR5R]

It's hard to tell, but it looks as if using an app_config like this for my dual hexacore (HT on) system:

So far I have shied away from spreading task across two sockets. On the other hand, the fairly good scaling that I saw with increasing thread count (on Linux, mind) indicates that there is little inter-thread communication going on. Still, there is the potential issue of non-uniform memory access.

And then setting the process affinity for even numbered cores seems to be helping. But I'm not sure because there isn't really time to experiment...

True. I began testing a week before the race, and hadn't really finished testing even halfway through the race. And that was merely testing on the two E5 boxes, not even with the smaller ones.

I guess what I'll need to check next is if affinity will need to be set each time a WU gets finished and another begins, or if the main process just stays open.

Each WU gets a new process of its own. Even if you suspend a task, the worker process will be shut down and a new process be started when you resume the task, if the option "Leave non-GPU tasks in memory while suspended" is off. At least that's what I have seen.

 

[crashtech]

So far I have shied away from spreading task across two sockets. On the other hand, the fairly good scaling that I saw with increasing thread count (on Linux, mind) indicates that there is little inter-thread communication going on. Still, there is the potential issue of non-uniform memory access.

I guess if that happens I will be able to see a computation error in the log, and be able to presume that this was the reason, since the machine is at stock clocks. Are you saying that the safest way might be to run 2 concurrent tasks with 6 cores each?

Each WU gets a new process of its own. Even if you suspend a task, the worker process will be shut down and a new process be started when you resume the task, if the option "Leave non-GPU tasks in memory while suspended" is off. At least that's what I have seen.

Ah, so I will need to keep an eye out and set them manually each time, then, if I think it's doing any good.

Thanks for the advice!

Edit: So far, these old Westmeres are estimated to finish one PSP work unit in around 9 hours, will revise when they are farther in. Probably not the best use of their time, but I though it would be nice to help.