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.

In the past 6 months I've had the microSD in both my phone and tablet semi-fail, where they decide they're approaching their lifespan and auto-switch into read-only mode. Apparently this is a "feature" to limit degradation and attempt to avoid read failures, but it's very frustrating when neither the user nor most of the apps expect this, the apps mostly don't actually check for write success, they just assume the write was successful, so you copy something to the card, and it shows as copied, then you look for it later and it's not there. But files you purportedly deleted are still there.

Again, this is a cheap-flash problem, and not something you'll run into on an SSD.

>The mistake is in local.txt. Set WorkerThreads=1
OK.
When I set WorkerThreads=1, the issue is fixed. (gwnum.txt, results.bench.txt)
Thanks.

My wrong local.txt (WorkerThreads=5) seems to lead to an app-crash.(crash.png)

start bench Apr 24 14:28:19 #188
app crash Apr 24 14:28:40

My machine is below.
[url]https://www.mersenneforum.org/showpost.php?p=511299&postcount=112[/url]
Hyperthread is enabled in BIOS.

There is an item about this which has caused a bit of frustration for me over the years. I do not know if it is [I]Prime95[/I] or [I]PrimeNet[/I], or both. My work preference will be arbitrarily changed.

It is my belief that people know the limitations of their hardware and what they can run in a reasonable amount of time. Please respect their choices and [U]do[/U] [U]not[/U] change them.

:mellow:

If you received a double check it is because accounts are by default set to receiving 1 double check per year per computer as a sanity check:
[url]https://www.mersenne.org/thresholds/[/url]