PrimeNet rejects my computer's specs

[kriesel]

@Paul:
There's a thread for remedial P-1 to make DC a little quicker. See https://mersenneforum.org/showthread.php?t=28038. Just copy/paste an available list of worktodo entries from there and post in that thread, what you took to run.

For optimal P-1 assigned by PrimeNet, to help at the first-test wavefront, work type is 4.
For a 7250 or 7210 with lots of DIMM ram, it would be interesting to see how it performs with say 4 workers, which would allow 2 workers at a time to use up to ~92GiB each for a deep stage 2 in mprime v30.8. (b17 is latest build.)
Please post how any such experimenting goes.

I may have done most if not all my Xeon Phi Bios exploration on the 7250 I got first.

[paulunderwood]

What I'd like to do is get P-1 before doing a (WR) PRP for each of 32 candidates if that is what the server doles out. At the moment my prime.txt has WorkPreference=152. Is that the right code? And local.txt contains Memory=307 during 7:30-23:30 else 307.

REM: I have 16GB MCDRAM and 192GB DDR4.

[kriesel]

Originally Posted by emilymm

the exact path is Advanced -> Chipset Configuration -> North Bridge -> Uncore Configuration.
they are the first two options in that page. it would be very strange for them to be greyed out, as this is considered a standard configuration option for these processors.

Thanks. Now I know exactly where to look, in pdf and BIOS.

`dmidecode` reports version 2.0, revision 5.12, from 12/05/2017.

Windows PowerShell reports were identical in ALL respects on 7210 and 7250. Date matches yours but rev string does not, literally. But 12= 0xC?

>Get-WmiObject win32_bios

SMBIOSBIOSVersion : 2.0
Manufacturer      : American Megatrends Inc.
Name              : BIOS Date: 12/05/17 15:20:04 Ver: 05.0000C
SerialNumber      : 0123456789
Version           : SUPERM - 1072009

i am using Gentoo, and currently it's on kernel 5.15.59, though i am about to upgrade to the latest 6.0 release.

Thx.

i have a Radeon RX Vega 56 in it right now, but i am only using it for additional monitor connections, and i intentionally do not have Mesa set up for it, so there is no 3d acceleration or OpenCL being used. the reason behind that is that i am currently using this machine as my primary workstation, and one of the projects i am working on is a software-rendered Vulkan implementation.

A normal sized GPU won't fit in my 7210 or 7250 cases. The CPU coolant lines are in the way. I had a lo profile 2GB RX550 on the 7210 for a while but relocated it. That GPU became a bit temperamental. My phis are temperamental enough on their own.

i would presume that was the issue, yes (it's now working)

Did George change something, or you?

[kriesel]

Originally Posted by paulunderwood

What I'd like to do is get P-1 before doing a (WR) PRP for each of 32 candidates if that is what the server doles out. At the moment my prime.txt has WorkPreference=152. Is that the right code? And local.txt contains Memory=307 during 7:30-23:30 else 307.

REM: I have 16GB MCDRAM and 192GB DDR4.

I think then you just set up max allowed memory day and night to something large, stick with maxhighmemworkers=1 default, and your workers that need P-1 before PRP will gradually get staggered in time. Workers that can't get high memory allocations will do something else until lots of ram becomes available for their turn at P-1 stage 2, assuming stage 1 finds no factors.

152 looks about right to me. I don't think advance P-1 is keeping up with demand. If you want to ensure you are always running P-1, set one or two workers to type 4. https://www.mersenneforum.org/showthread.php?t=23992 is my PrimeNet API reference info thread which has a more current work types list than http://v5.mersenne.org/v5design/v5webAPI_0.97.html

Please look at the curves for % net gain versus allowed P-1 stage 2 memory on v30.8b14/15/etc in the second attachment of https://www.mersenneforum.org/showpo...0&postcount=15, and note allowed ram there is units of GiB, while local.txt is in units of MiB.

307 as MB of memory allowed by your local.txt entry looks terribly low to me. That low limit is about default as mprime installs, and almost disables wavefront P-1 stage 2. It guarantees your large-ram system will generate primality tests lacking adequate P-1 bounds, costing at least 2.5% of feasible throughput (~3.5%+?). (Mersenne numbers factored efficiently quickly don't need a much longer primality test. You would be missing factors that could be found, so more of your assignments would be primality tested instead of eliminated more quickly by finding a factor.) For your system, set MUCH higher. Allowing even 4-12 GB is not very effective. It can probably do better set to somewhere in 32GiB-180GiB. I'm not sure how the NUMA aspects are configured in your Linux install and BIOS setup or will play out in mprime. Experiment.

My i5-1035G1 16 GiB busy Windows laptop typing this, has in local text,

Memory=8192 during 7:30-23:30 else 8192

(8GiB allowed out of 16; Firefox is memory hungry with lots of tabs open.)
A 64 GiB same-model laptop has 2 workers, set to varying amounts, now gathering data for the 100Mdigit curves in the second attachment referenced above. When done with that it will probably do full time WR P-1 set to ~58-60 GiB. The net gain is logarithmic with amount of ram allowed.

[chalsall]

Originally Posted by kriesel

I think then you just set up max allowed memory day and night to something large.

Please forgive me for this.. But experimentation can be useful.

Ken... Do you have any reference material that might help guide those who are currently confused?

My apologies in advance for being annoying.

Those who know me in "meat space" barely tollerate me. And that's in "real time"...

[paulunderwood]

Originally Posted by kriesel

I think then you just set up max allowed memory day and night to something large, stick with maxhighmemworkers=1 default, and your workers that need P-1 before PRP will gradually get staggered in time. Workers that can't get high memory allocations will do something else until lots of ram becomes available for their turn at P-1 stage 2, assuming stage 1 finds no factors.

152 looks about right to me. I don't think advance P-1 is keeping up with demand. If you want to ensure you are always running P-1, set one or two workers to type 4. https://www.mersenneforum.org/showthread.php?t=23992 is my PrimeNet API reference info thread which has a more current work types list than http://v5.mersenne.org/v5design/v5webAPI_0.97.html

Please look at the curves for % net gain versus allowed P-1 stage 2 memory on v30.8b14/15/etc in the second attachment of https://www.mersenneforum.org/showpo...0&postcount=15, and note allowed ram there is units of GiB, while local.txt is in units of MiB.

307 as MB of memory allowed by your local.txt entry looks terribly low to me. That low limit is about default as mprime installs, and almost disables wavefront P-1 stage 2. It guarantees your large-ram system will generate primality tests lacking adequate P-1 bounds, costing at least 2.5% of feasible throughput (~3.5%+?). (Mersenne numbers factored efficiently quickly don't need a much longer primality test. You would be missing factors that could be found, so more of your assignments would be primality tested instead of eliminated more quickly by finding a factor.) For your system, set MUCH higher. Allowing even 4-12 GB is not very effective. It can probably do better set to somewhere in 32GiB-180GiB. I'm not sure how the NUMA aspects are configured in your Linux install and BIOS setup or will play out in mprime. Experiment.

My i5-1035G1 16 GiB busy Windows laptop typing this, has in local text,

Memory=8192 during 7:30-23:30 else 8192

(8GiB allowed out of 16; Firefox is memory hungry with lots of tabs open.)
A 64 GiB same-model laptop has 2 workers, set to varying amounts, now gathering data for the 100Mdigit curves in the second attachment referenced above. When done with that it will probably do full time WR P-1 set to ~58-60 GiB. The net gain is logarithmic with amount of ram allowed.

Thanks, Ken. I have set "Memory=" to 32768. Hopefully my 32 worker computer will cope with a lot of wavefront P-1 if such work is assigned to it. It should do 6 P-1 work units simultaneously. Hopefully, assignment times will be staggered anyway and that there will be a mixture of P-1 and non-P-1 work units. It seems mprime handles well at runtime whatever PrimeNet throws at it.

[kriesel]

Originally Posted by paulunderwood

Thanks, Ken. I have set "Memory=" to 32768. Hopefully my 32 worker computer will cope with a lot of wavefront P-1 if such work is assigned to it. It should do 6 P-1 work units simultaneously. Hopefully, assignment times will be staggered anyway and that there will be a mixture of P-1 and non-P-1 work units. It seems mprime handles well at runtime whatever PrimeNet throws at it.

MaxHighMemoryWorkers=?
You might get away with 4 or 5 in that configuration above.

If running 32 workers in one program instance, the global "Memory=" should probably be set higher, and the per-worker sections set to ~48 GiB or maybe more individually. (Few will be running stage 2 at any given time.)

If explicitly dealing with NUMA, for performance, as in a test dual-Xeon system I have, with two prime95 instances each using half of system ram, the global "Memory=" per instance would be sysram *~0.9 / #NUMAnodes. I'm running only P-1, and 2 workers per instance, and the workers alternate on stage 2 so get the full per-instance allowed ram. 128GiB ram * 0.9 / 2 = 57.6GiB -> global "Memory=58982" or thereabouts, probably a little higher is usable and efficient.

It's not a problem if MaxHighMemoryWorkers * local Memory value > global Memory value. The last high memory worker will get somewhat less, and the following will wait until more memory becomes available, doing some other work instead while waiting for more memory. (Another stage 1, or some PRP iterations.)

from undoc.txt:

The Memory=n setting in local.txt refers to the total amount of memory the
program can use.  You can also put this in the [Worker #n] section to place
a maximum amount of memory that one particular worker can use.

You can set MaxHighMemWorkers=n in local.txt.  This tells the program how
many workers are allowed to use lots of memory.  This occurs doing stage 2
of P-1, P+1, or ECM.  Default is 1.

You can set a threshold for what is considered lots of memory in MaxHighMemWorkers
calculations.  In local.txt, set:
    HighMemThreshold=n        (default is 250)
The value n is in MB.

Please share any P-1 performance results you find on this large-ram system. Have fun!

[paulunderwood]

I have set "MaxHighMemoryWorkers" to 6 for now. I will most likely reduce this and bump up the "Memory" setting for the batch after next.

Yes, let's have some fun and find the next prime.