[QUOTE=ATH;406211]On my Sandy Bridge Prime95 uses AVX FFT like it should but on the same computer with mprime inside a VMware linux 64bit installation it uses pentium4 FFT?[/QUOTE]

Are you exposing the physical CPU attributes to the VM? vmware might be masking the CPUs capabilities.

One question for maker of Prime95 ( or anybody else who knows answer)
Lets say that I start Prime95 with 1 thread and three logical cores for PRP test. Then I shutdown Prime95 change from three to four ( and vice-versa) cores and resume computing: will that in any case make result non-confidient?

[QUOTE=pepi37;406249]One question for maker of Prime95 ( or anybody else who knows answer)
Lets say that I start Prime95 with 1 thread and three logical cores for PRP test. Then I shutdown Prime95 change from three to four ( and vice-versa) cores and resume computing: will that in any case make result non-confidient?[/QUOTE]

Not a problem.

Thanks for fast answer!

Can you compile 287 version?

Bump !
[QUOTE=Prime95;399389]Prime95 version 28.6 build 1 is available.
...
Important:
...
The bug affects AVX and FMA computers (more details in a later post). The bug has been present since version 27.1. To be safe, I recommend all users with Sandy Bridge or later CPUs upgrade to this version.
...[/QUOTE][QUOTE=TObject;401449]Which one is the recommended release as of today, May 05, 2015?[/QUOTE][QUOTE=Prime95;401457]28.6. We're testing some gwnum changes in 28.7 with LLR.[/QUOTE]The version of the software on the main download page is still 28.5.

And on this forum the thread for that version [url=http://www.mersenneforum.org/showthread.php?t=19182]Sticky: Prime95 version 28.5 (deprecated, use 28.7)[/url] refers to version 28.7 which, apart from the source files, is not available yet.

Then the folders accessible through FTP could do with some maintenance (move old and deprecated versions of the software to the mersenne.org/gimps_archive/archived_executables/ and mersenne.org/gimps_archive/archived_sources/ folders.)

Jacob

So, use 28.6 build 1 :smile:

[QUOTE=S485122;406512]Bump !
The version of the software on the main download page is still 28.5.

And on this forum the thread for that version [url=http://www.mersenneforum.org/showthread.php?t=19182]Sticky: Prime95 version 28.5 (deprecated, use 28.7)[/url] refers to version 28.7 which, apart from the source files, is not available yet.

Then the folders accessible through FTP could do with some maintenance (move old and deprecated versions of the software to the mersenne.org/gimps_archive/archived_executables/ and mersenne.org/gimps_archive/archived_sources/ folders.)[/QUOTE]

I think, maybe, George was still testing out some changes in 28.6 before making it official? I'd have to refresh my brain on that... I think because that one problem that was found in whatever part of the code didn't necessarily affect Prime95 28.5?

[QUOTE=Madpoo;406551]I think, maybe, George was still testing out some changes in 28.6 before making it official? [/QUOTE]

I was. I've since convinced myself that the scary bug that affected that one PRP test has virtual no chance of affecting a Mersenne test. Thus no urgency to make 28.6 (or 28.7) the official release. Since then I've been distracted (I know that is a pathetic excuse) and not bothered to build the 28.7 release.

reliability of CPU's
 

The current range of second tier of double checks is at a crossover point between two FFT sizes. I think that at least for some type of CPU architectures (in this case AVX2, FMA) the soft crossover is a bit high. I choose to use the prime.txt setting "SoftCrossoverAdjust=-0.012" because retries make you loose time but also because I am under the impression that there is a bug in detecting the "Result is reproducible" situation (see extracts from prime.log and results.txt files below.)
[code][Thu Jul 30 12:54:57 2015]
Trying 1000 iterations for exponent 34772027 using 1792K FFT.
If average roundoff error is above 0.2424, then a larger FFT will be used.
Final average roundoff error is 0.23739, using 1792K FFT for exponent 34772027.

[Sat Aug 01 20:50:31 2015]
Iteration: 20289756/34772027, Possible error: round off (0.408292146) > 0.40
Continuing from last save file.

[Sat Aug 01 21:14:43 2015]
Iteration: 20289756/34772027, Possible error: round off (0.408292146) > 0.40
Continuing from last save file.

[Sat Aug 01 21:29:33 2015]
Disregard last error. Result is reproducible and thus not a hardware problem.
For added safety, redoing iteration using a slower, more reliable method.
Continuing from last save file.

[Mon Aug 03 12:19:37 2015]
UID: S485122/5820K, M34772027 is not prime. Res64: C6C1EFD9E2792EA4. We4: F075176C,16354045,05000600, AID: 0583EF661F2D4F47F49B38D286C19C99

Prime.log

[Mon Aug 03 12:19:37 2015 - ver 28.6]
Sending result to server: UID: S485122/5820K, M34772027 is not prime. Res64: C6C1EFD9E2792EA4. We4: F075176C,16354045,05000600, AID: 0583EF661F2D4F47F49B38D286C19C99

PrimeNet success code with additional info:
Computer hardware check recommended. Possible hardware errors occured during LL test of M34772027
LL test successfully completes double-check of M34772027

-----------

results.txt

[Mon Aug 03 14:33:06 2015]
Trying 1000 iterations for exponent 34782841 using 1792K FFT.
If average roundoff error is above 0.2424, then a larger FFT will be used.
Final average roundoff error is 0.23813, using 1792K FFT for exponent 34782841.

[Thu Aug 06 06:18:51 2015]
Iteration: 23828249/34782841, Possible error: round off (0.4079129255) > 0.40
Continuing from last save file.

[Thu Aug 06 06:53:42 2015]
Iteration: 23828249/34782841, Possible error: round off (0.4079129255) > 0.40
Continuing from last save file.

[Thu Aug 06 07:07:56 2015]
Disregard last error. Result is reproducible and thus not a hardware problem.
For added safety, redoing iteration using a slower, more reliable method.
Continuing from last save file.

[Fri Aug 07 12:08:20 2015]
UID: S485122/5820K, M34782841 is not prime. Res64: 1E4706824A53B02A. We4: 1FF0A89C,14662417,01000200, AID: B1E3718D8D736FAB0056EF866DB5CA80

Prime.log

[Fri Aug 07 12:08:20 2015 - ver 28.6]
Sending result to server: UID: S485122/5820K, M34782841 is not prime. Res64: 1E4706824A53B02A. We4: 1FF0A89C,14662417,01000200, AID:

B1E3718D8D736FAB0056EF866DB5CA80

PrimeNet success code with additional info:
Computer hardware check recommended. Possible hardware errors occured during LL test of M34782841
LL test successfully completes double-check of M34782841
CPU credit is 41.1597 GHz-days.[/code]The double-checks where successful, the round-off that were too high occurred at the same iteration and had the same value (within the limits of what is displayed.) The problem is that the first occurrence of that high round-off was not considered reproducible.

A consequence of this is the drop in reliability of the computer which in turn affects the assignments received.

Jacob

[QUOTE=S485122;407446]The current range of second tier of double checks is at a crossover point between two FFT sizes.[/QUOTE]

I've noticed this myself when doing checks in the 34M+ range. I don't remember where the fuzzy area is, but quite a few of the tests involve that initial test to see what the round off is looking like.

Even then, once it's made it's FFT choice, about 10% of the time a test will still involve one of those round off > 0.4 errors, resulting in it retrying. At least on my machines it is *always* reproducible, so then it does it again using the safer method, etc.

All in all, that means probably a 1 hour delay in getting to the end of the test... does that sound right? An extra half hour or so to get the reproducible error, then another half hour or so using the safer method to redo it?

Of course if the test had picked the next higher FFT, the overall test might have taken more than an extra hour to run. I guess that depends on how many cores you're throwing at it. On a 10-core worker I can do a 34M exponent in about 13 hours, so losing an hour because of roundoff errors is kind of a big deal, and choosing the next higher FFT from the start may have only added another 30 minutes? I'm guessing there.

Anyway, I don't worry about it too much. Yeah, it makes the resulting error code non-zero, but if it's reproducible then the error code reflects that and it's not really too bad.

In all of my recent tests, I've only had *one* instance where it was unable to reproduce the error, but I think it may have occurred in the last few iterations so it never had the chance. My residue matched one of the other runs anyway so it was all good, but it was a pretty rare thing so again, I didn't let it bug me. :smile:

[QUOTE=Madpoo;407572]once it's made it's FFT choice, about 10% of the time a test will still involve one of those round off > 0.4 errors, resulting in it retrying. At least on my machines it is *always* reproducible, so then it does it again using the safer method, etc.[/QUOTE]

I'll change the code. It presently raises a warning & retries for roundoffs > 26/64.

The new code will warn for roundoffs > 27/64 if near the FFT limit and 26/64 for FFTs not near the limit.


BTW, there is a remote chance that a roundoff error will not be reproducible. Carry propagation takes a "shortcut" that does not guarantee the FFT data is in a strictly balanced representation. Reading data from the intermediate file does store the number in a strictly balanced representation.

[QUOTE=Batalov;403453]There is some blanket rule that kicks in at n>10000 for FFT choice -- and only generic reduction AVX FFT is used for all n's.
(For n<10000, all-complex AVX FFT is used most of the time; I can send you a lightly sieved set of n, or else for debugging tests you can use any n.)
If you use n=351111 for example, the error will be well-controlled for all-complex AVX FFT, yet it will not be chosen.

I think an appropriate sized all-complex AVX FFT for this form can always be used, but even with forced FFT2=NNN I cannot force it because for some ranges of n, even the forced FFT2 does not force all-complex, but a zero-padded instead.[/QUOTE]

I do not feel comfortable making this change. I tried changing this code:

[CODE]/* If the bits in an output word is less than the maximum allowed (or the user is trying to force us */
/* to use this FFT), then we can probably use this FFT length -- though we need to do a few more tests. */

if (weighted_bits_per_output_word <= max_weighted_bits_per_output_word || gwdata->specific_fftlen) {
double carries_spread_over;
[/CODE]

to this:

[CODE]/* If the bits in an output word is less than the maximum allowed (or the user is trying to force us */
/* to use this FFT), then we can probably use this FFT length -- though we need to do a few more tests. */

if (bits_per_output_word <= max_bits_per_output_word || gwdata->specific_fftlen) {
// if (weighted_bits_per_output_word <= max_weighted_bits_per_output_word || gwdata->specific_fftlen) {
double carries_spread_over;
[/CODE]

but was not happy with the results. You may wish to try your own tweaks to see if you can come up with a criteria that works over all k*b^n+c values.

[QUOTE=pepi37;406262]Can you compile 287 version?[/QUOTE]

OK, OK, 28.7 now available.

[QUOTE=Prime95;407580]OK, OK, 28.7 now available.[/QUOTE]
Thanks! :bow:
TitleOutputFrequency works!

[QUOTE=Prime95;407573]Carry propagation takes a "shortcut" ...[/QUOTE]Shortcuts make long delays, [size=1][sub]but inns make longer ones[/sub][/size].

Tolkien had this right.

[QUOTE=Madpoo;407572]...
Anyway, I don't worry about it too much. Yeah, it makes the resulting error code non-zero, but if it's reproducible then the error code reflects that and it's not really too bad.
...[/QUOTE]My point was that the errors were reproducible : they occurred at exactly the same iteration, with the same round off error and only the second time was the error considered reproducible. In the end the test was successful.

Anyway by changing the crossover point this thing will not happen any more. It plays havoc with the PrimeNet reliability of the computer and thus influences the work-units one gets.

Jacob

[QUOTE=S485122;407587]... It plays havoc with the PrimeNet reliability of the computer and thus influences the work-units one gets.[/QUOTE]

I don't remember the details, but I don't think the occasional reproducible round-off error will cause the computer's reliability index to suffer too much... at least not to the point where it won't get preferred assignments. George would have more input on that, but I think a reliability of 0.98+ is all it takes to get preferred work, so there is some accounting for "typical" round-off cases.

Plus you can login and tick your CPU's and mark them "corrected" to set the reliability back to 1.0 with the "Reset, I fixed the hardware" option.

I'm more concerned at the moment with all of the flaky machines I'm finding (of course, I'm [B]looking[/B] for them, so it's not surprising I'm finding them) that have high reliability, their results had a zero error code, but the residue is bad. Obviously these machines suffered along the way with some problems or another... overclocked memory perhaps.

Some systems return bad results so often, I'm surprised their system in general isn't crashing on a daily basis. :smile:

So yeah, when systems like that can skate by (at least until the double checkers discover their true nature) and good machines get flagged because of reproducible round-offs, it can seem unfair, but like I said, if you know your system is okay and all you've ever seen are those repro round-offs, just mark the "I fixed it" option and carry on.

[QUOTE=S485122;407587]My point was that the errors were reproducible : they occurred at exactly the same iteration, with the same round off error and only the second time was the error considered reproducible. In the end the test was successful.[/QUOTE]

Sorry if I am misunderstanding some detail here - just happened across last few posts here and too busy/lazy to read back in time - but wouldn't one need the 'second time' to establish reproducibility? Or are you referring to 'second time' in the sense of second 'hit-error/restart-from-last-savefile/see-if-retry-hits-same-error' program-flow cycle?

Thanks,
-Ernst

[QUOTE=ewmayer;407713]Sorry if I am misunderstanding some detail here[/QUOTE]

1) You get a roundoff > 0.4 on iteration X
2) Prime95 rolls back to the last save file
3) When you get to iteration X again, on good hardware prime95 expects to get a roundoff > 0.4 error again. However, this is not guaranteed.

[QUOTE=Prime95;407716]1) You get a roundoff > 0.4 on iteration X
2) Prime95 rolls back to the last save file
3) When you get to iteration X again, on good hardware prime95 expects to get a roundoff > 0.4 error again. However, this is not guaranteed.[/QUOTE]

This reminds me... can you alter the frequency that save files are generated from 30 minutes to maybe 5 minutes in an attempt to lower the impact of these rollback/retry cycles?

Or would 5 minutes not roll back enough iterations to retry using the alternate method for those cases when it's reproducible?

I see about one of my workers per day doing this on various 34M exponents that I presume were near the FFT crossover... just thinking of ways to recoup that lost hour or so.

[QUOTE=Madpoo;407717]This reminds me... can you alter the frequency that save files are generated from 30 minutes to maybe 5 minutes in an attempt to lower the impact of these rollback/retry cycles?[/QUOTE]This? Minimum is 10 minutes from the GUI. Don't know if changing [I]DiskWriteTime=30[/I] in prime.txt to lower than 10 works.

[ATTACH]12955[/ATTACH]
EDIT: Manually editing the prime.txt seems to work:[ATTACH]12956[/ATTACH]

[QUOTE=sdbardwick;407718]This? Minimum is 10 minutes from the GUI. Don't know if changing [I]DiskWriteTime=30[/I] in prime.txt to lower than 10 works.

[ATTACH]12955[/ATTACH]
EDIT: Manually editing the prime.txt seems to work:[ATTACH]12956[/ATTACH][/QUOTE]

Yeah, I just set it to 10 minutes but I didn't know if it was safe to do so in terms of retrying the iterations with the alternate method.

Well, I guess it should be fine... I have most of my 34M work being done by 6-core workers, and even those can go through an amazing # of iterations at that FFT size in 30 minutes. :smile:

I assume then that with 10 minutes between intermediate writes, at most I'd lose 20 minutes instead of an hour. Works for me.

IIRC (I did a search of the forum but no joy), not setting ErrorCheck=1 and SumInputsErrorCheck=1 to force error checking every iteration means the error checking occurred every 100 iterations (+- 1 factor of 10), so any positive integer setting of DiskWriteTime would be fine from a number of iterations standpoint.

I might have read that in an ancient readme or undoc file.

[SIZE="1"][COLOR="SlateGray"][FONT="Arial Narrow"](Then again, I might be misinterpreting the whole situation...)[/FONT][/COLOR][/SIZE]

[QUOTE=Madpoo;407717]This reminds me... can you alter the frequency that save files are generated from 30 minutes to maybe 5 minutes in an attempt to lower the impact of these rollback/retry cycles?[/QUOTE]

It would be great if P95 can be made to save a copy of the FFT _in memory_ every 100-1000 iterations, so that such restarts can be done really efficient (also useful in case of a "prime found" scenario).

The objective of savefile is to not lose work in case of improper shutdown, so it is not really the most optimal solution in this scenario. It is being used just because "it's there".

[QUOTE=Prime95;407716]1) You get a roundoff > 0.4 on iteration X
2) Prime95 rolls back to the last save file
3) When you get to iteration X again, on good hardware prime95 expects to get a roundoff > 0.4 error again. However, this is not guaranteed.[/QUOTE]

Yes, I get that - in fact my program now also uses a similar scheme to support auto-upping of the FFT length if the default breakpoint proves overly aggressive for the user's current p. My question to S485122 was whether by 'second time' he was referring to step (3) in your above flow, that is, the second run of the same checkpoint-anchored iteration subinterval.

But - could you clarify 'this is not guaranteed'? If there has been no data corruption, i.e. the ROE in (1) is 'genuine', what could possibly change on rerun of the subinterval to yield a different ROE on the iteration in question?

[QUOTE=ewmayer;407725]But - could you clarify 'this is not guaranteed'? If there has been no data corruption, i.e. the ROE in (1) is 'genuine', what could possibly change on rerun of the subinterval to yield a different ROE on the iteration in question?[/QUOTE]
See Post 109

[QUOTE=ewmayer;407713]Sorry if I am misunderstanding some detail here - just happened across last few posts here and too busy/lazy to read back in time - but wouldn't one need the 'second time' to establish reproducibility? Or are you referring to 'second time' in the sense of second 'hit-error/restart-from-last-savefile/see-if-retry-hits-same-error' program-flow cycle?

Thanks,
-Ernst[/QUOTE]An iteration provokes a round-off error, the program starts again from the last save file, at the same iteration it gets a round-off error again (same round off as far as they are shown on screen and in the log file), the program restarts from the last save file and, then only, it concludes the error is reproducible. See the excerpts from the log file sin my first post on the subject.

Jacob

[QUOTE=S485122;407727]An iteration provokes a round-off error, the program starts again from the last save file, at the same iteration it gets a round-off error again (same round off as far as they are shown on screen and in the log file), the program restarts from the last save file and, then only, it concludes the error is reproducible. See the excerpts from the log file sin my first post on the subject.[/QUOTE]

Thanks - so it really is the second retry, one more than should be required.

Note that before prime95 redoes the problematic iteration it writes a new save file. So on the third retry (the one where a slower method is used for extra safety) only the problematic iteration is redone.

Thus, if you are using the standard 30 minute save file write time, the time lost due to a roundoff error averages 15 minutes.

[QUOTE=Prime95;407793]Note that before prime95 redoes the problematic iteration it writes a new save file. So on the third retry (the one where a slower method is used for extra safety) only the problematic iteration is redone.

Thus, if you are using the standard 30 minute save file write time, the time lost due to a roundoff error averages 15 minutes.[/QUOTE]

Gotcha. In my brain I imagined it could get a round-off error just 1 second before it's next time to save the interim file, so it would roll back a full 30 minutes. Then I was thinking it would (hopefully) repeat the problem and roll back the full 30 minutes *again* using the safer method.

Knowing that it wouldn't go back to that same 30-minutes ago save file and uses something more recent is good, plus it makes me feel just fine about setting the save file time to 10 minutes (or less).

Believe it or not, I can actually remember back to when the save file size and the time it took to write it was an issue (like '97 or '98 I guess?). I even remember running it from a floppy at times so that my Prime95 was portable... saving the interim files was a much bigger deal and not something to do that often. :smile:

Now that I think about it, why is it set to 30 minutes by default? :confused: Just a legacy thing I suppose?

If I may also ask, why are save files limited to three?

One can write a batch file that wakes up every 5 minutes and, if it finds a "*.bu" (or a "*.bu2", etc) file will rename it to "*.iteration.bkk" (or bk1, etc) then go back to sleep, so you can very easy keep all the history if you want. About the "30 minutes" default time, this makes only sense when your power management does not turn the hdd off periodically. In windoze, that is set to 20 minutes by default, so if you didn't play with it, and didn't switch to SSD meantime, than the life of your HDD will be significantly shortened by the fact that every 20 minutes the HDD is turned off by PM, just to be spun again 10 minutes later by P95. This is case the computer stays idle during p95 is running, because when you edit your docs or play your game, the HDD may have no time to spin off.

[QUOTE=LaurV;407803]... the life of your HDD will be significantly shortened by the fact that every 20 minutes the HDD is turned off by PM, just to be spun again 10 minutes later by P95.[/QUOTE]Are you sure this reduces the lifetime of the HDD? Wouldn't the fact that it is running a duty cycle of only 666‰ increase the lifespan by 50%? No?

The life time of (almost) any electronic device (from light bulbs to including your HDD) is longer if it runs continuously than if you repeatedly turn them on/off. The most of the devices that get damaged ("the most" like in 99%, but take this with a grain of salt, I have no data to back this up, it is just a "feeling"), they get damaged when you turn them on or off. How many of you have seen a light bulb booming during it was lighting, and how many of you happened to turn a light bulb on just to see/hear it booming. The HDD is just the same: spinning it up repeatedly means that the head has to be parked, then it has to be brought to floating position again (there are no "springs" to keep the head out of the disks' surface, this is done by "ground effect", during the disk spins, some air goes between the head and the plate, due to the aerodynamical form of the head, lifting the head up), and during this process there are more chances that the plate can be scratched. In fact, there is a (destructive) HDD test that the manufactures are doing (like Western Digital, they have a factory in Thailand and we used to buy HDDs from them for one of our industrial terminals) which counts how many times the head can be parked and floated again before the plate is scratched. You will be amazed of how "small" is this number! (and no, not in the context of "small numbers" RDS is thinking about :razz:). Of course, this does not count other "effects" as thermal stress (expansion), variation in the frequency of vibrations, etc.

[edit: one of my colleagues reading this says: "C'mon, in few minutes, a good HDD does not have time to stop, friction is so small that it would continue to rotate for longer time after you cut the power", I don't know if this counts for me or for you, hehe, but the head is parked, anyhow...]

[QUOTE=LaurV;407807]The life time of (almost) any electronic device (from light bulbs to including your HDD) is longer if it runs continuously than if you repeatedly turn them on/off. The most of the devices that get damaged ("the most" like in 99%, but take this with a grain of salt, I have no data to back this up, it is just a "feeling"), they get damaged when you turn them on or off. How many of you have seen a light bulb booming during it was lighting, and how many of you happened to turn a light bulb on just to see/hear it booming. The HDD is just the same: spinning it up repeatedly means that the head has to be parked, then it has to be brought to floating position again (there are no "springs" to keep the head out of the disks' surface, this is done by "ground effect", during the disk spins, some air goes between the head and the plate, due to the aerodynamical form of the head, lifting the head up), and during this process there are more chances that the plate can be scratched. In fact, there is a (destructive) HDD test that the manufactures are doing (like Western Digital, they have a factory in Thailand and we used to buy HDDs from them for one of our industrial terminals) which counts how many times the head can be parked and floated again before the plate is scratched. You will be amazed of how "small" is this number! (and no, not in the context of "small numbers" RDS is thinking about :razz:). Of course, this does not count other "effects" as thermal stress (expansion), variation in the frequency of vibrations, etc.

[edit: one of my colleagues reading this says: "C'mon, in few minutes, a good HDD does not have time to stop, friction is so small that it would continue to rotate for longer time after you cut the power", I don't know if this counts for me or for you, hehe, but the head is parked, anyhow...][/QUOTE]Well I can give an anecdote (the singular of data) here. My WD "My Book" will park the heads just a few seconds after read/writes have stopped, and un-park when read/writes begin again. And after about 10 minutes of no read/writes the platters will spin down (and it only takes less than 30 seconds for the platters to stop rotating). So as far as parking is concerned it happens anyway even when the platters are not going to stop.

Well , every conversation is welcome, but somehow I cannot see how spin down and spin up of disc platters is connected with new version of Prime 95 :question::alex:

[QUOTE=pepi37;407816]Well , every conversation is welcome, but somehow I cannot see how spin down and spin up of disc platters is connected with new version of Prime 95 :question::alex:[/QUOTE]Well if we want to optimise the lifetime and reliability of our systems then we need to understand how P95 will affect the various components involved.

[QUOTE=retina;407817]Well if we want to optimise the lifetime and reliability of our systems then we need to understand how P95 will affect the various components involved.[/QUOTE]

Well, in that case it is better to know how OS works, Prime95 make one or two backup every xx minutes :)

Odd version # being logged with 28.6
 

This is probably more for George directly, but oh well... :smile:

I just noticed that in the result messages for the new 28.6 version, it has the short version of "We4". I guess that's been true for several older versions, at least back to 28.5 ?

Unfortunately that string seems to belong to "Windows64,Prime95,v26,(aka We4)"

I don't know if it makes a difference when the client itself checks in results... I do all of mine using the manual results page which parses that string to get the version # ? Seems my old auto check-ins with 28.5+ are okay, but the manually checked in stuff is either coming in with "unknown" or that v26.

I guess maybe versions past some 25.x or 26.x no longer had the old v4 "aka" string, or something like that, but the result string just uses "We4" for us manual folks?

Not a huge issue. I did do a little query to see if certain app versions had more errors than others, but the only anomalies I found were from a certain older version anyway ("Windows64,Prime95,v26.3,build 1" had more bad than good...could be more about the few people that used it than the software itself).

Oh... interim file names
 

Also, while I'm on a roll... LOL

Maybe future versions could change the filename scheme for the save files, so you don't need the secret decoder ring to figure out which save file belongs to which exponent? I puzzled out the scheme but it's too much work to figure out on the fly. I do tend to move work around, probably more than I really need to, and figuring out which file goes with which exponent is tricky.

I ended up writing a little script to look in the file itself to get the exponent and current iteration which has the benefit of telling me how far along it is from just the command line, which comes in handy.

I know that larger exponents already have just the exponent itself after the "P" so hopefully we could do that for all of them? There's really not much point these days to limit it to an 8.3 filename format, is there? If so maybe make that a new option in local.txt that people could set if they really must run it under DOS or something archaic. :no:

Is there a command line version of 28.7 for Mac OS X?

[QUOTE=Madpoo;407992]... so you don't need the secret decoder ring to figure out which save file belongs to which exponent ...[/QUOTE]Consider it a rite of passage. Part of the entry requirements into the elite club of users that can decode such arcane things in a fraction of a second without the aid of any computer technology. Where is the fun in simply spelling everything out in plain language where any old duffer could figure it out?

[size=1][color=grey]Admittedly, I am still not a member of said club. :([/color][/size]

[QUOTE=retina;409576]Consider it a rite of passage. Part of the entry requirements into the elite club of users that can decode such arcane things in a fraction of a second without the aid of any computer technology. Where is the fun in simply spelling everything out in plain language where any old duffer could figure it out?[/QUOTE]

I cheat a little... I look at the save file with a script that reads offset 0x14 for 0x28 bytes.

First 4 bytes of that block are the exponent, and then the last 4 bytes of that chunk are the current iteration. It's how I keep track (centrally) of each worker on each machine, by looking at the % done from just reading the save files. Yes... nerdy, I know, but I think it's safe to say if you're reading this, you're a nerd too. :smile:

Is it me or 28.7 version is shown as untrusted client in the CPUs page?

Forgive my stupid question: (as I am not using 28.7 yet, so I can not test it)
Did you compiled it by yourself? (i.e. without George's "funny" code?)

[QUOTE=LaurV;409861]Forgive my stupid question: (as I am not using 28.7 yet, so I can not test it)
Did you compiled it by yourself? (i.e. without George's "funny" code?)[/QUOTE]

No, it's the precompiled version (downloaded from this very thread).

When I recently started using some other computers, they showed up as untrusted at first with 28.6.

[QUOTE=UBR47K;409858]Is it me or 28.7 version is shown as untrusted client in the CPUs page?[/QUOTE]

I'm not seeing this. Please turn on Debug=2 in the Primenet section of prime.txt. Communicate with the server and email me the prime.log file.

Thanks.

[QUOTE=Prime95;409931]I'm not seeing this. Please turn on Debug=2 in the Primenet section of prime.txt. Communicate with the server and email me the prime.log file.

Thanks.[/QUOTE]

I checked the CPU page today and it now shows as a Trusted client.

If version 28.5 is deprecated and we're supposed to use 28.7, why is it that 28.5 is still listed at [URL="http://www.mersenne.org/download/"]http://www.mersenne.org/download/[/URL]?

[QUOTE=Kaboom;410331]If version 28.5 is deprecated and we're supposed to use 28.7, why is it that 28.5 is still listed at [URL="http://www.mersenne.org/download/"]http://www.mersenne.org/download/[/URL]?[/QUOTE]

Hmm... good reminder.

If all of the mirrors are updated I can fix that. I'll check on those, otherwise for now I could disable the mirrors from being included in the download links until they get 28.7 up there.

I also should make sure 28.7 is officially official. I know it's out there but I'm not sure if George has given it his stamp of approval that it's good to go?

EDIT: I checked the mirrors, and "mersenne.info" doesn't have the 28.7 stuff yet but the others do.

[QUOTE=Madpoo;410334]
I also should make sure 28.7 is officially official. I know it's out there but I'm not sure if George has given it his stamp of approval that it's good to go?[/QUOTE]

There haven't been any bug reports so I guess we should make it official.

[QUOTE=Prime95;410342]There haven't been any bug reports so I guess we should make it official.[/QUOTE]

I mocked up the changes earlier, so... done.

The OSX command line version for 28.7 doesn't seem to exist, so I left that one at version 28.5.

I also popped in the whatsnew.txt from 28.7 since there's a link to it on the page... I noticed it didn't have a "28.7" specific section so I added in the changes I was aware of or found when comparing sources. I always like being able to see what's new when I'm updating. :smile:

Speaking of which, the whatsnew.txt file included with the download only covers up to version 28.6.

[QUOTE=ixfd64;410785]Speaking of which, the whatsnew.txt file included with the download only covers up to version 28.6.[/QUOTE]

Yeah... the only things I was personally aware of that 28.7 has are the things I manually added to the online version.

[CODE]New features in Version 28.7 of prime95.exe
-------------------------------------------

1) Fixed a bug introduded in v28.6 with the "ScaleOutputFrequency" and "TitleOutputFrequency" options
2) Manually disabling AVX will also disable FMA3[/CODE]

Pretty minor stuff, although I appreciate the 1st one since I use it on my systems. Without the scaling, it was really wonky when testing a super large one alongside a much smaller on another worker.

Any news about the OSX command line version?

Also, bug report for the OSX GUI version: Window -> Merge All Workers causes a reproducible crash. Crash log attached.

[QUOTE=Zr40;412132]Any news about the OSX command line version?

Also, bug report for the OSX GUI version: Window -> Merge All Workers causes a reproducible crash. Crash log attached.[/QUOTE]

bug fixed in next release.

I've built a new non-GUI version, it is not tested.

I'm running stress test on my new computer with Prime95 28.7 and I noticed that most of these low exponents are composite, is this intentional? All of these are composite except 737279 and 638977.

I noticed it because I got a single error on 662593 and could not run a complete double check on it. I don't remember if the LL test even makes sense on a composite exponent?

[QUOTE=ATH;413606]I'm running stress test on my new computer with Prime95 28.7 and I noticed that most of these low exponents are composite, is this intentional?[/QUOTE]

It is unintentional. For stress testing, using composite exponents is just as good as prime exponents. I simply chose random odd exponents when building the stress test data.

When Prime95 encounters an error like Roundoff error it continues from last save file, but when it passes that same iteration again, there is no additional message.

I know it keeps reporting that there have been an error for stress testing purposes, but maybe it could report if the error was not there on the second pass of the same iteration, or is that implied since no further error messages?

[QUOTE=ATH;424626]
I know it keeps reporting that there have been an error for stress testing purposes, but maybe it could report if the error was not there on the second pass of the same iteration, or is that implied since no further error messages?[/QUOTE]

Yes that is implied. You will get a message only if the roundoff error was reproducible.

Can I from We4: 1798980A,00000000 calculate time that Prime95 need to finish PRP test?

[QUOTE=pepi37;427922]Can I from We4: 1798980A,00000000 calculate time that Prime95 need to finish PRP test?[/QUOTE]

no

Help in Prime95 F1 not working
 

When I press F1 in the Prime95 GUI, it is supposed to open a help file. Instead, it produces an error saying Failed to launch help :help:. Screenshot attached. Could this be because the help file wasn't placed in the build's zip file when uploaded to the internet? Or that the help file isn't correctly named so the program can't find it? Or was a help file planned but not implemented?

Help in Prime95 F1 not working
 

The F1 button, attached to the help file in Prime95, causes a reproducible error every time I try to open the help file. Also, I do not think there even is a help file in the downloadable zip. Screenshots attached of the error and the contents of the base zip. I do not know if this was unintentional, or if a help file was planned but never added.
[ATTACH]14128[/ATTACH]

[ATTACH]14129[/ATTACH]

F1, Help an help file
 

In previous versions of Prime95 a help file existed. If my memory serves well it was not included any more because of changes in standard format of help files. If you search on this forum it is possible that you could find a post explaining that.

If you need help read the different .txt files included with the software.

I still have a copy of the old .chm help file, the information therein is a bit outdated : the date on the file is 2005, I am not sure that is correct.

Jacob

I do not need the help file. I was just making sure that this was intentional. Also, sorry I posted it twice. On the first post, I did not have a chance to read the screen that shows up after you press submit that says it will be invisible until a mod approves it. I thought it was an error so I posted an updated version of it with 2 attachments. That is when I saw that screen and realized that my first post did go through.

Welcome to the forums! No need to apologize.

Anyone out there care to make a Windows help file? I gave up after MicroSoft changed help file formats for a 3rd time. I use Microsoft Visual Studio 2005 with MFC - I wouldn't be surprised if it was impossible to do new-style help from an old-style development platform.

The old help format, while not perfect, had a lot of features (including indexing, and ways of help integration from different vendors). It had a rich set of tools developed around the format, it was easy to implement and everybody was using it.

These days, if there is any kind of help at all [in programs, tools, and utilities], more often than not it just opens up a webpage in the browser. Good luck, if you are not connected to the Internet.

I think it was security vulnerabilities that were officially named as the reason for retiring the old help format. IMHO, it would have been better to plug the security holes and keep on building upon the old help format, rather that killing it all together.

BTW, Visual Studio 2005 is about to get officially retired: [url]https://support.microsoft.com/en-us/lifecycle?p1=3041[/url]