mersenneforum.org  

Go Back   mersenneforum.org > Great Internet Mersenne Prime Search > Software > Mlucas

Reply
 
Thread Tools
Old 2009-10-28, 14:38   #1
Sleeping_menace
 
Oct 2009

28 Posts
Default MLucas, submit results?

perhaps I'm being really numb here, and forgive me if I am, but the readme page is giving me instructions for submitting results.. but the link/button isn't there to press, so to speak.
Anyone know what page/link I use to submit results obtained running Mlucas?
Thanks in advance.
Sleeping_menace is offline   Reply With Quote
Old 2009-10-28, 21:12   #2
Mini-Geek
Account Deleted
 
Mini-Geek's Avatar
 
"Tim Sorbera"
Aug 2006
San Antonio, TX USA

102538 Posts
Default

http://www.mersenne.org/manual_result/ accepts Mlucas inputs.
(admittedly, it's not at all visible that it accepts things other than Prime95/Mprime lines, but it lists "Mlucas lines found" after you give it results)
Remember to log in to the site first so the credit goes to you and not ANONYMOUS.
Mini-Geek is offline   Reply With Quote
Old 2009-10-29, 08:09   #3
Sleeping_menace
 
Oct 2009

2 Posts
Smile Gratitude

Ah..thanks for that.. .. for whatever reason, as I looked around the site, I just didn't see that one.
Cheers.
Sleeping_menace is offline   Reply With Quote
Old 2015-05-12, 03:12   #4
alexvong1995
 
Dec 2014

37 Posts
Default cannot submitt mlucas results.txt

I have just finished my 1st LL test with Mlucas but it seems the primenet manual check-in form does not recognize the results.
Does anyone know why?

Here is my results.txt:
Quote:
INFO: primary restart file p67773569 not found...looking for secondary...
INFO: no restart file found...starting run from scratch.
INFO: primary restart file p67773569 not found...looking for secondary...
INFO: no restart file found...starting run from scratch.
INFO: primary restart file p67773569 not found...looking for secondary...
INFO: no restart file found...starting run from scratch.
INFO: primary restart file p67773569 not found...looking for secondary...
INFO: no restart file found...starting run from scratch.
INFO: primary restart file p67773569 not found...looking for secondary...
INFO: no restart file found...starting run from scratch.
M67773569 Roundoff warning on iteration 5175394, maxerr = 0.421875000000
M67773569 Roundoff warning on iteration 8635898, maxerr = 0.437500000000
M67773569 Roundoff warning on iteration 16462455, maxerr = 0.437500000000
M67773569 Roundoff warning on iteration 18912472, maxerr = 0.437500000000
M67773569 Roundoff warning on iteration 28470196, maxerr = 0.468750000000
Retrying iteration interval to see if roundoff error is reproducible.
M67773569 Roundoff warning on iteration 28470008, maxerr = 0.500000000000
Retrying iteration interval to see if roundoff error is reproducible.
M67773569 Roundoff warning on iteration 29200282, maxerr = 0.437500000000
M67773569 Roundoff warning on iteration 40912707, maxerr = 0.437500000000
M67773569 Roundoff warning on iteration 45488771, maxerr = 0.437500000000
M67773569 Roundoff warning on iteration 50502214, maxerr = 0.437500000000
M67773569 Roundoff warning on iteration 61959752, maxerr = 0.421875000000
M67773569 is not prime. Res64: 0A85E13CEFD7xxxx. Program: E14.1
M67773569 mod 2^36 = 5556347xxxx
M67773569 mod 2^35 - 1 = 18548321243
M67773569 mod 2^36 - 1 = 13658393030

Last fiddled with by ewmayer on 2015-05-12 at 05:16 Reason: Xed out last few digits of res64 and res36
alexvong1995 is offline   Reply With Quote
Old 2015-05-12, 04:54   #5
ewmayer
2ω=0
 
ewmayer's Avatar
 
Sep 2002
República de California

3·7·19·29 Posts
Default

Quote:
Originally Posted by alexvong1995 View Post
I have just finished my 1st LL test with Mlucas but it seems the primenet manual check-in form does not recognize the results.
Does anyone know why?

Here is my results.txt:
Is that quoted text what you tried to paste into the results-submit form?

Also, please PM me your p67773569.stat file - I want to look into that fatal-error retry around midway through, to see if the code handled it properly (this is a recently-added feature). The exponent is close to the default breakover point between 3584K and 3840K so the first dangerous [0.46875] roundoff error is not surprising, but the 0.500 one on the ensuing interval-retry needs looking into. (Your result should still be fine, if the code switched to the larger 3840K FFT length at the point).

What kind of hardware (and on how many cores) did you run this on?
ewmayer is offline   Reply With Quote
Old 2015-05-12, 06:54   #6
alexvong1995
 
Dec 2014

458 Posts
Default

Thanks author.
Yes the quoted text is what I submitted.
The .stat file is in the attachment.
I cannot pm because it does not support attachment and the file is too large to be in-line.

Code:
$ uname -a
Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24) x86_64 GNU/Linux
Code:
$ cat /proc/cpuinfo
processor    : 0
vendor_id    : AuthenticAMD
cpu family    : 16
model        : 4
model name    : AMD Phenom(tm) II X4 945 Processor
stepping    : 3
microcode    : 0x10000c8
cpu MHz        : 3012.706
cache size    : 512 KB
physical id    : 0
siblings    : 4
core id        : 0
cpu cores    : 4
apicid        : 0
initial apicid    : 0
fpu        : yes
fpu_exception    : yes
cpuid level    : 5
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca  cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt  pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc  extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic  cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt  nodeid_msr hw_pstate npt lbrv svm_lock nrip_save vmmcall
bogomips    : 6025.41
TLB size    : 1024 4K pages
clflush size    : 64
cache_alignment    : 64
address sizes    : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

processor    : 1
vendor_id    : AuthenticAMD
cpu family    : 16
model        : 4
model name    : AMD Phenom(tm) II X4 945 Processor
stepping    : 3
microcode    : 0x10000c8
cpu MHz        : 3012.706
cache size    : 512 KB
physical id    : 0
siblings    : 4
core id        : 1
cpu cores    : 4
apicid        : 1
initial apicid    : 1
fpu        : yes
fpu_exception    : yes
cpuid level    : 5
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca  cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt  pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc  extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic  cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt  nodeid_msr hw_pstate npt lbrv svm_lock nrip_save vmmcall
bogomips    : 6025.41
TLB size    : 1024 4K pages
clflush size    : 64
cache_alignment    : 64
address sizes    : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

processor    : 2
vendor_id    : AuthenticAMD
cpu family    : 16
model        : 4
model name    : AMD Phenom(tm) II X4 945 Processor
stepping    : 3
microcode    : 0x10000c8
cpu MHz        : 3012.706
cache size    : 512 KB
physical id    : 0
siblings    : 4
core id        : 2
cpu cores    : 4
apicid        : 2
initial apicid    : 2
fpu        : yes
fpu_exception    : yes
cpuid level    : 5
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca  cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt  pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc  extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic  cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt  nodeid_msr hw_pstate npt lbrv svm_lock nrip_save vmmcall
bogomips    : 6025.41
TLB size    : 1024 4K pages
clflush size    : 64
cache_alignment    : 64
address sizes    : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

processor    : 3
vendor_id    : AuthenticAMD
cpu family    : 16
model        : 4
model name    : AMD Phenom(tm) II X4 945 Processor
stepping    : 3
microcode    : 0x10000c8
cpu MHz        : 3012.706
cache size    : 512 KB
physical id    : 0
siblings    : 4
core id        : 3
cpu cores    : 4
apicid        : 3
initial apicid    : 3
fpu        : yes
fpu_exception    : yes
cpuid level    : 5
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca  cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt  pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc  extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic  cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt  nodeid_msr hw_pstate npt lbrv svm_lock nrip_save vmmcall
bogomips    : 6025.41
TLB size    : 1024 4K pages
clflush size    : 64
cache_alignment    : 64
address sizes    : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate
Attached Files
File Type: bz2 p67773569.stat.bz2 (156.4 KB, 150 views)
alexvong1995 is offline   Reply With Quote
Old 2015-05-12, 12:56   #7
James Heinrich
 
James Heinrich's Avatar
 
"James Heinrich"
May 2004
ex-Northern Ontario

C8116 Posts
Default

Quote:
Originally Posted by alexvong1995 View Post
I have just finished my 1st LL test with Mlucas but it seems the primenet manual check-in form does not recognize the results.
Does anyone know why?
I had not seen a result line with that Mlucas version number. I have adjusted the manual results form to accept a wider range of Mlucas version numbers. I also re-submitted your result for you:
http://www.mersenne.org/M67773569
James Heinrich is offline   Reply With Quote
Old 2015-05-12, 21:25   #8
ewmayer
2ω=0
 
ewmayer's Avatar
 
Sep 2002
República de California

101101001100112 Posts
Default

Alex, thanks - I am rerunning your exponent on my Haswell quad, 4-cored it needs ~9 ms/iter - currently around iter 6M, no roundoff warnings yet, but note that the FMA-using build I'm using has slightly lower roundoff errors than your non-FMA one. (I can't tell instantly from your CPU diagnostics whether this model supports AMD's FMA4, but in any event I have no intention of coding for that, i.e. my code supports only the Intel-introduced FMA3.)

Now, re. the history captured in your stat file:

o I see lots of restarts - not in itself unusual depending on system usage and stability - but also some one-restart-after-another inervals like this:
Quote:
[Mar 29 03:04:09] M67773569 Iter# = 390000 clocks = 00:06:46.013 [ 0.0406 sec/iter] Res64: 756756DA0FC6E775. AvgMaxErr = 0.239570977. MaxErr = 0.343750000
Restarting M67773569 at iteration = 390000. Res64: 756756DA0FC6E775
M67773569: using FFT length 3584K = 3670016 8-byte floats.
this gives an average 18.466832024710520 bits per digit
Using complex FFT radices 224 16 16 32
Restarting M67773569 at iteration = 390000. Res64: 756756DA0FC6E775
M67773569: using FFT length 3584K = 3670016 8-byte floats.
this gives an average 18.466832024710520 bits per digit
Using complex FFT radices 224 16 16 32
[Mar 29 03:16:17] M67773569 Iter# = 400000 clocks = 00:06:14.689 [ 0.0375 sec/iter] Res64: E3228230BA5452AB. AvgMaxErr = 0.239515427. MaxErr = 0.343750000
Restarting M67773569 at iteration = 400000. Res64: E3228230BA5452AB
M67773569: using FFT length 3584K = 3670016 8-byte floats.
this gives an average 18.466832024710520 bits per digit
Using complex FFT radices 224 16 16 32
...
[dozen more such 4-line restart msgs snipped]
...
Restarting M67773569 at iteration = 400000. Res64: E3228230BA5452AB
M67773569: using FFT length 3584K = 3670016 8-byte floats.
this gives an average 18.466832024710520 bits per digit
Using complex FFT radices 224 16 16 32
[Mar 29 03:43:11] M67773569 Iter# = 410000 clocks = 00:06:24.857 [ 0.0385 sec/iter] Res64: 689B7E4ABD60FE46. AvgMaxErr = 0.239397778. MaxErr = 0.343750000
Were you playing with overclocking or some other system-setup stuff here?

o The fatal-error occurrence about midway through is different than I expected. Instead of being in midst of some ongoing run (e.g. due to some kind of system/power/cosmic-ray glitch), in your case it happens almost immediately upon restart from the checkpoint file:
Quote:
[Apr 18 06:38:39] M67773569 Iter# = 28470000 clocks = 00:06:17.968 [ 0.0378 sec/iter] Res64: 5FA073737FB6FF79. AvgMaxErr = 0.239484814. MaxErr = 0.375000000
Restarting M67773569 at iteration = 28470000. Res64: 5FA073737FB6FF79
M67773569: using FFT length 3584K = 3670016 8-byte floats.
this gives an average 18.466832024710520 bits per digit
Using complex FFT radices 224 16 16 32
M67773569 Roundoff warning on iteration 28470196, maxerr = 0.468750000000 <*** 196 iters into restart ***
Retrying iteration interval to see if roundoff error is reproducible.
Restarting M67773569 at iteration = 28470000. Res64: 5FA073737FB6FF79
M67773569: using FFT length 3584K = 3670016 8-byte floats.
this gives an average 18.466832024710520 bits per digit
Restarting M67773569 at iteration = 28470000. Res64: 5FA073737FB6FF79 <*** I need to look into why the restart message gets printed twice ***
M67773569: using FFT length 3584K = 3670016 8-byte floats.
this gives an average 18.466832024710520 bits per digit
Using complex FFT radices 224 16 16 32
M67773569 Roundoff warning on iteration 28470008, maxerr = 0.500000000000 <*** On retry, get a different fatal error (both error level and iteration #) ***
Retrying iteration interval to see if roundoff error is reproducible.
Restarting M67773569 at iteration = 28470000. Res64: 5FA073737FB6FF79
M67773569: using FFT length 3584K = 3670016 8-byte floats.
this gives an average 18.466832024710520 bits per digit
M67773569: using FFT length 3584K = 3670016 8-byte floats.
this gives an average 18.466832024710520 bits per digit
Using complex FFT radices 224 16 16 32
M67773569: using FFT length 3584K = 3670016 8-byte floats.
this gives an average 18.466832024710520 bits per digit
Using complex FFT radices 224 16 16 32
[Apr 18 15:52:10] M67773569 Iter# = 28480000 clocks = 00:06:42.782 [ 0.0403 sec/iter] Res64: 74D0B0E5536739D7. AvgMaxErr = 0.239356785. MaxErr = 0.375000000
According to the notes-to-self in the code logic I use here, after the code hits the 0.50 error on the first retry, it should 'throw up its hands' and exit, as this sort of scenario is usually a sign of data corruption, and requires at least a code restart, and possibly a system reboot. According to the above the code instead did one more retry - again with the duplicate messaging - and this one was successful (last line of quoted snip).

I shall investigate - we'll know (based on my DC run) in around 48 hours whether your run got past the above glitch OK.

BTW, the code should have deposited persistent savefiles with custom suffixes every 10 Miters, so if my DC indicates the above fatal error somehow hosed your run, you can still rerun from the 20 Miter checkpoint file - but first let's wait on my DC to get to iter 28480000.

James, thanks for the server-side update. Note that Mlucas version numbers will henceforth have a major index reflecting the calendar year, i.e. 14.*** means a 2014 release. (14.0 was the first 2014 release; 14.1 was the second, last December).
ewmayer is offline   Reply With Quote
Old 2015-05-13, 11:21   #9
alexvong1995
 
Dec 2014

2516 Posts
Default

Thanks for the primenet submission!
Yes, some of the things you mentioned did happen.

I had data corruption back (or not since ext4 has journaling) then because of power failure. I remembered during fsck, serveral lines of 'clearing orphan inodes blablabla' was printed, but nothing bad happen afterwards.

My computer was over-clocked during winter from 3000MHz to 3300MHz. I switched it back to 3000MHz when summer arrived because the summer in HK is hot and humid. I don't think it is the cause of the round-off errors since I double-checked some of my mprime results and they appears to be correct. (The only bad result was when I over-clocked my cpu to 3600MHz)

One day my computer failed to boot and I found out it was due to ram slot failure. I transfered the ram from ram slot 1, 3 to ram slot 2, 4 and my computer booted again and passed memtest.

Last fiddled with by alexvong1995 on 2015-05-13 at 11:24
alexvong1995 is offline   Reply With Quote
Old 2015-05-14, 06:12   #10
ewmayer
2ω=0
 
ewmayer's Avatar
 
Sep 2002
República de California

1157110 Posts
Default

Alex, our runs match through iter 19M ... still a day from seeing whether your run made it through the fatal-error-and-interval-retry at 28.47M intact, but that does mean the first three 0.4375-level roundoff errors you hit were all benign. (I allow this as the largest acceptable maxerr based on a fair bit of statistics, but still treat it as "threat level yellow" in terms of keeping an eye on such runs.)
My run has encountered no warning-level roundoffs so far, i.e. all ROEs have been < 0.40.

Quote:
Originally Posted by alexvong1995 View Post
Yes, some of the things you mentioned did happen.

I had data corruption back (or not since ext4 has journaling) then because of power failure. I remembered during fsck, serveral lines of 'clearing orphan inodes blablabla' was printed, but nothing bad happen afterwards.

My computer was over-clocked during winter from 3000MHz to 3300MHz. I switched it back to 3000MHz when summer arrived because the summer in HK is hot and humid. I don't think it is the cause of the round-off errors since I double-checked some of my mprime results and they appears to be correct. (The only bad result was when I over-clocked my cpu to 3600MHz)
I wasn't concerned about the ROEs <= 0.4375 (except if there were more than 10 or so of the largest of these), those all look consistent ... just the anomalously large fatal-ROE-almost-immediately-after-restart at iter 28.47M.

Haven't yet had time yet to set up a debug simulation of that scenario - been working on a couple of must-fix bugs in my newly parallelized TF code. Found/fixed last of those a few hours ago, so will focus on the fatal-ROE/retry stuff tomorrow.
ewmayer is offline   Reply With Quote
Old 2015-05-15, 06:35   #11
ewmayer
2ω=0
 
ewmayer's Avatar
 
Sep 2002
República de California

264638 Posts
Default

Alex, I inserted some debug code into the mers_mod_square.c function (which has the key roundoff error handling logic) to make it easy to simulate the issue which I thought you had encountered in your run-restart at iter = 28.47M. Here are the highlights of that - first I did 10000 iterations (with no debug-code yet inserted) of the exponent used for the 2304K self-test (unimportant, I just picked one that was visible in my build/test xterm):

M44207087: using FFT length 2304K = 2359296 8-byte floats.
this gives an average 18.737405988905167 bits per digit
Using complex FFT radices 288 16 16 16
[May 14 11:47:28] M44207087 Iter# = 10000 clocks = 00:01:09.224 [ 0.0069 sec/iter] Res64: C2FA6D57AA3DF3F1. AvgMaxErr = 0.276980321. MaxErr = 0.375000000

I killed the run at this point, and added some debug code which made the control logic 'think' a ROE = 0.46 was hit on [restart iter + 78], then simulated on the ensuing retry of the iteration interval. Then I restarted under gdb (allowing me to step through the relevant code) - everything behaved as designed, here is the stat file output:

Restarting M44207087 at iteration = 10000. Res64: C2FA6D57AA3DF3F1
M44207087: using FFT length 2304K = 2359296 8-byte floats.
this gives an average 18.737405988905167 bits per digit
Using complex FFT radices 288 16 16 16
M44207087 Roundoff warning on iteration 10078, maxerr = 0.460000000000
Retrying iteration interval to see if roundoff error is reproducible.
Restarting M44207087 at iteration = 10000. Res64: C2FA6D57AA3DF3F1
M44207087: using FFT length 2304K = 2359296 8-byte floats.
this gives an average 18.737405988905167 bits per digit
M44207087 Roundoff warning on iteration 10026, maxerr = 0.500000000000

Now the only (minor) bug I found was that the final informational-message-to-user that gets printed after the 2nd roundoff error only got printed to stdout. I fixed that in my local code, here is the message that should have gotten printed at this point (followed by exit):

The error is not reproducible, but encountered a different ROE in the retry of the interval ... as this is
an indicator of likely data corruption, quitting. Please restart the program at your earliest convenience.


Notice one thing about the above diagnostics: The "Using complex FFT radices" line gets printed just once, because the retries in question all use the original FFT length. If the ROE encountered is fatal (> 0.4375) but "normal", i.e. simply a result of the FFT length and the data in question leading to a too-high error level, then you would see the same error (both magnitude and iteration#) on the retry attempt, and then you would see an added diagnostic indicating the program has switched to the next-higher FFT length and restarted from the checkpoint in question. In your data we don't see any next-larger-FFT-length stuff:

Restarting M67773569 at iteration = 28470000. Res64: 5FA073737FB6FF79
M67773569: using FFT length 3584K = 3670016 8-byte floats.
this gives an average 18.466832024710520 bits per digit
Using complex FFT radices 224 16 16 32
M67773569 Roundoff warning on iteration 28470196, maxerr = 0.468750000000
Retrying iteration interval to see if roundoff error is reproducible.
Restarting M67773569 at iteration = 28470000. Res64: 5FA073737FB6FF79
M67773569: using FFT length 3584K = 3670016 8-byte floats.
this gives an average 18.466832024710520 bits per digit
Restarting M67773569 at iteration = 28470000. Res64: 5FA073737FB6FF79
M67773569: using FFT length 3584K = 3670016 8-byte floats.
this gives an average 18.466832024710520 bits per digit

I now see that I was parsing this wrong - what I thought was duplicate printing of the last 6 lines above (same 3-lines repeated twice) should instead most probably (can't bee 100% sure since I wasn't there) be read as follows:

M67773569 Roundoff warning on iteration 28470196, maxerr = 0.468750000000
Retrying iteration interval to see if roundoff error is reproducible.
Restarting M67773569 at iteration = 28470000. Res64: 5FA073737FB6FF79
M67773569: using FFT length 3584K = 3670016 8-byte floats.
this gives an average 18.466832024710520 bits per digit
[*** above run got killed ***]
[*** start of a new run: ***]
Restarting M67773569 at iteration = 28470000. Res64: 5FA073737FB6FF79
M67773569: using FFT length 3584K = 3670016 8-byte floats.
this gives an average 18.466832024710520 bits per digit
Using complex FFT radices 224 16 16 32
M67773569 Roundoff warning on iteration 28470008, maxerr = 0.500000000000
Retrying iteration interval to see if roundoff error is reproducible.

In other words, you hit almost-instant fatal errors - but not of the reproducible kind - on 2 successive restart attempts. Perhaps you were playing with OCing and had the clock speed jacked up higher than safe here.

We then see what appears to be the standard "retry to see if reproducible" messaging, but again with 2x duplication of a 2-line sequence, and I don't have a ready explanation for that 2x-ing - do you pipe stdout to the stat file, perhaps?

Restarting M67773569 at iteration = 28470000. Res64: 5FA073737FB6FF79
M67773569: using FFT length 3584K = 3670016 8-byte floats.
this gives an average 18.466832024710520 bits per digit
M67773569: using FFT length 3584K = 3670016 8-byte floats.
this gives an average 18.466832024710520 bits per digit

The next few lines don't clear up my puzzlement:

Using complex FFT radices 224 16 16 32
M67773569: using FFT length 3584K = 3670016 8-byte floats.
this gives an average 18.466832024710520 bits per digit
Using complex FFT radices 224 16 16 32

The 2 "Using complex FFT radices" lines make it look like the code got restarted while the above interval-retry was still in progress.

Anyhoo, my run just hit iter 28480000, the result matches yours, so we can rest easy about the above funny business possibly corrupting your run data. "The integrity of our customers' run data is our #1 priority." :)
ewmayer is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Automatic submit results + fetch assignments for mfaktc? DuskFalls GPU Computing 5 2017-12-02 00:34
How do we prevent miraculously true DC results from manual submit? leonardyan96 PrimeNet 77 2017-06-01 16:18
how to submit manually a job with exponent 100M which is done by mfaktc? fairsky Information & Answers 17 2013-09-16 19:49
Only submit part of ECM results? dabaichi PrimeNet 5 2011-12-07 19:27
Unable to submit / retrieve new work Unregistered Information & Answers 12 2011-11-12 20:07

All times are UTC. The time now is 23:58.

Thu Dec 3 23:58:02 UTC 2020 up 20:09, 1 user, load averages: 1.19, 1.34, 1.29

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

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.