5/5 benchmarked ok
 

1) Prime95 v29.6b[B]6 [/B]x64 on dual 8-core E5-2690, Win 10 Pro; throughput benchmark 1,2,4,8,16 workers, HT and not, 1M-32M, completed without incident;

2) Prime95 v29.6b[B]7[/B] x64 on 6-core i7-8750H, Win 10 Home; throughput benchmark 1-3,6 workers, HT and not, 1M-32M, completed without incident;

3) Prime95 v29.6b7 x64 on Core 2 Duo E8200, Vista; throughput benchmark 1-2 workers, 1M-32M, completed without incident;

4) Prime95 v29.6b7 x64 on dual 6-core Xeon X5650, Win 7 Pro; throughput benchmark 1,2,3,4,6,12 workers, HT and not, 1M-32M, completed without incident;

5) Prime95 v29.6b[B]3[/B] x32 on Pentium 750 M, Vista; throughput benchmark 1M-32M, completed without incident.

So I put [U][COLOR=Red][B]FFT timings [/B][/COLOR][/U]from 256K to 512K on 4 cores, not [COLOR=Blue][B]throughput[/B][/COLOR] benchmark

[QUOTE=newalex;510544]The second ECM factor was found using prime 29.6. And it isn't displayed correctly in reports, too.

[URL]https://www.mersenne.org/report_exponent/?exp_lo=351457&full=1[/URL][/QUOTE]

And once more it doesn´t appear in the Recent Cleared Report

So I'm new to the upgrade thing, all I have to do is replace the prime.exe / mprime file?

[QUOTE=irowiki;510611]So I'm new to the upgrade thing, all I have to do is replace the prime.exe / mprime file?[/QUOTE]

And also the .dll files that are packaged with the prime95.exe

Look like something was fixed on server side. Now factors are displayed correctly and it presents in all reports.

It is still a bit different from previous version - ecm curves' count and bounds doesn't displayed. For example the latest discovery
[URL]https://www.mersenne.org/report_exponent/?exp_lo=354121&full=1[/URL]

with old version
[URL="https://www.mersenne.org/report_exponent/?exp_lo=20147&full=1"]https://www.mersenne.org/report_exponent/?exp_lo=20147&full=1
[/URL]
But it is a minor thing.

Thanks for the new release and all your hard work!

I'm still not clear on whether we should be running LL or PRP tests. Aren't LL tests expected to eventually be phased out?

Any progress on not filling up the output with daily 'Running Jacobi error check' messages?

Also - With as many issues, updates, suggestions, and feedback as these builds get would it make sense to create a new thread for each build (29.6B[B]1[/B], 29.6B[B]2[/B], etc...) instead of always editing the first post and letting these threads get too long? When a new thread is created the old one can be locked.

Finally - any word on integrating GPU testing into the main client?

[QUOTE=rainchill;510771]
I'm still not clear on whether we should be running LL or PRP tests. Aren't LL tests expected to eventually be phased out?[/quote]

You can run either. Personally, I am running PRP. Yes, I plan to make PRP the default work type if you select "What makes the most sense".

[quote]Any progress on not filling up the output with daily 'Running Jacobi error check' messages?[/quote]

No. You could run PRP and get Gerbicz error-check messages instead.

[quote]Also - With as many issues, updates, suggestions, and feedback as these builds get would it make sense to create a new thread for each build (29.6B[B]1[/B], 29.6B[B]2[/B], etc...) instead of always editing the first post and letting these threads get too long? When a new thread is created the old one can be locked.[/quote]

A new thread for each build would be too much clutter IMO. The old threads remain open as there are still many users of the old version.


[quote]
Finally - any word on integrating GPU testing into the main client?[/QUOTE]

Won't happen. There is vague talk of having these clients get work from the server automatically, but nothing ever seems to come of it.

[QUOTE=Prime95;510775]Won't happen.[/QUOTE]
Thinking out loud. What's preventing this from happening?

[QUOTE=axn;510776]Thinking out loud. What's preventing this from happening?[/QUOTE]I'm sure you know a lot of the following already, and I'm including it for other readers.

It's not simple, and we're short of qualified volunteer code developers. It's illegal to clone humans, at least in the US. There's only one George Woltman, and he lives in Florida. Who would update the prime95 & mprime family of apps for new processor models, and the other things he does now, if he's busy doing gpu programming and interfacing to primenet and prime95? (If anything, rather than finding more for him to do, we should find him some help. And that doesn't stop me from making suggestions or requests either. ;) He gets to decide what's worthwhile to him, and how much time he spends on this project.

There's a lot of identified bug list and feature request work for the several main existing gpu applications. There is no CUDAPRP at all. I think despite the great efforts by a lot of talented people, some of the gpu apps just haven't the quality yet that prime95 has. As is, it's hard to make headway as separate applications on the to-do list, or keep up on maintenance such as CUDA level. Some code does get shared, for efficiency. I think having it divided up into several programs helps though; programmers can work independently, yet share ideas.

The primenet API documentation is still "release candidate 0.97c" dated Nov. 2007, from before gpu computing in GIMPS was a thing, and it's not caught up to current practice in prime95 / mprime, and appears not well suited for gpus. It seems especially not well suited for dealing from a single instance with the cpu and disparate gpus per system of heterogenous-multi-gpu systems like I have. Many have looked at the Primenet API's complexity over the years, and chosen to go with separate assignment / submit scripts instead that work through the "manual" web pages or an altered version, at less effort than the Primenet API would take. Preda's a very recent example, of several. See [URL]https://www.mersenneforum.org/showpost.php?p=488292&postcount=3[/URL] and [URL]https://www.mersenneforum.org/showthread.php?t=23992[/URL]

The individual gpu apps each have their own unique ways of doing things. Probably the closest are mfaktc and mfakto. Each gpu app instance has its own worktodo file, ini file, etc. The same variable name in different gpu applications may mean different things. File formats often differ. Etc. Documentation other than the program source code is often quite sparse, or not current.

The development environment is more demanding for gpus. I've seen the installation of the NVIDIA or AMD SDK blow away the OpenCL driver for an Intel igp, ending use of mfakto. The NVIDIA and AMD SDKs may not coexist well. It's known to be tricky to get the gpu card drivers from NVIDIA and AMD to coexist on one system (Windows or linux) and system stability is reduced. Integrating the variety of gpu code into prime95 would complicate the build process and also software testing.

The status quo does not prevent George from helping out now and then on the gpu development side, as he has done occasionally. The status quo allows people like Preda to make rapid progress in a well defined area, independently.

Prime95 is an Intel-style-architecture program. Not all gpus are on Intel cpu systems. Some are on ARM systems (cell phones). There's a move afoot to explore cell phone computing via Mlucas. Ernst may be the second person to implement a Primenet client interface, in Mlucas generally, a cpu-oriented application. He'll probably implement PRP next, not gpu support.

We have abundant opportunity for programming volunteers.

[QUOTE=Prime95;510775]There is vague talk of having these clients get work from the server automatically, but nothing ever seems to come of it.[/QUOTE]

It can be argued that this problem space has already been solved. Scott's [URL="https://www.mersenneforum.org/misfit/"]MISFIT[/URL] for Windoze and Mark's [URL="https://github.com/MarkRose/primetools"]primetools[/URL] for Linux are stable and widely used tools.

[QUOTE=chalsall;510805]It can be argued that this problem space has already been solved. Scott's [URL="https://www.mersenneforum.org/misfit/"]MISFIT[/URL] for Windoze and Mark's [URL="https://github.com/MarkRose/primetools"]primetools[/URL] for Linux are stable and widely used tools.[/QUOTE]

But I think these require you to put your Primenet password in plaintext into the scripts, so not everyone is satisfied with that.

[QUOTE=chalsall;510805]It can be argued that this problem space has already been solved. Scott's [URL="https://www.mersenneforum.org/misfit/"]MISFIT[/URL] for Windoze and Mark's [URL="https://github.com/MarkRose/primetools"]primetools[/URL] for Linux are stable and widely used tools.[/QUOTE]
Partially addressed, perhaps. Progress reporting is needed in primality testing, and on longer TF or P-1 assignments it would be good to have also. (Some individual TF bit levels or P-1 stages can take weeks.)

MISFIT looks impressive, but I've balked at installing its multiple requirements everywhere, to gain only TF client support. It _used to_ support CUDALucas but that was discontinued years ago. Never CUDAPm1 or gpuowl or clLucas etc.

Primetools supports clLucas (is anyone still using that?) and mfakto, and "possibly" mfaktc and CUDALucas.

The grid of OS, gpu app, feature combination support is sparse. See the attachment at [URL]https://www.mersenneforum.org/showpost.php?p=488292&postcount=3[/URL]
If it's not giving due credit for features available, please point me to a reference and I'll update the posted summary table there.

[QUOTE=GP2;510812]But I think these require you to put your Primenet password in plaintext into the scripts, so not everyone is satisfied with that.[/QUOTE]

Have you looked in your prime.txt file recently?

Knowing only your Primenet UN, and a little bit of the API, you can do all kinds of fun things....

Small FFTs of torture test failed in windows 10.
Prime95.exe shows "No FFT lengths available in the range specified".
I use p95v296b7.win64.

[QUOTE=tshinozk;511299]Small FFTs of torture test failed in windows 10.
Prime95.exe shows "No FFT lengths available in the range specified".
I use p95v296b7.win64.[/QUOTE]

With 18MB of L2 cache and 24.75MB of L3 cache it is difficult (maybe impossible) to find an FFT size that will stress the L3 cache.

I'll see if I can grey the menu choice or relax the default FFT size calculations.

[QUOTE=Prime95;511335]With 18MB of L2 cache and 24.75MB of L3 cache it is difficult (maybe impossible) to find an FFT size that will stress the L3 cache.[/QUOTE]

Change of plans. I'll use the Inclusive flag returned by hwloc. Thus, on your machine with an non-inclusive L3 cache, I'll assume 24.75MB + 18MB will fit in L2+L3 caches before overflowing to memory.

I don't guarantee that there won't be cases where you'll still get no FFT sizes available.

Thank you.
I will use the other tests until next release.

[QUOTE]On machines with more than 4GB of memory, blend defaults to 1/16th of RAM.[/QUOTE]

On my 64GB RAM machine, Prime95.exe uses 62GB of RAM in blend test.
Is this a bug?

[QUOTE=tshinozk;511378]
On my 64GB RAM machine, Prime95.exe uses 62GB of RAM in blend test.
Is this a bug?[/QUOTE]

A bug in the documentation. The default is all but 2.5GB (3GB in Linux) of memory.

I found a issue about a stopping of a torture test.

While a torture test, I started a benchmark without manually stopping the torture test.
Prime95.exe tries to stop the torture test automatically.

[CODE][Main thread Mar 23 09:20] Stopping all worker threads.
[Worker #22 Mar 23 09:20] Test 1, 6000000 Lucas-Lehmer in-place iterations of M96607 using AVX-512 FFT length 4608.
[Worker #22 Mar 23 09:20] Torture Test completed 0 tests in 0 minutes - 0 errors, 0 warnings.
[Worker #22 Mar 23 09:20] Stopping worker at user request.
[Worker #22 Mar 23 09:20] Resuming worker at user request.
[Worker #22 Mar 23 09:20] Worker stopped.[/CODE]

Because CPU load were 0%, it seems that all workers were stopped internally.
But, some workers did not display "Worker stopped" and the benchmark were not started.

I selected a benchmark again. Then, Prime95.exe managed to stop workers again automatically.
[CODE][Main thread Mar 23 09:23] Stopping all worker threads.[/CODE]

Soon, the benchmark were started, but two benchmarks were started simultaneously.
[CODE][Worker #1 Mar 23 09:23] Worker starting
[Worker #1 Mar 23 09:23] Your timings will be written to the results.txt file.
[Worker #1 Mar 23 09:23] Compare your results to other computers at http://www.mersenne.org/report_benchmarks
[Worker #1 Mar 23 09:23] Worker starting
[Worker #1 Mar 23 09:23] Your timings will be written to the results.txt file.
[Worker #1 Mar 23 09:23] Compare your results to other computers at http://www.mersenne.org/report_benchmarks[/CODE]

After that, I stopped the benchmarks manually, then Prime95.exe crashed (ACCESS_VIOLATION: c0000005).

This is reproducible with mamy threads in my machine(#112).

When "Number of torture test threads to run" has small numbers, I have no issues.
And even when "Number of torture test threads to run" has 36,
I can stop manually torture tests using menu bar of GUI without any problems.

This issue exists in p95v294b8.win64 as well.

[QUOTE=tshinozk;511476]
While a torture test, I started a benchmark without manually stopping the torture test.
Prime95.exe tries to stop the torture test automatically. [/QUOTE]

I believe I have a fix for this in 29.7

[QUOTE=Prime95;511878][/QUOTE]

What happened to 29.7 build 1?
I saw someone linked it on overclock.net but it seems to have been pulled for some reason :) Was there a show stopper?

Why not get it the original place?

[url]ftp://mersenne.org/gimps/[/url]

[QUOTE=Falk;511878]

What happened to 29.7 build 1?[/quote]

The forum was down for a day. First post in the thread is now up to date

The front page and the downloads page need to be updated.

[QUOTE]11) Some SkylakeX CPUs would say "no FFT sizes available" for default small torture test. Upper bound on FFT size changed to use L2+L3 cache size since the L3 cache is not inclusive. Fixed in 29.7.
12) The ability to stop individual torture test threads was not working. Running a benchmark without first stopping the torture test could cause a hang or crash. Fixed in 29.7.[/QUOTE]

I confirm that 11) and 12) are fixed on my machine in p95v297b1.win64.

I run a benchmark with the checkbox of "Benchmark all FFT implementations to find best one for your machine".
Then, the textbox of "Number of workers to" changes to "5" automatically without manually changing it.
On my machine, it is always "5".

[QUOTE=ixfd64;511995]The front page and the downloads page need to be updated.[/QUOTE]

As soon as the release is official we'll get those updated.

If you want to know the sha256 hashes for the 29.7b1 files:
[CODE]p95v297b1.FreeBSD11-64.tar.gz - 04C661A081F28973A5E2663CA2D003A70640518BF97CA2F209427CA29AC10274
p95v297b1.win32.zip - 0AB13D353F5FD700FC605BAFAD5E7C0584883FF6B7E88572135C60EC03A45C4F
p95v297b1.win64.zip - 5E42162095A920A5570AA23CB4FD4B5F8DB2ABF3DAE2CD48D631B1DE68A741C5
p95v297b1.linux64.tar.gz - 838E49A43962AA47297C9924AD50FC287A4AA4A3F69FBC14E0EFDD518A219434
p95v297b1.linux32.tar.gz - CAC3C1D55F0676B3F40D1832EDD26CAC1916AF3F237C48766BC93D9AC995AFCB
p95v297b1.win32.service.zip - DEADA1877B685D125E69ECCE9DBAD8B3DABE2106D2758235632EF28A531B20E6
p95v297b1.win64.service.zip - BF9761F05B12C0432364A5C7F03FC1F73E2395C771D4A191B193EBFC1A6B662C
p95v297b1.source.zip - 4872CA5A50F009814AF5B8E587DC1EC8AC2699D500CD4B4C79012B2FAA46985D
p95v297b1.MacOSX.zip - FA5D0652579893EA8967B88AB148B467FC3B3175195A68BFD8F2990AC8959166[/CODE]

[QUOTE=Madpoo;512189][CODE]p95v297b1.win32.service.zip - [b][color=red]DEAD[/color][/b]A1877B685D125E69ECCE9DBAD8B3DABE2106D2758235632EF28A531B20E6[/CODE][/QUOTE]Best hash value evva.

[QUOTE=retina;512192]Best hash value evva.[/QUOTE]

Very fitting since Windows 32 bit is pretty much dead :cool:

[QUOTE=tshinozk;512183]I run a benchmark with the checkbox of "Benchmark all FFT implementations to find best one for your machine".
Then, the textbox of "Number of workers to" changes to "5" automatically without manually changing it.
On my machine, it is always "5".[/QUOTE]
Try change to factors of the number of cores.
Example: 12 cores total; 1-4,6,12
18 cores: 1-3,6,9,18.

feature request
 

The worker window title indicates % complete, and what general type of computation (PRP, LL, P-1, ECM, etc.) is being run, on what exponent. But for a primality test it does not indicate whether it is a first test or a DC, or what residue type of PRP is being run. Adding those would be very handy.

[QUOTE=Madpoo;512189]As soon as the release is official we'll get those updated.[/QUOTE]

Ah. For some reason, I was under the impression that 29.7 was the official release.

[QUOTE=ixfd64;512321]Ah. For some reason, I was under the impression that 29.7 was the official release.[/QUOTE]It was at one point described as the version that would be the eventual release version. Then it was made available, described in the middle of the post as a "pre-release" (see post 1).

V29.7b1 is the first version I've been able to start a prime95 P-1 run over 595M on my hardware. A 605M exponent is currently projected to take a bit over 10 days (2 core-months) on the i7-8750H that provided so much benchmark-stall-debugging fun earlier.

[QUOTE=ixfd64;512321]Ah. For some reason, I was under the impression that 29.7 was the official release.[/QUOTE]

I was hopeful, but now there is an LLR problem. Looks like there will be a 29.8.

In case you are curious about changing the (minor) version number vs. the build number -- any time the gwnum code changes I must increase the version number. In this way, when LLR or PFGW bugs are reported I can tie it down to which version of gwnum those programs were linked with. If gwnum does not change, then I can just bump the build number.

Changes to the major version number are reserved for big new features -- like AVX-512 support.

No issues so far with Version 29.7. Currently running on Fedora Linux 29 which is at least 5 per cent faster than Win10. The utilization of AVX-512 really speeds things up on my Intel 7960X 32 core, server. :smile::smile:

Gerbicz error check to the rescue!
 

The Gerbicz error check found an error while PRPing on an old laptop!

Turns out it had been overheating (surprise, surprise). After cleaning out the fan & applying some new thermal paste, the PRP test is back to "excellent" confidence!

Hooray for the update!

Edit: it found the error in 29.6.7, now running 29.7.1

[CODE]
PRP=1,3,17,1,99,0,2,1,"4"
[/CODE]

[CODE]
{[B]"status":"P"[/B], "k":1, "b":3, "n":17, "c":1, "known-factors":["4"], "worktype":"PRP-2", "fft-length":32, "error-code":"00000000", "security-code":"00220022", "program":{"name":"Prime95", "version":"29.7", "build":1, "port":8}, "timestamp":"2019-04-06 05:11:51", ... }
[/CODE]

But... [URL="http://factordb.com/index.php?query=%283%5E17%2B1%29%2F4"](3^17+1)/4[/URL] = 103 · 307 · 1021


Edit:

Hmmm... a simple GMP program also gives the residue 0000000000000001 which indicates a PRP. However, with PRP-5 rather than PRP-2, the residue is 00000000014F5FBC.

So it's a case of PRP-2 != P and needing to check bases other than 2. Not an mprime bug.

[QUOTE=GP2;512890]
But... [URL="http://factordb.com/index.php?query=%283%5E17%2B1%29%2F4"](3^17+1)/4[/URL] = 103 · 307 · 1021


Edit:

Hmmm... a simple GMP program also gives the residue 0000000000000001 which indicates a PRP.[/QUOTE]

Yes, Fermat pseudoprime for base=2:
[CODE]
(20:42) gp > n=(3^17+1)/4
%13 = 32285041
(20:42) gp > Mod(2,n)^n
%14 = Mod(2, 32285041)
(20:42) gp >
[/CODE]

[QUOTE=Robert_JD;512349]No issues so far with Version 29.7. Currently running on Fedora Linux 29 which is at least 5 per cent faster than Win10. :smile::smile:[/QUOTE]Any solid data on how power draw compares between the two OSes?

[QUOTE=GP2;512890]
So it's a case of PRP-2 != P and needing to check bases other than 2. Not an mprime bug.[/QUOTE]
Default base used for PRP is 3. And the number in question is a base-3 number. Ergo, false positives...

Don't use the same base as the number itself. i.e. while testing (b^n+/-1)/f, use a PRP-base other than b.

EDIT:- Oh, I see that you did the original test with base-2! Interesting...

29.8b2
 

Hmm, v29.8b2 made it into the bug fix list in post two, April 11, but not yet into the download links in post 1.

[QUOTE=kriesel;514037]Hmm, v29.8b2 made it into the bug fix list in post two, April 11, but not yet into the download links in post 1.[/QUOTE]

I wonder if build 2 is still a work in progress.

[QUOTE=Madpoo;514185]I wonder if build 2 is still a work in progress.[/QUOTE]

I´m the only one running it on a Xeon. The Xeon has had some problems writing and updating the worktodo.txt file and the consequence of that is that P95 hangs on all cores. It appears that Georges fix, has almost solved it, because now it just hang on Worker #1, while letting all the others run when not being able to create worktodo.txt. Does anyone have any suggestions on how to find out why Prime95 have problems writing worktodo.txt?

The worktodo.txt file currently contains 166000+ tasks - is that a problem or does anyone of you have experiences on running with such large worktodofiles?

The computer in question is this: [url]https://www.primegrid.com/show_host_detail.php?hostid=946415[/url] (The drive is a Samsung SSD with SATA connection)

Any feedback is much appreciated. At least what George made of changes has to some extent improved the hang problem, such that in stead of all 12 workers (1 core and 1 thread per worker) hangs now it only was 1 worker that hang.

Thanks in advance.

KEP

[QUOTE=KEP;514240]The worktodo.txt file currently contains 166000+ tasks - is that a problem or does anyone of you have experiences on running with such large worktodofiles?[/QUOTE]

Expletive me, and the horse I rode in on.

Why would you have that many assignments for a single (if high powered) CPU?

Sincerely, that comes across as very stupid. Perhaps you have a reason for doing that which I don't understand.

Very happy to be edified.

[QUOTE=KEP;514240]The worktodo.txt file currently contains 166000+ tasks - is that a problem or does anyone of you have experiences on running with such large worktodofiles?[/QUOTE]

I've created very large worktodo files for small exponents for non-Mersenne work. There is a very long pause at startup, several minutes or more, before mprime starts its work. I don't know what it's doing during that time. Obviously, this uses the [c]UsePrimenet=0[/c] setting since it's not Mersenne, but that doesn't make any difference.

The solution is to use smaller worktodo.txt files. You can append to them later on the fly by creating files called worktodo.add or worktodo.add.txt

c++ compiler & version
 

George,
I was wondering what c++ compiler & its version you use to create the windows 64 binary?
TIA,
Marv

[QUOTE=tServo;514256]George,
I was wondering what c++ compiler & its version you use to create the windows 64 binary?
[/QUOTE]

The latest and greatest: MSVC 2005

How can MSVC 2005 create binaries with AVX-512 which was not even proposed until July 2013 ?

[QUOTE=ATH;514264]How can MSVC 2005 create binaries with AVX-512 which was not even proposed until July 2013 ?[/QUOTE]

AVX-512 is assembly code. The object files just need to be linked.

[QUOTE=GP2;514254]I've created very large worktodo files for small exponents for non-Mersenne work. There is a very long pause at startup, several minutes or more, before mprime starts its work. I don't know what it's doing during that time. Obviously, this uses the [c]UsePrimenet=0[/c] setting since it's not Mersenne, but that doesn't make any difference.

The solution is to use smaller worktodo.txt files. You can append to them later on the fly by creating files called worktodo.add or worktodo.add.txt[/QUOTE]

It is a little pause at startup. As guessed it is non mersenne work wich is running the most productive on 1 core per test (1 worker = 1 thread) and tests are such fast that each core completes 50 tests a day.

I think I´ll reduce the worktodo.txt file to 6000 tests (500 per core) and see if any further errors occur. That is still enough for 10 days, so it will practically work as "set and forget" on my borrowed Xeon :smile:

Thanks for your productive feedback :smile:

Maybe a race condition?
 

[QUOTE=KEP;514276]It is a little pause at startup. As guessed it is non mersenne work wich is running the most productive on 1 core per test (1 worker = 1 thread) and tests are such fast that each core completes 50 tests a day.

I think I´ll reduce the worktodo.txt file to 6000 tests (500 per core) and see if any further errors occur. That is still enough for 10 days, so it will practically work as "set and forget" on my borrowed Xeon :smile:

Thanks for your productive feedback :smile:[/QUOTE]

I'm not sure how Prime95 handles worktodo.txt code-wise, but with such large worktodo.txt and many workers, is it possible a race condition is occurring where different workers are trying to write to/read worktodo.txt at the same time and it's causing a hang?

[QUOTE=pokemonlover123;514280]I'm not sure how Prime95 handles worktodo.txt code-wise, but with such large worktodo.txt and many workers, is it possible a race condition is occurring where different workers are trying to write to/read worktodo.txt at the same time and it's causing a hang?[/QUOTE]

You are thinking the same that I have thought about. Well now that I´m going to play with worktodo.add or/and? worktodo.add.txt I hope that the much smaller worktodo.txt file will at least prevent this from happening again. Most likely because now it takes in stead of 3700 KB only 128 KB to write each time the worktodo.txt file has to be updated :smile: Thanks for chiming in :smile:

I thought [C]worktodo.add[/C] was an mfakt* feature?

[QUOTE=pokemonlover123;514280]I'm not sure how Prime95 handles worktodo.txt code-wise, but with such large worktodo.txt and many workers, is it possible a race condition is occurring where different workers are trying to write to/read worktodo.txt at the same time and it's causing a hang?[/QUOTE]

There is a lock around the code that reads and writes worktodo.txt -- a bug in that code is what caused KEP's hang on all 12 workers (the lock was not released when an error occurred writing worktodo).

[QUOTE=ixfd64;514323]I thought [C]worktodo.add[/C] was an mfakt* feature?[/QUOTE]
If I recall correctly, worktodo.add originated in prime95, was adopted in mfakto, and then brought to mfaktc at V0.21. As far as I know, CUDAlucas, CUDAPm1, ClLucas do not have it. Not sure about gpuowl or Mlucas. The functionality is not as important in situations where individual work lines take hours, days, or weeks.

[QUOTE=GP2;514254]I've created very large worktodo files for small exponents for non-Mersenne work. There is a very long pause at startup, several minutes or more,[/QUOTE]

I believe the delay is because prime95 is looking for a save file for every worktodo entry to set percent complete for future messages to primenet to update completion dates.

Try setting WellBehavedWork=1. This will stop the looking for save files at start up and will limit the rewriting of the worktodo file to once every half hour. The downside is that restarting after a crash could lead to some tests being rerun.

[QUOTE=Prime95;514260]The latest and greatest: MSVC 2005[/QUOTE]

Zounds !

As Jan & Dean said in the Sixties, "It's an oldie but a goodie!"

Do you use Win 7 or Win 10?

Regards,
Marv

[QUOTE=tServo;514336]
Do you use Win 7 or Win 10?
[/QUOTE]

Why Vista of course. In a virtual machine on my Mac.

I do own one Windows 10 machine, but I don't do any development on it. My Mac is having issues and my next Laptop will likely be Windows 10.

KEP: build 3 ready to test

[QUOTE=Prime95;514339]KEP: build 3 ready to test[/QUOTE]


link?

[QUOTE=kriesel;514329]If I recall correctly, worktodo.add originated in prime95, was adopted in mfakto, and then brought to mfaktc at V0.21. As far as I know, CUDAlucas, CUDAPm1, ClLucas do not have it. Not sure about gpuowl or Mlucas. The functionality is not as important in situations where individual work lines take hours, days, or weeks.[/QUOTE]

I looked through [C]readme.txt[/C] and [C]undoc.txt[/C] but could find no mention of this feature. The documentation should probably be updated.

[QUOTE=ixfd64;514344]I looked through [C]readme.txt[/C] and [C]undoc.txt[/C] but could find no mention of this feature.[/QUOTE]It is mentioned briefly in [c]whatsnew.txt[/c]:[quote]New features in Version 25.5 of prime95.exe
-------------------------------------------
...
9) In older versions, editing the worktodo.ini file while prime95 was running
sometimes had the desired effect. That is no longer the case. [b]You can
create a worktodo.add file to add work to a running prime95.[/b][/quote]

[QUOTE=ixfd64;514344]I looked through [C]readme.txt[/C] and [C]undoc.txt[/C] but could find no mention of this feature. The documentation should probably be updated.[/QUOTE]

I'll add it to undoc.txt.

[QUOTE=pepi37;514340]link?[/QUOTE]

I sent the link to KEP in a PM.

feature request
 

George, please add to prime95 V29.8b4?, an indication in the worker title window or prime.log or both, an indication whether a PRP or LL test is a first test or DC.

Also, for PRP, which residue type is being run.

Currently there seems to be no way to tell from the log file or the GUI whether a PRP run is first or double check, or what residue type is being run. Presumably the last parameter in the PRP worktodo line is residue type, but having to launch it in an editor is not so convenient. For example,

PRP=(aid redacted),1,2,79335979,-1,75,0,3,[B]1[/B]
(worktype=AID,k,b,p,c,tflimit,?,PRPbase,PRPresiduetype)
(Why doesn't that worktype say PRPDC or some such to match the Worker windows setting "Double check PRP tests"?)

See also [URL]https://www.mersenneforum.org/showpost.php?p=514381&postcount=3087[/URL]
and [URL]https://www.mersenneforum.org/showpost.php?p=512230&postcount=132[/URL]

[QUOTE=Prime95;514347]I sent the link to KEP in a PM.[/QUOTE]

Recieved, downloaded and started on the Xeon. Thanks for your quick effort. For now I´m continuing with just under 6000 tests in the worktodo.txt file - but please let me know if I have to load all the tests (~164000) to worktodo.txt :smile:

@Everyone (maybe off-topic): I´ve heard that a SSD has a limited lifespan in terms of writing and reading data (at least on writing data) - is that correct? If correct, how much of the lifetime writing capacity does a worktodo.txt file on 3700 KB takes up each time the worktodo.txt file has to be rewritten? ... yes I know that everytime a test completes the filesize shrinks, but just curious how much pressure I put on my brothers Xeon and the SSD that holds his OS :smile:

[QUOTE=KEP;514387]
@Everyone (maybe off-topic): I´ve heard that a SSD has a limited lifespan in terms of writing and reading data (at least on writing data) - is that correct? If correct, how much of the lifetime writing capacity does a worktodo.txt file on 3700 KB takes up each time the worktodo.txt file has to be rewritten? ... yes I know that everytime a test completes the filesize shrinks, but just curious how much pressure I put on my brothers Xeon and the SSD that holds his OS :smile:[/QUOTE]

Curious about this too lol

I uses Vegacrypt to store files within a virtual drive (5gb) that is synced across devices via google drive stream. Everytime I edit/move/add/rename any files within the entire 5gb is rewritten across all devices (thanks university high speed internet). I've been doing for a year if not years now, none of my ssd show any signs of failure.

Doesn't any OS with any full disk encruption enabled i.e. Bitlocker, File Vault (or LUKs by linux) consistently overwrite a large portion of the drive? It doesn't seem like it's a big concern.

:rolleyes:

Yes, there is limited write cycles available on an SSD. If possible, you can put worktodo.txt [i]and[/i] results.txt onto either a RAMdrive, or a mechanical HDD, to avoid SSD wear. This is significant for high-turnover files (like 5-second assignments), less of an issue where there is less rewrite.

[QUOTE=James Heinrich;514389]Yes, there is limited write cycles available on an SSD. If possible, you can put worktodo.txt [i]and[/i] results.txt onto either a RAMdrive, or a mechanical HDD, to avoid SSD wear. This is significant for high-turnover files (like 5-second assignments), less of an issue where there is less rewrite.[/QUOTE]

So if the file is 3770 KB I use 3770 KB each time worktodo.txt (just an example given in this case) is updated and written again? So generally I´m better off running smaller worktodo.txt files? :smile:

Not really, since even if you have 1kB files, a lot more data than that ends up being written each time (see: [url=https://en.wikipedia.org/wiki/Write_amplification]Write Amplification[/url]).
Best solution: keep the worktodo/results off your SSD if you're going through more than a couple assignments an hour.

[QUOTE=KEP;514240] The worktodo.txt file currently contains 166000+ tasks - is that a problem or does anyone of you have experiences on running with such large worktodofiles?

Any feedback is much appreciated. At least what George made of changes has to some extent improved the hang problem, such that in stead of all 12 workers (1 core and 1 thread per worker) hangs now it only was 1 worker that hang.

Thanks in advance.

KEP[/QUOTE]

What about setting up 12 copies of prime95, each in it's own directory with its own worktodo.txt and set to use 1 core each? That way the worktodo.txt's are smaller and there are no synchronisation issues.

Chris

[QUOTE=James Heinrich;514393]Not really, since even if you have 1kB files, a lot more data than that ends up being written each time (see: [url=https://en.wikipedia.org/wiki/Write_amplification]Write Amplification[/url]).
Best solution: keep the worktodo/results off your SSD if you're going through more than a couple assignments an hour.[/QUOTE]

I´m currently completing 20-30 tests an hour. Think I better get one of those good old HDD up and running. Its fine that my brother allows me to borrow his Xeon, but it would really be a problem for me personally if I destroyed his SSD just because he allows me to crunch for CRUS on his machine. Good that I have several external HHDs that can be put to use :smile:

Thanks for sharing this very off-topic but nice to know knowledge. I did not know that it was actually that bad to write to a SSD.

Have a very nice day my fine gentleman :smile:

[QUOTE=KEP;514395]I´m currently completing 20-30 tests an hour. Think I better get one of those good old HDD up and running. Its fine that my brother allows me to borrow his Xeon, but it would really be a problem for me personally if I destroyed his SSD just because he allows me to crunch for CRUS on his machine. Good that I have several external HHDs that can be put to use :smile:

Thanks for sharing this very off-topic but nice to know knowledge. I did not know that it was actually that bad to write to a SSD.[/QUOTE]

The longevity of SSD units depends quite a bit on the memory technology used - how many bits / charge levels are stored per cell - with TLC (three bits = eight levels per cell) being the most common now. Those seem to be rated at about 1000-3000 writes. So, let's assume a 500GB SSD. You'd have to write that 4MB file roughly 125 million times to get to those figures. For a life span of 10 years, that would be a bit over 20 writes per minute. I don't see any problems, you're still off by a couple orders of magnitude :smile:

Or you could do longer assignments on his machine, and shorter ones on your personal machines that still have regular disks.

On my own SSD, I don't worry about write cycles; I figure by the time the life of the SSD is up, something 5-10x bigger will be cheap. That's not my decision to make on someone else's machine, though!

[QUOTE=KEP;514395]...
Thanks for sharing this very off-topic but nice to know knowledge. I did not know that it was actually that bad to write to a SSD.

Have a very nice day my fine gentleman :smile:[/QUOTE]
Modern SSD's are much better than their reputation for limited write cycles suggests thanks to early clunkers. A decent SSD from a few years ago onwards should not be a problem, it's only when you get to extreme use cases that you should take pause. That said £20 for peace of mind and to avoid liability on the off-chance that the SSD ever fails in its lifespan is pretty cheap.

[QUOTE=nomead;514397]The longevity of SSD units depends quite a bit on the memory technology used - how many bits / charge levels are stored per cell - with TLC (three bits = eight levels per cell) being the most common now. Those seem to be rated at about 1000-3000 writes. So, let's assume a 500GB SSD. You'd have to write that 4MB file roughly 125 million times to get to those figures. For a life span of 10 years, that would be a bit over 20 writes per minute. I don't see any problems, you're still off by a couple orders of magnitude :smile:[/QUOTE]

I agree. SSD's monitor writes, and if a particular sector has been written too many times compared to the rest of the drive, the data is moved to a lesser used area. That's called wear leveling.

There are places out there hammering SSD's 24/7/365, for the express purpose of trying to get them to fail. There are a few infant mortalities of course, and a few that fail about when expected, but most are still going strong after many times the number of writes they were supposed to be able to handle.

[QUOTE=nomead;514397]The longevity of SSD units depends quite a bit on the memory technology used - how many bits / charge levels are stored per cell - with TLC (three bits = eight levels per cell) being the most common now. Those seem to be rated at about 1000-3000 writes. So, let's assume a 500GB SSD. You'd have to write that 4MB file roughly 125 million times to get to those figures. For a life span of 10 years, that would be a bit over 20 writes per minute. I don't see any problems, you're still off by a couple orders of magnitude :smile:[/QUOTE]

Wow thanks. Guess that I´ll keep it on the Samsung EVO-850 500GB SSD. Currently it is writing the entire file an average of 25 times per hour, so fast calculations in my head tells me there will be no problems for the next 480 Years :smile: Thanks for your feedback - it was very helpfull :smile:

[QUOTE=chris2be8;514394]What about setting up 12 copies of prime95, each in it's own directory with its own worktodo.txt and set to use 1 core each? That way the worktodo.txt's are smaller and there are no synchronisation issues.

Chris[/QUOTE]

Thanks for your reply, wich I almost missed because I made my own answer to another post, while you made yours - but George has sent me an updated Prime95 file and I´ll test it first for the less than 6,000 tests and once they complete I´ll load all 158,000 tests remaining and see if I can run for at least 14 days without any hangs. In case I can that I´ll consider the problem ultimately solved. :smile:

[QUOTE=VBCurtis;514399]Or you could do longer assignments on his machine, and shorter ones on your personal machines that still have regular disks.

On my own SSD, I don't worry about write cycles; I figure by the time the life of the SSD is up, something 5-10x bigger will be cheap. That's not my decision to make on someone else's machine, though![/QUOTE]

Well I guess that I´ll be safe when I read the feedback from before your post and the feedback below. I know that most people can´t grasp that it actually is nescessary to have a worktodo.txt file containing 166,000 candidates - but logic is, that when that worktodo.txt file is excausted all tests that runs the most productive on the Xeon using just 1 core will have ceased to excist. After completion of this worktodo.txt file I´ll create a worktodo.txt file containing all the tests that runs the fastest on 2 cores per test (running 6 tests at a time).

[QUOTE=M344587487;514400]Modern SSD's are much better than their reputation for limited write cycles suggests thanks to early clunkers. A decent SSD from a few years ago onwards should not be a problem, it's only when you get to extreme use cases that you should take pause. That said £20 for peace of mind and to avoid liability on the off-chance that the SSD ever fails in its lifespan is pretty cheap.[/QUOTE]

It is a Samsung SSD - 850 EVO 500GB, bought 2 years ago. From the way I read your reply, it is safe to use and like the previous feedback suggested I should fear nothing because the computer has most likely perished before the SSD becomes useless.

[QUOTE=KEP;514414]Currently it is writing the entire file an average of 25 times per hour[/QUOTE]

Would you be willing to share what work you're currently doing? I have a few machines doing a little bit of work for Primenet, and they only update their worktodo.txt file three or four times a day.

I'll show you mine if you show me yours... :wink:

[QUOTE=chalsall;514429]Would you be willing to share what work you're currently doing? I have a few machines doing a little bit of work for Primenet, and they only update their worktodo.txt file three or four times a day.

I'll show you mine if you show me yours... :wink:[/QUOTE]

Yes, the Xeon is running S383 at n=~217500 for my CRUS reservation. These tests are running the fastest when running 1 test per core (12 tests in total). Due to faster test for small k´s and slower tests for higher k´s, the average per hour is 25 tests completed - hence the worktodo.txt file will be updated 25 times per hour. Of course less and less data will be written fewer and fewer times per hour :smile:

I don´t need to see yours, mine is bigger anyway :wink:

[QUOTE=KEP;514387]...@Everyone (maybe off-topic): I´ve heard that a SSD has a limited lifespan in terms of writing and reading data (at least on writing data) - is that correct? If correct, how much of the lifetime writing capacity does a worktodo.txt file on 3700 KB takes up each time the worktodo.txt file has to be rewritten? ... yes I know that everytime a test completes the filesize shrinks, but just curious how much pressure I put on my brothers Xeon and the SSD that holds his OS :smile:[/QUOTE]

Don't worry about it at all. With wear-leveling algorithms in use on all SSDs (even really old ones) you could literally write gigs of data per day for years before you would have any issues. If your drive has a decent amount of free space then it means your drive would last longer.

I have a few older SSDs that I repurposed for my surveillance system. These things are written to 24/7, gigs and gigs of data daily. Over the past 2-3 years I've had one of the older 256GB SSD drives die. It started giving SMART errors, etc. Plus, these drives were previously used for years in a workstation so who knows what kind of write cycles they had before.

Anyway... yeah, you could re-write your worktodo once per minute probably for centuries before you'd get your first error. :smile:

[url]https://www.seagate.com/tech-insights/ssd-over-provisioning-benefits-master-ti/[/url]


:mike:

[QUOTE=Xyzzy;514790][url]https://www.seagate.com/tech-insights/ssd-over-provisioning-benefits-master-ti/[/url]


:mike:[/QUOTE]

Thanks for very usefull information :smile:

[QUOTE=Madpoo;514751]Don't worry about it at all. With wear-leveling algorithms in use on all SSDs (even really old ones) you could literally write gigs of data per day for years before you would have any issues. If your drive has a decent amount of free space then it means your drive would last longer.

I have a few older SSDs that I repurposed for my surveillance system. These things are written to 24/7, gigs and gigs of data daily. Over the past 2-3 years I've had one of the older 256GB SSD drives die. It started giving SMART errors, etc. Plus, these drives were previously used for years in a workstation so who knows what kind of write cycles they had before.

Anyway... yeah, you could re-write your worktodo once per minute probably for centuries before you'd get your first error. :smile:[/QUOTE]

I guess I´ll take it easy then. I´m now assured that the Samsung EVO 850 500GB (200+GB free space) is not going to be harmed :smile:

I run some PRP tests in Windows 10. (p95v298b3.win64)
I aware that Prime95.exe seems to write nothing in results.bench.txt while PRP testing.
Is it OK?

I think that auto-bench wrote some messages in some previous version.

[QUOTE=tshinozk;515064]I run some PRP tests in Windows 10. (p95v298b3.win64)
I aware that Prime95.exe seems to write nothing in results.bench.txt while PRP testing.
Is it OK?

I think that auto-bench wrote some messages in some previous version.[/QUOTE]

Unless you have AutoBench=0 in prime.txt you should get some benchmark results -- one set of results every 24 hours.

I did not set AutoBench=0.

This also occured in p95v298b1.win64. (I deleted older versions than that.)
I attach it in this post, too.

The numbers of "Line-Feed" in results.bench.txt seem to differ every time.

[QUOTE=tshinozk;515083]
The numbers of "Line-Feed" in results.bench.txt seem to differ every time.[/QUOTE]

Interesting. Like prime95 starts to run some benchmarks and doesn't find any are needed??? Can you send me your worktodo.txt and CPU specs? Thanks.

I run PRP tests as stability check using AVX512 for my machine.

I use a series of the well-known mersenne primes.
I use only one worker, and the worker uses all 18 cores of 7980XE.

Do I make any mistakes in worktodo.txt ?

[QUOTE=Madpoo;514751]Don't worry about it at all. With wear-leveling algorithms in use on all SSDs (even really old ones) you could literally write gigs of data per day for years before you would have any issues. If your drive has a decent amount of free space then it means your drive would last longer.

I have a few older SSDs that I repurposed for my surveillance system. These things are written to 24/7, gigs and gigs of data daily. Over the past 2-3 years I've had one of the older 256GB SSD drives die. It started giving SMART errors, etc. Plus, these drives were previously used for years in a workstation so who knows what kind of write cycles they had before.

Anyway... yeah, you could re-write your worktodo once per minute probably for centuries before you'd get your first error. :smile:[/QUOTE]

Note this doesn't apply to cheap thumb drives. I've had many fail when used as an OS drive for running mprime.

[QUOTE=Mark Rose;515196]Note this doesn't apply to cheap thumb drives. I've had many fail when used as an OS drive for running mprime.[/QUOTE]

Neither does it apply to most memory cards, unless explicitly stated that they do some non-basic wear leveling. So keep that in mind when setting up devices that use, for example, SD cards for main storage. Worst case, I've had one SD card fail in under a week, and another in about two weeks, but that was not a typical use case at all, writing small files (1k-100k) just about all the time. Memory cards and thumb drives may have something simple in use, designed for FAT32, where the allocation table and root directory are always at the beginning of the device, but if the file system is different (in my failed cases, ext2 and reiserfs) the metadata writes are more spread out and those places are the most likely to die first.

But for a proper SSD, no problem.

[QUOTE=tshinozk;515128]I run PRP tests as stability check using AVX512 for my machine.

I use a series of the well-known mersenne primes.
I use only one worker, and the worker uses all 18 cores of 7980XE.

Do I make any mistakes in worktodo.txt ?[/QUOTE]

The mistake is in local.txt. Set WorkerThreads=1

I'm debugging why the configuration you set up freaks out the autobench code.

[QUOTE=Mark Rose;515196]Note this doesn't apply to cheap thumb drives. I've had many fail when used as an OS drive for running mprime.[/QUOTE]

Oh, good point. USB drives/thumb drives don't typically do wear leveling. I've also had many fail that I use for transporting a few large files around, sneakernet style.

Some are better than others, like the SDCards you might use for digital cameras, but you're getting what you pay for most of the time. Cheap ones will fail sooner.