[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?