[QUOTE=Kevin;140896]I think after the last false-alarm, something was added so that if a prime was reported it would also send the error code (for whatever reason it didn't before). I imagine there would be far less optimism from all parties in the know if this were the case, and more to the point, I don't think George would've posted something on the main page if the test had an error and thus a non-trivial chance of being a false alarm.[/QUOTE]

Check page 3 of this thread.

[QUOTE=Prime95;140010]Now it is very official. I have the last save file and I've rerun the last 5000+ iterations. Ahhhh, the pleasant beeping sound and repeating "New Mersenne Prime!!!" message.[/QUOTE]

I'm aware of that. But an error that occurred before the last save file in some bizarre way that lead to a false positive would still lead to a false positive if you ran the last iterations again. As I already said, the optimism of George et. all in multiple statements are the best indications that there was no error.

[QUOTE=ewmayer;140900]we just got the keys to the proverbial Ferrari[/QUOTE] Can you describe the hardware of [I]your [/I]Ferrari ?
Seems that [I]my [/I]own Ferrari is a little bit slower than yours...
T.

[quote=jinydu;140909]Why do you say that? As I recall from looking at cleared.txt, all 18 candidates are first-time LL tests.[/quote]
This is what I have in my cleared.txt from 0700 to 0800 23 Aug 2008 (sorted by latest first).

[code]
42796219 69 0x4F4C53A0908A5D__ 23-Aug-08 07:59 DingoDog starfury
21087943 67 D 0xC75D8B55B1D1B7__ 23-Aug-08 07:58 DarekM DAREKM20
42781927 69 0x8613884B69237A__ 23-Aug-08 07:56 jmoseley Vader
41935241 69 0xEDB167FA1DBB31__ 23-Aug-08 07:53 S00039 Cinebox_0
41959849 69 0xD689BE98B86C77__ 23-Aug-08 07:53 curtisc grn206--11l
[COLOR=Red][B]32428427 69 0xB6C80137FEDB7E__ 23-Aug-08 07:49 suuuncon SPDELL[/B][/COLOR]
42760397 70 0xA6090C299C0678__ 23-Aug-08 07:46 curtisc JCKL-ccd62L
42801739 69 0xF6DDB517B9A4C6__ 23-Aug-08 07:44 DingoDog starfury[B]
28829407 69 0x849E58408C92DE__ 23-Aug-08 07:41 hagenbuchner XENserv1
20623513 67 D 0xF685AD4A0C9134__ 23-Aug-08 07:35 WileECoyote TimB21-1a[/B]
40896127 69 0x4F9CCA10FDF131__ 23-Aug-08 07:35 fcg619 C1391
37763179 70 0xB141C151483C99__ 23-Aug-08 07:34 curtisc wcm128--03L
42206137 69 0x0A0EEC17151DAC__ 23-Aug-08 07:33 drrocket MIS5PC
43112609 69 0x8691696D2BDA50__ 23-Aug-08 07:33 UclaMath C20E3341C
36705287 70 0xDDA8BEB967041D__ 23-Aug-08 07:32 dmazh dm2
43411699 69 0x7C0112FE295ECD__ 23-Aug-08 07:25 salfter office1
38859463 69 0x5840B65CA7CB7B__ 23-Aug-08 07:23 curtisc JCKL-cce41L
43096799 69 0x32E28ECEC2C31B__ 23-Aug-08 07:21 TeamRessler 1062315
37946213 69 0x901FF5AA04168E__ 23-Aug-08 07:19 S611352 p4raid[B]
19825909 67 D 0x6C5F679CF11DAD__ 23-Aug-08 07:11 PennyBlkP PennyBlk_S1[/B]
37425887 68 0x9B10891A72B405__ 23-Aug-08 07:02 BranMuffin ROTV-O4[/code]32428427 was the one with the known fake residue, which is [URL="http://v5www.mersenne.org/report_exponent/?exp_lo=32428427&exp_hi=&B1=Get+status"]now known to be composite[/URL].

Of the candidates below 10M digits which occured before 32428428 (bolded above), two of them are doublechecks, and they have residues matching the first time checks, compared to older cleared.txt reports and the v5 server in this thread (again, assuming they haven't been faked to match, which I think is unlikely).

I see. I copied my list of candidates from Fusion_power on post #123. He must have omitted the double-checks.

[quote=T.Rex;140875]I'm using a 16x Itanium2 1.6 Ghz NUMA machine. And I've used some specific code and some special features of the Bull Linux version in order to have such a terrific speed.[/quote]
What are those special Linux features, if you can say that is :smile:. hugetlb stuff? Others?

[QUOTE=T.Rex;140915]Can you describe the hardware of [I]your [/I]Ferrari ?
Seems that [I]my [/I]own Ferrari is a little bit slower than yours...
T.[/QUOTE]

I've held off giving much in the way of details as we have been running on some outdated hacked up version of Mlucas from last year which we hadn't really tested well at the current FFT length. As of today we have the nice new Mlucas code release working which means we have a bit more speed and a lot more reliability in terms of restart capability (just in case if anything goes pear shaped).

The system we have been using is a [URL="http://www.sun.com/servers/midrange/m5000/"]Sun SPARC Enterprise M5000 Server[/URL]. These are a very popular Sun systems due to the impressive raw performance both in CPU and I/O.

Up until today we have been running on 8 (16 cores) * 2.15 GHz SPARC64 VI processors. From today with the new code and availability of a new system we are now able to continue the run on a M5000 with 4 (16 cores) * 2.4 GHz SPARC64 VII processors.

The systems are running [URL="http://www.sun.com/software/solaris/index.jsp"]Solaris 10[/URL], the Mlucas code was compiled with [URL="http://developers.sun.com/sunstudio/index.jsp"]Sun Studio Express[/URL] and parallelized using [URL="http://openmp.org"]OpenMP[/URL].

The biggest pain as Ernst has [URL="http://www.mersenneforum.org/showpost.php?p=140856&postcount=320"]pointed out[/URL] is that we are running at an unnecessarily large FFT length of 4096K which means we have a significant performance deficit that we are still trying to resolve.

NB: The Mlucas code we are using is pure C with no special machine specific assembler code. This really highlights the amazing application design from Ernst and the OpenMP skills of Tom Harper (who worked on Mlucas during last years [URL="http://code.google.com/soc/2007/opensolaris/about.html"]Google Summer of Code[/URL]).

[QUOTE=rgiltrap;140925] Up until today we have been running on 8 (16 cores) * 2.15 GHz SPARC64 VI processors. From today with the new code and availability of a new system we are now able to continue the run on a M5000 with 4 (16 cores) * 2.4 GHz SPARC64 VII processors.
[/QUOTE]

I should note that using Mlucas the maximum number of usable threads is currently 16, though Ernst has plans for that :smile:

I would love to throw [URL="http://www.sun.com/servers/highend/m9000/"]256 SPARC64 VII cores[/URL] at it if we could use them :flex:. Then again I don't think anyone would loan me one of those!

Just for reference, the smallest exponent for which Prime95 version 24.14 uses 4096K FFT is M68,130,000. So the fact that 4096K is unnecessarily large is of no use as a hint...

[QUOTE=ewmayer;140878]But I strongly suspect both Prime95 and Glucas are using the same FFT length, because it should be ample for testing the number in question.
[/QUOTE]

That on the other hand could be a clue. I'm guessing it means the exponent is not just barely above one of the Prime95 FFT boundaries.

[quote=rgiltrap;140925](just in case if anything goes pear shaped)..[/quote]
I don't know about you, but I find nothing wrong with pear-shaped... thingies... Some of them are really useful ...for one thing or another...

[quote=ewmayer;140900]
[B]Verification Update[/B]

Also, on the Sparc alleged-new-Mersenne-prime verify front, we just got the keys to the proverbial Ferrari: I have grayed out the iteration number, the other verifiers will be able to fill it in once they see a matching 64-bit residue for their own runs:

[I][Sep 04 04:30:19] Mxxxxxxxx Iter# = 2**00000 clocks = 00:26:06.000 [ 0.0224 sec/iter] Res64: 9A889EC66E9DB2DC. AvgMaxErr = 0.000001898. MaxErr = 0.00000381[/I]

So even though this is still at the wastefully long FFT length of 4096K, we are running as fast as Tony Reix's more-recently-started verify run.[/quote]

0.0224 sec/iter means ten days for 40M iterations.
Taking this with the presumed inadequacy of a 2048K FFT,
I think we can anticipate an exponent > 40M.