[QUOTE=Prime95;529599]Is this option only for one-worker mprime runs?[/QUOTE]

My personal use case has two Worker threads (each with approximately same amount of work). So, the instance would quit if _all_ of the workers are empty.

I suppose, the feature is applicable only if:
a) UsePrimenet = 0 (this is the kaggle/colab) OR
b) UsePrimenet = 1 and NoMoreWork = 1 (and worktodo.add is not there/empty??) (regular GIMPS, but we want to stop work, and quit the instance as well).

[QUOTE=axn;529602]My personal use case has two Worker threads (each with approximately same amount of work).[/QUOTE]

Ah, I now understand George's question.

In the Colab / Kaggle Notebook instances, if a GPU is attached the CPU available is only a single core (HT enabled). Kaggle offers two CPU cores (again HT enabled) when running CPU only.

So, only one worker.

Edit: Oh, and it would be fine if mprime reported back to Primenet before exiting. In my use-case I'll proxy it if needed.

This would also be nice for automated benchmarking.

Exit when out of work: Please try build 29.8 build 7. I did not test this, let me know if it works or could be improved upon. New feature is described in undoc.txt.

[QUOTE=Prime95;529656]New feature is described in undoc.txt.[/QUOTE]

Sweet! Thanks, George!

It will be a couple of days before I can test this myself.

[QUOTE=Prime95;529656]Exit when out of work: Please try build 29.8 build 7. I did not test this, let me know if it works or could be improved upon. New feature is described in undoc.txt.[/QUOTE]

Will the source for this release be posted somewhere?

[QUOTE=mathwiz;529658]Will the source for this release be posted somewhere?[/QUOTE]

If the feature works and someone needs the source. Do you need it?

[QUOTE=Prime95;529656]Exit when out of work: Please try build 29.8 build 7. I did not test this, let me know if it works or could be improved upon. New feature is described in undoc.txt.[/QUOTE]

Link?

[URL]https://mersenne.org/ftp_root/gimps/p95v298b7.linux64.tar.gz[/URL]

[QUOTE=Prime95;529672][URL]https://mersenne.org/ftp_root/gimps/p95v298b7.linux64.tar.gz[/URL][/QUOTE]

Thanks. But I don't seem to be able to find the relevant section in undoc.txt (or readme or whatsnew for that matter). What keyword should I search for?

maybe I screwed up building the package

[CODE]LINUX/FREEBSD ONLY: When mprime runs out of work to do, it normally loops waiting for the
server to assign more work. This prime.txt option can be used to have mprime exit
when all workers runs out of work. Note this probably only makes sense when UsePrimenet=0
or when UsePrimenet=1 and NoMoreWork=1.
ExitWhenOutOfWork=n
where n is the number of seconds to wait before exiting. Waiting several seconds
gives mprime some time to send the last results to the server.

[/CODE]

[QUOTE=Prime95;529677][CODE]ExitWhenOutOfWork=n[/CODE][/QUOTE]
Thank you. I'll try it out today and let you know how it goes.

[QUOTE=axn;529679]Thank you. I'll try it out today and let you know how it goes.[/QUOTE]

It works as expected (at least for my use case)!

Mac command-line version
 

I run the command-line version of Prime95 on my Mac because I find it easier than a GUI. I noticed that the latest command-line version is 28.7, while the Mac GUI is 29.8b6, as is the Linux command-line version. Will an updated Mac command-line version be released?

Expected completion dates for P-1 of type P-1=1,300000000,242166,1,20000,200000 is totally messed up. Prime predicts that for every candidate needs around 24 days on worker with 2 cores: in real candidate is processed in less then 15 minutes

[QUOTE=pepi37;530626]Expected completion dates for P-1 of type P-1=1,300000000,242166,1,20000,200000 is totally messed up. Prime predicts that for every candidate needs around 24 days on worker with 2 cores: in real candidate is processed in less then 15 minutes[/QUOTE]Such low bounds will not clear the P-1 task from the database unless a factor is found by the P-1 run. Perhaps the duration being calculated is for the full sufficient bounds. I have another 5 weeks to go on a 6-core run of an M901M that's showing 34% complete in stage 1. [URL]https://www.mersenneforum.org/showpost.php?p=503892&postcount=3[/URL]

[QUOTE=Theodore;530523]I run the command-line version of Prime95 on my Mac because I find it easier than a GUI. I noticed that the latest command-line version is 28.7, while the Mac GUI is 29.8b6, as is the Linux command-line version. Will an updated Mac command-line version be released?[/QUOTE]

Try this: [url]https://www.dropbox.com/s/fdra82vuuj2woa2/mprime?dl=0[/url]
It is the executable only. The Clang tool chain forced a dependency on OS 10.9.

When running mprime 29.8 build 6, if I choose torture test, blend, then answer Y to customize settings, when choosing the Max FFT size it won't accept anything above 4096. Attempting to do so results in a message "Please enter a value between 64 and 4096".

EDIT: If it matters, this is the 32-bit version.

[QUOTE=PhilF;530717]When running mprime 29.8 build 6, if I choose torture test, blend, then answer Y to customize settings, when choosing the Max FFT size it won't accept anything above 4096. Attempting to do so results in a message "Please enter a value between 64 and 4096".

EDIT: If it matters, this is the 32-bit version.[/QUOTE]

It might matter. Does your machine support SSE2? If not, there are no FFTs larger than 4M available.

Yes, it does support SSE2. It is a Q8400S (Yorkfield).

Even if it didn't there's a problem, because the default answer is 8192. But unless you simply accept the default, it won't accept 8192.

[QUOTE=PhilF;530722]Yes, it does support SSE2. It is a Q8400S (Yorkfield).[/QUOTE]

Weird. Tried it here and I get a default of 32768.

Does the output (especially feature set) look right in Options/CPU?

[QUOTE=Prime95;530701]Try this: [URL]https://www.dropbox.com/s/fdra82vuuj2woa2/mprime?dl=0[/URL]
It is the executable only. The Clang tool chain forced a dependency on OS 10.9.[/QUOTE]


Thanks for responding.



I couldn't get the executable to work. But since there is a good reason why the command-line tool won't be updated, I might as well change to the GUI.

[QUOTE=Theodore;530738]
I couldn't get the executable to work.[/QUOTE]

I did test it - it can work.

Perhaps mprime cannot find the HWLOC library on your machine. HWLOC library is included in the GUI version - try copying it to the folder containing the new mprime. If you can get it to work there is no reason not to use it (other than I don't update it frequently).

[QUOTE=Prime95;530729]Weird. Tried it here and I get a default of 32768.

Does the output (especially feature set) look right in Options/CPU?[/QUOTE]

Yes, as far as I can tell:

[code]CPU Information:
Intel(R) Core(TM)2 Quad CPU Q8400 @ 2.66Ghz
CPU speed: 2666.61 Mhz, 4 cores
CPU features: Prefetch, SSE, SSE2, SSE4
L1 cache size: 3x32 KB, L2 cache size: 2x2 MB[/code]

I tried 64-bit mprime running on 64-bit linux. The default is still 8192, but now I am allowed to enter any number between 4 and 32768 for the Max FFT size.

[STRIKE]The problem seems to be only when running 32-bit linux, because if I run 32-bit mprime on 64-bit linux, the program behaves as expected.[/STRIKE]

The CPU information shown above is the same for both 32-bit and 64-bit linux.

EDIT: I can't get 32-bit mprime to run under 64-bit linux, so scratch that info.

[QUOTE][Nov 17 00:38:01] Setting affinity to run helper thread 1 on CPU core #3
[Nov 17 00:38:01] Setting affinity to run helper thread 2 on CPU core #4
[Nov 17 00:38:01][COLOR=Magenta][B] Error setting affinity to cpuset 0x00000008: No error[/B][/COLOR][/QUOTE]


What this mean?

[QUOTE=Prime95;530752]I did test it - it can work.

Perhaps mprime cannot find the HWLOC library on your machine. HWLOC library is included in the GUI version - try copying it to the folder containing the new mprime. If you can get it to work there is no reason not to use it (other than I don't update it frequently).[/QUOTE]




What steps did you follow to activate the executable? Normally "./mprime" activates it, but not this time. Is there some setup I should do first?

Mac OS Catalina 10.15.1
 

V298b6 does not appear to open and run on Mac OS 10.15.1.

[QUOTE=Theodore;530804]What steps did you follow to activate the executable? Normally "./mprime" activates it, but not this time. Is there some setup I should do first?[/QUOTE]

Do you need to do a [c]chmod u+x mprime[/c]? Or change the execution permission for mprime on your Mac?

[QUOTE=Jet1945;531135]V298b6 does not appear to open and run on Mac OS 10.15.1.[/QUOTE]

Was it running previously and you upgraded the OS? Or is this a fresh install on 10.15?

If a fresh install can you try moving the hwloc dynamic link library to /usr/local/lib

[QUOTE=paulunderwood;531185]Do you need to do a [c]chmod u+x mprime[/c]? Or change the execution permission for mprime on your Mac?[/QUOTE]


I got it to work. Thanks!

[QUOTE=Prime95;531193]Was it running previously and you upgraded the OS? Or is this a fresh install on 10.15?

If a fresh install can you try moving the hwloc dynamic link library to /usr/local/lib[/QUOTE]

First time user and I just followed the install instructions as listed. When launched, I got a dialog box that said it could not open the program. Nothing I have tried has seemed to affect the ability to get the program to run.

I have no idea / knowledge on what you mean by moving a dynamic link.

Mac OS 10.15.1 on a 2017 iMac Retina

[QUOTE=Jet1945;531289]First time user and I just followed the install instructions as listed. When launched, I got a dialog box that said it could not open the program. Nothing I have tried has seemed to affect the ability to get the program to run.

I have no idea / knowledge on what you mean by moving a dynamic link.

Mac OS 10.15.1 on a 2017 iMac Retina[/QUOTE]

Does the program have execution permissions? Some systems unzip executables to be non-executable. Look into the permissions of the program.

On linux based systems you can do [c]chmod u+x mprime[/c] when in in mprime's directory.

[QUOTE=paulunderwood;531290]Does the program have execution permissions? Some systems unzip executables to be non-executable. Look into the permissions of the program.[/QUOTE]

I understand the question but as a Mac user, I have no knowledge of where or how to affect the permissions of a program. That is not something I have ever done in 10 years on a Mac.

[QUOTE=paulunderwood;531290]On linux based systems you can do chmod u+x mprime when in in mprime's directory.[/QUOTE]

I know the the Mac OS has at the kernel level a passing acquaintance with Linux and that the command you mentioned can be used with the Terminal program. However, that is a detailed level of familiarity that I do not have with the Mac. For me the mprime's directory would be the folder labeled p95v298b6-2 which is where the program Prime95 and the accompanying text files reside.

[QUOTE=Jet1945;531291]I understand the question but as a Mac user, I have no knowledge of where or how to affect the permissions of a program. That is not something I have ever done in 10 years on a Mac.[/QUOTE]

See the edit to my previous post.

Please see the section on [c]chmod[/c] [URL="http://www.macinstruct.com/node/415"]here[/URL]. You must be in the right directory to use it properly!

[c]chmod[/c] is Unix speak for change mode. When in mprime's directory you can run [c]chmod 755 mprime[/c]. There is a explanation on what "755" means in the link. Afterwards run [c]ls -l[/c] -- Unix speak for list file in long format -- and you should see rwxrw-rw- where r=read, w=write and x=execute -- the groupings are you, your gtoup and everyone. So only you can execute the program. If you are paranoid about things you can use "744" or even "700"

[QUOTE=Jet1945;531291]I understand the question but as a Mac user, I have no knowledge of where or how to affect the permissions of a program. That is not something I have ever done in 10 years on a Mac.[/QUOTE]

Please try [url]http://mersenne.org/ftp_root/gimps/p95v298b4.MacOSX.zip[/url]
This zip file has the libgmp dynamic link library located in a different place in the heirarchy - I'm curious if that makes a difference.

BTW, sorry for the troubles and thanks for helping me figure this out.

[QUOTE=paulunderwood;531293]See the edit to my previous post.

Please see the section on [c]chmod[/c] [URL="http://www.macinstruct.com/node/415"]here[/URL][/QUOTE]

I did respond to your edit. I also checked the Get Info on the program and I (as user) have all the permissions to read and write for the program.

The balance with chmod is a level that I am not comfortable doing. Without being snarky at all, if the is the level of difficulty necessary to get a program to run on a Mac - it probably isn't something that I ought to be doing.

Thanks for your help.

[QUOTE=paulunderwood;531293]Please try [url]http://mersenne.org/ftp_root/gimps/p95v298b4.MacOSX.zip[/url]
This zip file has the libgmp dynamic link library located in a different place in the heirarchy - I'm curious if that makes a difference.[/QUOTE]

I dl'd the file and saw the library file included in the package. I installed the lib file (double clicking) and the launched the Prime95 and got the same dialog box "The application Prime95 could not be opened." Not sure what to try next.

[QUOTE=Jet1945;531295]I did respond to your edit. I also checked the Get Info on the program and I (as user) have all the permissions to read and write for the program.

The balance with chmod is a level that I am not comfortable doing. Without being snarky at all, if the is the level of difficulty necessary to get a program to run on a Mac - it probably isn't something that I ought to be doing.

Thanks for your help.[/QUOTE]

I have never used a Mac. Do they still have only one mouse button? :wink:

[QUOTE=paulunderwood;531296]I have never used a Mac. Do they still have only one mouse button? :wink:[/QUOTE]

Naaah!! We have gone to the 21st century - its a Magic Mouse - press on the left side for the normal stuff and the right side for the old CTL-click things you used to have to do.

Modern technology is amazing .... sorta .... when it works .... not like now

@George, FWIW, when I unzipped the Mac version here on Debian, Prime95 does not have execution permission.

[QUOTE=Jet1945;531295]
I dl'd the file and saw the library file included in the package. I installed the lib file (double clicking) and the launched the Prime95 and got the same dialog box "The application Prime95 could not be opened." Not sure what to try next.[/QUOTE]

I'll be away for 2 days. When I get back, I'll borrow my wife's Mac and see if I can install prime95.

[QUOTE=Prime95;531302]I'll be away for 2 days. When I get back, I'll borrow my wife's Mac and see if I can install prime95.[/QUOTE]Time for Ben to find his first prime.

[QUOTE=Uncwilly;531303]Time for Ben to find his first prime.[/QUOTE]

I suspect the next biggest prime number is found by curtisc and the following one from Ben Delo.

[QUOTE=Prime95;529677]maybe I screwed up building the package

[CODE]LINUX/FREEBSD ONLY: When mprime runs out of work to do, it normally loops waiting for the
server to assign more work. This prime.txt option can be used to have mprime exit
when all workers runs out of work. Note this probably only makes sense when UsePrimenet=0
or when UsePrimenet=1 and NoMoreWork=1.
ExitWhenOutOfWork=n
where n is the number of seconds to wait before exiting. Waiting several seconds
gives mprime some time to send the last results to the server.

[/CODE][/QUOTE]

I tried this on a Colab session, running ECM Stage 1 curves, but the program did not exit. It just sat there waiting. The line added to prime.txt is:

ExitWhenOutOfWork=15

UsePrimenet is set to 0, NoMoreWork is set to 1, and GmpEcmHook is set to 1.

[QUOTE=Prime95;531302]I'll be away for 2 days. When I get back, I'll borrow my wife's Mac and see if I can install prime95.[/QUOTE]

I have confirmed that prime95 will not run on Catalina -- thanks Apple! The error message is most uninformative.


I cannot upgrade my Mac to Catalina. Catalina eliminates support for 32-bit apps. The editor I use is 32-bits. VNC program I use is 32-bits. Several games I run occasionally are 32-bits.


So, aside from guessing at possible causes and fixes, debugging seems to be impossible. I'll think on possible ways forward from here. Not too optimistic.

[QUOTE=Prime95;531490]I have confirmed that prime95 will not run on Catalina -- thanks Apple! The error message is most uninformative.


I cannot upgrade my Mac to Catalina. Catalina eliminates support for 32-bit apps. The editor I use is 32-bits. VNC program I use is 32-bits. Several games I run occasionally are 32-bits.


So, aside from guessing at possible causes and fixes, debugging seems to be impossible. I'll think on possible ways forward from here. Not too optimistic.[/QUOTE]

I appreciate you validating the problem / difficulty. While I am not sure precisely what I might be able to do - if you think of something - just ask.

Mac OS 10.15.1 Catalina

[QUOTE=Jet1945;531627]I appreciate you validating the problem / difficulty. While I am not sure precisely what I might be able to do - if you think of something - just ask.

Mac OS 10.15.1 Catalina[/QUOTE]

Try this: [URL]https://mersenne.org/ftp_root/gimps/p95v298b7.MacOSX.zip[/URL]

I downloaded the latest xcode. It would not build prime95 until I created a valid code signing certificate. I'd try it on the wife's MacBook except she's using it now.

[QUOTE=Prime95;531655]Try this: [URL]https://mersenne.org/ftp_root/gimps/p95v298b7.MacOSX.zip[/URL]

I downloaded the latest xcode. It would not build prime95 until I created a valid code signing certificate. I'd try it on the wife's MacBook except she's using it now.[/QUOTE]

I'm getting the HTML Error 404 about page / file not found.

[QUOTE=Jet1945;532036]I'm getting the HTML Error 404 about page / file not found.[/QUOTE]It's not just you.

Zip file build error. Try this: [URL]https://mersenne.org/ftp_root/gimps/p95v298b7.MacOSX.zip.zip[/URL]

[QUOTE=Prime95;532056]Zip file build error. Try this: [URL]https://mersenne.org/ftp_root/gimps/p95v298b7.MacOSX.zip.zip[/URL][/QUOTE]

Unfortunately, still get the dialog box with the statement that "Prime95" can't be opened when I launch the app.

Using Catalina 10.15.1 Bummer

Can you upgrade routine for calculating expected competition dates: I now run candidates they are finished in 40 minutes, and Prime95 predict 55 minutes. Can somehow Prime95 after few finished times, update that table or recalculate finishing time?

@George, @Prime95

One difficulty I'm having in my new cluster is managing ECM, P-1 restore files.

Is there a tool that reads all the backup/restore files in a directory and prints their status (e.g. PM1 complete to B1=<X>, B2=<Y> ...)?

If I write a small patch to add a new command (or cli flag) for this would you being willing to consider pulling it in a future release?

Thanks.

[QUOTE=SethTro;533196]@George, @Prime95

One difficulty I'm having in my new cluster is managing ECM, P-1 restore files.

Is there a tool that reads all the backup/restore files in a directory and prints their status (e.g. PM1 complete to B1=<X>, B2=<Y> ...)?

If I write a small patch to add a new command (or cli flag) for this would you being willing to consider pulling it in a future release?

Thanks.[/QUOTE]

There is no such tool. Yes, I'd be willing to add useful code.

[QUOTE=Prime95;531490]I have confirmed that prime95 will not run on Catalina -- thanks Apple! The error message is most uninformative.
[/QUOTE]

[quote] Zip file build error. Try this: [url]https://mersenne.org/ftp_root/gimps/...MacOSX.zip.zip[/url]
[/quote]

Yes, the issue is the executable is not marked as such. After unzipping, in the Terminal, go to the folder where Prime95 resides and do
chmod a+x ./Prime95.app/Contents/MacOS/Prime95

That should fix it.

Remember you have to right-click+Open once, since the app is not signed.

Prime95 ver 29.8 not running on HighSierra?
 

Hi,
I'm new, sorry if this question is answered elsewhere: I have serched.
Prime95 is failing to run on my HighSiera.
I've never had this error msg: "The application “Prime95.app” can’t be opened."

I can run the command line version, and I seem to be doing the GIMP calls.

But Prime95 on the GUI doesn't seem to run.

Is there an archive of earlier versions?

I have downloaded the source code, and will have a "bash" (soon, bad pun) at compiling it.
I suspect this is my own fault, but I'm not sure how to address it.

I want to use Prime95 to benchmark my system.
As well as work towards the GIMP goals, but I don't need the GUI for that.

Thanks for any help.
Alan

[QUOTE=WarthogARJ;534199]
Prime95 is failing to run on my HighSiera.
I've never had this error msg: "The application “Prime95.app” can’t be opened."

I can run the command line version, and I seem to be doing the GIMP calls.

But Prime95 on the GUI doesn't seem to run.

Is there an archive of earlier versions?[/QUOTE]

Go to [url]ftp://mersenne.org/gimps[/url] You should be able to find a previous version that works.

Bugs report: PrimeNet and prime95 handling of PRPDC PrimeNet assignments is robustly broken
 

Please fix all 9 identified issues.

System condor, dual Xeon X5650, Windows 7, prime95 v29.8b6 PrimeNet connected, set to do [B]PRPDC[/B] on all four 3-core workers

worktodo.txt:
[Worker #1]
[B]PRPDC[/B]=(aid redacted),1,2,81912167,-1,75,0,3,1
(worktodo entry is correct)

prime95 status output:
[Worker thread #1]
M81912167,[B]PRP[/B],Sat Feb 08 15:20 2020
(prime95 status output is incorrect, 1)

prime.log on the client:
[Mon Jan 06 23:30:08 2020 - ver 29.8]
Getting assignment from server
PrimeNet success code with additional info:
Server assigned [B]PRP[/B] work.
Got assignment (aid): [B]PRP[/B] M81912167
(prime95 logging is incorrect twice, 2 & 3)

Prime95 worker window title says [B]PRP[/B] not PRP DC
(prime95 window title is inaccurate, 4)

[URL]https://www.mersenne.org/report_exponent/?exp_lo=81912167&full=1[/URL]
claims it was assigned to me as a first test [B]PRP[/B], not "PRPDC", although [B]there is already a first test PRP result reported by another user on 2018-11-05[/B]
(PrimeNet exponent status lookup is incorrect and inconsistent, 5)

[URL]https://www.mersenne.org/workload/[/URL] claims 819121677 is a first test [B]PRP, Cat 0[/B], expiring in [B]23[/B] days, with 25 days left to go.
It's actually a [B]PRP DC, Cat 4[/B], which should have up to [B]360[/B] days allowed for ETA before expiration.
(workload listing is incorrect 3 ways, 6, 7, 8)

Double checking such a large exponent should be, and should be indicated as, a cat 4 exponent allowed up to 360 days to complete: [URL]https://www.mersenne.org/thresholds/[/URL]
(likely outcome of mistreating a cat 4 PRPDC as a cat 0 PRP is incorrect [B]too-early expiration of the assignment[/B], 9)

As a workaround to avoid early expiration, I've reconfigured this instance from 4 workers to 2 workers to reduce latency, and manually edited the worktodo to queue up the falsely-claimed cat0 PRPs on this system (81912167 PRPDC and 81889037 PRPDC) as first assignment in each remaining worker. See also [URL]https://www.mersenne.org/report_exponent/?exp_lo=81889037&full=1[/URL], which was earlier reported as showing this problem also. See [URL]https://www.mersenneforum.org/showthread.php?t=25066[/URL] and an additional report linked there made months earlier.

Please fix the client software and server software to correctly handle PRPDC in the general case. Soon would be good. This system's prime95 will be doing nothing other than PRPDC for a while. To produce meaningful PRP error rate statistics, such as patrik graphs annually, GIMPS needs many many more than the ~1584 PRPDC results it has so far at p>75M. [URL="https://www.mersenneforum.org/showthread.php?t=10377&highlight=error+rate&page=10"]https://www.mersenneforum.org/showthread.php?t=10377&page=10[/URL]

(end)

Why is prime95 benchmarking the same set every 21 hours for a week?
 

What is the point of automatically doing apparently identical benchmark runs more than daily? Here are just the last two iterations, of a series of 9 so far, that began early Jan 2, of apparently identical sets of benchmarks at precisely 21 hour intervals of an otherwise uninterrupted prime95 run:[CODE][Wed Jan 08 14:27:54 2020]
FFTlen=4480K, Type=3, Arch=3, Pass1=896, Pass2=5120, clm=4 (12 cores, 4 workers): 33.22, 37.66, 32.66, 38.88 ms. Throughput: 112.99 iter/sec.
FFTlen=4480K, Type=3, Arch=2, Pass1=896, Pass2=5120, clm=4 (12 cores, 4 workers): 33.79, 33.60, 32.80, 32.71 ms. Throughput: 120.42 iter/sec.
FFTlen=4480K, Type=2, Arch=3, Pass1=896, Pass2=5120, clm=4 (12 cores, 4 workers): 35.83, 35.65, 34.26, 34.29 ms. Throughput: 114.31 iter/sec.
FFTlen=4480K, Type=2, Arch=2, Pass1=896, Pass2=5120, clm=4 (12 cores, 4 workers): 34.12, 33.42, 32.94, 32.93 ms. Throughput: 119.96 iter/sec.
FFTlen=4608K, Type=3, Arch=3, Pass1=512, Pass2=9216, clm=4 (12 cores, 4 workers): 43.83, 43.42, 43.93, 43.28 ms. Throughput: 91.72 iter/sec.
FFTlen=4608K, Type=3, Arch=3, Pass1=1024, Pass2=4608, clm=4 (12 cores, 4 workers): 36.05, 35.96, 34.52, 35.02 ms. Throughput: 113.07 iter/sec.
FFTlen=4608K, Type=3, Arch=2, Pass1=1024, Pass2=4608, clm=4 (12 cores, 4 workers): 38.58, 34.46, 33.22, 33.52 ms. Throughput: 114.87 iter/sec.
FFTlen=4608K, Type=2, Arch=3, Pass1=512, Pass2=9216, clm=4 (12 cores, 4 workers): 45.09, 44.84, 44.87, 44.28 ms. Throughput: 89.35 iter/sec.
FFTlen=4608K, Type=2, Arch=3, Pass1=1024, Pass2=4608, clm=4 (12 cores, 4 workers): 37.74, 37.16, 36.28, 36.29 ms. Throughput: 108.53 iter/sec.
FFTlen=4608K, Type=2, Arch=2, Pass1=1024, Pass2=4608, clm=4 (12 cores, 4 workers): 36.37, 36.40, 35.16, 34.62 ms. Throughput: 112.30 iter/sec.

[Thu Jan 09 11:27:53 2020]
FFTlen=4480K, Type=3, Arch=3, Pass1=896, Pass2=5120, clm=4 (12 cores, 4 workers): 33.05, 32.13, 32.17, 31.75 ms. Throughput: 123.96 iter/sec.
FFTlen=4480K, Type=3, Arch=2, Pass1=896, Pass2=5120, clm=4 (12 cores, 4 workers): 32.18, 33.16, 33.08, 31.60 ms. Throughput: 123.11 iter/sec.
FFTlen=4480K, Type=2, Arch=3, Pass1=896, Pass2=5120, clm=4 (12 cores, 4 workers): 35.99, 35.23, 33.44, 33.77 ms. Throughput: 115.68 iter/sec.
FFTlen=4480K, Type=2, Arch=2, Pass1=896, Pass2=5120, clm=4 (12 cores, 4 workers): 33.51, 34.05, 33.47, 31.96 ms. Throughput: 120.38 iter/sec.
FFTlen=4608K, Type=3, Arch=3, Pass1=512, Pass2=9216, clm=4 (12 cores, 4 workers): 44.14, 43.69, 43.60, 43.43 ms. Throughput: 91.50 iter/sec.
FFTlen=4608K, Type=3, Arch=3, Pass1=1024, Pass2=4608, clm=4 (12 cores, 4 workers): 35.81, 35.69, 35.26, 34.72 ms. Throughput: 113.11 iter/sec.
FFTlen=4608K, Type=3, Arch=2, Pass1=1024, Pass2=4608, clm=4 (12 cores, 4 workers): 37.18, 36.03, 33.16, 33.34 ms. Throughput: 114.80 iter/sec.
FFTlen=4608K, Type=2, Arch=3, Pass1=512, Pass2=9216, clm=4 (12 cores, 4 workers): 44.47, 43.93, 44.37, 44.08 ms. Throughput: 90.47 iter/sec.
FFTlen=4608K, Type=2, Arch=3, Pass1=1024, Pass2=4608, clm=4 (12 cores, 4 workers): 40.35, 40.15, 41.60, 39.78 ms. Throughput: 98.87 iter/sec.
FFTlen=4608K, Type=2, Arch=2, Pass1=1024, Pass2=4608, clm=4 (12 cores, 4 workers): 34.76, 34.09, 34.79, 34.51 ms. Throughput: 115.82 iter/sec.
[/CODE]

Prime95 looks ahead in your worktodo.txt file to see what FFT sizes you will soon be running. It then does 10 automatic benchmarks 21 hours apart. Ten benchmarks are done so that the worst timings can be thrown out in case other programs happen to be running during the benchmark.

There are two INI settings you can tweak:

autobench_days_of_work = (double) IniGetInt (INI_FILE, "AutoBenchDaysOfWork", 7);
autobench_num_benchmarks = IniGetInt (INI_FILE, "AutoBenchNumBenchmarks", 10);

[QUOTE=Prime95;534693]Prime95 looks ahead in your worktodo.txt file to see what FFT sizes you will soon be running. It then does 10 automatic benchmarks 21 hours apart. Ten benchmarks are done so that the worst timings can be thrown out in case other programs happen to be running during the benchmark.

There are two INI settings you can tweak:

autobench_days_of_work = (double) IniGetInt (INI_FILE, "AutoBenchDaysOfWork", 7);
autobench_num_benchmarks = IniGetInt (INI_FILE, "AutoBenchNumBenchmarks", 10);[/QUOTE]Thanks for the reply on benchmarking frequency.
Hmm, looks like candidates for not_even_undoc.txt. (Not in readme, whatsnew, or undoc)

Would that be something like this in prime.txt?

AutoBenchDaysOfWork=3
AutoBenchNumBenchmarks=5

[QUOTE=kriesel;534704]T
Would that be something like this in prime.txt?

AutoBenchDaysOfWork=3
AutoBenchNumBenchmarks=5[/QUOTE]

Yes. That peeks ahead 3 days in worktodo and runs 5 benchmarks of each FFT size.

[QUOTE=Prime95;534712]Yes. That peeks ahead 3 days in worktodo and runs 5 benchmarks of each FFT size.[/QUOTE]Thanks for the confirmation.
What are the prospects for addressing the concerns listed in [URL]https://www.mersenneforum.org/showpost.php?p=534689&postcount=445?[/URL]

I just noticed that if some assignments are added via [i]worktodo.add[/i] they're pulled into [i]worktodo.txt[/i] (after a short time) but it does not trigger the code that checks for, and fetches if necessary, assignment IDs for the new work. If I quit Prime95 and restart it then it correctly notices the new work does not have AID (nor N/A) and gets assignments from PrimeNet. Should it not do this immediately upon sucking in new work via [i]worktodo.add[/i] ?

[QUOTE=James Heinrich;534777] Should it not do this immediately upon sucking in new work via [i]worktodo.add[/i] ?[/QUOTE]

I've changed this for the next build -- whenever that is.

[QUOTE=kriesel;534689]Please fix all 9 identified issues.

System condor, dual Xeon X5650, Windows 7, prime95 v29.8b6 PrimeNet connected, set to do [B]PRPDC[/B] on all four 3-core workers

worktodo.txt:
[Worker #1]
[B]PRPDC[/B]=(aid redacted),1,2,81912167,-1,75,0,3,1
(worktodo entry is correct)

prime95 status output:
[Worker thread #1]
M81912167,[B]PRP[/B],Sat Feb 08 15:20 2020
(prime95 status output is incorrect, 1)

prime.log on the client:
[Mon Jan 06 23:30:08 2020 - ver 29.8]
Getting assignment from server
PrimeNet success code with additional info:
Server assigned [B]PRP[/B] work.
Got assignment (aid): [B]PRP[/B] M81912167
(prime95 logging is incorrect twice, 2 & 3)

Prime95 worker window title says [B]PRP[/B] not PRP DC
(prime95 window title is inaccurate, 4)

[URL]https://www.mersenne.org/report_exponent/?exp_lo=81912167&full=1[/URL]
claims it was assigned to me as a first test [B]PRP[/B], not "PRPDC", although [B]there is already a first test PRP result reported by another user on 2018-11-05[/B]
(PrimeNet exponent status lookup is incorrect and inconsistent, 5)

[URL]https://www.mersenne.org/workload/[/URL] claims 819121677 is a first test [B]PRP, Cat 0[/B], expiring in [B]23[/B] days, with 25 days left to go.
It's actually a [B]PRP DC, Cat 4[/B], which should have up to [B]360[/B] days allowed for ETA before expiration.
(workload listing is incorrect 3 ways, 6, 7, 8)

Double checking such a large exponent should be, and should be indicated as, a cat 4 exponent allowed up to 360 days to complete: [URL]https://www.mersenne.org/thresholds/[/URL]
(likely outcome of mistreating a cat 4 PRPDC as a cat 0 PRP is incorrect [B]too-early expiration of the assignment[/B], 9)

As a workaround to avoid early expiration, I've reconfigured this instance from 4 workers to 2 workers to reduce latency, and manually edited the worktodo to queue up the falsely-claimed cat0 PRPs on this system (81912167 PRPDC and 81889037 PRPDC) as first assignment in each remaining worker. See also [URL]https://www.mersenne.org/report_exponent/?exp_lo=81889037&full=1[/URL], which was earlier reported as showing this problem also. See [URL]https://www.mersenneforum.org/showthread.php?t=25066[/URL] and an additional report linked there made months earlier.

Please fix the client software and server software to correctly handle PRPDC in the general case. Soon would be good. This system's prime95 will be doing nothing other than PRPDC for a while. To produce meaningful PRP error rate statistics, such as patrik graphs annually, GIMPS needs many many more than the ~1584 PRPDC results it has so far at p>75M. [URL="https://www.mersenneforum.org/showthread.php?t=10377&highlight=error+rate&page=10"]https://www.mersenneforum.org/showthread.php?t=10377&page=10[/URL]

(end)[/QUOTE]

#1,#3 fixed next build
#2 fixed on server
#4 wont be fixed

#5 on require server web page work. James or Aaron might work on it as time permits.

[QUOTE=S485122;523925]Trying to run the win64 version I get the following error message : "prime95,exe - Application error / The application was unable to start correctly (0xc000007b). Click OK to close the application." It seems the file libhwloc-15.dll is the culprit : using the version from 29.8b3 does not give the problem. (Could it be that the dll is the 32 bits version ? it is smaller than the version shipped with 29.8b3...)

Then a cosmetic correction is also needed : in the Windows 64 version, the File Version and the Product version are stuck at 28.8.1.0 and 29.8.0.0.

Jacob[/QUOTE]


[B]SAME ISSUE![/B]
Same attachment.
CPU: Ryzen 1600@2600
MSI B450 Tomahawk Max
16GB@3200 RAM

I stumbled upon some code I'm confused by.

in ecm.c

[CODE]
/* When E >= 2, we can do prime pairing and each loop iteration */
/* handles the range m-D to m+D. When E = 1, each iteration handles */
/* the range m-D to m. */
...
bitclr (pm1data.bitarray, bitcvt (m - i, &pm1data));
if (pm1data.E >= 2)
bitclr (pm1data.bitarray, bitcvt (m + i, &pm1data));
...
[/CODE]

but when it comes times to print status

[CODE]
if (pm1data.E <= 2)
sprintf (buf+strlen(buf), ", B2=%.0f", (double) C);
else
sprintf (buf+strlen(buf), ", B2=%.0f, E=%lu", (double) C, pm1data.E);
...
if (pm1data.E > 2) sprintf (JSONbuf+strlen(JSONbuf), ", \"brent-suyama\":%lu", pm1data.E);
[/CODE]

When pm1data.E = 2 shouldn't E=2 be printed?

Related I see some results in [URL="https://www.mersenne.ca/brent-suyama.php?s=e&o=a"]"Mersenne numbers with P-1 factors found via Brent-Suyama extension"[/URL] don't list e, is it possible this is why?

There is no reason ever to run with E=1. E=2 is always cheaper than E=1. And E=2 doesn't count as B-S extension, since it doesn't introduce any new primes in stage 2.

[QUOTE=zzzzzzzzzz;535114][B]SAME ISSUE![/B]
Same attachment.
CPU: Ryzen 1600@2600
MSI B450 Tomahawk Max
16GB@3200 RAM[/QUOTE]George has addressed the problem the same day in August 2019 :[QUOTE=Prime95;523962]My bad, included the 32-bit hwloc-15.dll.

I repaired and uploaded the win64 zip file[/QUOTE]The current downloads do not have the problem.
Go to "official" download page [url=https://www.mersenne.org/download/]https://www.mersenne.org/download/[/url] (you can also download the program directly from one of the mirrors [url=ftp://mersenne.org/gimps/]ftp://mersenne.org/gimps/[/url], mersenne.org, [url=https://mersenneforum.org/gimps/]https://mersenneforum.org/gimps/[/url] or [url=https://download.mersenne.ca/gimps]https://download.mersenne.ca/gimps[/url]).

Jacob

[QUOTE=Prime95;533197]There is no such tool. Yes, I'd be willing to add useful code.[/QUOTE]

[URL="https://github.com/sethtroisi/prime95/pull/1/files"]I got the code finished[/URL]. I'll still need to cleanup some of the comments and match the style of other code in prime95.

Using this worktodo.txt stopped at the points indicated
[CODE]
[Worker #1]
#Pminus1=N/A,1,2,13007,-1,20000000,0
# Stopped at ~7% stage 1 (stage 0, squaring small primes)

#Pminus1=N/A,1,2,12011,-1,20000000,0
# Stopped at ~71% stage 1

#Pminus1=N/A,1,2,13009,-1,30000,300000000
# Stopped at ~9% stage 2

#Pminus1=N/A,1,2,13217,-1,200000,0
# Finished stage 1, stage 2

#ECM2=1,2,13033,-1,1000000,0,7
# Stopped at ~33% stage 1

#ECM2=1,2,13037,-1,10000,100000000,7
# Stopped at ~27% stage 2 (curve 2)

#PRP=1,2,500009,-1
# Stopped at ~3.3%

#TEST=500029,40,1
# Stopped at ~9%

#PRP=4847,2,3321063,1
# Seventeen or bust like number stopped at ~10.8%

#PRP=6,10,71299,7
# Near Repunit prime stopped at 89%
[/CODE]

I generated this status/backup/restore status


[CODE]
Status of files in 'testing'.
Backup e0013033 | ECM | Curve 1 | Stage 1 (33.2%).
Backup e0013033.bu | ECM | Curve 1 | Stage 1 (33.2%).
Backup e0013037 | ECM | Curve 2 | Stage 2 (27.9%).
Backup e0013037.bu | ECM | Curve 2 | Stage 2 (27.9%).
Backup m0012011 | P-1 | Stage 1 (71.9%) B1 @ 14376553.
Backup m0012011.bu | P-1 | Stage 1 (71.9%) B1 @ 14376553.
Backup m0013007 | P-1 | Stage 1 (8.4%) B1 <2436719.
Backup m0013007.bu | P-1 | Stage 1 (8.4%) B1 <2436719.
Backup m0013009 | P-1 | B1=30000 complete, Stage 2 (9.9%).
Backup m0013009.bu | P-1 | B1=30000 complete, Stage 2 (9.9%).
Backup m0013217 | P-1 | B1=200000,B2=20000000,E=12 complete.
Backup m0013217.bu | P-1 | B1=200000,B2=20000000,E=12 complete.
Backup p0500009 | PRP | Iteration 16631/500009 [3.33%].
Backup p0500009.bu | PRP | Iteration 16631/500009 [3.33%].
Backup p0500029 | LL | Iteration 45144/500029 [9.03%].
Backup p0500029.bu | LL | Iteration 45144/500029 [9.03%].
Backup p4847_3321063 | PRP | Iteration 360034/3321063 [10.84%].
Backup p4847_3321063.bu | PRP | Iteration 360034/3321063 [10.84%].
Backup p6_71299_7 | PRP | Iteration 212862/71299 [89.87%].
Backup p6_71299_7.bu | PRP | Iteration 212862/71299 [89.87%].
[/CODE]

Does is look useful? Is there additional status that I could print (error count, file modified date...)

P-1 Save Files Incompatible...Stage 1 only
 

I Upgraded 4 CPUs from 29.4 to 29.8.
All had at least 1 core running P-1 Stage 1 at the time of the upgrade.

1 of the 4 got the following error on each core running stage 1:
[CODE][Jan 16 13:35] Worker starting
[Jan 16 13:35] Setting affinity to run worker on CPU core #1
[Jan 16 13:35] P-1 on M41872769 with B1=750000, B2=15000000
[Jan 16 13:35] Chance of finding a factor is an estimated 3.52%
[Jan 16 13:35] Using AVX FFT length 2304K, Pass1=384, Pass2=6K, clm=1
[Jan 16 13:35] P-1 save file incompatible with this program version. Restarting stage 1 from the beginning.
[Jan 16 13:35] Error reading intermediate file: m8G72769
[Jan 16 13:35] Renaming m8G72769 to m8G72769.bad1
[Jan 16 13:35] All intermediate files bad. Temporarily abandoning work unit.
[Jan 16 13:35] P-1 on M41870533 with B1=750000, B2=15000000
[Jan 16 13:35] Chance of finding a factor is an estimated 3.52%
[Jan 16 13:35] Using AVX FFT length 2304K, Pass1=384, Pass2=6K, clm=1[/CODE]

It was an i5-3570.
However there was a second identical CPU that did NOT get this error.
Both were previously on v29.4.5.0. Created 11/11/2017 7:38PM

Thanks

[QUOTE=SethTro;535206]
Does is look useful? Is there additional status that I could print (error count, file modified date...)[/QUOTE]

What does the public think? Tweak it until you're happy and I'll look at the code when I get back from vacation -- could be April though. In SFO airport right now.

[QUOTE=petrw1;535263]

It was an i5-3570.
However there was a second identical CPU that did NOT get this error.
Both were previously on v29.4.5.0. Created 11/11/2017 7:38PM

[/QUOTE]

There was a warning buried in this thread or maybe the whatsnew.txt file or both that P-1 stage 1 save files changed.

Hmmm, whatsnew has it listed as an issue upgrading *to* 29.4. The relevant code was added April 1, 2018.

[QUOTE=Prime95;535286]There was a warning buried in this thread or maybe the whatsnew.txt file or both that P-1 stage 1 save files changed.

Hmmm, whatsnew has it listed as an issue upgrading *to* 29.4. The relevant code was added April 1, 2018.[/QUOTE]


As I posted sometime on this forum: got similar error on PRP tasks where both worker have same exponent .

Sucess, and an observation about Plist
 

[QUOTE=Prime95;534225]Go to [url]ftp://mersenne.org/gimps[/url] You should be able to find a previous version that works.[/QUOTE]

Great stuff: that worked to run chmod.
Perhaps others will have this issue, seems a good idea to add it to the Instructions or FAQ.

Another issue is that I noticed in the MacOSx plist that the OSx version in DTSDKName jumps from 10.9 to 10.14 in Version 296b1.

And yet I'm running 10.13.6, and seem to be able to run the newest versions.

Which is the best version for High Sierra 10.3.6 to run?

Anyways, thanks for the help.
Alan

too-long iteration times, cured eventually by manual stop all workers/restart all workers
 

Dual Xeon E5-2670, Windows 7 X64, prime95 V29.8b6, 4 workers, all showed tslower than normal iteration timing, to varying degrees. One example shown following. All 4 exponents are 258M<p<383M. Speed ratios ranged from1.22 to 2.30.[CODE][Jan 15 10:26] Waiting 15 seconds to stagger worker starts.
[Jan 15 10:27] Worker starting
[Jan 15 10:27] Setting affinity to run worker on CPU core #13
[Jan 15 10:27] Setting affinity to run helper thread 1 on CPU core #14
[Jan 15 10:27] Setting affinity to run helper thread 2 on CPU core #15
[Jan 15 10:27] Setting affinity to run helper thread 3 on CPU core #16
[Jan 15 10:27] Resuming Gerbicz error-checking PRP test of M315690521 using AVX FFT length 17920K, Pass1=896, Pass2=20K, clm=2, 4 threads
[Jan 15 10:27] Iteration: 124666805 / 315690521 [39.49%].
[Jan 15 10:31] Iteration: 124670000 / 315690521 [39.49%], ms/iter: 85.981, ETA: 190d 02:14
[Jan 15 10:50] Iteration: 124680000 / 315690521 [39.49%], ms/iter: 112.920, ETA: 249d 15:20
[Jan 15 11:10] Iteration: 124690000 / 315690521 [39.49%], ms/iter: 117.746, ETA: 260d 07:06
...
[Jan 27 00:51] Iteration: 132970000 / 315690521 [42.12%], ms/iter: 120.968, ETA: 255d 19:49
[Jan 27 01:11] Iteration: 132980000 / 315690521 [42.12%], ms/iter: 120.476, ETA: 254d 18:30
[Jan 27 01:32] Iteration: 132990000 / 315690521 [42.12%], ms/iter: 120.248, ETA: 254d 06:37
[Jan 27 01:52] Iteration: 133000000 / 315690521 [42.12%], ms/iter: 121.018, ETA: 255d 21:21
[Jan 27 01:53] Gerbicz error check passed at iteration 133000000.
[Jan 27 02:14] Iteration: 133010000 / 315690521 [42.13%], ms/iter: 116.939, ETA: 247d 06:00
[Jan 27 02:34] Iteration: 133020000 / 315690521 [42.13%], ms/iter: 120.483, ETA: 254d 17:31
[Jan 27 02:54] Iteration: 133030000 / 315690521 [42.13%], ms/iter: 121.195, ETA: 256d 05:17
[Jan 27 03:14] Iteration: 133040000 / 315690521 [42.14%], ms/iter: 120.390, ETA: 254d 12:09
[Jan 27 03:35] Iteration: 133050000 / 315690521 [42.14%], ms/iter: 120.685, ETA: 255d 02:44
[Jan 27 03:55] Iteration: 133060000 / 315690521 [42.14%], ms/iter: 120.953, ETA: 255d 16:02
[Jan 27 04:15] Iteration: 133070000 / 315690521 [42.15%], ms/iter: 120.515, ETA: 254d 17:29
[Jan 27 04:36] Iteration: 133080000 / 315690521 [42.15%], ms/iter: 120.331, ETA: 254d 07:47
[Jan 27 04:56] Iteration: 133090000 / 315690521 [42.15%], ms/iter: 120.725, ETA: 255d 03:27
[Jan 27 05:16] Iteration: 133100000 / 315690521 [42.16%], ms/iter: 120.079, ETA: 253d 18:20
[Jan 27 05:36] Iteration: 133110000 / 315690521 [42.16%], ms/iter: 119.458, ETA: 252d 10:30
[Jan 27 05:54] Stopping PRP test of M315690521 at iteration 133118583 [42.16%]
[Jan 27 05:54] Worker stopped.
[Jan 27 05:54] Waiting 15 seconds to stagger worker starts.
[Jan 27 05:54] Worker starting
[Jan 27 05:54] Setting affinity to run worker on CPU core #13
[Jan 27 05:54] Setting affinity to run helper thread 1 on CPU core #14
[Jan 27 05:54] Setting affinity to run helper thread 2 on CPU core #15
[Jan 27 05:54] Setting affinity to run helper thread 3 on CPU core #16
[Jan 27 05:54] Resuming Gerbicz error-checking PRP test of M315690521 using AVX FFT length 17920K, Pass1=896, Pass2=20K, clm=2, 4 threads
[Jan 27 05:54] Iteration: 133118584 / 315690521 [42.16%].
[Jan 27 05:55] Iteration: 133120000 / 315690521 [42.16%], ms/iter: 52.086, ETA: 110d 01:29
[Jan 27 06:04] Iteration: 133130000 / 315690521 [42.17%], ms/iter: 52.412, ETA: 110d 17:52
[Jan 27 06:13] Iteration: 133140000 / 315690521 [42.17%], ms/iter: 52.550, ETA: 111d 00:42
[Jan 27 06:22] Iteration: 133150000 / 315690521 [42.17%], ms/iter: 52.169, ETA: 110d 05:14
[Jan 27 06:30] Iteration: 133160000 / 315690521 [42.18%], ms/iter: 52.202, ETA: 110d 06:47

[/CODE]

Brokien mouse scrolling.
 

I have set roll wheel one notch to 3 lines, but prime95 does not use these values.

I'm getting the following error (see image) when I run ECM2 on M332XXXXXX. I just ran ECM2 successfully on a much smaller Mersenne.
//EDIT: I don't see the attachment. Here is the screen output:
Opyinizig for CPU architecture: Core i3/it/i7, L2 cache size: 2x256 KB, L3 cache sizw: 3 MB
ECM on M332XXXXXX, curve #1 with s=[digits], B1=50000, B2=5000000.

I think it's attached here

[QUOTE=JuanTutors;537349]I'm getting the following error (see image) when I run ECM2 on M332XXXXXX.[/QUOTE]There is [B][U]no good reason[/U][/B] to run ECM on this exponent. If you are trying to find a factor of it, you are wasting your time now. It is at 81 bits (unless you have a great GPU, don't do any more TF.) You have done P-1 on it. ECM is a waste on this exponent.

[QUOTE=Uncwilly;537352]There is [B][U]no good reason[/U][/B] to run ECM on this exponent. If you are trying to find a factor of it, you are wasting your time now. It is at 81 bits (unless you have a great GPU, don't do any more TF.) You have done P-1 on it. ECM is a waste on this exponent.[/QUOTE]
I know. I have a laptop that is on for very few hours per year, so I set it to do some factoring on a 100M digit Mersenne on which I am doing PRP on another computer on the tiny off chance I find a factor and save time. I just posted here in case the error is a bug.

[QUOTE=JuanTutors;537356]I know. I have a laptop that is on for very few hours per year, so I set it to do some factoring on a 100M digit Mersenne on which I am doing PRP on another computer on the tiny off chance I find a factor and save time. I just posted here in case the error is a bug.[/QUOTE]

Watch the temperature. Laptops do not have the best cooling schemes. I have one Using [I]Prime95[/I], running anything other than small ECM's, it gets really warm. I use the "Throttle=x" setting in [I]prime.txt [/I]to control it. Example: Throttle=85 means run 85% and rest 15%. It helps. [I]Prime95[/I] really works a CPU.

Undocumented feature to lock GUID?
 

I seem to remember this being discussed somewhere, but after twenty minutes of flaying around, I can't find it...

Is there a way (with a line in prime.txt or local.txt) to have mprime use the "ComputerGUID=" line as provided in local.txt without changing it (based on changed hardware)?

[QUOTE=chalsall;538048]I seem to remember this being discussed somewhere, but after twenty minutes of flaying around, I can't find it...

Is there a way (with a line in prime.txt or local.txt) to have mprime use the "ComputerGUID=" line as provided in local.txt without changing it (based on changed hardware)?[/QUOTE]

[url]https://www.mersenneforum.org/showthread.php?p=530390&highlight=FixedHardwareUID#post530390[/url]
[url]https://www.mersenneforum.org/showthread.php?p=506064&highlight=ComputerGUID#post506064[/url]
[url]https://www.mersenneforum.org/showthread.php?p=506747&highlight=ComputerGUID#post506747[/url]

[QUOTE=Uncwilly;538052]Links...[/QUOTE]

Thanks!

Hi,

It's been suggested to me that I share here my experience running Prime95 (v29.8 build 6) on an AMD Threadripper 3970X.

The post is quite long so instead of copy/pasting it here, let me give a link to Level1Techs forum where you will find all the details:

[url]https://forum.level1techs.com/t/amd-threadripper-3970x-under-heavy-avx2-load-defective-by-design[/url]

The conversation is also happening over at Hacker News, with some informative posts:

[url]https://news.ycombinator.com/item?id=22382946[/url]

Hopefully you don't mind linking...

Thanks for the great work on Prime95: Over the past weeks I've been peeking at the code (being a C/C++ developer myself, but in the field of rendering) and I'm quite in awe at the level of optimization of this program.

Hi there and welcome to the forum.
The "instant" part in your fail report, together with the fact that 8k AVX2 passes, points a lot towards a software bug. I am sure George didn't have a system with so many cores at hand when he wrote the benchmarks.

Hopefully he sees the thread soon, or you can PM him on this forum (user Prime95) and point him to the thread. He is generally a busy person, but it will take the time to look into it as soon as possible.

[QUOTE=LaurV;538142]The "instant" part in your fail report, together with the fact that 8k AVX2 passes, points a lot towards a software bug.[/QUOTE]
Doubtful, but that's just my personal opinion.

I also doubt it.

We are currently investigating together with AMD what's really going on. The current thinking is that this may be an issue with how the VRMs (part of the power delivery network on the motherboard) are programmed to react to low-to-high and high-to-low load transitions. We will keep you posted here.

That said, speaking for myself, I would love to hear from George on this topic that he surely knows a lot about.

[QUOTE=franz;538174]
That said, speaking for myself, I would love to hear from George on this topic that he surely knows a lot about.[/QUOTE]

I know less than you think.

While I'm not saying it is impossible for this to be a prime95 bug, each torture test worker is running the same code. That the 16K FFT works on Intel chips, when fewer workers are running, and on some Zen systems, strongly indicates the problem is not in prime95.

Prime95 on my first Haswell systems had a similar problem. The voltage changes were not handled well causing a crash. I worked around the issue by disabling "C states" so that the chip didn't try to drop the voltage nearly as much.

It is puzzling that the crash only happens with the 16K FFT, but I think the AMD engineers are better placed in figuring out why.

Thanks for chiming in George.

Indeed, Prime95 with 16K FFTs passes even on my 3970X if I use fewer worker threads:
it fails instantly with 64, after a second with 62, after a few seconds with 58, and it's stable for at least 15 minutes with only 32, for instance.

Interesting to hear about C-states. Not sure it's a realistic option on the 3970X since the TDP is so high that one will certainly want to save some electricity at idle.

Out of curiosity, I tried disabling C-states but that didn't solve the issue, although P95/FFT16K seems to only fail after 1-3 seconds instead of within a fraction of a second.

[QUOTE=JuanTutors;537349]I'm getting the following error (see image) when I run ECM2 on M332XXXXXX..[/QUOTE]

The GMP library is running out of memory in mpz_gcdext. Catching allocation errors in GMP is non-trivial.

I apologize if here is not the most correct place for my question, but why in version 29.8 build 5 my 9900k only passes with 1.38v and in version 29.8 build 6 it passes with 1.36v, any technical explanation or correction in the new build?

[QUOTE=HLB;538729]I apologize if here is not the most correct place for my question, but why in version 29.8 build 5 my 9900k only passes with 1.38v and in version 29.8 build 6 it passes with 1.36v, any technical explanation or correction in the new build?[/QUOTE]

No changes in prime95 to explain that.

George... Thanks a lot for the new ExitWhenOutOfWork functionality. It is working out perfectly for my use-case.

One minor change request, please... When mprime exits gracefully, could it please delete its PID file?

Thanks.

Edit: I just observed an mprime instance finish its assignment, and exit cleanly. It removed its PID file. Perhaps it's left around when SIGINT'ed? Or perhaps I'm insane (non-zero probability)...

Weird slowdown on mprime P-1'ing.
 

Hey George et al.

I noticed something which seemed a bit strange to me in one of my Colab jobs's log file:[CODE]
[Work thread Mar 5 11:01] Using 10235MB of memory. Processing 237 relative primes (237 of 480 already processed).
[Work thread Mar 5 11:13] M95xxxxxx stage 2 is 80.04% complete.
[Work thread Mar 5 11:22] M95xxxxxx stage 2 is 80.56% complete. Time: 543.684 sec.
...
[Work thread Mar 5 16:19] M95xxxxxx stage 2 is 97.81% complete. Time: 540.886 sec.
[Work thread Mar 5 16:28] M95xxxxxx stage 2 is 98.33% complete. Time: 540.351 sec.
[Work thread Mar 5 16:37] M95xxxxxx stage 2 is 98.86% complete. Time: 544.413 sec.
[Work thread Mar 5 16:44] Using 859MB of memory. Processing 6 relative primes (474 of 480 already processed).
[Work thread Mar 5 16:48] M95xxxxxx stage 2 is 99.25% complete. Time: 633.379 sec.
[Work thread Mar 5 16:55] M95xxxxxx stage 2 is 99.30% complete. Time: 434.847 sec.
[Work thread Mar 5 17:02] M95xxxxxx stage 2 is 99.34% complete. Time: 431.063 sec.
[/CODE]

It seems like mprime slows down considerably while working on the smaller number of relative primes right at the end of the run. Is this expected?

Thanks.