PRPnet rally Feb. 18th-25th

[mdettweiler]

Originally Posted by AMDave

I saw the accidental '-' at the end of the team name for KD7LRJ but someone fixed it faster than I could get to it. (Good shooting whoever that was)
The team total will be corrected automatically by the database on the next refresh.

Ah yes, that was me...just fired off a PM to Ian so he would know it was me and not some mysterious gremlins, but didn't expect that you too would be on the ball and catch it before the next refresh.

[gd_barnes]

Originally Posted by Neo

Back to back primes!

Nice job PCZ.

Neo
AtP

Unfortunately this was not to be. They both turned out to be composite. Brian reported in our "report primes for k<1000" thread that a bad machine found them to be erroneously prime. Max and Dave, see that thread for questions about how to get our DB corrected.


Gary

[AMDave]

Oh Boo! Find more primes everyone!

EDIT - action taken pending revised residuals / re-queue. See that thread.

[Neo]

I'm crunching w/u's with N>1026440.

Last prime was at N=1018709

Did we find a gap??

I'm thinking Lumiukko might have a prime in one of his offline batches ....

Neo

[Neo]

The server says "14th Drive (K=600-1001, n=1M-2M)"

Below is all -1 primes for 600<K<1001 for N=1M-2M)
---- -------------------------------- ------- ----- ---- --------------
rank description digits who year comment
----- -------------------------------- ------- ----- ---- --------------
242 737*2^1592724-1 479461 L191 2006
292 907*2^1501169-1 451900 L860 2010
888 861*2^1203625-1 362331 L251 2011
947 617*2^1175468-1 353854 L426 2007
1459 727*2^1018709-1 306665 L1809 2012
1462 829*2^1017747-1 306376 L1817 2012
1478 691*2^1013875-1 305210 L1809 2012
1481 669*2^1013592-1 305125 L1809 2012
1483 947*2^1012854-1 304903 L1809 2012
1495 899*2^1010544-1 304208 L1809 2012
1497 811*2^1010419-1 304170 L2995 2012
1509 663*2^1009098-1 303772 L1809 2012
1511 695*2^1008532-1 303602 L1809 2012
1518 921*2^1006898-1 303110 L1817 2012
1520 993*2^1006834-1 303091 L1817 2012
1521 903*2^1006812-1 303084 L2257 2012
1534 729*2^1003373-1 302049 L466 2008
1536 853*2^1003063-1 301955 L2257 2012
1540 735*2^1002509-1 301789 L2257 2012
1541 819*2^1002205-1 301697 L2257 2012
----- -------------------------------- ------- ----- ---- --------------

This is confusing. ??

RPS didn't start their search at N=1M? for all k 600-1001?

Neo

[mdettweiler]

Originally Posted by Neo

The server says "14th Drive (K=600-1001, n=1M-2M)"

Below is all -1 primes for 600<K<1001 for N=1M-2M)
<snip>
This is confusing. ??

RPS didn't start their search at N=1M? for all k 600-1001?

Neo

The history of this range is somewhat interesting. Before NPLB began actively searching the range, k=300-1001 was handled by the PrimeSearch project, which provided a web-based automated reservation system for individual k's within the range. Over time the project lapsed into inactivity as it ran into technical difficulties with its website, and much of their later search data ended up being spotty and unreliable. Seeing the inactivity at PrimeSearch, RPS did some limited searches on an individual-k basis, starting from the (assumed correct) PrimeSearch testing limits and somtimes skipping forward to top-5000 ranges. In general, though, the range didn't see much activity during this period, due to uncertainty as to who "owned" the range (so to speak, since of course nobody can "own" a number per se). NPLB was started as an attempt to revitalize the original PrimeSearch effort (it was, in fact, a renaming of the original project with an recognized transfer of leadership from the original admin to Gary), and started right away on the entire continuous k=300-1001, n<1M range. (We completed that goal last year and are now working on completing the entire range to n=2M.)

The idea of doing continuous searches over large blocks of k and n was actually somewhat unique to NPLB when it started--to this day, AFAIK, NPLB and PrimeGrid are the only projects to utilize this approach on a large scale in the Riesel and Proth number spaces. RPS has done some of this recently as well with their 11th Drive on the k=2000-2300 range, though unlike NPLB they opted to start at the current top-5000 threshold level and skip k's that may have (but haven't been confirmed firmly) already tested.

Anyway, long story short, that's how the handful of pre-NPLB primes you found (from 617*2^1175468-1 up on your list) got there--they were found in previous sporadic searches in the range by RPS, pre-NPLB PrimeSearch, and other unaffiliated prime hunters.

[AMDave]

Originally Posted by mdettweiler

...That particular error you got, "Number sent to gwsetup is too large...", is, interestingly enough, the exact same error some fellows over at PrimeGrid were reporting with AMD Bulldozer machines on the latest development version of LLR--though in their case it was due to the latest development verison adding AVX support for a speed boost on Sandy Bridge and Bulldozer CPUs, but not (yet) properly taking into account differences in how Bulldozer implements AVX. I don't think I've ever heard of this error being thrown up by a pre-AVX machine, least of all with a non-development LLR build, but nonetheless it is what you're seeing. It would almost seem to indicate that somehow LLR doesn't know how to handle your CPUs, which is strange because a T4500 is a pretty standard laptop-spec Core 2 Duo, which should be a no-brainer for LLR.

Your thoughts gave me a hunch, so I just redeployed the prpnetclient 5.0.5 bundle, but this time I set the INI to use llravx.exe instead of llr.exe (which is counter intuitive for this CPU but bear with me...)

It worked.

So, methinks the 2 filenames of llr.exe and llravx.exe are the wrong way around in the 5.0.5 bundle.

rogue / Lennart is there any way you can verify this?

ITMT I'll redeploy the clients to the T4500s in this configuration and see if I can pull back some ground.

Thanks for the hunch, Max.

[mdettweiler]

Originally Posted by AMDave

Your thoughts gave me a hunch, so I just redeployed the prpnetclient 5.0.5 bundle, but this time I set the INI to use llravx.exe instead of llr.exe (which is counter intuitive for this CPU but bear with me...)

It worked.

So, methinks the 2 filenames of llr.exe and llravx.exe are the wrong way around in the 5.0.5 bundle.

rogue / Lennart is there any way you can verify this?

ITMT I'll redeploy the clients to the T4500s in this configuration and see if I can pull back some ground.

Thanks for the hunch, Max.

Hmm...quite interestingly, there was somebody else at PrimeGrid who had it work exactly that way: he had an eminently "ordinary", non-AVX CPU that failed with regular LLR but worked with llrAVX. I don't recall what CPU he had, but given that you're experiencing basically the same thing, I would hazard a guess that the LLRs are indeed labeled correctly, and llrAVX (for some unknown reason) can handle your non-AVX CPU better.

Incidentally, the non-AVX llr.exe should be on the order of 25 MB, and llrAVX.exe around 35 MB (since it includes most, if not all, of the code for handling pre-AVX CPUs present in earlier versions, plus new code for AVX). If your copies match that, they're probably labeled correctly.

Edit: Aha, found it! The issue was reported here in a cross-post from the PrimeGrid forums. In this case the CPU was an AMD E350--one of the somewhat-recent AMD CPUs (non-Bulldozer) that is sold as an "APU"--a processor and graphics card wrapped up in one unit, AMD's counterpart to the on-die GPUs in Intel Sandy Bridges. Though it isn't a Bulldozer, it would make sense that the older LLR (more precisely, the older gwnum math library compiled into LLR--the AVX and non-AVX binaries currently provided are both LLR 3.8.7 but compiled with the development and stable gwnum releases respectively) might not be able to handle it since it's a newer and more "oddball" CPU type; but it doesn't explain why your much more common Pentium Dual-Core (C2D based) T4500 is experiencing the same issue.

I have personally used LLR (pre-AVX, in fact an older version, probably the same one you got from the 3.1.7 package) on a laptop Pentium Dual-Core Txxxx (not 4500 but close, a 2.0GHz model) and it worked fine--just like yours did with the older LLR. Unfortunately that laptop belongs to a family member 300 miles away and I can't readily test it with the latest LLR AVX and non-AVX builds to verify your results, but I am quite curious how that would turn out...

[AMDave]

Uh, oh. I think my head just imploded. hahaha

So not something as simple as a file naming error upstream then.
How bizarre. I guess that, with the need to keep compilers working across so many core types, these variations would arise eventually.
Is it worth cross posting to that thread to let Jean Penné know that it is not an isolated case?

On the bright-side, I've got a couple of them suckers crunching so if the results are accepted I'm still better off than I was.

[odicin]

Not only at this time, I try to remember around some months ago (before avx) a similar problem with the older 3.8.4 llr and some AMD CPU's at PG. In fact the problem was the used gnum version so Primegrid updated all there stock apps to 3.8.6 llr which uses a newer gnum version.

Rebirthers AVX build of llr uses the early beta of gnum 27.3, the latest llr from jean penne still use 26.5. I suppose this is the problem there.

You can track down the problem with rebirthers non-avx x64 llr build. This one also use gnum 27.3 instead of 26.5.

Regards Odi

[Neo]

Anyway, long story short, that's how the handful of pre-NPLB primes you found (from 617*2^1175468-1 up on your list) got there--they were found in previous sporadic searches in the range by RPS, pre-NPLB PrimeSearch, and other unaffiliated prime hunters.

Thanks Max for the clarification; I suspected that was the reason.

Neo
AtP