Thoughts on future NPLB searches

[em99010pepe]

I just don't like to call it mini-drive.
I already processed a few candidates from k=315, I can put it next on C443 server after k=341.
I'm going to do the following and there's no come back. After 341 I'll put 315, ok?

[gd_barnes]

Originally Posted by em99010pepe

I just don't like to call it mini-drive.
I already processed a few candidates from k=315, I can put it next on C443 server after k=341.
I'm going to do the following and there's no come back. After 341 I'll put 315, ok?

Sounds good to me.

Do you mind if a few others join in on the fun on k=315 when you get it in your server? I would just put a couple of cores on it but not all the time.


Gary

[em99010pepe]

Of course not Gary, it's a public server. I think I'll add 315 from 700k because I already processed a bunch of candidates with 4 cores from 600k to 700k.

Carlos

[gd_barnes]

Originally Posted by em99010pepe

Of course not Gary, it's a public server. I think I'll add 315 from 700k because I already processed a bunch of candidates with 4 cores from 600k to 700k.

Carlos

OK, sounds good. I'll reflect the split of that reservation in the 1st post of that drive.

[gd_barnes]

About the upcoming k=1005-2000 range:

We can start the lower n-ranges for what will be our 8th drive at any time now as it is well past optimal sieve for the low ranges. I'm thinking we'll probably wait until a few days after the 5th/6th/7th drives have 'officially' started after the 1st drive has completed.

I'd like to make a different kind of proposal for searching this k-range at the lower n-ranges: Let's search it by k-value within specific defined n-value ranges instead of doing the entire thing by n-value like our usual drives. For the top-5000 ranges, we'll still stick with searching all the k's by n-value as usual as there will be far less primes than these lower ranges.

I'm suggesting this because I think Karsten will thank me. lol Imagine this: We search n=50K-55K for ~500 k's and find 50-100 primes. Now Karsten is stuck resorting them by k-value before putting them in his pages and after entering them all, he has to change 500 k's search limits.

Here is what I would propose:
Search k=1005-2000 for n=50K-100K by k-value, then do n=100K-150K by k-value, 150K-200K, etc. up to n=350K. That is first, k=1005 will be searched for n=50K-100K, then k=1007 for the same n-range, then k=1009, 1011, etc. thru k=1999. We'll then repeat all of the k's for n=100K-150K.

As it is now, Karsten will have to enter primes all over his pages all at once as well as update multiple search limits at once. Doing it this way, he can just systematically enter them, more at his leisure, one k at a time as well as update each k's search limit when he is done. It will give him more flexibility as to when he enters the primes in his pages.

I just threw out the idea of n=50K-100K, 100K-150K, etc. but there's no reason is has to be the same n-range every time. Perhaps we'd want to do n=50K-125K or 50K-150K to start with and slowly make the n-ranges smaller as we search higher within the non-top-5000 ranges.


Gary

[Flatlander]

Originally Posted by gd_barnes

...

I just threw out the idea of n=50K-100K, 100K-150K, etc. but there's no reason is has to be the same n-range every time. Perhaps we'd want to do n=50K-125K or 50K-150K to start with and slowly make the n-ranges smaller as we search higher within the non-top-5000 ranges.
Gary

Methinks 50K-150K for the first range. Shouldn't take long and easier for Karsten.

[gd_barnes]

Originally Posted by Flatlander

Methinks 50K-150K for the first range. Shouldn't take long and easier for Karsten.

Agreed and works for me. What do others think of searching by k instead of n for k=1005-2000 and n=50K-350K? Chris has effectively suggested one k at a time for n=50K-150K. Of course this CAN be all one big file depending on people want to reserve it. Once one k is done, the next k can begin immediately. People don't need to reserve just 1k at a time. It can be processed in a manner similar to our double-check drive but with much more flexibility as to the pieces that are reserved.

One thing to keep in mind: This will be all manual reservations up to at least n=200K and probably higher. The speed of processing such low n-ranges makes it a bad choice for a server. Can you imagine having 80-100 cores on tests that take < 15 secs on a server? That wouldn't be so good! lol


Gary

[Flatlander]

Originally Posted by Flatlander

Methinks 50K-150K for the first range. Shouldn't take long and easier for Karsten.

One thing that might be worth considering is the size of the lresults.txt. It might be easier for Karsten if they are under 244KB so they can be posted here instead of emailed. (Maybe they will be too big to post here even for a 50k range?)

[Mini-Geek]

Originally Posted by Flatlander

One thing that might be worth considering is the size of the lresults.txt. It might be easier for Karsten if they are under 244KB so they can be posted here instead of emailed. (Maybe they will be too big to post here even for a 50k range?)

If this is considered, remember that the lresults can easily be zipped, which (with 7-Zip saving it as .zip with Normal compression) makes it just over a fourth the size (e.g. two of my lresults files totalling 565,758 bytes compress to a 125,445 bytes size file, 565758/125445=~4.51). This means there's an effective lresults limit of about 1 MB. (4.51*244.1=~1101 KB, or about 1.075 MB)
Edit: I just did a test with this, and it seems to be correct, if a little (VERY little) pessimistic. Four lresults.txt files totalling 1,126,759 bytes (~1.07456 MB) zip into a 249,816 byte file (~243.96 KB), which is under the limit.

[mdettweiler]

Originally Posted by Flatlander

One thing that might be worth considering is the size of the lresults.txt. It might be easier for Karsten if they are under 244KB so they can be posted here instead of emailed. (Maybe they will be too big to post here even for a 50k range?)

Originally Posted by Mini-Geek

If this is considered, remember that the lresults can easily be zipped, which (with 7-Zip saving it as .zip with Normal compression) makes it just over a fourth the size (e.g. two of my lresults files totalling 565,758 bytes compress to a 125,445 bytes size file, 565758/125445=~4.51). This means there's an effective lresults limit of about 1 MB. (4.51*244.1=~1101 KB, or about 1.075 MB)
Edit: I just did a test with this, and it seems to be correct, if a little (VERY little) pessimistic. Four lresults.txt files totalling 1,126,759 bytes (~1.07456 MB) zip into a 249,816 byte file (~243.96 KB), which is under the limit.

We could probably do this sort of like we do in the doublecheck drive--i.e. zip 'em up, and post them here if they'll fit; if not, email them.

P.S.: Oh, I forgot to mention, yes, the idea of searching the n=50K-150K by k sounds good.

[henryzz]

sounds good to me
one thing though:
some people might prefer to take one k all the way to 350k in one chunk
will reservations for the next level be available