[QUOTE=KEP;531326]From the range n=200,001 to n=1,000,000 there is a total of:

410,389 Sierpinski tests remaining
54,882 Riesel tests remaining

Due to using Prime95, I'm running 1 k on each core on the 12 core Xeon. This means that there is a huge difference in testdepth for the various k's.[/QUOTE]

Which is faster for these tests, Prime95 or llr?

R61 and S463 competed to n=400000. No primes and continuing.

[QUOTE=rogue;531368]Which is faster for these tests, Prime95 or llr?[/QUOTE]

Rogue, from long time ago speed is same

[QUOTE=rogue;531368]Which is faster for these tests, Prime95 or llr?[/QUOTE]

Speed is the same, at least it was once I began testing using P95, but I have not timed it lately so I'm not sure if P95 is faster than LLR, with the latest optimizations of gwnum library. My guess is that it most likely won't be faster to use P95 over LLR.

However, now that I come to think about it, there is one mayor advantage over P95, compared to LLR. If you have a roundoff error, then you are penetalized untill you shut down LLR, even though the following tests could have done with a smaller FFT size. P95, recons that you have had a roundoff error, resumes from last known good checkpoint using a larger FFT and then the next many tests are started with normal FFT size, in stead of what compares to -a1 in PFGW. So in that point of perspective, LLR will be slower compared to P95. But if you run without incidents and errors LLR will be just the same speed as P95, with the CRUS advantage of STOPonprime=1 :smile:

[QUOTE=KEP;531374]Speed is the same, at least it was once I began testing using P95, but I have not timed it lately so I'm not sure if P95 is faster than LLR, with the latest optimizations of gwnum library. My guess is that it most likely won't be faster to use P95 over LLR.

However, now that I come to think about it, there is one mayor advantage over P95, compared to LLR. If you have a roundoff error, then you are penetalized untill you shut down LLR, even though the following tests could have done with a smaller FFT size. P95, recons that you have had a roundoff error, resumes from last known good checkpoint using a larger FFT and then the next many tests are started with normal FFT size, in stead of what compares to -a1 in PFGW. So in that point of perspective, LLR will be slower compared to P95. But if you run without incidents and errors LLR will be just the same speed as P95, with the CRUS advantage of STOPonprime=1 :smile:[/QUOTE]

I suggest you use PRPNet as it supports llr. It will help you manage the work on your server and you can use an html interface to see the status. Of course if you are getting roundoff errors and llr cannot recover, that would be a problem.

[QUOTE=rogue;531394]I suggest you use PRPNet as it supports llr. It will help you manage the work on your server and you can use an html interface to see the status. Of course if you are getting roundoff errors and llr cannot recover, that would be a problem.[/QUOTE]

I was considering PRPnet, but PRPnet is not installed on the Xeon and the Xeon isn't mine. I did not consider it for the quad, since I switched from LLR to P95 and in P95 I have the work spread across the workers as it would have been in PRPnet. I know that someone at Primegrid has found a solution to run LLR multithreaded using PRPnet, but I guess it slipped my mind when taking my initial decision :smile:

Reserving R295 as new base using the new-base script up to 2.5k and sieving to 10k (1G) with srsieve2

Reserving R267 as new base using the new-base script up to 2.5k and sieving to 10k (1G) with srsieve2

R295 tested to n=2.5k + sieved to 1G (2.5-10k)

2358 remain

Results emailed - Base released

Reserving S410 to 350K
Reserving S412 to 250K


S450 at 410K

R267 tested to n=2.5k + sieved to 1G (2.5-10k)

10689 remain

Results emailed - Base released