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]

[QUOTE=ATH;516020]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][/QUOTE]

I have seen this before. Not too far in the past, I ran this test on my HP. This i7, I am not sure how long it has been. I believe I have my setting configured to do this. I generally run DC's on a GPU. In this case, that wold not work.

Thank you! :smile:

[U]Edit[/U]: I filtered my results to show only LL tests. I did run one on this i7 which completed on 9/26/2018. Nothing appeared for the HP. Strange! I will run another.

FYI: 29.8 is now the official download version at mersenne.org.

Also, I just tweaked the get-assignment server code for "what makes the most sense" prime95 clients. They will get PRP assignments if running version 29.6 or later. Keep an eye out for any unusual get assignment behavior.

[QUOTE=Prime95;516107]FYI: 29.8 is now the official download version at mersenne.org.[/QUOTE]

You might want to mention this on the front page.

Edit: and it's done!

IMO, it would make sense to move older versions of Prime95 and gwnum libraries from [URL="https://www.mersenneforum.org/gimps/"]GIMPS mirror[/URL] to one or subdirectories. The naming convention has changed over time and some of the versions posted there are buggy or no longer supported.

[QUOTE=rogue;516151]it would make sense to move older versions of Prime95 and gwnum libraries from [URL="https://www.mersenneforum.org/gimps/"]GIMPS mirror[/URL][/QUOTE]It would also make sense to move all the non-current stuff from [url]ftp://mersenne.org/gimps/[/url] to [url]ftp://mersenne.org/gimps_archive/[/url]
I thought about cleaning up [url]https://download.mersenne.ca/gimps[/url] but that's tied to the above FTP via automatic mirroring so cleaning the one will fix the other.

I noticed a very minor issue: the "Visit Mersenne Wiki" option is still directing users to the now-defunct wiki. It should be updated to point to the [url=https://rieselprime.de/ziki/Main_Page]new one[/url] or removed altogether.

[QUOTE=Prime95;516107]FYI: 29.8 is now the official download version at mersenne.org.[/QUOTE]

Question: Is there a symbol, or symbols, which can be used to cause [I]Prime95[/I] ignore lines in [I]local.txt[/I] and [I]prime.txt[/I]? Just curious. :smile:

[QUOTE=storm5510;516257]Question: Is there a symbol, or symbols, which can be used to cause [I]Prime95[/I] ignore lines in [I]local.txt[/I] and [I]prime.txt[/I]?[/QUOTE][code]New features in Version 25.5 of prime95.exe
-------------------------------------------
8) It is now legal to put comment lines in the prime.txt, local.txt, and
worktodo.txt files.[/code]It doesn't mention it, but I believe starting a line with [color=red][b]#[/b][/color] will make that line into a comment.

I [I]think[/I] semicolons can also denote comments.

[QUOTE=ixfd64;516259]I [I]think[/I] semicolons can also denote comments.[/QUOTE]After a little experimenting, it seems Prime95 is very liberal with what constitutes a comment: I believe any line starting with [i]any[/i] non-alpha character will be treated as a comment.

[QUOTE=ixfd64;516259]I [I]think[/I] semicolons can also denote comments.[/QUOTE]
That's been the case for many releases.
It was how [Worker #n] could still appear in the worktodo.txt, along with explanatory text added, after the number of workers got reduced below n, by the prime95 program

[QUOTE=James Heinrich;516258][code]New features in Version 25.5 of prime95.exe
-------------------------------------------
8) It is now legal to put comment lines in the prime.txt, local.txt, and
worktodo.txt files.[/code]It doesn't mention it, but I believe starting a line with [COLOR=red][B]#[/B][/COLOR] will make that line into a comment.[/QUOTE]

I experimented by using the [B]#[/B] symbol first. I didn't not see any error message about it so I figured it was alright to use, if needed.

Thank you all who replied. :smile:

Are P-1 save files incompatible between versions 29.4 and 29.8 on macOS?

I just upgraded Prime95 from 29.4 build 7 to the latest version on my MacBook Pro. Both workers were running P-1 stage 1 at the time. Prime95 immediately complained that the save files were incompatible and marked them as bad.The problem went away after I downgraded back to the previous stable release.

I know that P-1 stage 1 save files are incompatible between 29.4 and earlier versions, but I'm not aware of any such issue between 29.4 and the current version. At least there were no problems when I upgraded to 29.8 build 3 on Windows machines.

After upgrading to mprime 29.8 build 3, when I choose torture test I was presented with 3 options, but the default was set to option #4.

I noticed a minor inconsistency: Prime95 always appends two newlines to [C]results.bench.txt[/C] when it adds en entry. In the other results files, Prime95 only adds one newline at a time. I assume this is unintentional.

[QUOTE=PhilF;516589]After upgrading to mprime 29.8 build 3, when I choose torture test I was presented with 3 options, but the default was set to option #4.[/QUOTE]

Fixed in 29.8b4 (not out yet)

[QUOTE=ixfd64;516561]Are P-1 save files incompatible between versions 29.4 and 29.8 on macOS?[/QUOTE]

I don't think so. Do you still have the example?

Running p95v298b3.MacOSX and just tried doing a Torture Test on my MacBook Air while doing a P1 Stage 2 test and the program crashes. Will send the crash report to George. Same issue with p95v297b1.MacOSX and it doesn't matter if P-1 is in Stage 1 or Stage 2. Even crashes if the P-1 test has been stopped.

I am going to attempt to set the record for the most trivial bug ever reported.

Now, when mprime submits ECM results, if only 1 curve was run the result report on the web site shows "1 curves". It used to say "1 curve".

Do I get a prize or something?

Forgot to mention that my MacBook Air is still running Version 10.14.4 (haven't upgraded to the new 10.14.5 yet). Went back and tested older versions:

29.4b7 Good
29.6b3 Good
29.7b1 Crash
29.8b3 Crash

[QUOTE=PhilF;516667]
Do I get a prize or something?[/QUOTE]

Nope, I think it is a web site bug.

[QUOTE=ixfd64;516157]I noticed a very minor issue: the "Visit Mersenne Wiki" option is still directing users to the now-defunct wiki. It should be updated to point to the [url=https://rieselprime.de/ziki/Main_Page]new one[/url] or removed altogether.[/QUOTE]

Where are you seeing a link? I thought I had commented out all of the defunct links to mersennewiki. I haven't seen the replacement yet - I knew it was being worked on but hadn't heard anything else.

[QUOTE=Madpoo;516692]Where are you seeing a link? I thought I had commented out all of the defunct links to mersennewiki. I haven't seen the replacement yet - I knew it was being worked on but hadn't heard anything else.[/QUOTE]

It's still in the Prime95 help menu. I think the GIMPS website is fine.

[QUOTE=ixfd64;516694]It's still in the Prime95 help menu. I think the GIMPS website is fine.[/QUOTE]

Fixed in next build. Thanks.

[QUOTE=PhilF;516667]I am going to attempt to set the record for the most trivial bug ever reported.

Now, when mprime submits ECM results, if only 1 curve was run the result report on the web site shows "1 curves". It used to say "1 curve".

Do I get a prize or something?[/QUOTE]

I wasn't quite sure what page you saw that on. Here's an example of an exponent with a single ECM curve turned in from someone and it renders as expected (singular "curve"):
[URL="https://www.mersenne.org/report_exponent/?exp_lo=222316561&exp_hi=&full=1&ecmhist=1"]M222316561[/URL]

If you wouldn't mind including the URL where you saw that, I can take a look. Or maybe it was somewhere in your specific account details or something?

Here's one:

[url]https://www.mersenne.org/report_exponent/?exp_lo=10611691&exp_hi=&full=1&ecmhist=1[/url]

[QUOTE=Prime95;516655]I don't think so. Do you still have the example?[/QUOTE]

I still have the save files, but unfortunately my computer has been having a problem where it would frequently freeze and restart on its own. I can barely use it for a few minutes before it crashes. I'll try to retrieve the save files after I get it fixed.

[QUOTE=ixfd64;516638]I noticed a minor inconsistency: Prime95 always appends two newlines to [C]results.bench.txt[/C] when it adds en entry. In the other results files, Prime95 only adds one newline at a time. I assume this is unintentional.[/QUOTE]

Possibly related issue: Prime95 sometimes appends a timestamp to [C]results.bench.txt[/C] even when there are no further benchmarks:

[QUOTE][Tue May 14 09:43:12 2019]
FFTlen=5120K, Type=3, Arch=4, Pass1=256, Pass2=20480, clm=4 (2 cores, 2 workers): 139.85, 145.95 ms. Throughput: 14.00 iter/sec.
FFTlen=5120K, Type=3, Arch=4, Pass1=256, Pass2=20480, clm=2 (2 cores, 2 workers): 77.50, 84.59 ms. Throughput: 24.73 iter/sec.
FFTlen=5120K, Type=3, Arch=4, Pass1=256, Pass2=20480, clm=1 (2 cores, 2 workers): 69.04, 79.34 ms. Throughput: 27.09 iter/sec.
FFTlen=5120K, Type=3, Arch=4, Pass1=320, Pass2=16384, clm=4 (2 cores, 2 workers): 67.16, 71.81 ms. Throughput: 28.82 iter/sec.
FFTlen=5120K, Type=3, Arch=4, Pass1=320, Pass2=16384, clm=2 (2 cores, 2 workers): 70.60, 72.47 ms. Throughput: 27.96 iter/sec.
FFTlen=5120K, Type=3, Arch=4, Pass1=320, Pass2=16384, clm=1 (2 cores, 2 workers): 76.72, 79.73 ms. Throughput: 25.58 iter/sec.
FFTlen=5120K, Type=3, Arch=4, Pass1=512, Pass2=10240, clm=4 (2 cores, 2 workers): 71.50, 78.28 ms. Throughput: 26.76 iter/sec.
FFTlen=5120K, Type=3, Arch=4, Pass1=512, Pass2=10240, clm=2 (2 cores, 2 workers): 67.50, 70.45 ms. Throughput: 29.01 iter/sec.
FFTlen=5120K, Type=3, Arch=4, Pass1=512, Pass2=10240, clm=1 (2 cores, 2 workers): 63.39, 66.65 ms. Throughput: 30.78 iter/sec.
FFTlen=5120K, Type=3, Arch=4, Pass1=640, Pass2=8192, clm=4 (2 cores, 2 workers): 74.18, 75.13 ms. Throughput: 26.79 iter/sec.
FFTlen=5120K, Type=3, Arch=4, Pass1=640, Pass2=8192, clm=2 (2 cores, 2 workers): 59.12, 66.70 ms. Throughput: 31.91 iter/sec.
FFTlen=5120K, Type=3, Arch=4, Pass1=640, Pass2=8192, clm=1 (2 cores, 2 workers): 67.94, 71.46 ms. Throughput: 28.71 iter/sec.
FFTlen=5120K, Type=3, Arch=4, Pass1=1024, Pass2=5120, clm=4 (2 cores, 2 workers): 76.80, 79.12 ms. Throughput: 25.66 iter/sec.
FFTlen=5120K, Type=3, Arch=4, Pass1=1024, Pass2=5120, clm=2 (2 cores, 2 workers): 80.23, 75.21 ms. Throughput: 25.76 iter/sec.
FFTlen=5120K, Type=3, Arch=4, Pass1=1024, Pass2=5120, clm=1 (2 cores, 2 workers): 70.73, 69.32 ms. Throughput: 28.56 iter/sec.
FFTlen=5120K, Type=3, Arch=4, Pass1=1280, Pass2=4096, clm=4 (2 cores, 2 workers): 74.33, 80.91 ms. Throughput: 25.81 iter/sec.
FFTlen=5120K, Type=3, Arch=4, Pass1=1280, Pass2=4096, clm=2 (2 cores, 2 workers): 62.55, 70.21 ms. Throughput: 30.23 iter/sec.
FFTlen=5120K, Type=3, Arch=4, Pass1=1280, Pass2=4096, clm=1 (2 cores, 2 workers): 63.12, 71.52 ms. Throughput: 29.83 iter/sec.
[Tue May 14 09:48:14 2019]

<EOF>[/QUOTE]

Prime95 main thread:

[QUOTE][Main thread May 14 09:42] Benchmarking multiple workers to tune FFT selection.
[Main thread May 14 09:42] Timing 5120K FFT, 2 cores, 2 workers. Average times: 139.85, 145.95 ms. Total throughput: 14.00 iter/sec.
[Main thread May 14 09:43] Timing 5120K FFT, 2 cores, 2 workers. Average times: 77.50, 84.59 ms. Total throughput: 24.73 iter/sec.
[Main thread May 14 09:43] Timing 5120K FFT, 2 cores, 2 workers. Average times: 69.04, 79.34 ms. Total throughput: 27.09 iter/sec.
[Main thread May 14 09:43] Timing 5120K FFT, 2 cores, 2 workers. Average times: 67.16, 71.81 ms. Total throughput: 28.82 iter/sec.
[Main thread May 14 09:44] Timing 5120K FFT, 2 cores, 2 workers. Average times: 70.60, 72.47 ms. Total throughput: 27.96 iter/sec.
[Main thread May 14 09:44] Timing 5120K FFT, 2 cores, 2 workers. Average times: 76.72, 79.73 ms. Total throughput: 25.58 iter/sec.
[Main thread May 14 09:44] Timing 5120K FFT, 2 cores, 2 workers. Average times: 71.50, 78.28 ms. Total throughput: 26.76 iter/sec.
[Main thread May 14 09:45] Timing 5120K FFT, 2 cores, 2 workers. Average times: 67.50, 70.45 ms. Total throughput: 29.01 iter/sec.
[Main thread May 14 09:45] Timing 5120K FFT, 2 cores, 2 workers. Average times: 63.39, 66.65 ms. Total throughput: 30.78 iter/sec.
[Main thread May 14 09:45] Timing 5120K FFT, 2 cores, 2 workers. Average times: 74.18, 75.13 ms. Total throughput: 26.79 iter/sec.
[Main thread May 14 09:45] Timing 5120K FFT, 2 cores, 2 workers. Average times: 59.12, 66.70 ms. Total throughput: 31.91 iter/sec.
[Main thread May 14 09:46] Timing 5120K FFT, 2 cores, 2 workers. Average times: 67.94, 71.46 ms. Total throughput: 28.71 iter/sec.
[Main thread May 14 09:46] Timing 5120K FFT, 2 cores, 2 workers. Average times: 76.80, 79.12 ms. Total throughput: 25.66 iter/sec.
[Main thread May 14 09:46] Timing 5120K FFT, 2 cores, 2 workers. Average times: 80.23, 75.21 ms. Total throughput: 25.76 iter/sec.
[Main thread May 14 09:47] Timing 5120K FFT, 2 cores, 2 workers. Average times: 70.73, 69.32 ms. Total throughput: 28.56 iter/sec.
[Main thread May 14 09:47] Timing 5120K FFT, 2 cores, 2 workers. Average times: 74.33, 80.91 ms. Total throughput: 25.81 iter/sec.
[Main thread May 14 09:47] Timing 5120K FFT, 2 cores, 2 workers. Average times: 62.55, 70.21 ms. Total throughput: 30.23 iter/sec.
[Main thread May 14 09:47] Timing 5120K FFT, 2 cores, 2 workers. Average times: 63.12, 71.52 ms. Total throughput: 29.83 iter/sec.
[Main thread May 14 09:48]
[Main thread May 14 09:48] Throughput benchmark complete.[/QUOTE]

When I run the new Mac OS X version 29.8b3 windows come up with black text on black backgrounds. If I select the text the background changes to blue and the text becomes visible. Im running the latest macOS Mojave version 10.14.4

[QUOTE=PhilF;516775]Here's one:

[url]https://www.mersenne.org/report_exponent/?exp_lo=10611691&exp_hi=&full=1&ecmhist=1[/url][/QUOTE]

Thanks. Fun little artifact of how the JSON result is being parsed. I can work on a fix for that later. With the non-JSON results I was just taking the text from the result as-is which had the correct work, but for JSON I must have been lazy and just used "curves" irrespective of how many. :smile:

[QUOTE=Madpoo;516857]Thanks. Fun little artifact of how the JSON result is being parsed. I can work on a fix for that later. With the non-JSON results I was just taking the text from the result as-is which had the correct work, but for JSON I must have been lazy and just used "curves" irrespective of how many. :smile:[/QUOTE]

Later? You mean this isn't a showstopper? :smile:

[QUOTE=PhilF;516859]Later? You mean this isn't a showstopper? :smile:[/QUOTE]

LOL... no. :smile:

But I did get it done. Had to juggle some code so I pull the # of curves out of the JSON first and then choose which word based on that, but simple enough. Testing it took longer.

[URL="https://www.mersenne.org/M10611691"]M10611691[/URL]

[QUOTE=brucix;516842]When I run the new Mac OS X version 29.8b3 windows come up with black text on black backgrounds. If I select the text the background changes to blue and the text becomes visible. Im running the latest macOS Mojave version 10.14.4[/QUOTE]

Thanks a lot :yucky:

I upgraded to Mojave. This broke xcode. The App Store won't download a new xcode.

I hate Apple....

[QUOTE=brucix;516842]When I run the new Mac OS X version 29.8b3 windows come up with black text on black backgrounds. If I select the text the background changes to blue and the text becomes visible. Im running the latest macOS Mojave version 10.14.4[/QUOTE]

Re-linking with the latest xcode magically fixed this. Hopefully, it will work for pre-Mojave users too.

Another example of why I hate Apple. They change the OS and don't care one whit that they break existing apps. At least they broke existing apps for a [B]hugely[/B] important feature.

I've got a few more suggestions:

1. If the user stops all workers, any already-stopped workers will display a message saying it's starting on the user's request followed by a second message saying it's stopped. This seems a bit redundant in my opinion. I've attached a screenshot for reference.

2. The default exponent for ECM and P-1 should be changed to something other than 1061 because M1061 was factored several years ago. Or even better: allow Prime95 to get the default exponent from the server.

3. On a related note: perhaps Prime95 could check for updates and notify the user. This would be especially useful if there is ever a reason to abandon an old version. The version 17 shift bug comes to mind here.

Another random low-priority suggestion:

PauseWhileRunning / LowMemWhileRunning show an appropriate message when <program> is running, but if there are multiple programs listed, and the first one detected (shown in the console message) is no longer running but another one is, the message is not changed. So you see
[i]Pausing because <ProgramA> is running[/i]
but it no longer is. Presumably this check happens every 10s or so - perhaps iff the previously-noted program is no longer running it could put out an additional console line saying the [i]current[/i] reason it's paused (or low-mem).

[QUOTE=James Heinrich;517118]Another random low-priority suggestion:

PauseWhileRunning / LowMemWhileRunning show an appropriate message when <program> is running, but if there are multiple programs listed, and the first one detected (shown in the console message) is no longer running but another one is, the message is not changed. So you see
[I]Pausing because <ProgramA> is running[/I]
but it no longer is. Presumably this check happens every 10s or so - perhaps iff the previously-noted program is no longer running it could put out an additional console line saying the [I]current[/I] reason it's paused (or low-mem).[/QUOTE]
PauseWhileRunning is a nice feature. It does not handle though, a situation I see leading to thermal shutdown of one of my systems. Antivirus/security software is always running, so it can't be in PauseWhileRunning if prime95 is to get anything done. Its cpu usage is very variable; mostly it's trivial, but it will saturate a core during a full system scan. Similarly backups and miscellaneous activity like multiple web browsers (especially a video stream) can push the system to cpu utilization that's more than it can handle thermally along with a throttled prime95 instance. It would be good if prime95 had an option PauseAboveLoad, where the load limit is the % cpu utilization by processes other than prime95 combined. Without it, I must manually pause prime95, and sometimes it gets forgotten for hours or days, or the thermal shutdown still gets initiated, despite prime95's throttle setting down to 20% now. If prime95 yielded entirely above a certain system load, I could probably raise the throttle value and get more throughput and fewer shutdowns.

After updating to 29.8b3 I see prime95 crushing often.

I do not get to see the error message, prime95 just stops running at some point, is anyone else having this issue?

I used backup files from previous version to continue (LL) tests using the new version.

[QUOTE=patgie;517257]After updating to 29.8b3 I see prime95 crushing often.

I do not get to see the error message, prime95 just stops running at some point, is anyone else having this issue?

I used backup files from previous version to continue (LL) tests using the new version.[/QUOTE]

What CPU? Are you overclocked? If you read threads like this one, you'll see that AVX-512 is not properly implemented on many motherboards, in terms of voltage control or turbo clock stepping. If you're overclocking, AVX-512 is the toughest load on the CPU and thus the best test of stability for your overclock.

If none of these apply, still provide some info about your hardware setup for those in the know to guess at your potential problem.

Version 29.8 runs AVX512 if your cpu supports it, while 29.4 and earlier uses AVX2/FMA. AVX512 is faster but more demanding for your CPU, check the temperature while running 29.8.

You can try disable AVX512 with this line in local.txt:
CpuSupportsAVX512F=0

If this helps then you know it is AVX512 causing it and you can maybe improve your cooling or check the BIOS for AVX512 settings that might be off.

[QUOTE=patgie;517257]After updating to 29.8b3 I see prime95 crushing often.

I do not get to see the error message, prime95 just stops running at some point, is anyone else having this issue?

I used backup files from previous version to continue (LL) tests using the new version.[/QUOTE]

Possibly related to this issue: [url]https://mersenneforum.org/showthread.php?t=24445[/url]

[QUOTE=ixfd64;517283]Possibly related to this issue: [url]https://mersenneforum.org/showthread.php?t=24445[/url][/QUOTE]

That's about right it is causing cudalucas to shut down too on the same machines.

Any way around it different than going back to the previous version?

I will try:

CpuSupportsAVX512F=0

it crushes while running simultaneously on my cpu i9 (prime95) + cudalucas on gpu

I have few laptops i5-i7 some with gpus running cudalucas that it would crush on too, no exceptions really sometimes it would be fine for days sometimes it would crush few hours after restarting

[QUOTE=patgie;517319]cudalucas[/QUOTE]
??

Did you try ATH's solution above?
Of course, on long term, you should fix your thermal issues, or bios (upgrade?), but right now, disabling the big AVX is the only way.

Cudalucas has nothing to do with it. Your CPU just crashes or goes into thermal lock. As long as you do not provide any info about the hardware (cpu/mobo/bios?) we can't help more...

[QUOTE=LaurV;517320]??

Did you try ATH's solution above?
Of course, on long term, you should fix your thermal issues, or bios (upgrade?), but right now, disabling the big AVX is the only way.

Cudalucas has nothing to do with it. Your CPU just crashes or goes into thermal lock. As long as you do not provide any info about the hardware (cpu/mobo/bios?) we can't help more...[/QUOTE]

i9 7940x 14x2 core 3.1ghz/
x299 ud4 pro/
f3

I am trying ATH solution, ms/iter went down from 1.5 to 1.8 I will be able to say if it is working after checking on other cpus later

[QUOTE=Prime95;517099]Re-linking with the latest xcode magically fixed this. Hopefully, it will work for pre-Mojave users too.[/QUOTE]

Mac OS X users: 29.8 build 4 now available for download

[QUOTE=ixfd64;517114]
3. On a related note: perhaps Prime95 could check for updates and notify the user. This would be especially useful if there is ever a reason to abandon an old version. The version 17 shift bug comes to mind here.[/QUOTE]

I mentioned this a few years ago too. Don't recall ever hearing much back. Perhaps Prime95 could act as a shell and download the latest executable automatically and alert the user to any manually required updates?

[QUOTE=rainchill;517371]I mentioned this a few years ago too. Don't recall ever hearing much back. Perhaps Prime95 could act as a shell and download the latest executable automatically and alert the user to any manually required updates?[/QUOTE]

Fifteen plus years ago, the community felt this was a bad idea. It was 1) viewed as a potential security risk and 2) viewed as a nuisance popping-up an "update now?" dialog box (especially if you've installed prime95 on a friends machine).

Nowadays, this behavior is commonplace. I suspect most people set to auto-update without notification or simply click yes to the numerous you-have-an-update-ready messages they get each week.

Thoughts on whether prime95 should rethink this old decision?

I think update notifications can be as simple as printing a message in the communication window the next time Prime95 connects to the server. Something like this will do:

[QUOTE]Prime95 <version number> is now available.
Get it from the GIMPS downloads page: [url]https://mersenne.org/download[/url][/QUOTE]

A pop-up window is fine but should probably be disabled by default. Users would be able to enable it by editing their [C]local.txt[/C] file.

[QUOTE=Prime95;517385]Thoughts on whether prime95 should rethink this old decision?[/QUOTE]

Any automated downloads must be encrypted. Unfortunately, the current manual download links all use http instead of https. If you want an https download you have to alter the URL yourself. If Madpoo is unwilling to make https the default even for manual updates, then this idea will go nowhere.

Even if that hurdle is overcome, it's still inadvisable. Although the very largest companies like Google and Microsoft know how to properly secure automatic updates, there are many cases of other companies failing to do so and allowing malware to infiltrate their users' hardware. A recent case in point: [URL="https://yro.slashdot.org/story/19/03/25/144248/hackers-hijacked-asus-software-updates-to-install-backdoors-on-thousands-of-computers"]ASUS[/URL].

Based on that track record, I think it will be impossible to get this right. And implementing this would just be a distraction in any case from continuous improvement of the core functionality.


Edit: in the ASUS case I linked, it seems it was actually the central download server that was hacked. But earlier there were numerous cases where the system software client and protocols that did the automated downloads were themselves insecure.

[QUOTE=Prime95;517385]Fifteen plus years ago, the community felt this was a bad idea. It was 1) viewed as a potential security risk and 2) viewed as a nuisance popping-up an "update now?" dialog box (especially if you've installed prime95 on a friends machine).

Nowadays, this behavior is commonplace. I suspect most people set to auto-update without notification or simply click yes to the numerous you-have-an-update-ready messages they get each week.

Thoughts on whether prime95 should rethink this old decision?[/QUOTE]
I don't want prime95/mprime joining in the objectionable behavior of Windows 10, downloading big updates many times, once per system, via my crappy slow unreliable DSL, when once per flavor to my file server for local install will do.

Also, are you ready to assume the responsibility for not performing an update when it will hammer (negate, abandon, start over) work in progress? With multiple worker windows, set to multiple work types, that could get interesting.

Any auto-update-only version will not be installed here.
[B].[/B]

I definitely think that automatic updates are more complicated than what we need. Simply notifying users is enough in my opinion.

[QUOTE=ixfd64;517393]I definitely think that automatic updates are more complicated than what we need. Simply notifying users is enough in my opinion.[/QUOTE]A notification per installation, or per user? Imagine curtisc getting one notification, or every U of Central Missouri PC popping up a notification.

Actual automated updating is fraught with complexity, and is both unnecessary and probably undesirable in many cases. However, notifying the user with a simple (but prominent) box at the top of the application would be simple and effective (crude sample attached). The link should be clickable; perhaps the notification should include something about the current version and possibly an option to hide the notification until a subsequent version is released (i.e. "skip this version").

And no pop-up notifications. Popups should only happen in response to direct user action, never automated. Simply having the notification in the app if and when the user looks at it is fine. Also offer an option on the website to sign up for email notification of new versions.

I like to mockup James put together. In my opinion there is a case to be made for annoying popups in the case of severely (1 year+) outdated software and/or in the instance of a bug which is severe enough to require an update.

Suggestions if updating is to be added:
If updating an existing install, assume no checking, no notifications, so it runs as always has.
If a new installation, put a passive indication asking to opt-in to updates. By passive, I mean it should take no user action to ignore it, not even a click to get rid of it. This could be a text message in the main window saying go to options to turn on update notifications for example. Maybe only show it on first run.
If a user opts-in to updates, include an option for notify only. I think most smaller software I use, if they have updates, give you a link to the download page. They don't do the download in client. It may also be those pages are full of adverts they want looking at, but that's another story...

[QUOTE=Prime95;517385]Thoughts on whether prime95 should rethink this old decision?[/QUOTE]

Yes, definitely need to rethink it. However, rather than update P95 / Primenet to do this, leverage existing platform that already does this -- BOINC!

[QUOTE=ixfd64;517386]I think update notifications can be as simple as printing a message in the communication window the next time Prime95 connects to the server. Something like this will do:



A pop-up window is fine but should probably be disabled by default. Users would be able to enable it by editing their [C]local.txt[/C] file.[/QUOTE]

This is a good idea. But I would rather have it as an option in gui for prime95. Maybe where you put in you username and proxy. A box you can klick in and you will get the popup info about new version and link to it. And only put stable and tested builds there.

Maybe also if you click ok you don't get it again until next build. Maybe you can make a check for really bad versions to make a recommended to upgrade because your version is bad popup. Just ideas.

For Debian Variants
 

For mprime, the Prime95 variant for Linux, you could create a deb file so users running a Debian variant such as Ubuntu could install it/uninstall it at will, as well as a PPA to install from. The advantages of a PPA would be that running apt update would see any upgrades to mprime. In addition, having it installed would make it easier to run mprime (for example, you wouldn't need to go to the folder mprime is in to run it). The only downside is in order to run multiple instances of mprime, some new option would be needed that set the current instance to run or some other way of doing it. Not sure if this has been suggested or what other detriments or obstacles to such a solution would be.

Linux distribution agnostic package
 

mprime's available now on [URL]https://flathub.org/apps/details/org.mersenne.mprime[/URL] (with optional steps at [URL]https://github.com/flathub/org.mersenne.mprime[/URL]) .


Can be kept up to date just like you'd do with any package manager.

[QUOTE=Prime95;517385]Fifteen plus years ago, the community felt this was a bad idea. It was 1) viewed as a potential security risk and 2) viewed as a nuisance popping-up an "update now?" dialog box (especially if you've installed prime95 on a friends machine).

Nowadays, this behavior is commonplace. I suspect most people set to auto-update without notification or simply click yes to the numerous you-have-an-update-ready messages they get each week.

Thoughts on whether prime95 should rethink this old decision?[/QUOTE]

I think something as simple as changing the color of the title bar and a message saying something like "an update is available" is as non-obtrusive as possible and leaves it up to the user what to do. No pop ups, no flashing things, etc. Just a little visual reminder.

On the server side all we'd really need to do is place a little txt file in the root, something like [url]www.mersenne.org/latetversion.txt[/url] that holds the value like "29.8b4".

Although at this point you really should consider using major.minor.build.revision versioning or whatever. Version 29.8b3 would be 29.8.3 -- it just makes comparing one version to another easier, with easy like "if 29.8.3 <= 29.8.4 then ..."

It gets weird doing that with text values. Is "29.8b3" <= "29.8b10" ? Of course you'd want to make sure you're using actual version comparisons because even then, if you're comparing versions as text you'll get funny results, like "29.10" would be considered less than "29.9" even though it's greater than.

[QUOTE=Madpoo;517502]I think something as simple as changing the color of the title bar and a message saying something like "an update is available" is as non-obtrusive as possible and leaves it up to the user what to do. No pop ups, no flashing things, etc. Just a little visual reminder.

On the server side all we'd really need to do is place a little txt file in the root, something like [URL="http://www.mersenne.org/latetversion.txt"]www.mersenne.org/latetversion.txt[/URL] that holds the value like "29.8b4".

Although at this point you really should consider using major.minor.build.revision versioning or whatever. Version 29.8b3 would be 29.8.3 -- it just makes comparing one version to another easier, with easy like "if 29.8.3 <= 29.8.4 then ..."

It gets weird doing that with text values. Is "29.8b3" <= "29.8b10" ? Of course you'd want to make sure you're using actual version comparisons because even then, if you're comparing versions as text you'll get funny results, like "29.10" would be considered less than "29.9" even though it's greater than.[/QUOTE]
Perhaps make it moot by making versioning a decimal real:
29.048 (instead of 29.4b8)
29.083 (instead of 29.8b3)
29.084
29.092
29.101
Are there ever more than 9 separately numbered builds of x.y?
I just checked, and did not find a 29.8b4 to download.
[URL]https://www.mersenneforum.org/showpost.php?p=508841&postcount=1[/URL] is all 29.8b3
although [URL]https://www.mersenneforum.org/showpost.php?p=508842&postcount=2[/URL] makes at least 4 references to 29.8b4

No, just leave the version number as-is (29.10b17) and let the single function inside Prime95.exe worry about appropriate version-compare functionality.
Speaking of which, consideration may be needed to "most-current" version number for different OSs that are not always in sync.

[QUOTE=James Heinrich;517509]No, just leave the version number as-is (29.10b17) and let the single function inside Prime95.exe worry about appropriate version-compare functionality.
Speaking of which, consideration may be needed to "most-current" version number for different OSs that are not always in sync.[/QUOTE]

My frustration with version numbers comes from my recent work dealing with Dell firmware revisions. Older systems have versions like A13, A27, etc. At least doing a simple <= is easy.

New systems use major.minor.build like 1.3.12 which is fine, but when working with different models that use one or the other, I can't use the same code because then 1.3.12 would compute as less than 1.3.8 which is wrong.

To work around it in powershell I can do a [system.version] thing which will do proper comparisons of each part of the version string. It's actually pretty nice.

The thing with major.minor.build.revision is that it's very common. I don't know if I'd go so far as to say it's a standard (although it may be close, or a de-facto standard) because there are clearly plenty of counter examples.

What is *uncommon* is the way Prime95 builds are numbered, with a curious mix of major.minor and then the "b" followed by build. Maybe it was more common a decade or two ago.

It only bugs me (and let's be clear, it's not like it's a major annoyance, just one of those nits to pick) when doing string comparisons to see if a version is greater or less than some reference. String comparisons do funny things. Or rather, they work exactly as they should, but not how humans [I]think[/I] they should work. :smile:

[QUOTE=kriesel;517507]Perhaps make it moot by making versioning a decimal real:
29.048 (instead of 29.4b8)
29.083 (instead of 29.8b3)
29.084
29.092
29.101
Are there ever more than 9 separately numbered builds of x.y?[/QUOTE]This would be a good idea, it could be something like 29.09.04.
At the moment the "File version" of prime95.exe version 29.8 build 3 is 29.8.1.0 and the "Program Version" is 29.8.0.0. This discrepancy (the file properties not being updated) occurred in the past as well.
[QUOTE=kriesel;517507]I just checked, and did not find a 29.8b4 to download.
[URL]https://www.mersenneforum.org/showpost.php?p=508841&postcount=1[/URL] is all 29.8b3
although [URL]https://www.mersenneforum.org/showpost.php?p=508842&postcount=2[/URL] makes at least 4 references to 29.8b4[/QUOTE]29.8b4 is for Mac OSX only and it is available at [url]ftp://mersenne.org/gimps[/url]. As James remarked, sometimes a particular flavour of Prime95 needs an intermediary build.

Jacob

[QUOTE=kriesel;517507]Perhaps make it moot by making versioning a decimal real:
29.048 (instead of 29.4b8)
29.083 (instead of 29.8b3)
29.084
29.092
29.101
Are there ever more than 9 separately numbered builds of x.y?
[/QUOTE]


[url]https://semver.org[/url] seems a good alternative.

I guess Intel has pulled a page out of AMD's playbook.

Some of their mid/low range Xeon CPU's have only one AVX-512 execution unit instead of two. When LLR runs AVX-512 on these CPUs, it's significantly slower than the FMA3 transform. Although we haven't tried it, presumably P95 exhibits the same behavior.

The bottom line is that right now, if you run on some AVX-512 CPUs, you get a significant increase in performance, while on others, you get a significant decrease in performance.

I'm not sure if the software can be adapted to get better performance on single-unit AVX-512 CPUs, or if using FMA3 is the better option.

Details can be found over in the LLR thread: [url]https://www.mersenneforum.org/showpost.php?p=517508&postcount=7[/url]

(Before someone inevitably suggests it, LLR lacks the CpuSupportsAVX512F flag, so it can't be disabled.)

[QUOTE=Prime95;517385]Fifteen plus years ago, the community felt this was a bad idea. It was 1) viewed as a potential security risk and 2) viewed as a nuisance popping-up an "update now?" dialog box (especially if you've installed prime95 on a friends machine).

Nowadays, this behavior is commonplace. I suspect most people set to auto-update without notification or simply click yes to the numerous you-have-an-update-ready messages they get each week.

Thoughts on whether prime95 should rethink this old decision?[/QUOTE]

Keep it simple. There is no need to spoon feed people who are too lazy to update manually.
Let them eat cake. Just keep things nice and working as they are, with your hard work you've done over the years. No need to join in on the "auto connected" cloud bangwagon ;)

I, for one, definitely vote for some sort of notification, be it in the communication log or somewhere else, notifying me of a new available version. I don't necessarily look at the site to see if there is a new version, so I usually don't know if there is one until I think to check, which is rare. Though I do agree it should be opt-in. However, I'm curious how this would be back-propagated to the older versions of the software this is meant to target. As in, how would the older versions know they are being told to inform the user of an available update if they weren't programmed to have that feature? In addition, could there be an option for people who like to test beta versions of Prime95 to get a notification for a new beta build?

Integrated updaters are messy, uncomfortable to use and pointless IMO. Subscribing to the unix philosophy of doing one thing and doing it well, updating is a package managers job so a package manager if anything should do it. Ideally I'd go so far as having the primenet communication handled by a separate utility, as nice as it is to have rich communication embedded in prime95 it would be nicer to have rich communication available to all programs without them having to reinvent the wheel.

[QUOTE=S485122;517533]
29.8b4 is for Mac OSX only and it is available at [URL]ftp://mersenne.org/gimps[/URL]. As James remarked, sometimes a particular flavour of Prime95 needs an intermediary build.

Jacob[/QUOTE]Thanks for your response. [url]https://www.mersenneforum.org/showpost.php?p=508842&postcount=2[/url] lists four issues fixed in 29.8b4, only one of which is identified as Mac specific; another is linux specific; two appear to be generic.

I found a hang issue for Torture Test, which is reproducible in my machine.
(7980XE, Windows 10, p95v298b3.win64)

"Right after OS boot", I run the Torture Test.
But some workers did not start. (Worker#19)
After that, I stopped the test. Then it hung.

Long after OS boot, it does not seem to occur.

You should "only" use 18 workers.

The i9-7980XE has 18 cores but 36 threads using hyperthreading.

But hyperthreading is not useful for Prime95, it is meant for low demanding tasks where 2 threads can share 1 physical core because each thread is not running 100% of the time.

In mprime 29.8b3 I had: WorkPreference=101 in prime.txt which used to be "double check" but the server gave me a 80M PRPDC, which should be WorkPreference=151 ?

Is this intentional? The priority should be to work on LL DC before PRP DC?

[QUOTE=ATH;518362]In mprime 29.8b3 I had: WorkPreference=101 in prime.txt which used to be "double check" but the server gave me a 80M PRPDC, which should be WorkPreference=151 ?

Is this intentional? The priority should be to work on LL DC before PRP DC?[/QUOTE]

The server will default to PRP checks for client versions 29.8b3 and higher. I wasn't sure if the release notes said that was just for first-time or not... it seems like if you are looking for double-checks, you're probably not wanting to do DC of first-time PRP checks since those are going to be much larger exponents.

I'll let George address that, but it seems strange at first glance.

Yeah, that should be changed because PRPDC is much lower priority than LL DC because of the much higher exponents and because of the increased error checking.

Well, i'm not really sure that this is the place to report bugs, but it seems to be a good spot.


I recently got a ryzen 2600 to test and play with from time to time and i tried to use prime95 for some stress testing like i always do. But on the newer Versions i get errors right after the start as long as i select 'just stress testing' or 'join gimps' in the first startup dialogue.
p95v298b3.win64
[CODE]Problemereignisname: APPCRASH
Anwendungsname(application name): prime95.exe
Anwendungsversion(application version): 29.8.1.0
Anwendungszeitstempel(application timestamp): 5cbe72a3
Fehlermodulname('error module name'): prime95.exe
Fehlermodulversion('error module version'): 29.8.1.0
Fehlermodulzeitstempel('error module timestamp'): 5cbe72a3
Ausnahmecode(error code): c0000094
Ausnahmeoffset(error offset?relative memory position?): 00000000000160de[/CODE]
the error code is the same for p95v298b3.win32, p95v297b1.win64, p95v296b7.win64
p95v295b9.win64 worked/is wiorking

everything running on win7, neither cpu nor memory overclocked aside from the 'usual' turbo and xmp

[QUOTE=Bigeagle;518698]Well, i'm not really sure that this is the place to report bugs, but it seems to be a good spot.


I recently got a ryzen 2600 to test and play with from time to time and i tried to use prime95 for some stress testing like i always do. But on the newer Versions i get errors right after the start as long as i select 'just stress testing' or 'join gimps' in the first startup dialogue.
p95v298b3.win64
[CODE]Problemereignisname: APPCRASH
Anwendungsname(application name): prime95.exe
Anwendungsversion(application version): 29.8.1.0
Anwendungszeitstempel(application timestamp): 5cbe72a3
Fehlermodulname('error module name'): prime95.exe
Fehlermodulversion('error module version'): 29.8.1.0
Fehlermodulzeitstempel('error module timestamp'): 5cbe72a3
Ausnahmecode(error code): c0000094
Ausnahmeoffset(error offset?relative memory position?): 00000000000160de[/CODE]
the error code is the same for p95v298b3.win32, p95v297b1.win64, p95v296b7.win64
p95v295b9.win64 worked/is wiorking

everything running on win7, neither cpu nor memory overclocked aside from the 'usual' turbo and xmp[/QUOTE]

Have you checked sha256 for it?

Well, no. I did it now for the p95v298b3.win64.zip as the checksum is provided in the download section and it matches
here - [url]ftp://mersenne.org/gimps/[/url] - i didn't find any checksums so i don't know how to check the older versions.

[QUOTE=Bigeagle;518698]
I recently got a ryzen 2600 to test and play with from time to time and i tried to use prime95 for some stress testing like i always do. But on the newer Versions i get errors right after the start as long as i select 'just stress testing' or 'join gimps' in the first startup dialogue.
p95v298b3.win64

the error code is the same for p95v298b3.win32, p95v297b1.win64, p95v296b7.win64
p95v295b9.win64 worked/is wiorking[/QUOTE]

Clearly a program bug.

Please run a benchmark in p95v295b9.win64. Abort it as soon as it starts. In results.txt (or results.bench.txt) you should see hwloc's dump of the Ryzen architecture. Can you post that please?

AMD Ryzen 5 2600 Six-Core Processor
CPU speed: 3792.95 MHz, 6 hyperthreaded cores
CPU features: 3DNow! Prefetch, SSE, SSE2, SSE4, AVX, AVX2, FMA
L1 cache size: 12x32 KB, L2 cache size: 12x512 KB, L3 cache size: 12x16 MBL1 cache line size: 64 bytes
L2 cache line size: 64 bytes
Machine topology as determined by hwloc library:
Machine#0 (total=28201712KB, Backend=Windows, hwlocVersion=2.0.3, ProcessName=prime95.exe)
Package (total=28201712KB, CPUVendor=AuthenticAMD, CPUFamilyNumber=23, CPUModelNumber=8, CPUModel="AMD Ryzen 5 2600 Six-Core Processor ", CPUStepping=2)
Core (cpuset: 0x00000003)
L3 (size=16384KB, linesize=64, ways=16, Inclusive=0)
L2 (size=512KB, linesize=64, ways=8, Inclusive=1)
L1d (size=32KB, linesize=64, ways=8, Inclusive=0)
PU#0 (cpuset: 0x00000001)
L3 (size=16384KB, linesize=64, ways=16, Inclusive=0)
L2 (size=512KB, linesize=64, ways=8, Inclusive=1)
L1d (size=32KB, linesize=64, ways=8, Inclusive=0)
PU#1 (cpuset: 0x00000002)
Core (cpuset: 0x0000000c)
L3 (size=16384KB, linesize=64, ways=16, Inclusive=0)
L2 (size=512KB, linesize=64, ways=8, Inclusive=1)
L1d (size=32KB, linesize=64, ways=8, Inclusive=0)
PU#2 (cpuset: 0x00000004)
L3 (size=16384KB, linesize=64, ways=16, Inclusive=0)
L2 (size=512KB, linesize=64, ways=8, Inclusive=1)
L1d (size=32KB, linesize=64, ways=8, Inclusive=0)
PU#3 (cpuset: 0x00000008)
Core (cpuset: 0x00000030)
L3 (size=16384KB, linesize=64, ways=16, Inclusive=0)
L2 (size=512KB, linesize=64, ways=8, Inclusive=1)
L1d (size=32KB, linesize=64, ways=8, Inclusive=0)
PU#4 (cpuset: 0x00000010)
L3 (size=16384KB, linesize=64, ways=16, Inclusive=0)
L2 (size=512KB, linesize=64, ways=8, Inclusive=1)
L1d (size=32KB, linesize=64, ways=8, Inclusive=0)
PU#5 (cpuset: 0x00000020)
Core (cpuset: 0x000000c0)
L3 (size=16384KB, linesize=64, ways=16, Inclusive=0)
L2 (size=512KB, linesize=64, ways=8, Inclusive=1)
L1d (size=32KB, linesize=64, ways=8, Inclusive=0)
PU#6 (cpuset: 0x00000040)
L3 (size=16384KB, linesize=64, ways=16, Inclusive=0)
L2 (size=512KB, linesize=64, ways=8, Inclusive=1)
L1d (size=32KB, linesize=64, ways=8, Inclusive=0)
PU#7 (cpuset: 0x00000080)
Core (cpuset: 0x00000300)
L3 (size=16384KB, linesize=64, ways=16, Inclusive=0)
L2 (size=512KB, linesize=64, ways=8, Inclusive=1)
L1d (size=32KB, linesize=64, ways=8, Inclusive=0)
PU#8 (cpuset: 0x00000100)
L3 (size=16384KB, linesize=64, ways=16, Inclusive=0)
L2 (size=512KB, linesize=64, ways=8, Inclusive=1)
L1d (size=32KB, linesize=64, ways=8, Inclusive=0)
PU#9 (cpuset: 0x00000200)
Core (cpuset: 0x00000c00)
L3 (size=16384KB, linesize=64, ways=16, Inclusive=0)
L2 (size=512KB, linesize=64, ways=8, Inclusive=1)
L1d (size=32KB, linesize=64, ways=8, Inclusive=0)
PU#10 (cpuset: 0x00000400)
L3 (size=16384KB, linesize=64, ways=16, Inclusive=0)
L2 (size=512KB, linesize=64, ways=8, Inclusive=1)
L1d (size=32KB, linesize=64, ways=8, Inclusive=0)
PU#11 (cpuset: 0x00000800)
Prime95 64-bit version 29.5, RdtscTiming=1

I assume this is what you meant.

[QUOTE=Bigeagle;518719]I assume this is what you meant.[/QUOTE]

Yes.

I'm pretty sure you are a victim of bug #19 in the second post of this thread. Since I have not released a win64 29.8 build 4, the only workaround would be to add "NumCpus=12" to local.txt.

But first --- I don't like hwloc's description of your hardware. Please go to
[url]https://www.open-mpi.org/software/hwloc/v2.0/[/url] and get 2.0.4rc1. Rerun the benchmark and see if the hwloc description changes for the better.

The Workaround worked. I just get offered to run 24 workers by default :)


AMD Ryzen 5 2600 Six-Core Processor
CPU speed: 3473.40 MHz, 6 hyperthreaded cores
CPU features: 3DNow! Prefetch, SSE, SSE2, SSE4, AVX, AVX2, FMA
L1 cache size: 12x32 KB, L2 cache size: 12x512 KB, L3 cache size: 12x16 MBL1 cache line size: 64 bytes
L2 cache line size: 64 bytes
Machine topology as determined by hwloc library:
Machine#0 (total=27862856KB, Backend=Windows, hwlocVersion=2.0.4rc1, ProcessName=prime95.exe)
Package (total=27862856KB, CPUVendor=AuthenticAMD, CPUFamilyNumber=23, CPUModelNumber=8, CPUModel="AMD Ryzen 5 2600 Six-Core Processor ", CPUStepping=2)
Core (cpuset: 0x00000003)
L3 (size=16384KB, linesize=64, ways=16, Inclusive=0)
L2 (size=512KB, linesize=64, ways=8, Inclusive=1)
L1d (size=32KB, linesize=64, ways=8, Inclusive=0)
PU#0 (cpuset: 0x00000001)
L3 (size=16384KB, linesize=64, ways=16, Inclusive=0)
L2 (size=512KB, linesize=64, ways=8, Inclusive=1)
L1d (size=32KB, linesize=64, ways=8, Inclusive=0)
PU#1 (cpuset: 0x00000002)
Core (cpuset: 0x0000000c)
L3 (size=16384KB, linesize=64, ways=16, Inclusive=0)
L2 (size=512KB, linesize=64, ways=8, Inclusive=1)
L1d (size=32KB, linesize=64, ways=8, Inclusive=0)
PU#2 (cpuset: 0x00000004)
L3 (size=16384KB, linesize=64, ways=16, Inclusive=0)
L2 (size=512KB, linesize=64, ways=8, Inclusive=1)
L1d (size=32KB, linesize=64, ways=8, Inclusive=0)
PU#3 (cpuset: 0x00000008)
Core (cpuset: 0x00000030)
L3 (size=16384KB, linesize=64, ways=16, Inclusive=0)
L2 (size=512KB, linesize=64, ways=8, Inclusive=1)
L1d (size=32KB, linesize=64, ways=8, Inclusive=0)
PU#4 (cpuset: 0x00000010)
L3 (size=16384KB, linesize=64, ways=16, Inclusive=0)
L2 (size=512KB, linesize=64, ways=8, Inclusive=1)
L1d (size=32KB, linesize=64, ways=8, Inclusive=0)
PU#5 (cpuset: 0x00000020)
Core (cpuset: 0x000000c0)
L3 (size=16384KB, linesize=64, ways=16, Inclusive=0)
L2 (size=512KB, linesize=64, ways=8, Inclusive=1)
L1d (size=32KB, linesize=64, ways=8, Inclusive=0)
PU#6 (cpuset: 0x00000040)
L3 (size=16384KB, linesize=64, ways=16, Inclusive=0)
L2 (size=512KB, linesize=64, ways=8, Inclusive=1)
L1d (size=32KB, linesize=64, ways=8, Inclusive=0)
PU#7 (cpuset: 0x00000080)
Core (cpuset: 0x00000300)
L3 (size=16384KB, linesize=64, ways=16, Inclusive=0)
L2 (size=512KB, linesize=64, ways=8, Inclusive=1)
L1d (size=32KB, linesize=64, ways=8, Inclusive=0)
PU#8 (cpuset: 0x00000100)
L3 (size=16384KB, linesize=64, ways=16, Inclusive=0)
L2 (size=512KB, linesize=64, ways=8, Inclusive=1)
L1d (size=32KB, linesize=64, ways=8, Inclusive=0)
PU#9 (cpuset: 0x00000200)
Core (cpuset: 0x00000c00)
L3 (size=16384KB, linesize=64, ways=16, Inclusive=0)
L2 (size=512KB, linesize=64, ways=8, Inclusive=1)
L1d (size=32KB, linesize=64, ways=8, Inclusive=0)
PU#10 (cpuset: 0x00000400)
L3 (size=16384KB, linesize=64, ways=16, Inclusive=0)
L2 (size=512KB, linesize=64, ways=8, Inclusive=1)
L1d (size=32KB, linesize=64, ways=8, Inclusive=0)
PU#11 (cpuset: 0x00000800)
Prime95 64-bit version 29.5, RdtscTiming=1


just out of curiosity, what is wrong with the description? aside from the odd 12x16 MB L3. That would be a nice thing to have.

[QUOTE=Bigeagle;518768]
just out of curiosity, what is wrong with the description? aside from the odd 12x16 MB L3. That would be a nice thing to have.[/QUOTE]

Correct, hwloc is reporting far too many caches.

[QUOTE=Bigeagle;518768]
AMD Ryzen 5 2600 Six-Core Processor

just out of curiosity, what is wrong with the description? aside from the odd 12x16 MB L3. That would be a nice thing to have.[/QUOTE]

I opened a bug report with hwloc developers. They request the output of "coreinfo -cgnlsm".

Their initial guess is that version of the OS does not support this Ryzen well (yet).

[QUOTE=Prime95;516107]Also, I just tweaked the get-assignment server code for "what makes the most sense" prime95 clients.[/QUOTE]

Silly question: do newer versions still automatically get LL double-check assignments on new computers?

well, it's a win7 prof 64 bit, so a little suboptimal support is to be expected i guess


[CODE]Coreinfo v3.31 - Dump information on system CPU and memory topology
Copyright (C) 2008-2014 Mark Russinovich
Sysinternals - [URL="http://www.sysinternals.com"]www.sysinternals.com[/URL]

Logical to Physical Processor Map:
**---------- Physical Processor 0 (Hyperthreaded)
--**-------- Physical Processor 1 (Hyperthreaded)
----**------ Physical Processor 2 (Hyperthreaded)
------**---- Physical Processor 3 (Hyperthreaded)
--------**-- Physical Processor 4 (Hyperthreaded)
----------** Physical Processor 5 (Hyperthreaded)

Logical Processor to Socket Map:
************ Socket 0

Logical Processor to NUMA Node Map:
************ NUMA Node 0

No NUMA nodes.

Logical Processor to Cache Map:
*----------- Data Cache 0, Level 1, 32 KB, Assoc 8, LineSize 64
*----------- Instruction Cache 0, Level 1, 64 KB, Assoc 4, LineSize 64
*----------- Unified Cache 0, Level 2, 512 KB, Assoc 8, LineSize 64
*----------- Unified Cache 1, Level 3, 16 MB, Assoc 16, LineSize 64
-*---------- Data Cache 1, Level 1, 32 KB, Assoc 8, LineSize 64
-*---------- Instruction Cache 1, Level 1, 64 KB, Assoc 4, LineSize 64
-*---------- Unified Cache 2, Level 2, 512 KB, Assoc 8, LineSize 64
-*---------- Unified Cache 3, Level 3, 16 MB, Assoc 16, LineSize 64
--*--------- Data Cache 2, Level 1, 32 KB, Assoc 8, LineSize 64
--*--------- Instruction Cache 2, Level 1, 64 KB, Assoc 4, LineSize 64
--*--------- Unified Cache 4, Level 2, 512 KB, Assoc 8, LineSize 64
--*--------- Unified Cache 5, Level 3, 16 MB, Assoc 16, LineSize 64
---*-------- Data Cache 3, Level 1, 32 KB, Assoc 8, LineSize 64
---*-------- Instruction Cache 3, Level 1, 64 KB, Assoc 4, LineSize 64
---*-------- Unified Cache 6, Level 2, 512 KB, Assoc 8, LineSize 64
---*-------- Unified Cache 7, Level 3, 16 MB, Assoc 16, LineSize 64
----*------- Data Cache 4, Level 1, 32 KB, Assoc 8, LineSize 64
----*------- Instruction Cache 4, Level 1, 64 KB, Assoc 4, LineSize 64
----*------- Unified Cache 8, Level 2, 512 KB, Assoc 8, LineSize 64
----*------- Unified Cache 9, Level 3, 16 MB, Assoc 16, LineSize 64
-----*------ Data Cache 5, Level 1, 32 KB, Assoc 8, LineSize 64
-----*------ Instruction Cache 5, Level 1, 64 KB, Assoc 4, LineSize 64
-----*------ Unified Cache 10, Level 2, 512 KB, Assoc 8, LineSize 64
-----*------ Unified Cache 11, Level 3, 16 MB, Assoc 16, LineSize 64
------*----- Data Cache 6, Level 1, 32 KB, Assoc 8, LineSize 64
------*----- Instruction Cache 6, Level 1, 64 KB, Assoc 4, LineSize 64
------*----- Unified Cache 12, Level 2, 512 KB, Assoc 8, LineSize 64
------*----- Unified Cache 13, Level 3, 16 MB, Assoc 16, LineSize 64
-------*---- Data Cache 7, Level 1, 32 KB, Assoc 8, LineSize 64
-------*---- Instruction Cache 7, Level 1, 64 KB, Assoc 4, LineSize 64
-------*---- Unified Cache 14, Level 2, 512 KB, Assoc 8, LineSize 64
-------*---- Unified Cache 15, Level 3, 16 MB, Assoc 16, LineSize 64
--------*--- Data Cache 8, Level 1, 32 KB, Assoc 8, LineSize 64
--------*--- Instruction Cache 8, Level 1, 64 KB, Assoc 4, LineSize 64
--------*--- Unified Cache 16, Level 2, 512 KB, Assoc 8, LineSize 64
--------*--- Unified Cache 17, Level 3, 16 MB, Assoc 16, LineSize 64
---------*-- Data Cache 9, Level 1, 32 KB, Assoc 8, LineSize 64
---------*-- Instruction Cache 9, Level 1, 64 KB, Assoc 4, LineSize 64
---------*-- Unified Cache 18, Level 2, 512 KB, Assoc 8, LineSize 64
---------*-- Unified Cache 19, Level 3, 16 MB, Assoc 16, LineSize 64
----------*- Data Cache 10, Level 1, 32 KB, Assoc 8, LineSize 64
----------*- Instruction Cache 10, Level 1, 64 KB, Assoc 4, LineSize 64
----------*- Unified Cache 20, Level 2, 512 KB, Assoc 8, LineSize 64
----------*- Unified Cache 21, Level 3, 16 MB, Assoc 16, LineSize 64
-----------* Data Cache 11, Level 1, 32 KB, Assoc 8, LineSize 64
-----------* Instruction Cache 11, Level 1, 64 KB, Assoc 4, LineSize 64
-----------* Unified Cache 22, Level 2, 512 KB, Assoc 8, LineSize 64
-----------* Unified Cache 23, Level 3, 16 MB, Assoc 16, LineSize 64

Logical Processor to Group Map:
************ Group 0[/CODE]

[QUOTE=Bigeagle;518847]well, it's a win7 prof 64 bit, so a little suboptimal support is to be expected i guess[/QUOTE]

From hwloc developers:

[QUOTE]coreinfo has the same bug, this likely confirms that the bug is in windows. You may want to update your windows since this processor is very recent.
[/QUOTE]

thanks for your help :)
sadly updating is always a nasty thing since microsoft did some ... strange things to their update mechanism in win7 so it's always likely to fail without manual help and absolutely needs a full backup
i think i will try that if i got some time


probably the easiest thing concerning this (and other problems) would be to get a still supported OS, but linux is out of question on this machine (would be so easy ...) and win10 is uhm ... troublesome of it's own. at least in my personal opinion

let alone all that hassle with the updates there. sometime in the future when the owner is forced to drop win7 things will get very 'interesting' ^^
until then i'm happy if it works without too much problems since i'm the 'tech guy'

As a note, hwloc 2.0.4 is now the latest stable release: [url]https://www.open-mpi.org/software/hwloc/v2.0[/url]

[QUOTE=Bigeagle;518891]thanks for your help :)
sadly updating is always a nasty thing since microsoft did some ... strange things to their update mechanism in win7 so it's always likely to fail without manual help and absolutely needs a full backup
i think i will try that if i got some time


probably the easiest thing concerning this (and other problems) would be to get a still supported OS, but linux is out of question on this machine (would be so easy ...) and win10 is uhm ... troublesome of it's own. at least in my personal opinion

let alone all that hassle with the updates there. sometime in the future when the owner is forced to drop win7 things will get very 'interesting' ^^
until then i'm happy if it works without too much problems since i'm the 'tech guy'[/QUOTE]

Side note: I've been working on a little project to update systems from Win7 to Win10, and it actually works pretty well.

The trickiest part is converting the system itself to UEFI since that involves running mbr2gpt once the update is done, and then making sure to change the appropriate BIOS settings to match. Of course, that's if you care about UEFI... you may not.

The OS update itself though... pretty solid in my experience.

May you add support to FMA4 FFT and XOP FFT for Bulldozer?

[QUOTE=Bulldozer;519338]May you add support to FMA4 FFT and XOP FFT for Bulldozer?[/QUOTE]

I believe they would add very little over FMA3. They are also no longer supported on new CPUs.

[QUOTE=Prime95;516655]I don't think so. Do you still have the example?[/QUOTE]

I've uploaded a "bad" P-1 save file here: [url]https://workupload.com/file/EPLrREPc[/url]

I suspect the issue is related to what Kriesel is seeing: [url]https://mersenneforum.org/showpost.php?p=508877&postcount=4[/url]