Jean Penne kindly ask one proth number example that have slowdown in PRP mode ( or any proth number can be used)?
____________
92*10^^1439761-1 REPDIGIT PRIME :) :) :)
314187728^¹³¹⁰⁷²+1 GENERALIZED FERMAT
31*332^³⁶⁷⁵⁶⁰+1 CRUS PRIME
Proud member of team Aggie The Pew. Go Aggie!

GIMPS have found primes in double check.

FTR... Never happened.

Jean Penne kindly ask one proth number example that have slowdown in PRP mode ( or any proth number can be used)?

Jean Penne kindly ask one proth number example that have slowdown in PRP mode ( or any proth number can be used)?

Any proth number will do, but here's what I used for testing:

146220094124808:P:0:2:1 171 2097152

In proth mode, it was taking 0.7 ms/iter, while in PRP mode, it was taking about 1.0 ms/iter.

Same FFT and everything, so that's not it. Possibly due to comparing with -1 after every iteration in PRP mode (SWAG).

EDIT: 64-bit LLR v3.8.17 on Win7

GREAT NEWS

Bug was found and in updated version PRP will be faster ( as should be in first place)
Waiting for new version and for little testing
____________
92*10^^1439761-1 REPDIGIT PRIME :) :) :)
314187728^¹³¹⁰⁷²+1 GENERALIZED FERMAT
31*332^³⁶⁷⁵⁶⁰+1 CRUS PRIME
Proud member of team Aggie The Pew. Go Aggie!

Patched version of LLR is out ( but officially it will take some time because they are now in way to implement multicore support in LLR)

So far

corrected version ( PRP forced)

Starting probable prime test of 171*2^2097152+1
Using all-complex AVX FFT length 128K, Pass1=128, Pass2=1K, a = 3
171*2^2097152+1, bit: 290000 / 2097160 [13.82%]. Time per bit: 0.660 ms.


non corrected version ( PRP forced)

Starting probable prime test of 171*2^2097152+1
Using all-complex AVX FFT length 128K, Pass1=128, Pass2=1K, a = 3
171*2^2097152+1, bit: 300000 / 2097160 [14.30%]. Time per bit: 0.819 ms.
____________
92*10^^1439761-1 REPDIGIT PRIME :) :) :)
314187728^¹³¹⁰⁷²+1 GENERALIZED FERMAT
31*332^³⁶⁷⁵⁶⁰+1 CRUS PRIME
Proud member of team Aggie The Pew. Go Aggie!

Patched version of LLR is out ( but officially it will take some time because they are now in way to implement multicore support in LLR)

So far

corrected version ( PRP forced)

Starting probable prime test of 171*2^2097152+1
Using all-complex AVX FFT length 128K, Pass1=128, Pass2=1K, a = 3
171*2^2097152+1, bit: 290000 / 2097160 [13.82%]. Time per bit: 0.660 ms.


non corrected version ( PRP forced)

Starting probable prime test of 171*2^2097152+1
Using all-complex AVX FFT length 128K, Pass1=128, Pass2=1K, a = 3
171*2^2097152+1, bit: 300000 / 2097160 [14.30%]. Time per bit: 0.819 ms.

Yes, you can download it at his personal page ( links below)

http://jpenne.free.fr/llr3/cllr38hc.zip

http://jpenne.free.fr/llr3/llr38hclinux64.zip

And yes: you can read it here

http://www.mersenneforum.org/showthread.php?p=451890#post451890


____________
92*10^^1439761-1 REPDIGIT PRIME :) :) :)
314187728^¹³¹⁰⁷²+1 GENERALIZED FERMAT
31*332^³⁶⁷⁵⁶⁰+1 CRUS PRIME
Proud member of team Aggie The Pew. Go Aggie!

http://www.mersenneforum.org/showthread.php?p=451890#post451890

http://www.mersenneforum.org/showthread.php?p=451890#post451890

I only see discussion of the multi-threading and Serge's changes for testing Generalized Uniques there. Clearly, it is implemented in the version you have tried though. Probably we should wait for a stable/official release (unless this will be very much later), since I guess he will also be using an upgraded gwnum version to what we are currently running and tested, and so some level of organised testing will be needed.

- Iain

I made copy&paste of PRP problem and send it to Jean Penne via Mersenne forums message. Then he answer to me, and told me that problem is corrected and links are available on his page. But also told me , that next official release will be when he implement multi-core support.
____________
92*10^^1439761-1 REPDIGIT PRIME :) :) :)
314187728^¹³¹⁰⁷²+1 GENERALIZED FERMAT
31*332^³⁶⁷⁵⁶⁰+1 CRUS PRIME
Proud member of team Aggie The Pew. Go Aggie!

Is there a new gwnum library? I'm pretty sure both changes (Serge's and ours) are changes just to LLR, not gwnum.

I dont think that much more testing will be needed when new LLR is released because patch is already tested and checked many times in last year :)
It is tested on specific Phi function, but it works perfectly. So we will have to wait: and will doesnot need to use new LLR ,we can use PRP corrected version for SoB

Only change in corrected LLR is

I found the bug : I defaulted the global variable "strong" to "TRUE" so, by default, a strong Fermat test is done, which is costly! For double checking numbers that are unlikely to be prime, it was really useless, a simple Fermat test being sufficient!

I suspect we're going to wait for the new LLR before starting the double check, so we might be starting the double check somewhat later than expected. I'll let you know as events develop, but there's no dates I can give you at this time.

We finally got multi-core support

We finally got multi-core support

This part I think is great news and will make bigger tasks easier to swallow, with caution there are times where it should, or shouldn't be used for maximum throughput. I don't want to hijack this thread as it is more general than SoB, but I will help out with organised checking that it works when the call is made. It could be "interesting" how BOINC might handle one task using more than one CPU core...

Diverted from origianal SoB Double Checking starting soon


____________
My stats
Badge score: 1*1 + 5*1 + 8*3 + 9*11 + 10*1 + 11*1 + 12*3 = 186

I just hope it isn't "interesting" as in "interesting times".

It scales out differently on different CPUs.
Note that those are run times, not cpu-time (x86 version on Win x64).
But as with other cases, it is better to run several instances.
Once higher FFT size, it may scale out better (due to CPU cache).


i7-3820, no HT, 1-4 threads.
52206462075*2^333333-1 is prime! (100354 decimal digits) Time : 53.023 sec.
52206462075*2^333333-1 is prime! (100354 decimal digits) Time : 38.400 sec.
52206462075*2^333333-1 is prime! (100354 decimal digits) Time : 29.273 sec.
52206462075*2^333333-1 is prime! (100354 decimal digits) Time : 25.233 sec.

i5-6600
52206462075*2^333333-1 is prime! (100354 decimal digits) Time : 37.021 sec.
52206462075*2^333333-1 is prime! (100354 decimal digits) Time : 25.890 sec.
52206462075*2^333333-1 is prime! (100354 decimal digits) Time : 20.523 sec.
52206462075*2^333333-1 is prime! (100354 decimal digits) Time : 19.279 sec.


Older Intel Xeon E5630 (2,5GHz), 2 CPUs, no HT, 1-7 threads.
Note that best perfomance is using 5 threads.
52206462075*2^333333-1 is prime! (100354 decimal digits) Time : 168.229 sec.
52206462075*2^333333-1 is prime! (100354 decimal digits) Time : 92.560 sec.
52206462075*2^333333-1 is prime! (100354 decimal digits) Time : 88.651 sec.
52206462075*2^333333-1 is prime! (100354 decimal digits) Time : 75.826 sec.
52206462075*2^333333-1 is prime! (100354 decimal digits) Time : 66.724 sec.
52206462075*2^333333-1 is prime! (100354 decimal digits) Time : 69.302 sec.
52206462075*2^333333-1 is prime! (100354 decimal digits) Time : 76.635 sec.
52206462075*2^333333-1 is prime! (100354 decimal digits) Time : 87.253 sec.

____________
My stats
Badge score: 1*1 + 5*1 + 8*3 + 9*11 + 10*1 + 11*1 + 12*3 = 186

Is there somewhere I can get the current maximum FFT sizes for each LLR based project? I think it was posted before but may be out of date even if I could find it again. I think I have a good enough model to predict where going multi-thread could show gains based on past testing with Prime95, but obviously I'd like to verify it with representative manual LLR tests.

It scales out differently on different CPUs.
Note that those are run times, not cpu-time (x86 version on Win x64).
But as with other cases, it is better to run several instances.
Once higher FFT size, it may scale out better (due to CPU cache).

*PPS and PPS-Mega: ?

All numbers in K

Can't write much at the moment, but I wouldn't think SGS is a good use case for this :) There's two ways to look at it: shortest possible time for a single test, vs. best overall throughput. Maybe the shortest possible time is of interest for verification, but I would except the main optimisation to be for best overall throughput.

Based on using Prime95 previously, the optimum point is when the single task with multi-threads substantially fills the processor cache. You will get better throughput than running separate tasks individually. If the processor cache is exceeded, you run back into ram bandwidth limitations. If the tasks are particularly small, presumed overheads will lead to reduced throughput. I need to work out what type of tasks may benefit most and will focus my testing on those. I think the maximum benefit point is up to around 768k for an i5, and 1024k for an i7.

Even if there is no throughput benefit, I would prefer to run one task 4x faster than 4 parallel tasks as current (assuming 4 cores).

I'd be happy to be proven wrong, but if not bandwidth limited, you're execution unit limited. HT doesn't help with the heavy lifting. Maybe there is a minor benefit to be obtained elsewhere.

I just did a thought exercise based on the earlier FFT sizes, and some testing I did previously at the 2nd chart in post below:
http://www.primegrid.com/forum_thread.php?id=6545&nowrap=true#92525

The take away point is that, for an 8MB cache quad core, the multi-thread throughput benefit zone is when the blue line is above the orange line. At small FFT sizes, running one unit per core is still most efficient.

At a point, going multi-threaded gives a boost. The cores can collectively work on a shared data set which fits in the processor cache, where it doesn't if they work on separate tasks.

Keep going up in unit size, the cache will eventually be filled and ram limitations come in once again. While throughput isn't improved, you could still run the same number of units quickly in serial sequence than slowly in parallel.

So for a typical i7 which is quad core with 8MB cache, I predict there will be a speed benefit from running SR5 or bigger, with the optimal zone around 321, TRP and ESP projects.

This should scale for smaller cache too, where an i5 with 6MB of cache would also benefit from SR5 and bigger tasks, but the sweet spot is reduced to SR5 and 321 projects.

I would need to give more thought on how i3s behave but the smaller cache sizes might mean they never really give a significant speed increase. They may still benefit from running two large tasks sequentially in the same time as two in parallel. Similarly I don't know if it will scale well to more cores, or how it might work with multiple sockets on the same task.

Thanks for the link to the charts, well done.

I also wonder how it would work on multiple sockets, may try again later with larger FFT size(s).

Sure, on general, running same number of units quickly in serial sequence than slowly in parallel is a win also for (any) project: faster turn-around, less tasks in progress etc.
*IF* boinc scheduler is ready for it and it may get messy if single-threaded and multi-threaded tasks are combined, number of available cores are changing etc.
____________
My stats
Badge score: 1*1 + 5*1 + 8*3 + 9*11 + 10*1 + 11*1 + 12*3 = 186

I don't know how BOINC works in enough useful detail, so following is just speculation. I'd imagine a task could say it needs N cores to run, and would then handle it as such. A user setting might be "use up to N cores per task", set per project.

My understanding of the gwnum multicore handling is that it breaks the work into chunks and fires them out until it all gets done. So, it isn't dependant on having all nominated cores available at once, but would run slower if for example one core was busy elsewhere. Presumably the breaking of up work still need regular recombination, so this isn't generalised enough to allow a huge task to be done on multiple machines for example.

My concern about multiple sockets is how they might interact between the work, per CPU cache, and relative bandwidth between sockets and also ram. A safe option would be to run each socket on a single task each to ensure the cache access is local to the socket. I don't know if the combination of LLR/gwnum, BOINC and/or OS schedulers are smart enough to do that. On the Intel side at least, the inter-socket connection isn't that high in bandwidth terms, less than local memory, so I don't think it would end well to rely on that.

Batalov confirmed Multi core support covers all types of tests.

rebirther has compiled the llr3.8.18 64bit win version.
Now on Jean's site:
http://jpenne.free.fr/

rebirther can't compile the aprcl.exe though. New Wieferich prime search feature seems to need it. Maybe someone with Linux wants to try it out.
First create file weiferich_test_range.abcd:

ABC$a$b$c
1 5000 2

>cllr64.exe weiferich_test_range.abcd -d
Starting Wieferich prime search base 2 from n = 1 to 5000
Error 2 while trying to create new process
Wieferich prime searching not available...

Or if set in PG prefs rather than computing prefs, could even have different settings for different sub-projects.

The wrinkle is going to be when people run a multi core app using an older client.... does the scheduler refuse to let them download, or do they get a task that over commits their processors, or does the project figure out a way to enforce cores=1 on an older client?

As I understand it, Intel HT is execution unit based, either one vcore is running of the other one is.

So my semi-informed guess is that AMD would benefit slightly more, but not a lot more, than Intel by going over to multi-threading on a pair of virtual cores. At least till we see Ryzen, it won't be enough to put AMD back in the lead.

Some timings from my testing of LLR & Prime 95 ( 2 cores per work)
I do few tests and got average values

Candidate length 200K
LLR 3130 second
Prime95 1950 second

candidate length 240K
LLR 2300 seconds
Prime95 2400 seconds

candidate length 320K
LLR 3850 seconds
Prime95 3900 seconds

candidate length 400K
LLR 6800 seconds
Prime95 7200 seconds

candidate length 480K (FMA 3)
LLR 6300 seconds
Prime95 6850 seconds

candidate length 576K (FMA3)
LLR 12100 seconds
Prime95 12800 seconds
____________
92*10^^1439761-1 REPDIGIT PRIME :) :) :)
314187728^¹³¹⁰⁷²+1 GENERALIZED FERMAT
31*332^³⁶⁷⁵⁶⁰+1 CRUS PRIME
Proud member of team Aggie The Pew. Go Aggie!

Just a heads up: It is not likely that we will implement support for multi-core LLR anytime in the foreseeable future. BOINC's support for mutli-core apps is rudimentary and wouldn't be able to do what we'd need it to do.(*)

At the present time, we *think* you could run LLR multithreaded by using app_info.xml to supply a custom llr.ini file. (And, of course, you need app_info.xml to run the new LLR app instead of the stock app.) App_config, which is much simpler to use, won't work at the present time.

With either, you would still need to micro-manage the core utilization on your CPU. BOINC won't help with that.

(*) By "rudimentary" I mean that BOINC doesn't provide a reasonable mechanism by which we could pass a user-specified thread count to the BOINC client. We could certainly tell the app how many cores to use, but the BOINC client wouldn'get that information and wouldn't know how many cores are being used, so it would be unable to schedule tasks correctly.

The other problem is that multi-core apps don't play well with single core apps. BOINC tends not to run any multi-core apps when a single core app is running.

The bottom line is that currently we can't offer a "click here and run multi-core" solution, nor do we expect this to ever happen. I hope that at some point you'll be able to use app_config.xml to specify multi-core via the command line.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Michael, would you have any objection to the use of multi-threads via app_info.xml?

I'm conscious that with past software updates, there has been verification testing before it is deployed. Maybe it would be wise to carry out a similar (manual) exercise for confidence it is working as expected, before use on live tasks. I don't know how much testing it may have had before release.

At the moment I'm doing performance testing using a SR5 prime to confirm the expected speed gains are present, which as a side effect will also provide some data that they get the expected result. Shortly I'll also attempt a test with a TRP unit which I assume isn't prime. I just extracted the test which was run recently.

Michael, would you have any objection to the use of multi-threads via app_info.xml?

I'm conscious that with past software updates, there has been verification testing before it is deployed. Maybe it would be wise to carry out a similar (manual) exercise for confidence it is working as expected, before use on live tasks. I don't know how much testing it may have had before release.

At the moment I'm doing performance testing using a SR5 prime to confirm the expected speed gains are present, which as a side effect will also provide some data that they get the expected result. Shortly I'll also attempt a test with a TRP unit which I assume isn't prime. I just extracted the test which was run recently.

I'm perfectly happy if you wish to volunteer to be a guinea pig. :)

Ok, had a go at app_info.xml, failed. I really don't know what I'm doing and this is a combination of random bits I found elsewhere in the forums, but I've no idea how up to date any of it is, and if anything I changed is relevant.

This is what I have so far:

If you get it working, please let me know how. At some point I'd like to try llrCUDA on 321, which I think is the only project where it will work.
____________

Hi This works for me

Hi This works for me

I have SR5 running on two systems now, one i7-6700k, one i5-6600k. SR5 tasks only need about 4.6MB of storage, so should fit equally in both CPU caches. Both CPUs are also clocked at 4.2 GHz, so I'd expect them to finish in the same time. They don't.

It is early days, and I only have two units each checked to be 576k FFT. The i5 is about 4.4% slower than the i7. I feel this is a bit more than should be expected from a simple measurement variation, and will continue to watch this as more units come though. I have a hunch, could these be L3 cache speed influenced now? The i5 cache happens to run at 3.9 GHz, the i7 cache runs at 4.1 GHz. The difference is 5.1%, so in the same ball park... if this holds up with more units, I'll have to try adjusting the cache speeds and see if it follows.

On the i5, I do have some units passed through it previously. The average was only 1.2% slower for same FFT size. I kinda hoped to see a bigger difference here. This is close enough to 4 threads taking 1/4 the time.

I'm running some units normally on another i7, to check some other recent units which were much faster than the i5 also. I've not run a 4 thread task on this system yet, but if it comes out similar to the other i7, 4-threads would only come out 3.66x faster than one when running 4 at same time, so lower throughput.

I have a hunch, could these be L3 cache speed influenced now? The i5 cache happens to run at 3.9 GHz, the i7 cache runs at 4.1 GHz. The difference is 5.1%, so in the same ball park... if this holds up with more units, I'll have to try adjusting the cache speeds and see if it follows.

Ram timings shouldn't come into it. With only one task it should fit in the L3 cache. Also, the ram in the i7 is slower than the ram in the i5! (2x 2666 2R vs. 4x 3000 1R)

Note where multithread times are mentioned below, they are the reported sum of the 4 threads, so for elapsed time divide by 4.

I've got averages of more units now, and the gap has reduced. The i5 running 4 threads averaged 11781s for 10 of 576k FFT tasks. The i7 running 4 threads averaged 11475s for 11 of 576k FFT tasks, being 2.6% faster on average.

I'm wondering, is there a difference in run times between S and R units? I'm not sure, but the odd unit may be a little faster than others in the same FFT size. The difference between the median values remains similar, at 3.1% faster on the i7.

To confuse matters, I've also been running SR5 units normally on another i7. That is, 4 cores, 4 tasks. This is now confirmed as faster in throughput. Average times for 12 units was 10688s, or 6.9% more throughput than the i7 running 4 threads. This I wasn't expecting. I thought the multithread version would take the lead here.

I need to try two things now, the i7 on 4 threads, switch back to normal. The i7 on normal, switch to 4 threads. Depending on how that goes should point towards the software or hardware.

It doesn't make sense to assume ram is influencing multithread results here as the faster system has the slower ram. The number I prefixed with is the number of modules in total. I had previously found 2 rank per channel gave significantly better results than single, so the 4x1R should be near enough equivalent to 2x2R in that respect. The number of channels is implied through the CPU models stated.

Changing ram settings to normalise them is not trivial. The only way I could guarantee it is to swap modules, and that is physically impossible, or would require running in a significantly degraded state, which I have no intention of doing.

My goal is to do the other testing I mentioned on my other suspiciously fast i7 system, and after that, I'll start talking baseline timings on TRP with the two i7 systems, while I explore cache speed settings with the i5.

I'm wondering, is there a difference in run times between S and R units? I'm not sure, but the odd unit may be a little faster than others in the same FFT size. The difference between the median values remains similar, at 3.1% faster on the i7.

I think that's not the first time I had that advice :)

With enough units done I hope to average it out. I don't have the time to micro-manage manual testing at the moment. Maybe later.

On the i7, I had a bad unit. The system is slightly overclocked to 4.2 GHz (4.0 stock) and doesn't have a history of bad units, apart from one time when cooling failed. So as of right now, that's 32 units completed using 4 threads, 25 valid, 1 invalid, 5 pending, 1 inconclusive. The inconclusive wingman doesn't have any invalid in current history. Temperatures look ok though, not even reaching 60C.

I'll let it continue as is for now but will keep a close eye on it. If that turns out bad I'll revert the OC. Speculation: by not being ram limited, is it pushing the compute units harder than it has before and entering some borderline unstable state?

Edit: the i5 also has an inconclusive unit, where the wingman doesn't have any current history of errors.

Speculation: by not being ram limited, is it pushing the compute units harder than it has before and entering some borderline unstable state?

Edit: the i5 also has an inconclusive unit, where the wingman doesn't have any current history of errors.

While that remains a possibility, I need to let the inconclusive units run their course and see where we are. Since I added a 3rd similar system, it would get really interesting if they all show similar signs, as they were all bought at different times. For them to all suffer at the same time would be unlikely. But, I'm getting ahead of myself here and will let the crunching keep going.

I've had two bad SR5 units each when running 4 threads on both the initial test i5 and i7 systems. To me that points to overclock instability with the new load. Solutions are either to lower clocks or increase voltages. I'll do the former initially as I will be limited on time to decide/test voltages vs power/heat in the short term.

I'll also aim to expand the testing to other quad cores over the weekend.

2 invalid, 1 inconclusive WU on my Skylake, no problems on the Haswell so far.
I hope you have the time to run 3.8.18 on a Haswell.

I'll also aim to expand the testing to other quad cores over the weekend.

It would be interesting to know how many are trying this, on what type of system, with or without any problems.

So far I'm running it on 3 Skylake systems, and the first two are having bad units. The 3rd similar system was set up later so we'll see if that follows.

The two systems I'll try adding are an i5-5675C and i5-4570S. The Broadwell is OC'd so I might have to rethink that before I do so.

It would be interesting to know how many are trying this, on what type of system, with or without any problems.

So far I'm running it on 3 Skylake systems, and the first two are having bad units. The 3rd similar system was set up later so we'll see if that follows.

The two systems I'll try adding are an i5-5675C and i5-4570S. The Broadwell is OC'd so I might have to rethink that before I do so.

http://www.primegrid.com/result.php?resultid=775826749

Above is one of the invalid results I had.

Edit: at this point, I'd still assume it was overclocking related, but as the test will only take about an hour I can re-run it quickly.

http://www.primegrid.com/result.php?resultid=775826749

Above is one of the invalid results I had.

Edit: at this point, I'd still assume it was overclocking related, but as the test will only take about an hour I can re-run it quickly.

64598*5^2318694-1 is not prime. RES64: 4692831FEF0D2834. OLD64: 585DF74D64965C94 Time : 2540.820 sec

From the original computer giving the error (i5):
64598*5^2318694-1 is not prime. RES64: 56D39BCA085E5378. OLD64: 047AD35E191AFA65 Time : 2710.984 sec.

From the i7 which gave errors on different units:
64598*5^2318694-1 is not prime. RES64: 3C7B9361E288F512. OLD64: B572BA25A79ADF33 Time : 2491.017 sec.

Above two are obviously different from each other, and also the previous incorrect result. Both systems have been clock lowered from 4.2 GHz previously, to 4.0 GHz now, without touching voltage. The i5 is still overclocked, and the i7 is essentially at stock, but the voltage may still be lower than standard. Is either one correct?

I've got the same unit running on a Haswell too, but that'll take a bit longer.

From the original computer giving the error (i5):
64598*5^2318694-1 is not prime. RES64: 56D39BCA085E5378. OLD64: 047AD35E191AFA65 Time : 2710.984 sec.

From the i7 which gave errors on different units:
64598*5^2318694-1 is not prime. RES64: 3C7B9361E288F512. OLD64: B572BA25A79ADF33 Time : 2491.017 sec.

Above two are obviously different from each other, and also the previous incorrect result. Both systems have been clock lowered from 4.2 GHz previously, to 4.0 GHz now, without touching voltage. The i5 is still overclocked, and the i7 is essentially at stock, but the voltage may still be lower than standard. Is either one correct?

I've got the same unit running on a Haswell too, but that'll take a bit longer.

64598*5^2318694-1 is not prime. RES64: 47DC8FF7EF9583A8. OLD64: 5C3C1DD5662F6EF0 Time : 31893.685 sec.

I'm not sure we're at the end of the story yet...

64598*5^2318694-1 is not prime. RES64: 7D73797E64F86BC3. OLD64: FD00DA68C6582741 Time : 3431.898 sec.

This is on a Haswell Xeon. CPU is not overclocked (it can't), although it does run some tight timing ram, but the work should fit in cache. I don't recall that this system ever put out a bad unit before. I'm running it again and will see if it gives the same res, as the earlier run I did stop part way through and adjust the number of threads, not that I think it should make a difference.

Just to remove it from the equation, I'm going to restore both systems to stock CPU clocks, and also their ram. To answer the other question why I picked SR5, it wasn't because of a performance sweet spot, but a convenience sweet spot. I think TRP would see better benefits, but I want to walk before I run, and shorter SR5 units means less potential loss in case of problems.

Edit: the 6600k is now back to stock, so all core turbo of 3.6GHz, and auto voltage is about the same as where I was for 4.2 GHz. Ram dropped from 3000 to 2133. The 6700k clock is largely unchanged at 4.0 GHz all cores active, but the auto voltage has gone up 0.1v or so. Temps still look well in the safe zone. Ram I left alone, as it ran Kingston 2666 without needing XMP. Both are running the same test unit once again.

I'm not sure we're at the end of the story yet...

64598*5^2318694-1 is not prime. RES64: 7D73797E64F86BC3. OLD64: FD00DA68C6582741 Time : 3431.898 sec.

Not the end, My results are
Haswell:
64598*5^2318694-1 is not prime. RES64: C2FBBEFA317CD966. OLD64: CD99AADC2BE5702A Time : 3204.941 sec.
Skylake:
64598*5^2318694-1 is not prime. RES64: CAE67DDE583A6E33. OLD64: E559E788A01E2E91 Time : 3522.986 sec.

mackerel, I don't expect your computers to be inaccurate.
Maybe we find some other users running this WU and posting their results.

cllr64 -d -t4 -q"64598*5^2318694-1"

Change the number after -t for number of threads to run.

Random though: wonder if there's any difference between 64 and 32 bit ones...

I think I've seen enough that I'll discontinue running it on live tasks until we have a better understanding on what's happening here.

Give us a test suit with the necessary command line (tried to get manual LLR working once and failed miserably) and I'd gladly do it. Among others, I do have a Skylake and a Haswell machine to try and replicate results.

64598*5^2318694-1 is not prime. RES64: 63392344EFABDF39. OLD64: 32F845A9FDE1659E Time : 2537.613 sec.
Same i7 as before but now at stock with more voltage. Still not matching, and different res again.

64598*5^2318694-1 is not prime. RES64: EEF0CC6BA6D485DD. OLD64: 5178D3308BEC758F Time : 2893.044 sec.
Same i5 as before but now at stock. Doesn't match.

I think this is enough for me to say, this specific test doesn't like these Skylakes. I haven't run it on my main system yet, but I do have it running on one each Haswell and Skylake i3s. They're going to be overnight jobs for me and I'll check in again in morning. On that note, I'll try single thread on those systems.

The re-run on Haswell Xeon did give the expected res. The difference between the latest run and past run was that the past one I had stopped to change the number of threads from 14 to 8. The 2nd run I just went straight to 8.

Uh... Houston, we have a problem. After 52min of crunching:

Hey, guys, I made an assumption about a zillion posts ago, but maybe it's not a valid assumption.

Could everyone who built these apps (Jean, Rebirther, and Iain) please verify that the apps were indeed built with the multi-threaded versions of the libraries?

This is exactly the kind of problem you might see when you're using libraries that are not thread-safe when you're running multiple threads. That doesn't mean this is indeed the problem, but it's a possibility.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

More bad news:

6600k, 4t:

Different bad news?

3930k 4t

Base prime factor(s) taken : 5
Starting N+1 prime test of 64598*5^2318694-1
Using AVX FFT length 512K, Pass1=512, Pass2=1K, 4 threads, a = 3


64598*5^2318694-1 is not prime. RES64: 47DC8FF7EF9583A8. OLD64: 5C3C1DD5662F6EF0 Time : 4998.610 sec.
____________
Eating more cheese on Thursdays.

We know this problem happens on lots of CPUs.

I know it's happening with the Windows 64 bit build. Is anyone seeing a problem with any of the other builds? Win 32, linux, or Mac?
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

i7-4790K, HT off, non-OCed, Windows 8.1

Base prime factor(s) taken : 5 Starting N+1 prime test of 64598*5^2318694-1 Using FMA3 FFT length 512K, Pass1=256, Pass2=2K, 4 threads, a = 3 64598*5^2318694-1 is not prime. RES64: EF360BA3B795C277. OLD64: 524890D8BE302B5D Time : 2587.020 sec.

Tried again in safe mode

Base prime factor(s) taken : 5 Starting N+1 prime test of 64598*5^2318694-1 Using FMA3 FFT length 512K, Pass1=256, Pass2=2K, 4 threads, a = 3 64598*5^2318694-1 is not prime. RES64: 900E14D83350E1F4. OLD64: B9771A63C8D06DCF Time : 2679.875 sec.

Hmm...?
Does this means my computer is unstable?

Different bad news?

3930k 4t

Base prime factor(s) taken : 5
Starting N+1 prime test of 64598*5^2318694-1
Using AVX FFT length 512K, Pass1=512, Pass2=1K, 4 threads, a = 3


64598*5^2318694-1 is not prime. RES64: 47DC8FF7EF9583A8. OLD64: 5C3C1DD5662F6EF0 Time : 4998.610 sec.

Different bad news?

3930k 4t

Base prime factor(s) taken : 5
Starting N+1 prime test of 64598*5^2318694-1
Using AVX FFT length 512K, Pass1=512, Pass2=1K, 4 threads, a = 3


64598*5^2318694-1 is not prime. RES64: 47DC8FF7EF9583A8. OLD64: 5C3C1DD5662F6EF0 Time : 4998.610 sec.

That's the correct result.

What build was that?

For following, do not read anything into the runtimes since other activities were also going. All were using 64 bit app on Windows.

64598*5^2318694-1 is not prime. RES64: 47DC8FF7EF9583A8. OLD64: 5C3C1DD5662F6EF0 Time : 7114.683 sec.
E5-2650 stock, 8 threads (Sandy Bridge)

64598*5^2318694-1 is not prime. RES64: 47DC8FF7EF9583A8. OLD64: 5C3C1DD5662F6EF0 Time : 8928.284 sec.
i7-6700k stock, single thread

64598*5^2318694-1 is not prime. RES64: 47DC8FF7EF9583A8. OLD64: 5C3C1DD5662F6EF0 Time : 11461.348 sec.
i5-6600k stock, single thread

64598*5^2318694-1 is not prime. RES64: B0EF9F206AB6B9DD. OLD64: 12CEDD6140242D94 Time : 7391.210 sec.
i3-6100 stock, 2 threads

64598*5^2318694-1 is not prime. RES64: 80985D7DC09AF970. OLD64: 066F8666D93FD048 Time : 9067.840 sec.
i3-4360 stock, 2 threads

At this point I would recommend that people NOT use llr 3.8.18, even in single threaded mode, for real tasks.

We do not understand the root cause of this problem, and it's unclear which tests, on which computers, will be affected.

Although it doesn't appear that there's any danger of two bad results validating against each other (although we can't be 100% certain of that), every bad test means lost computing time, lost credits, and potential lost primes for the person running the test.

We have an excellent test case with that SR5 candidate, and I've posted on the Mersenne forums so Jean Penne can take a look at it. It doesn't appear to be a build problem (unless the same mistake was made in all of the builds), so it's possible it's a coding error either in LLR or gwnum.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

At this point I would recommend that people NOT use llr 3.8.18, even in single threaded mode, for real tasks.

We do not understand the root cause of this problem, and it's unclear which tests, on which computers, will be affected.

Although it doesn't appear that there's any danger of two bad results validating against each other (although we can't be 100% certain of that), every bad test means lost computing time, lost credits, and potential lost primes for the person running the test.

We have an excellent test case with that SR5 candidate, and I've posted on the Mersenne forums so Jean Penne can take a look at it. It doesn't appear to be a build problem (unless the same mistake was made in all of the builds), so it's possible it's a coding error either in LLR or gwnum.