suspect LL assigned again to me

[rudi_m]

Hi,

Two months ago I committed a suspect LL result for
M24935857
(Iteration: 8604965/24935683, ERROR: ROUND OFF (0.421875) > 0.40)

Yesterday I got the same exponent assigned again.
Shouldn't it be verified by somebody else?

BTW
I got the same error on M24959279 which is positively verified by somebody else now.
In both cases mprime decided to use 1280K FFT instead 1536K but then I got a round off error during test.

[garo]

I would throw it back in the pool.

[S485122]

Originally Posted by rudi_m

I got the same error on M24959279 which is positively verified by somebody else now.
In both cases mprime decided to use 1280K FFT instead 1536K but then I got a round off error during test.

I have had a batch of primes on a FFT size crossover. I got so many recoverable round off errors that I tweaked the SoftCrossover values in the configuration files. (See undoc.txt the format of those adjustments has change since 24.14.)

Jacob

[rudi_m]

I threw it back to the pool.

BTW I noticed that the roundoff error became smaller since last version:

v258 on core 2:
Final average roundoff error is 0.23479, using 1280K FFT for exponent 24935683

v259.3 on core 2:
Final average roundoff error is 0.22402, using 1280K FFT for exponent 24935683

[garo]

I got 24935683 today and was just mumbling to myself about the recoverable roundoff errors I am going to get.

[Nelson]

I got a recent Doublecheck near the fft limits that also chose the smaller fft (1024) and "slam, bang, thank you m'am" it produced a round off error:

Trying 1000 iterations for exponent 20066933 using 1024K FFT.
If average roundoff error is above 0.242, then a larger FFT will be used.
Final average roundoff error is 0.24017, using 1024K FFT for exponent 20066933.

I think the 0.242 criteria is much too large and should be something like 0.121 or use the largest round-off error instead of the average and/or more iterations 1000 doesn't seem to be enough. I haven't been able to tweak the Soft crossovers successfully. The last time I tried it I started getting progress reports every 64K(=65536) iterations. The round-off errors seem to be accumulative until a savefile is employed by either stopping and restarting or the program does it for you.

[Sat Feb 07 09:43:57 2009]
Iteration: 644800/20066933, ERROR: ROUND OFF (0.40625) > 0.40
Continuing from last save file.

I restarted as it didn't indicate a recoverable error at least not yet so I've disabled communication with the server and turned round-off checking on until I get a matching residue. And later after a day of offtime restarting at a point further down but prior to the first Round-off error voila it happens again. The error value is exactly the same as the previous error and seems to indicate that the LL test is working properly I guess I'll find out Wenesday. The testing system has produced reliable LL-D results and has a reliability , Confidence of (0.94,10.0)

[Mon Feb 09 12:20:07 2009]
Iteration: 10106065/20066933, ERROR: ROUND OFF (0.40625) > 0.40
Continuing from last save file.

 [Feb 9 11:59] Iteration: 10000000 / 20066933 [49.83%].  Round off: 0.1953125000 to 0.3750000000.  Per iteration time: 11.58 ms.
[Feb 9 11:59] M20066933 interim Wd1 residue F5D29AC426CB3F13 at iteration 10000000
[Feb 9 11:59] M20066933 interim Wd1 residue C48E66A19DF6B92F at iteration 10000001
[Feb 9 11:59] M20066933 interim Wd1 residue D992C34319750A31 at iteration 10000002
[Feb 9 12:20] Iteration: 10106065/20066933, ERROR: ROUND OFF (0.40625) > 0.40
[Feb 9 12:20] Continuing from last save file.
[Feb 9 12:20] Setting affinity to run helper thread 1 on logical CPU #1
[Feb 9 12:20] Resuming primality test of M20066933 using FFT length 1024K, 2 threads
[Feb 9 12:20] Iteration: 10058524 / 20066933 [50.12%].  Round off: 0.1953125000 to 0.3750000000.
[Feb 9 12:47] Iteration: 10200000 / 20066933 [50.82%].  Round off: 0.1953125000 to 0.3750000000.  Per iteration time: 11.63 ms.

Is there another means of forcing the larger FFT and will it affect the final residue? My guess is it would but as LL series it should be the same regardless of fft size.

DoubleCheck=(AID),FFT2=1M,20066933,66,1 adjusted assignment after iteration test
DoubleCheck=(AID),20066933,66,1 assignment prior to to iteration test

I suppose replacing "FFT2=1M" with some other value would work and restarting from scratch but if the final residue turns out differently it wouldn't be much use unless it turned out to be Prime. And what would that value be "1.280M" perhaps? (source code)?
Some final questions what else should I do just let it go and if it matches great if not try for a error free residue? Would someone be willing to test also with a larger FFT for a matching residue before turning in results?

nelson

[S485122]

Originally Posted by Nelson

I haven't been able to tweak the Soft crossovers successfully.

Remember you have to exit Prime95 to edit the configuration files. the settings also depend on the Pime95 version...

Do not forget to remove those lines once you are through with such a bad exponent.

I had two exponents with 09000900 error counts that checked perfectly, but I was feeling nervous... When I had another exponent with the same kind of problems I tweaked the settings successfully, but that was with version 21.14.

Good luck !

Jacob

[Nelson]

Well the assignment completed successfully with 2 roundoff errors. I think it would have been 3 if I hadn't had a stop and restart during the test.

20066933 No factors below 2^66 
  P-1   B1=210000, B2=1522500 
  Verified LL  A74AA6B38477449F  by "............."  
  Verified LL  A74AA6B38477449F  by "HighPriceRanch" on 2009-02-10 
  History  A74AA6B3847744__  by "HighPriceRanch" on 2009-02-10

however primenet responded with the following additional message:

 
Comm thread Feb 10 22:10] PrimeNet success code with additional info:
[Comm thread Feb 10 22:10] Computer hardware check recommended. Possible hardware errors occured during LL test of M20066933
[Comm thread Feb 10 22:10] Done communicating with server.

red highlights mine.

That's not very encouraging and I appreciate your good wishes Jacob. My nervousness was compounded by the fact that one of my v4 units(P4 using v24.14) had returned a number of bad tests that returned without errors. Which I discovered while testing this machine thinking that a residue without errors should be reliable "NOT". After testing 2 earlier assignments about 8 times each on different configurations and hardware I managed to arrive at a reliable result and didn't want to go through that again. A wasteful use of electricity and time but it's the only testing method I've found that really squeezes out any bugs. Far better than the stress test which gives at best an easy starting point.

I got 24935683 today and was just mumbling to myself about the recoverable roundoff errors I am going to get.

The "Disregard last error..." never appeared still I guess I can ignore the warning about hardware except that reliability, confidence dropped to 0.88, 10.0 from 0,94, 10,0. Any more results like that and reliability will be out the window as far as the server is concerned and not at all desirable. Knowing where the roundoff errors will occur and stopping and restarting basically going back to the save file would prevent the errors from recording but that isn't part of the game plan as far as I know(not to mention the extra testing time).

nelson

[rudi_m]

Originally Posted by Nelson

After testing 2 earlier assignments about 8 times each on different configurations and hardware I managed to arrive at a reliable result and didn't want to go through that again. A wasteful use of electricity and time but it's the only testing method I've found that really squeezes out any bugs.

For testing hardware you should do a double or even triple check.
To speed up the procedure you could use InterimFiles=n (see undoc.txt), so you can diff these interim files against reliable ones and possibly recognize an error without finishing that LL completely.

Originally Posted by garo

I got 24935683 today and was just mumbling to myself about the recoverable roundoff errors I am going to get

I hope you will confirm my result. :)
I guess you will not get roundoff errors if you are using v259.3 since the roundoff seemed to improve like I mentioned in my last posting.

[Nelson]

Yes, Thanks Rudi that's exactly what I've been doing. I take it a step further and keep the interim residues or is that what you meant. I keep residues every 1 million iterations and interim files every 5 million iterations. When the drive gets crowded I move them to external storage with the residues moved to a new text file for each specific exponent of interest for future checking. Sometimes it can take up to 20 million non-stop iterations before an error pops up. When it does though I don't have to go back to the beginning and start over using the interim files.

My real complaint though is the reliability ranking that gets knocked down because of the expected errors on a test near a crossover. The machine is just as reliable as before but really got sacked for roundoff errors even though the residues matched.

I hope Garo gets a matching residue for you too. If he posts it here would be nice but of more interest would be the consequences to his reliability standing if errors do occur.

nelson

[garo]

Once I start work on that exponent, I will post here with any round off errors I get and finally when the result is submitted. But be warned, I have a number of 18M double checks to work through first.