[QUOTE=GP2;472083]But this is at compile time only. It needs a runtime check, to check the version of the shared library. So the global variable gmp_version is needed instead.[/QUOTE]And using a string for what is essentially a number is such bad practice IMO.

[size=1]Sorry, [/rant] on the state of software development these days.[/size] :sad:

[QUOTE=GP2;472083]But this is at compile time only. It needs a runtime check, to check the version of the shared library. So the global variable gmp_version is needed instead.[/QUOTE]

Ok then this should work:

[CODE]sscanf(gmp_version,"%i.%i",&ver,&mver);
if ((ver<5) || (ver==5 && mver<1)) { jacobi_check=0; }[/CODE]or this longer "manual" way without using "sscanf":

[CODE]
ver=0; mver=0; i=0;
while(gmp_version[i]>=48 && gmp_version[i]<=57) { ver=ver*10+gmp_version[i]-48; i++; }
i++;
while(gmp_version[i]>=48 && gmp_version[i]<=57) { mver=mver*10+gmp_version[i]-48; i++; }
if ((ver<5) || (ver==5 && mver<1)) { jacobi_check=0; }
[/CODE]

Edit: Fixed "gmp_version[i]>=48 && gmp_version[i]<=57" instead of "gmp_version[i]>48 && gmp_version[i]<57

[QUOTE=kruoli;471896]If you have set your [I]Iterations between screen outputs[/I] by chance to exactly the number of iterations to be done, the following will happen:
[CODE][Worker #1 Nov 15 19:48] Iteration: 100000 / 100000 [100.00%], roundoff: 0.070, ms/iter: 0.026, ETA: 30:25:40[/CODE]
Of course the ETA should be nearly zero or equal to zero.[/QUOTE]

Off by one bug. Fixed next release.

One issue. If you do a manual benchmark then it always offers to use 4 cores and you have to change it each time.

These are my settings:

prime.txt
...
MinBenchFFT=2688
MaxBenchFFT=2688
BenchErrorCheck=0
BenchAllComplex=0
OnlyBench5678=0
BenchCores=3
BenchHyperthreads=1
BenchWorkers=1
AllBench=1
BenchTime=15

local.txt:
...
CoresPerTest=3

[QUOTE=Madpoo;472035]The download page has just been updated... v29.4 build 5 is now the official build. George gave his stamp of approval...

Enjoy!
[URL]https://www.mersenne.org/download/[/URL][/QUOTE]

I did a complete torture test with no warnings or errors. This was a follow-up to some issues I had because of an incorrect BIOS setting. Prime95 alerted me to something being wrong. "10" v1709 was doing cold reboots. I reset the BIOS to its defaults. There were no more issues.

How is the runtime of PRP compared to LL on the same exponent?
And which should I do, PRP or LL?

[QUOTE=heliosh;472416]How is the runtime of PRP compared to LL on the same exponent?
And which should I do, PRP or LL?[/QUOTE]

PRP adds a little time to testing but is by far more reliable -- not so prone to hardware errors such as those caused by cosmic rays. Run PRP!

I ran a PRP DC which finished recently. No problem there.

The problem is that even though I have selected the cpu to resume TF rather than PRP, it will not stop getting another PRP exponent.

I have to obtain a fresh batch of manual TFs and then unselect the PRP exponent. I then edit the worktodo.ini file, removing the PRP exponent, and adding in the new manually obtained exponents. Then after having restarted Prime95 I do a manual communictation.

Is there somewhere else I have to go to stop Prime95 grabbing another unwanted PRP exponent?

Running 29.4 build 5 on my Mac

[QUOTE=bayanne;472647]The problem is that even though I have selected the cpu to resume TF rather than PRP, it will not stop getting another PRP exponent.[/QUOTE]

How long did you wait before switching the type of work?

There is a parameter called "DaysOfWork" in the prime.txt file. If it's set to, for example, "3", then three days before the program estimates that it will finish the last assignment in the worktodo file, it will fetch one or more new assignments.

The idea is to store up three day's worth of work ahead of time (in this example), just in case a network interruption or server outage is happening when the final assignment finishes, which would then leave your computer idle and unable to fetch a new assignment.

DaysOfWork is set at 1

[QUOTE=bayanne;472652]DaysOfWork is set at 1[/QUOTE]

Same principle applies. If the program estimates that there are less than 24 hours to go before all the existing assignments in worktodo are completed, it will fetch one or more assignments.

So maybe the question should be: Did P95 fetch the PRP before or after the work preference was changed?

Go to the mersenne.org web pages. Under the CPUs page make sure the work preference is set properly for that CPU.

The tail of prime.log might indicate what went wrong. At some point it should have sent your new work preference to the server. If so, did this before or after it got those PRP assignments?

It grabbed PRP after preference had been changed.

CPU is set at TF

Having grabbed a batch of TFs manually will need to wait a day or so to see if it grabs a PRP again.

It's done it again, it has grabbed another PRP exponent to test

What do I need to do to stop it doing this please?

[QUOTE=bayanne;472732]It's done it again, it has grabbed another PRP exponent to test

What do I need to do to stop it doing this please?[/QUOTE]

If you're mixing manual and primenet work, use Quit Gimps option to ensure no more work is fetched during the manual work.

[QUOTE=axn;472735]If you're mixing manual and primenet work, use Quit Gimps option to ensure no more work is fetched during the manual work.[/QUOTE]

He's not trying to. He's used manual work acquisition as a [i]workaround[/i] for the client's inability to sync worktypes with the server, but it's not what he wants to do.

On the client, try changing the work type to anything but your target. Make it communicate with the server, and send new completion dates. Check online to see if the change carried over. Assuming that it did, reset to your desired type on the client. Manually communicate again, with completion dates checked. See if the server matched the type change.

In the past, this sequence would usually get things in sync. If the server is not responding to the changes, I am not sure what to do next.

Once the server and client are in agreement you can unreserve unwanted assignments.

[QUOTE=Dubslow;472736]He's not trying to. He's used manual work acquisition as a [i]workaround[/i] for the client's inability to sync worktypes with the server, but it's not what he wants to do.[/QUOTE]

That's right :smile:

[QUOTE=kladner;472745]On the client, try changing the work type to anything but your target. Make it communicate with the server, and send new completion dates. Check online to see if the change carried over. Assuming that it did, reset to your desired type on the client. Manually communicate again, with completion dates checked. See if the server matched the type change.

In the past, this sequence would usually get things in sync. If the server is not responding to the changes, I am not sure what to do next.

Once the server and client are in agreement you can unreserve unwanted assignments.[/QUOTE]

Not really with you there, sorry ...

Whereabouts on my system is it finding that I want PRP?

Go to [url]https://www.mersenne.org/cpus/[/url]
Click on your computer.
Change the work preference to trial factoring.

[QUOTE=Prime95;472750]Go to [url]https://www.mersenne.org/cpus/[/url]
Click on your computer.
Change the work preference to trial factoring.[/QUOTE]

I have already done that, and did so quite a few days ago

It has just grabbed yet another PRP.

This is beginning to get tiresome ...

Everything shows as TF and not PRP

What I do when it grabs a PRP is quit P95, then manually grab a number of TFs. I then open worktodo.ini and replace the PRP exponent with the new manually obtained TFs.

I then restart P95, and then do a manual communication.

In [url]www.mersenne.org/cpus[/url] it shows as TF

Any other suggestions would be most welcome

[QUOTE=bayanne;472753]Any other suggestions would be most welcome[/QUOTE]

Look at the file prime.txt

It should have a line of the form

WorkPreference=

with a numerical value.

Is the numerical value 150 or 151? Or perhaps even 0?

If it's anything other than 2, then stop the program, and change that value to 2, then restart the program.

[QUOTE=GP2;472757]Look at the file prime.txt

It should have a line of the form

WorkPreference=

with a numerical value.

Is the numerical value 150 or 151? Or perhaps even 0?

If it's anything other than 2, then stop the program, and change that value to 2, then restart the program.[/QUOTE]

No, it is already set at 2 ...

Check all the CPUs at mersenne.org website. Perhaps your computer spontaneously renamed itself (it has been known to happen). Sorry, I'm on a cruise ship right now and cannot peer into any of the server databases.

[QUOTE=bayanne;472752]It has just grabbed yet another PRP.

This is beginning to get tiresome ...[/QUOTE]

Probably what the server is really trying to say is, that you really shouldn't do TF on the CPU, and that PRP is a better choice :)

(that was a joke; but speaking seriously probably a CPU is better used to do any of LL, LL-DC, PRP. Anyway, that does not invalidate your choice).

[QUOTE=bayanne;472749]Not really with you there, sorry ...

Whereabouts on my system is it finding that I want PRP?[/QUOTE]
I know this sounds flaky. However, in the past there were situations in which P95/PrimeNet were balky about work type changes. This procedure worked back then. Now, the same factors (no pun intended) may not be in play, what with the new functions being addressed.

[QUOTE=kladner;472745]On the client, try changing the work type to anything but your target. Make it communicate with the server, and send new completion dates. Check online to see if the change carried over. Assuming that it did, reset to your desired type on the client. Manually communicate again, with completion dates checked. See if the server matched the type change.

In the past, this sequence would usually get things in sync. If the server is not responding to the changes, I am not sure what to do next.

Once the server and client are in agreement you can unreserve unwanted assignments.[/QUOTE]


[QUOTE=bayanne;472749]Not really with you there, sorry ...

Whereabouts on my system is it finding that I want PRP?[/QUOTE]

kladner's advice is quite good. Generally, in our collective experience, if Prime95 refuses to get the right type of work, it's because the server's saved workpreference differs from the client's saved workpreference. kladner's list of instructions is a way to "flush" the settings so that the client and server are synchronized. It's the best advice I've seen so far in this thread, so I definitely recommend trying to understand his post one more time.

[QUOTE=Prime95;472792]Sorry, I'm on a cruise ship right now and cannot peer into any of the server databases.[/QUOTE]

Ahh so you are on vacation?!?!? That is usually the time we find a new Mersenne Prime!! :cool: *crosses fingers*

(We really need a *crosses fingers* or *hoping* smiley)

[QUOTE=Prime95;472792]Check all the CPUs at mersenne.org website. Perhaps your computer spontaneously renamed itself (it has been known to happen). Sorry, I'm on a cruise ship right now and cannot peer into any of the server databases.[/QUOTE]

That was it, the cpu in question had not changed itself on the server to TF and was still showing PRP :smile:

Now all I need is someone who is able to compile mfaktc on a Mac ... :wink:

Glad you found the glitch! :smile:

Prime95 29.4 build 5 is refusing to do PRP-CF on a few exponents:

In my results.txt files:

4456310665879544089 does not divide [M]M2207441[/M]
12415622589540644657 does not divide [M]M2233183[/M]
1219861756779140901119 does not divide [M]M2233019[/M]

All of these statements are false, actually.

It should be very straightforward to do [URL="https://gmplib.org/manual/Integer-Exponentiation.html"]modular exponentiation with a GMP library function[/URL]. The condition 2[SUP]p[/SUP] (mod f) == 1 is obviously true if f is a factor of 2[SUP]p[/SUP] − 1

Some previous versions were able to do these exponents.

Just now, it seems that YarBer completed PRP-CF for M2233183, I'm not sure with what version, but the result shows as "Verified (Factored)" rather than Verified, which basically means it's not considered a match with the currently known factors.

[QUOTE=GP2;473167]Prime95 29.4 build 5 is refusing to do PRP-CF on a few exponents:

In my results.txt files:

4456310665879544089 does not divide [M]M2207441[/M]
12415622589540644657 does not divide [M]M2233183[/M]
1219861756779140901119 does not divide [M]M2233019[/M]

All of these statements are false, actually.
.[/QUOTE]

On each exponent there are problems, see for example:
[CODE]
M2207441/211914337/325862722477981217/4456310665879544089/4456310665879544089 is not prime. Res64: 6550ADD498325C__
[/CODE]
for q=4456310665879544089 it is true that q divides M2207441, but here q^2 doesn't divide, so the posted number M2207441/factors is not even an integer. [This also means that if you see it in this way the posted message could be even true, because the second(!) q factor doesn't divide M2207441].

[QUOTE=R. Gerbicz;473172]On each exponent there are problems[/QUOTE]

Hmm, yes, I see the previous PRP tests on 2017-10-18 had bad (duplicated) factors. And that seems to be preventing a new test from being run with the correct factors.

[QUOTE]but here q^2 doesn't divide[/QUOTE]

And our hopes of a new Wieferich prime are dashed. 😭

Two problems on M2207441.
1) Somehow the factor got added to the database .003 seconds apart.
2) Somehow a PRP test was run with the doubled factor without triggering the "xxx does not divide Myyy" error.
Database fixed manually.

[QUOTE=Prime95;473178]Two problems on M2207441.
1) Somehow the factor got added to the database .003 seconds apart.
2) Somehow a PRP test was run with the doubled factor without triggering the "xxx does not divide Myyy" error.
Database fixed manually.[/QUOTE]

Does the database test divisibility of each factor into M2207441 individually or divisibility into M2207441/alreadytestedfactors. In the former case the double factor would be permitted.

[URL]https://mersenne.org/M2233019[/URL] also have a double factor in a previous PRP test.

I have experienced forced restarts while running ECM's on 29.4. I tried 29.3. Same thing. I tried a lot of different things, like resetting my BIOS to its default values. Nothing helped. So, last night, I deleted [I]prime.txt[/I] and [I]local.txt[/I]. I let 29.4 recreate them. The system ran overnight without incident.

It is true that I added a few things i saw in [I]undoc.txt[/I]. The only thing major I added was an Affinity setting to pick specific CPU threads in [I]local.txt[/I]. It was as below:

[CODE][Worker #1]
Affinity=1,{3,5,7}[/CODE]I had kept the two configuration files for a long time and simply replaced the program file(s) as they came along. There must have been some kind of hold-over from a version previous to 29.1. As to exactly what that was, I have no idea. I am not sure this was even the cause. So, I will leave the two files as is and see what happens.

[QUOTE=Prime95;473178]Database fixed manually.[/QUOTE]

There may still be a problem with [M]M2207441[/M] because the newly submitted result by ATH with the correct set of factors shows up as Verified (Factored) rather than Unverified.

I will run the exponent and see what happens.

I would like to know why in v27.9 build 1 AVX recommended by Gigabyte with 5GHZ in the 7700k with 1.38v 2 hours of test and v29.4 build 5 FMA3 does not go through 5 minutes? Bug?

I just installed 29.4 on my MacBook Pro and got an error saying that Prime95 could not be opened because of a problem. Here is the error report:

[CODE]Process: Prime95 [1056]
Path: /private/var/folders/*/Prime95.app/Contents/MacOS/Prime95
Identifier: org.mersenne.Prime95
Version: 28.8 (1.0)
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: Prime95 [1056]
User ID: 1455265355

Date/Time: 2017-12-07 11:34:08.884 -0800
OS Version: Mac OS X 10.12.6 (16G1114)
Report Version: 12
Anonymous UUID: F12EAC70-6EC2-D3A6-6EF5-BA05C2B556D5


Time Awake Since Boot: 3700 seconds

System Integrity Protection: enabled

Notes: Translocated Process

Crashed Thread: 0

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY

Termination Reason: DYLD, [0x1] Library missing

Application Specific Information:
dyld: launch, loading dependent libraries

Dyld Error Message:
Library not loaded: /usr/local/lib/libgmp.10.dylib
Referenced from: /private/var/folders/*/Prime95.app/Contents/MacOS/Prime95
Reason: image not found

Binary Images:
0x100000000 - 0x101466fff +org.mersenne.Prime95 (28.8 - 1.0) <F2132812-7C26-3140-9923-32E16D9E6BDB> /var/folders/*/Prime95.app/Contents/MacOS/Prime95
0x10afec000 - 0x10b029dc7 dyld (433.5) <322C06B7-8878-311D-888C-C8FD2CA96FF3> /usr/lib/dyld
0x7fffe1e81000 - 0x7fffe1ed7ff7 libc++.1.dylib (307.5) <0B43BB5D-E6EB-3464-8DE9-B41AC8ED9D1C> /usr/lib/libc++.1.dylib
0x7fffe22bc000 - 0x7fffe230efff libcurl.4.dylib (95.70.4) <D81AEB1D-8501-3EEC-9651-D6D476C2A387> /usr/lib/libcurl.4.dylib

Model: MacBookPro13,3, BootROM MBP133.0233.B00, 4 processors, Intel Core i7, 2.7 GHz, 16 GB, SMC 2.38f7
Graphics: Intel HD Graphics 530, Intel HD Graphics 530, Built-In
Graphics: Radeon Pro 455, AMD Radeon Pro 455, PCIe, 2048 MB
Memory Module: BANK 0/DIMM0, 8 GB, LPDDR3, 2133 MHz, 0x802C, 0x4D5435324C31473332443450472D30393320
Memory Module: BANK 1/DIMM0, 8 GB, LPDDR3, 2133 MHz, 0x802C, 0x4D5435324C31473332443450472D30393320
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x15A), Broadcom BCM43xx 1.0 (7.21.171.133.1a2)
Bluetooth: Version 5.0.5f1, 3 services, 27 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en0
USB Device: USB 3.0 Bus
USB Device: iBridge
USB Device: USB-C Multiport Adapter
USB Device: USB 2.0 Hub
USB Device: USB Receiver
USB Device: USB-C Multiport Adapter
USB Device: AX88179
Thunderbolt Bus: MacBook Pro, Apple Inc., 22.1
Thunderbolt Bus: MacBook Pro, Apple Inc., 22.1
[/CODE]

Move the included libgmp.10.dylib to /usr/local/lib/libgmp.10.dylib

I'm working on a better solution.

[QUOTE=HLB;473361]I would like to know why in v27.9 build 1 AVX recommended by Gigabyte with 5GHZ in the 7700k with 1.38v 2 hours of test and v29.4 build 5 FMA3 does not go through 5 minutes? Bug?[/QUOTE]

If by "bug" you mean "evidence my overclock is not fully stable", then yes. Turn speed down, find software runs fine, conclude it's not the software at fault.

[QUOTE=Prime95;473372]Move the included libgmp.10.dylib to /usr/local/lib/libgmp.10.dylib

I'm working on a better solution.[/QUOTE]

That works like a charm. Thanks!

[QUOTE=VBCurtis;473375]If by "bug" you mean "evidence my overclock is not fully stable", then yes. Turn speed down, find software runs fine, conclude it's not the software at fault.[/QUOTE]The only way I found stability was by using avx offset -2, some manufacturers do not recommend testing with the prime FMA3 just the old 27.9 with AVX.

[QUOTE=HLB;473380]The only way I found stability was by using avx offset -2, [B]some manufacturers do not recommend testing with the prime FMA3 [/B]just the old 27.9 with AVX.[/QUOTE]
Is this testing to establish a benchmark? In that case, limiting the test parameters to avoid instability might be worthwhile. If you want the system actually to run at the speed you mentioned, then consider that some Intel chip functions impose a Vcore increase. This will affect your OC.

Build 6 available for the Mac. It references libgmp contained within the Prime95 bundle.

[QUOTE=Prime95;473501]Build 6 available for the Mac. It references libgmp contained within the Prime95 bundle.[/QUOTE]

I just updated the download page for that build.

[QUOTE=bayanne;472823]That was it, the cpu in question had not changed itself on the server to TF and was still showing PRP :smile:

Now all I need is someone who is able to compile mfaktc on a Mac ... :wink:[/QUOTE]

Thanks to TheJudger for guiding me through the compiling of mfaktc for Mac :tu:

I'm wondering if or when the Windows Service version will be updated. I have a machine that I would like to update. I also think that it would be beneficial with the way Windows 10 reboots after automatically updating to have the service version running and not losing out on days of work before I notice a machine sitting at the login prompt.

[QUOTE=endless mike;473963]I'm wondering if or when the Windows Service version will be updated. I have a machine that I would like to update. I also think that it would be beneficial with the way Windows 10 reboots after automatically updating to have the service version running and not losing out on days of work before I notice a machine sitting at the login prompt.[/QUOTE]

I used the Group Policy Editor to prevent unwanted restarts. To get there, do the following:

1. To run it, press the Windows logo key +R.
2. Type "gpedit" in the dialog, without the quotes, then click OK.
3. In the left panel, there will be "Local Computer Polity" at the top. Below that will be "Computer Configuration."
4. In that group: Administrative Templates > Windows Components > Windows Update. Select "Windows Update." In the larger right panel, a long list of items will appear.
6. In that list, find "Configure auto-restart required notification for updates." Highlight and right mouse button click, then select "Edit"
7. Change the radio-button near the upper left side from "Not Configured" to "Enabled." Below that is "Options." Change "Method" from "Auto" to "User Action." At the bottom, click "OK."

After I did this, a message would appear in the Action Center. One of the options is "Restart now." I have had no auto restarts since I set this about six weeks ago. Sorry about all the quotation marks. :smile:

I've switched from LL to PRP as I've read that it has a better error detecting method now.

At the same time I've overclocked the RAM (1600 to 2000) which surprisingly works flawless at the same voltage and timings. Ran memtest86+ for an hour which passed without an error.

Question: Would mprime 29.4 report it on the console if it would stumble across a memory glitch?

[QUOTE=heliosh;473985]Question: Would mprime 29.4 report it on the console if it would stumble across a memory glitch?[/QUOTE]

Yes. The PRP test is able to detect memory problems and it will report, something like this:

[Work thread Dec 14 16:12] Iteration: 61480000 / 75757575 [81.09%], ms/iter: 6.939, ETA: 27:37:15
[Work thread Dec 14 16:12] Hardware errors have occurred during the test!
[Work thread Dec 14 16:12] 15 Gerbicz/double-check errors.
[Work thread Dec 14 16:12] Confidence in final result is excellent.

Unfortunately, some of my machines are running Windows 10 Home, which does not have the group policy editor.

[QUOTE=storm5510;473973]I used the Group Policy Editor to prevent unwanted restarts. To get there, do the following:

1. To run it, press the Windows logo key +R.
2. Type "gpedit" in the dialog, without the quotes, then click OK.
3. In the left panel, there will be "Local Computer Polity" at the top. Below that will be "Computer Configuration."
4. In that group: Administrative Templates > Windows Components > Windows Update. Select "Windows Update." In the larger right panel, a long list of items will appear.
6. In that list, find "Configure auto-restart required notification for updates." Highlight and right mouse button click, then select "Edit"
7. Change the radio-button near the upper left side from "Not Configured" to "Enabled." Below that is "Options." Change "Method" from "Auto" to "User Action." At the bottom, click "OK."

After I did this, a message would appear in the Action Center. One of the options is "Restart now." I have had no auto restarts since I set this about six weeks ago. Sorry about all the quotation marks. :smile:[/QUOTE]

[QUOTE=endless mike;474115]Unfortunately, some of my machines are running Windows 10 Home, which does not have the group policy editor.[/QUOTE]

Oh, I see. I'll do some digging and see if there is another way. :smile:

[QUOTE=storm5510;474124]Oh, I see. I'll do some digging and see if there is another way. :smile:[/QUOTE]

I use TinyWall to block Windows Updates (among other things) from accessing the internet.

I am enjoying a free ride on a cheap cloud server, having 5 core hours of AVX @2.3GHz and the remaining 19 at a tweaked power (about 5%-6% of the normal).

Although slow, the server worked fine until today, when I got the following (repeating) message:

[code]
[Work thread Dec 18 11:17] Possible hardware errors have occurred during the test! 1 ROUNDOFF > 0.4.
[Work thread Dec 18 11:17] Confidence in final result is excellent.
[/code]

I am running PRP-CF on exponents in the 64265XX range.
Questions:

1 - Is it a possible (cheap) server issue or a FFT boundary issue?
2 - Should I unreserve the exponent (I'm still at 25% and in the "slow" tide)?
3 - Should I revert to some less stresssing work for the CPU, like trial-factoring?

Luigi

[QUOTE=Mark Rose;474041]Yes. The PRP test is able to detect memory problems and it will report, something like this:

[Work thread Dec 14 16:12] Iteration: 61480000 / 75757575 [81.09%], ms/iter: 6.939, ETA: 27:37:15
[Work thread Dec 14 16:12] Hardware errors have occurred during the test!
[Work thread Dec 14 16:12] [COLOR="Red"]15 Gerbicz/double-check errors.[/COLOR]
[Work thread Dec 14 16:12] Confidence in final result is excellent.[/QUOTE]

I don't have the sentences highlighted in red.
Also the "hardware thinghie" wording is different.

And when I restarted the program, I had the message:

[code]
[Work thread Dec 18 12:24] Resuming Gerbicz error-checking PRP test of M64265XX
[/code]

[QUOTE=ET_;474290]

1 - Is it a possible (cheap) server issue or a FFT boundary issue?
2 - Should I unreserve the exponent (I'm still at 25% and in the "slow" tide)?
[/QUOTE]

1) My guess is cheap server.
2) Continue on - that is the point of Gerbicz error checking.

The exponent 6426523 ended up being "[B]Unverified (Reliable)[/B]", with error code 00000100 and a message saying "Computer hardware check recommended. Possible hardware errors occured during PRP test of M6426523 -- ".
The Gerbitz test was correctly run, and the following (smaller) exponent does not show (till now) any hardware problems.

Finger crossed.

This is VERY GOOD!!!

[Dec 18 23:59] Iteration: 75690000 / 75699408 [99.98%], ms/iter: 36.999, ETA: 00:05:48
[Dec 18 23:59] Hardware errors have occurred during the test!
[Dec 18 23:59] 15 Gerbicz/double-check errors, 1 ROUNDOFF > 0.4.
[Dec 18 23:59] Confidence in final result is excellent.
[Dec 19 00:06] M75699409 is not prime. Type-4 RES64: 2399B098FED4DF02. Wg4: 81556197,45940480,00F00100

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

[QUOTE=moebius;474348]This is VERY GOOD!!!

[Dec 18 23:59] Hardware errors have occurred during the test!
[Dec 18 23:59] 15 Gerbicz/double-check errors, 1 ROUNDOFF > 0.4.
[Dec 18 23:59] Confidence in final result is excellent.
[/QUOTE]

It is even catching FFT multiplication errors, or (very unlikely) bug in the FFT code.
Still not many people are using this new feature [url]http://mersenneforum.org/showthread.php?t=22796[/url].

Something strange just happened. I'm doing P-1 factoring on an old Windows XP machine and noticed that Prime95 did not continue to stage 2 after stage 1 completed. It only started the GCD step when I stopped and restarted the worker thread.

[CODE][Dec 20 23:48] M84865621 stage 1 is 99.68% complete. Time: 90.472 sec.
[Dec 20 23:50] M84865621 stage 1 is 99.73% complete. Time: 90.556 sec.
[Dec 20 23:51] M84865621 stage 1 is 99.78% complete. Time: 90.703 sec.
[Dec 20 23:53] M84865621 stage 1 is 99.83% complete. Time: 90.632 sec.
[Dec 20 23:54] M84865621 stage 1 is 99.88% complete. Time: 93.313 sec.
[Dec 20 23:56] M84865621 stage 1 is 99.94% complete. Time: 88.540 sec.
[Dec 20 23:57] M84865621 stage 1 is 99.99% complete. Time: 88.393 sec.
[Dec 20 23:59] M84865621 stage 1 is 100.00% complete. Time: 94.614 sec.
[Dec 21 00:01] M84865621 stage 1 is 100.00% complete. Time: 97.427 sec.
[Dec 21 00:02] M84865621 stage 1 is 100.00% complete. Time: 93.984 sec.
[Dec 21 00:04] M84865621 stage 1 is 100.00% complete. Time: 97.137 sec.
[Dec 21 00:05] M84865621 stage 1 is 100.00% complete. Time: 93.610 sec.
[Dec 21 00:07] M84865621 stage 1 is 100.00% complete. Time: 97.245 sec.
[Dec 21 00:09] M84865621 stage 1 is 100.00% complete. Time: 96.892 sec.
[Dec 21 00:10] M84865621 stage 1 is 100.00% complete. Time: 95.887 sec.
[Dec 21 00:12] M84865621 stage 1 is 100.00% complete. Time: 92.649 sec.
[Dec 21 00:13] M84865621 stage 1 is 100.00% complete. Time: 94.918 sec.
[Dec 21 00:15] M84865621 stage 1 is 100.00% complete. Time: 93.742 sec.
[Dec 21 00:17] M84865621 stage 1 is 100.00% complete. Time: 129.542 sec.
[Dec 21 00:19] M84865621 stage 1 is 100.00% complete. Time: 120.094 sec.
[Dec 21 00:21] M84865621 stage 1 is 100.00% complete. Time: 138.607 sec.
[Dec 21 00:24] M84865621 stage 1 is 100.00% complete. Time: 143.351 sec.
[Dec 21 00:26] M84865621 stage 1 is 100.00% complete. Time: 126.266 sec.
[Dec 21 00:28] M84865621 stage 1 is 100.00% complete. Time: 134.494 sec.
[Dec 21 00:30] M84865621 stage 1 is 100.00% complete. Time: 120.805 sec.
[Dec 21 00:32] M84865621 stage 1 is 100.00% complete. Time: 137.120 sec.
[Dec 21 00:35] M84865621 stage 1 is 100.00% complete. Time: 139.006 sec.
[Dec 21 00:37] M84865621 stage 1 is 100.00% complete. Time: 138.002 sec.
[Dec 21 00:39] M84865621 stage 1 is 100.00% complete. Time: 117.075 sec.
[Dec 21 00:39] Worker stopped.
[Dec 21 00:40] Worker starting
[Dec 21 00:40] Optimal P-1 factoring of M84865621 using up to 512MB of memory.
[Dec 21 00:40] Assuming no factors below 2^76 and 2 primality tests saved if a factor is found.
[Dec 21 00:40] Optimal bounds are B1=640000, B2=8480000
[Dec 21 00:40] Chance of finding a factor is an estimated 2.76%
[Dec 21 00:40] Using Pentium4 FFT length 4480K, Pass1=896, Pass2=5K, clm=4
[Dec 21 00:40] Starting stage 1 GCD - please be patient.
[Dec 21 00:45] Stage 1 GCD complete. Time: 303.138 sec.
[Dec 21 00:45] Using 478MB of memory. Processing 8 relative primes (0 of 480 already processed).
[Dec 21 00:46] M84865621 stage 2 is 0.13% complete.
[Dec 21 00:48] M84865621 stage 2 is 0.21% complete. Time: 131.798 sec.
[Dec 21 00:50] M84865621 stage 2 is 0.29% complete. Time: 122.391 sec.[/CODE]

Is this a bug?

[QUOTE=ixfd64;474483]
Is this a bug?[/QUOTE]

Sure looks like one.

Seems I'm a bit late on upgrading to v29.4, guess this has already been reported, anyway here is some console output of v29.4b5 64bit Linux. 4 workers, 1 thread per worker:

[CODE][Worker #1 Dec 30 01:57] Running Jacobi error check. [Dec 30 01:57] Running Jacobi error check. [Dec 30 01:57] Running Jacobi error check. [Dec 30 01:57] Running Jacobi error check. [Dec 30 01:57] Sending interim residue 30000000 for
M79xxxxxx
[Comm thread Dec 30 01:57] Sending interim residue 25000000 for M79xxxxxx
[Comm thread Dec 30 01:57] Done communicating with server.
[Worker #2] Passed. Time: 23.227 sec.
[Worker #4] Passed. Time: 23.278 sec.
[Worker #1] Passed. Time: 23.282 sec.
[Worker #3] Passed. Time: 23.287 sec.
[/CODE]
[LIST][*]1st line: missing new lines and missing "Worker #X" or "Comm thread" for following messages within the same line.[*]4th to 7th line ("Passed" Jacobi error checks): no timestamps inside the square brackets[/LIST]
Oliver

Build 7 uploaded.

What's new:

P-1 is marginally faster in stage 1. Unfortunately, old P-1 save files from stage 1 are no longer any good.

M77232917 will no longer beep like crazy when run to completion

The service versions were also built.

[QUOTE=Prime95;476466]Build 7 uploaded.

What's new:

P-1 is marginally faster in stage 1. Unfortunately, old P-1 save files from stage 1 are no longer any good.

M77232917 will no longer beep like crazy when run to completion

The service versions were also built.[/QUOTE]

I updated the download page with the new details... good stuff.

Not quite a bug, just a request for comments.

I am using mprime for Linux 64, version 29.4b5

While setting up computers to get enough work for the next days, I used Option/Preferences and set "Days of work to queue up" from 3 to 15, expecting to receive some work. I didn't.
Then I selected the work to get and set it to 1 (TF-LMH). Nothing happened.
Then I chose Advanced/Manual Communication, answered Y to all requests. The program contacted the server, sent out the completion dates of what I had on the worktodo.txt (about 2 days of work) and stopped the communication. No new work was sent from the Server.
Then I tried Option 4 twice (Stop execution - Start execution). Nothing.
Finally I tried Option 4 (Stop execution) followed by Option 5 (Exit mprime), restarted the program and again Option 4 to (re)start the computation. I didn't receive the new work from the server.
At this point I even tried to select again Manual Communicaiton. Nothing.

Now I have "Days of work queued" set to 15, and the last exponent expiring on January 8. 15 exponents on the worktodo.txt file, 1 worker, 1 thread selected.

Is this the expected behaviour?

Luigi

[QUOTE=Prime95;476466]P-1 is marginally faster in stage 1.[/QUOTE]

Nice! I'm seeing about a 6% speed up! :tu:

[QUOTE=Madpoo;476705]I updated the download page with the new details... good stuff.[/QUOTE]

One thing I noticed while upgrading some of my machines: while the download page is SSL, the download links are just HTTP. Software links should definitely be SSL, to avoid any "Man in the Middle" injections.

"Yes, I'm paranoid. The question is, am I paranoid enough?" :wink:

[QUOTE=ET_;476841]15 exponents on the worktodo.txt file, 1 worker, 1 thread selected.

Is this the expected behaviour?[/QUOTE]

When I started with PRP-CF, most assignments were really small and I remember that it maxed out at some point such that it was only able to run a few minutes without web access. This seems to be a hardcoded upper bound; maybe there is an option to increase it?

EDIT:
As Luigi pointed out, there is [FONT="Courier New"]MaxExponents=n[/FONT] for prime.txt.

[QUOTE]p95v294b7.win64.zip
SHA256: 6A00740098F10BAB76492E5AAF0BB290A459B261D12D824932FCC7A6204B4EBE[/QUOTE]

When you don't trust those (securely transmitted) checksums on the download page, there is no need to trust in SSL. :razz:

[QUOTE=kruoli;476858]When I started with PRP-CF, most assignments were really small and I remember that it maxed out at some point such that it was only able to run a few minutes without web access. This seems to be a hardcoded upper bound; maybe there is an option to increase it?[/QUOTE]

Yes there is. undoc.txt.

The program will restrict how many exponents can be added to worktodo.txt.
To override this, change prime.txt:
MaxExponents=n

[QUOTE=kruoli;476859]When you don't trust those (securely transmitted) checksums on the download page, there is no need to trust in SSL. :razz:[/QUOTE]

True... But how many Winblows users know how to run a SHA256 checksum? :wink:

[QUOTE=chalsall;476867]True... But how many Winblows users know how to run a SHA256 checksum? :wink:[/QUOTE]


Just use standard PowerShell:

[CODE]
get-filehash your_filename
[/CODE]

You can specify a different algorithm with the -algorithm option, but -algorithm SHA256 is the default

[QUOTE=ET_;476841]Not quite a bug, just a request for comments.

Is this the expected behaviour?[/QUOTE]

Look in undoc.txt for a limit on the number of exponents that can be queued up. Maybe I called it "MaxExponents" or some such???

[QUOTE=chalsall;476867]True... But how many Winblows users know how to run a SHA256 checksum? :wink:[/QUOTE]
That is, if they use "Exblower", to stay in tone with you. If there is a single program that we have to pick from a list of programs we hate, then that program is Windows Explorer. There is no other stupider file manager. Fortunately, most of us (i.e. people who use computers for other things than office, word, email, etc., but also do some programming, playing some games, hunting for some primes, etc) use different file browsers. "Total Commander" from Chris Ghisler is quite a good choice, and for that, playing with CRCxx, MDA5, SHAxx, etc, is piece of cake, in fact if you have the file with the right extension in the folder, you can get automatically kicks and punches in the nose if the files are corrupted.

[QUOTE=Madpoo;476705]I updated the download page with the new details... good stuff.[/QUOTE]

You should update the GIMPS home page to say that a new version is available. Not everyone reads the forums. By the same token, the fact that the P-1 stage 1 format isn't backward compatible should be noted on the download page.

[QUOTE=GP2;476880]Just use standard PowerShell[/QUOTE]Exactly. How many Windows users even know what PowerShell is? :smile:
BTW: get-filehash requires PowerShell 4.0, so won't run on stock Windows 7/8 installations.

For what it's worth, Windows 7 does come with [url=https://technet.microsoft.com/en-us/library/cc732443(v=ws.11).aspx#BKMK_hashfile]certutil[/url] which can generate assorted hashes in a similar way, but with the unusual quirk of space-splitting each hex digit pair.

I have redirected all download.mersenne.ca pages to HTTPS.

[SIZE="1"]I guess I should keep quiet about using Windows Explorer [/SIZE] :leaving:

[QUOTE=James Heinrich;476931]Exactly. How many Windows users even know what PowerShell is? :smile:
BTW: get-filehash requires PowerShell 4.0, so won't run on stock Windows 7/8 installations.

For what it's worth, Windows 7 does come with [url=https://technet.microsoft.com/en-us/library/cc732443(v=ws.11).aspx#BKMK_hashfile]certutil[/url] which can generate assorted hashes in a similar way, but with the unusual quirk of space-splitting each hex digit pair.

I have redirected all download.mersenne.ca pages to HTTPS.

[SIZE="1"]I guess I should keep quiet about using Windows Explorer [/SIZE] :leaving:[/QUOTE]

I use a command line replacement on boxes I have to work daily with... Take Command from JPSoft. Has a nice %@sha256[filename.exe] type syntax...that what I use to generate the hashes I put on the download page. :smile:

I deliberately let the downloads bypass the normal "redirect to https" routine that the rest of the site does, and that's just because it makes little sense to bother encrypting the downloads, especially when the hashes are available on a secure-only page, for the truly paranoid...er, I mean, cautious.

As for adding something to the home page about the new version... yeah, I did think about that because it does make some kind of sense, because a new version is kind of important to let people know about.

George had mentioned some other ideas for spicing up the home page as well. I kind of remember there being some sort of blob on the old home page that had info about the # of accounts, assignments, etc. Just as a for instance.

Typically though, home pages don't get a lot of traffic on many sites. Ever since people stopped bothering to go directly to a website, and rely instead of going to Google first, they usually wind up somewhere besides the home page. And often, that sub page is actually where they wanted to go anyway... i.e. they wanted the download page so they go straight there from search results.

Still, there are folks out there who put in [url]www.mersenne.org[/url] into their address bar, like the old fogeys they are, and we may as well entertain them with something or another on the home page, for the couple of seconds they're there. :smile:

[QUOTE=James Heinrich;476931]...I have redirected all download.mersenne.ca pages to HTTPS....[/QUOTE]

So this is what you were doing yesterday. I wondered what all the downtime was about.

:smile:

[QUOTE=storm5510;477030]So this is what you were doing yesterday. I wondered what all the downtime was about.[/QUOTE]Actually no, the downtime was totally unrelated, I accidentally blacklisted everyone, and only when I went to set up the HTTPS redirect did I notice that and fixed it :smile:

Hi. Is it normal to have the temperatures of two CPUs experiencing a difference of about 8C when undergoing the toruture tests (70C vs 60C)?

I'm assuming it is because of the difference in positions of the CPUs w.r.t the fans.

I'm running the test on an old server (ibm x3620 M3) for an experiment.

Just curious about this discrepancy.

Yes, that's quite common. It could be physical location of the CPUs (as you guessed), or a difference in thermal-paste application, where one has a more efficient connection to its heatsink. Differences in dust buildup can explain such a temp difference too!

[QUOTE=VBCurtis;477075]...Differences in dust buildup can explain such a temp difference too![/QUOTE]

I have to clean heat-sinks and a liquid-cooling radiator every other month. If I do not, then they start to plug up. My dust situation is horrid. Old building, old carpet, old drywall, cat hair, and the list goes on. :yucky:

[QUOTE=storm5510;477082]I have to clean heat-sinks and a liquid-cooling radiator every other month. If I do not, then they start to plug up. My dust situation is horrid. Old building, old carpet, old drywall, cat hair, and the list goes on. :yucky:[/QUOTE]

Get a robot vacuum cleaner. Helps a lot.

[QUOTE=Mark Rose;477096]Get a robot vacuum cleaner. Helps a lot.[/QUOTE]
Yeah, that toy is very good to have, it [URL="http://www.telegraph.co.uk/technology/2017/07/25/robot-vacuum-cleaner-plans-sell-maps-peoples-homes/"]maps your house[/URL] too... :razz:

[QUOTE=LaurV;477130]Yeah, that toy is very good to have, it [URL="http://www.telegraph.co.uk/technology/2017/07/25/robot-vacuum-cleaner-plans-sell-maps-peoples-homes/"]maps your house[/URL] too... :razz:[/QUOTE]

Saves me the effort :razz:

Actually, I bought a Eufy.

[QUOTE=Mark Rose;477096]Get a robot vacuum cleaner. Helps a lot.[/QUOTE]

My sister has one that she uses on a hardwood floor. I would not think this would be ideal for carpet.

[QUOTE=storm5510;477301]My sister has one that she uses on a hardwood floor. I would not think this would be ideal for carpet.[/QUOTE]
It would indeed depend on the depth and density of the carpet pile. Such a device might get bogged down in shag.

[QUOTE=kladner;477312]It would indeed depend on the depth and density of the carpet pile. Such a device might get bogged down in shag.[/QUOTE]

Mine works well on low pile carpet and gets it very clean. It would not work well on shag.

[QUOTE=Mark Rose;477379]Mine works well on low pile carpet and gets it very clean. It would not work well on shag.[/QUOTE]

What I have is somewhere between indoor-outdoor and shag. Whoever lived here before me really loved carpet-fresh. After nearly five years, I'm still pulling that stuff out with my upright. :yucky:

Forgive me, but I'm going to go off-topic for a second: Am I right that the benchmarking bug on Xeons has not been fixed? Because I've run into that bug on build 7 as well as another benchmark bug that I don't believe has been mentioned yet. On certain worker/core tests, Prime95 will outright crash. E.g. 10 cores and 10 workers will crash; 24 cores and 22-24 workers will each crash. Crashes on different FFTs (224K, 2560K).

Dual E5-2683 v3 Xeon machine.

[QUOTE=storm5510;477454]What I have is somewhere between indoor-outdoor and shag. Whoever lived here before me really loved carpet-fresh. After nearly five years, I'm still pulling that stuff out with my upright. :yucky:[/QUOTE]
Rent a carpet cleaner. Work the carpets over: first with "heavy cleaning" dose of the prescribed detergent for the machine, then with plain water. Moving slowly gives time to really scrub and extract. Watch the returning liquid, which should be visible through some part of the machine. It should show when foam and suds have reduced.

I dealt with a similar situation in a rental beach house I was involved in. Something smelled funky, and contract cleaning crews had saturated the carpets with something which overcame the reek by sheer aggressive restroom type deodorizer. Eventually, the carpet got replaced as part of a rehab. In the meantime, we did the sort of deluge cleaning described. It took considerable fluid to flush those noxious treatments out of a very low pile commercial carpet.

We did discover the likely source of the odor being drowned out. When we tore out an island-type bar, we discovered evidence of rodent occupancy, including a desiccated rat carcass. Then, while degreasing the back of the electric stove, I found that another rat had been dining on said grease, and had crawled between the 230 V terminals.

Sorry for the digression. But seriously, wash those carpets.

[QUOTE=Jayder;477485]Forgive me, but I'm going to go off-topic for a second: Am I right that the benchmarking bug on Xeons has not been fixed? Because I've run into that bug on build 7 as well as another benchmark bug that I don't believe has been mentioned yet. On certain worker/core tests, Prime95 will outright crash. E.g. 10 cores and 10 workers will crash; 24 cores and 22-24 workers will each crash. Crashes on different FFTs (224K, 2560K).

Dual E5-2683 v3 Xeon machine.[/QUOTE]

FWIW I can run 29.4b7 on a 22-core Xeon E5 2696v4 with 22 workers on a 2560K FFT without it crashing.

[QUOTE=Jayder;477485]Forgive me, but I'm going to go off-topic for a second: Am I right that the benchmarking bug on Xeons has not been fixed? Because I've run into that bug on build 7 as well as another benchmark bug that I don't believe has been mentioned yet. On certain worker/core tests, Prime95 will outright crash. E.g. 10 cores and 10 workers will crash; 24 cores and 22-24 workers will each crash. Crashes on different FFTs (224K, 2560K).

Dual E5-2683 v3 Xeon machine.[/QUOTE]

I tried benchmarking dual Xeon E5-2690v3 in 29.4b7 and it crashed as well.