Separate names with a comma.
Discussion in 'Distributed Computing' started by Ken g6, Dec 29, 2016.
Oh and by the way, 2ch and RKN have each been producing 800 k today.
Thanks for the updates. I'll get back on this tomorrow
Day 9.15 stats:
MIXI passed us! Gotta get done with this NF@H race and get back to some other math project.
Thanks, Ken g6. I said I stick with PG, but...
Nice graphs! Thanks!
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.
Oh yes, PSP-LLR draws a serious amount of power, and constantly tries to bring those little heat spots in modern CPUs to melt.
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.
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.
Well, Day 10.06 stats aren't that bad:
We're still very close to BOINC@MIXI.
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
Let's go get them!
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.
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.
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.
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.
We passed BOINC@MIXI again even earlier than I hoped.
But the twist in the story is that Team 2ch did so too.
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...
@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.
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".
Day 11.05 stats:
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!
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.
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)
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.
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:
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.
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.
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.
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.
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?
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.