PrimeGrid
Please visit donation page to help the project cover running costs for this month

Toggle Menu

Join PrimeGrid

Returning Participants

Community

Leader Boards

Results

Other

drummers-lowrise
11) Message boards : Problems and Help : Can't figure out why CPU isn't being used 100% (Message 147348)
Posted 21 days ago by Profile Michael GoetzProject donor
That means you shouldn't run more than 1 MEGA with 4 threads (CPUs),
or 2 MEGAs with 2 threads (CPUs) each. By doing this, your CPUs will be
close to 100% and you'll do at least twice as many MEGA tasks per day.

Since you're running other things (which use L3 too), I'd recommend 1 MEGA with 4 threads.
If you weren't running other things, 2 MEGAs with 2 threads might be slightly faster.


While this is generally good advice for most other CPU apps, I don't believe GFN supports multithreading (except for GFN-21).


He is running PPS-MEGA on the CPU.
12) Message boards : Problems and Help : Can't figure out why CPU isn't being used 100% (Message 147347)
Posted 21 days ago by Profile Michael GoetzProject donor
Each MEGA task uses 2 MB L3 cache. Since you're running 4 MEGA tasks, that's 8 MB of L3 demand.
You only have 6 MB of L3 available. You're thrashing your L3 cache. That means every MEGA
memory access has to wait for a read of RAM memory (very slow vs. L3 cache).
Your MEGA data never has a chance to be reused from L3 cache before
it's knocked out of L3 cache by another MEGA data access.

That means you shouldn't run more than 1 MEGA with 4 threads (CPUs),
or 2 MEGAs with 2 threads (CPUs) each. By doing this, your CPUs will be
close to 100% and you'll do at least twice as many MEGA tasks per day.

Since you're running other things (which use L3 too), I'd recommend 1 MEGA with 4 threads.
If you weren't running other things, 2 MEGAs with 2 threads might be slightly faster.


This is all true, but it is off-topic and doesn’t answer his question. Cache misses are too low level a concept to be reflected in the Windows Task Manager. It does not explain why he’s seeing only 50% utilization.

TThrottle and similar utilities/tools/features could cause this, however. A clue here is the very low clock speed. The device is likely overheating, and something may be idling the CPU in order to keep the temperature down.
13) Message boards : Wieferich and Wall-Sun-Sun Prime Search : WW 1.05 credits (Message 147298)
Posted 23 days ago by Profile Michael GoetzProject donor
Are you looking at this computer? that's the one I tested on?

But why WW is 25% faster on one of the two RTX 2070?
RTX 2070, driver 432.00, i7-6700K, Win10: 91M primes per second WW + Cullen (4 threads / 4 cores, L3: 8MB, HT off) RTX 2070, driver 441.08, i7-9700K, Win10: 114M primes per second WW + 2 * Cullen (2 * 4 threads / 8 cores, L3: 12MB)
The driver (I don't think so), HT on could help on the 6700, but it does not give an explanation.

There seems to be a big variation in a number of TNG's gpus - some of the 2070 supers are running even slower than the above. Is there a cooling problem resulting in downclocking?



1) Different clocks... (clocks are visible in the work unit outputs for the GFN work done on these).

2) Dual GPU systems only report the device -0 type. Some of tng's dual GPU machines have a 2070 with a 2070 super.


Well it's all very confusing.
this pc reports as a 2070 super but the tasks identify as a 2080 and yet they're running 800-1600s/task.

this one reports as a 2070 super but has tasks running as 2070s + 2080 and both running 500-700s/task.




If there's more than one GPU, and the task is paused and resumed, it may resume on a different GPU. Pretty much, all bets are off in a multi-GPU system with heterogeneous GPUs.
14) Message boards : Number crunching : Great Conjunction Challenge (Message 147215)
Posted 25 days ago by Profile Michael GoetzProject donor
A few days ago, GFN-19 was calculated with OCL3 in approx. 50 minutes (using GTX 1660 Super).
Today, GFN-19 was calculated with OCL2 and it took more than 1h 20m.
Is it going to stay like this?


Yes.

GFN-19 recently passed the OCL3 limit, and now must use OCL2 going forward. Unless you get a resend of an older GFN19, everything will be on OCL2 from now on.
15) Message boards : Wieferich and Wall-Sun-Sun Prime Search : New Version Testing (Message 147205)
Posted 25 days ago by Profile Michael GoetzProject donor
Regarding credit on WW:

If the speed of the software changes, the credit for each task does not change.

If the size of the task, meaning the number of candidates checked, is changed, then we will adjust the credit proportionally.

This is consistent with how we usually award credit.
16) Message boards : News : Change in Prime Reporting Procedure (Message 147103)
Posted 29 days ago by Profile Michael GoetzProject donor
Okay, so... Where / how do folks change the setting?

Is it not set by default to give permission, or asked during setup or something?

EDIT: Looks like it's on the Your Account page, under "Primegrid Preferences."

Mine is set to "Yes," FWIW. Don't know if by default or due to some action when setting things up originally a few years back? *Shrug*


You must set it to "Yes' AND also supply your real name. (That's a requirement of T5K's.)

17) Message boards : Generalized Fermat Prime Search : Guessing the future of GFN-22 and DYFL (Message 147095)
Posted 29 days ago by Profile Michael GoetzProject donor
Here is a tough bet: Which will happen first:

  1. GFN-22 reaches the starting point (b = 846'396.7) of DYFL, likely without finding any GFN-22 primes, and the two 22-subprojects merge
  2. Someone outside PrimeGrid, likely GIMPS, finds a new world record prime, and DYFL jumps to that new position (resulting in two "holes")

And when?

/JeppeSN



Almost certainly #2 is going to happen first. GFN22's leading edge took nearly 9 years to get to where it is now at 187K, and it's over three times as far to go to get to the start of DYFL. Additionally, it will exceed both the OCL and OCL4 limits before then, so the tasks will slow down.

GIMPS has been finding new world records every few years, so unless they hit a huge dry patch in Mersenne primes, they'll probably find a new prime decades before GFN22 ends.
18) Message boards : News : Change in Prime Reporting Procedure (Message 147088)
Posted 30 days ago by Profile Michael GoetzProject donor
Are these new prime finding users generally running older and/or slower machines that wouldn't have otherwise been likely to be first? Asking more out of curiosity than anything.


This has nothing to do with being first, or how fast your computer is. People need to, at some point, give us permission to report primes on their behalf, or to do it themselves. They have 19 days to do that -- note that this is not computations, this is a person taking some action.

With LLR2, who does PG consider the double checker? (or am I misreading that part and they all get reported as anonymous if there is no response?)


There's no double checkers when we use fast proofs. For now, that means some LLR2 projects, and in the future, Genefer.
19) Message boards : Number crunching : LLR2 installed on all big LLR projects (Message 147065)
Posted 31 days ago by Profile Michael GoetzProject donor
So do you throttle the workunits being sent to that person based on their pc having problems?


No. We put an indicator on the task so that they can see there's a problem and, if they want, fix it.
20) Message boards : Number crunching : 2021 Challenge Schedule (Message 147061)
Posted 31 days ago by Profile Michael GoetzProject donor
@dannyridel and @Skivelitis2

Please look at post: 146747

The SoB challenge is now proposed to be 10 months :)

Take care


I took that to be tongue in cheek. Proposed not tentative and no start/end times. Michael?


It's a joke.


Next 10 posts
[Return to PrimeGrid main page]
DNS Powered by DNSEXIT.COM
Copyright © 2005 - 2021 Rytis Slatkevičius (contact) and PrimeGrid community. Server load 3.73, 3.31, 3.65
Generated 26 Jan 2021 | 5:35:08 UTC