mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   News (https://www.mersenneforum.org/forumdisplay.php?f=151)
-   -   41st Known Mersenne Prime Reported!! (https://www.mersenneforum.org/showthread.php?t=2475)

ixfd64 2004-05-23 18:28

Any estimated dates of completion yet?

Oh, and welcome back, TTn. :)

ewmayer 2004-05-23 19:06

My run passed 9M three hours ago, so Jeff now has me in his rear-view mirror.

Attempting a theoretically possible (but never before attempted outside a laboratory) reverse-plasma pinch maneuver to get my remaining 2 warp engines online, so I can rejoin Xyzzy and Jeff in the fight against the Borg Cube.


Re. the "mystery" false-positive exponent, between the information people have already gleaned on this thread and the information here (in particular my 13. June post):

[url]http://www.mersenneforum.org/showthread.php?t=663[/url]

It's really quite obvious.

Prime95 2004-05-23 19:52

[QUOTE=TTn]I have one last question on the topic.
Do you mean zero residue as in the Lucas test?
As I found zero residue(hex)of the false test, which could be crutial in deciphering the cyclic problem.
FFT routines are cyclic, and it is mentioned in the source code that there is a problem especially with the SSE2.[/QUOTE]

TTn, this will be my last attempt at explaining various errors that have you worried. The cases you have cited over the months have different causes.

1) The false prime at 16.8 million. A zero final residue was generated due to a hardware error. While we can't know what caused the problem, Ernst and I came up with 3 or 4 different scenarios where a memory glitch could cause repeated zero residues. For example, if the FFT weights table got zeroed, then multipplying the FFT result by the FFT weights would cause a zero every iteration. I put in more safeguards to detect these nasty scenarios. That doesn't mean we haven't overlooked a scenario and we get a false positive in the future. That is why we have folks like Jeff and Ernst double-check the result before announcing it to the world.

2) False negatives are quite common. Roughly 2% of all tests have a hardware glitch ruin the result. This is why we run a double-checking program.

3) PRP and LLR have had many problems with testing "small" numbers - say a thousand bits or less. These were program bugs, there may be more bugs left to find. The FFT code was designed with big multiplies in mind and there hasn't been a lot of testing on small numbers. I know you are loathe to do so, but you'll just have to take my word that these small number bugs had no effect on testing larger numbers.

4) The recent LLR false negative, the LLR program printed out "xxx is not prime. Residue: 0000000000000000." Someone thought that looked fishy and tested the number with an older LLR or PRP. Sure enough, it was prime. Jean Penne has fixed this bug.

5) I've no info on the recent LLR false positive report.

In short, sometimes problems are caused by bugs in LLR, PRP, or prime95. Sometimes the hardware screws up and bad results are produced. You'll just have to take our word on whether a given problem report was caused by a program bug or hardware glitch. The alternative is to download the source code and fire up the debugger, we're happy to fix any bugs you find.

Xyzzy 2004-05-23 20:02

[QUOTE=koekie]Btw Xyzzy how is your run progressing :bounce: ?[/QUOTE]15.4M...

TTn 2004-05-23 21:01

Fair enough,
It's a problem to be watched.

T.Rex 2004-05-23 21:43

Progressing
 
Hi,
I'm 0.020 iter/sec on our Bull NovaScale 16x ia64 NUMA machine.
Since Glucas is not fully NUMA-scalable, it can be improved in the future.
More than 60 % is already done.
Due to a hang of NPTL, I lost 32 hours. I hate NPTL's bugs! (Look at nptl.bullopensource.org , help is welcome!).
I have to move to a slower machine Monday morning ...
Hope it will be finished next Friday.
I'll provide more information tomorrow morning (night in USA).
Tony

tom11784 2004-05-24 01:12

My P-1 is done:

UID: tom11784/desktop, M24036583 completed P-1, B1=625000, B2=10000000, WZ1: 6D52BE44

ixfd64 2004-05-24 05:24

[QUOTE=T.Rex]Hi,
I'm [b]0.020 iter/sec[/b] on our Bull NovaScale 16x ia64 NUMA machine.
Since Glucas is not fully NUMA-scalable, it can be improved in the future.
More than 60 % is already done.
Due to a hang of NPTL, I lost 32 hours. I hate NPTL's bugs! (Look at nptl.bullopensource.org , help is welcome!).
I have to move to a slower machine Monday morning ...
Hope it will be finished next Friday.
I'll provide more information tomorrow morning (night in USA).
Tony[/QUOTE]
I don't want to wait 38 years... :shock:

jinydu 2004-05-24 08:35

Anyone know how I got this new avatar? I didn't make it.

Also, 0.020 sec/iteration seems incredibly fast! Its faster than my 3.055 GHz doublecheck on a 12.13M exponent with all nonessential programs closed down!

koekie 2004-05-24 09:08

[QUOTE=jinydu]Anyone know how I got this new avatar? I didn't make it.

Also, 0.020 sec/iteration seems incredibly fast! Its faster than my 3.055 GHz doublecheck on a 12.13M exponent with all nonessential programs closed down![/QUOTE]

As for your avatar I think it are aliens who want to tell you something :alien:

It's indeed very fast, but it are 12 processors crunching away on the same number using multithreaded software, the :showoff:

T.Rex 2004-05-24 12:58

17.25 M
 
17.25 M at still 0.020 sec/iter with only 46 % of 16x ia64 .
Should be finished Wednesday morning (France time) if everything's OK.


All times are UTC. The time now is 08:27.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.