Sierp base 16 - team drive #1

[mdettweiler]

Originally Posted by gd_barnes

I'll edit that post to tell people to ignore it. Subsequent to that after a posting by Carlos in the Sierp base 4 mini-drive, I posted the bolded type in the first message in this thread. Feeding 104K-120K to LLRNet works for me. Anyone else is free to weight in on that here if they'd like.

At this point, I'd say let LLRNet run dry, change it over to Sierp and then run these files. We can individually reserve up to n=100K on the Riesel side. That'll give us time to sieve it above n=100K.


Gary

Okay, sounds good.

[mdettweiler]

Taking 104K-120K for LLRnet.

[gd_barnes]

A

Originally Posted by Anonymous

Taking 104K-120K for LLRnet.

Cool! Bring on those BIG primes!

Quick questions: Should I bother posting files with k's removed where a prime was found? I'm assuming that it would be a big hassle to change what was loaded to the server.

This is a nice amount of files to take for the server. As for upcoming ranges, I'd prefer that we leave SOME ranges for individual searches, especially for bases that are powers of 2. Let's handle LLRNet like a BIG searcher; kind of like a really BIG Carlos running 10 cores. In other words, let's max it at about 10 files at a time. Part of that has to do with testing k's where a prime is found in one of the first few files, which wastes CPU cycles for subsequent files but the other part has to do with people who don't have a good LLRing machine that's on 24x7.

For instance in my situation, I have only one computer that is online 24x7 and it is an Athlon...poor at LLRing but great at sieving and is what is sieving Riesel base 16 for n=100K-200K right now. Of course my work laptop, which is a nice LLRing machine and that I'm typing from now, is online from work but not from home. Others may be in a similar situation.

We may change that as we get above n=200K, which is n=800K base 2. At that point, we need all the firepower that we can get.

You guys have done a nice job in getting that going. Kudos to the computer techie guys!


Gary

[mdettweiler]

Originally Posted by gd_barnes

A


Cool! Bring on those BIG primes!

Quick questions: Should I bother posting files with k's removed where a prime was found? I'm assuming that it would be a big hassle to change what was loaded to the server.

This is a nice amount of files to take for the server. As for upcoming ranges, I'd prefer that we leave SOME ranges for individual searches, especially for bases that are powers of 2. Let's handle LLRNet like a BIG searcher; kind of like a really BIG Carlos running 10 cores. In other words, let's max it at about 10 files at a time. Part of that has to do with testing k's where a prime is found in one of the first few files, which wastes CPU cycles for subsequent files but the other part has to do with people who don't have a good LLRing machine that's on 24x7.

For instance in my situation, I have only one computer that is online 24x7 and it is an Athlon...poor at LLRing but great at sieving and is what is sieving Riesel base 16 for n=100K-200K right now. Of course my work laptop, which is a nice LLRing machine and that I'm typing from now, is online from work but not from home. Others may be in a similar situation.

We may change that as we get above n=200K, which is n=800K base 2. At that point, we need all the firepower that we can get.

You guys have done a nice job in getting that going. Kudos to the computer techie guys!


Gary

When a prime is found, the simplest thing will be just to have Carlos shutdown the LLRnet server, run a quickie srfile -d command on the knpairs.txt file, then start it up again. Thus, you don't have to worry about posting files with removed k's for LLRnet's reserved ranges.

[gd_barnes]

Originally Posted by Anonymous

When a prime is found, the simplest thing will be just to have Carlos shutdown the LLRnet server, run a quickie srfile -d command on the knpairs.txt file, then start it up again. Thus, you don't have to worry about posting files with removed k's for LLRnet's reserved ranges.

Will LLRNet know the correct line # to restart on? That's what you have to be careful of when manual LLRing and you remove a k...that you restart in the same spot, which is a different line # when candidates are removed.

I'm assuming someone would have to manually change the line #.

If I'm all wet here, let me know. Perhaps it's easier to waste a few CPU cycles then to try to mess with this. As a happy medium, perhaps 2-3 files could be loaded at a time. Letting it run dry a little more frequently may or may not waste more CPU cycles than searching a k that no longer needs a prime.

On the flip side, we could get more than one top-5000 prime from the same k-value! I guess I couldn't argue about that.

Tell you what...you guys decide what is best to do there since you'd be more aware of the hassles involved in removing a k-value.

I will now remove all past files from the first page of this thread.


Gary

[mdettweiler]

Originally Posted by gd_barnes

Will LLRNet know the correct line # to restart on? That's what you have to be careful of when manual LLRing and you remove a k...that you restart in the same spot, which is a different line # when candidates are removed.

I'm assuming someone would have to manually change the line #.

If I'm all wet here, let me know. Perhaps it's easier to waste a few CPU cycles then to try to mess with this. As a happy medium, perhaps 2-3 files could be loaded at a time. Letting it run dry a little more frequently may or may not waste more CPU cycles than searching a k that no longer needs a prime.

On the flip side, we could get more than one top-5000 prime from the same k-value! I guess I couldn't argue about that.

Tell you what...you guys decide what is best to do there since you'd be more aware of the hassles involved in removing a k-value.

I will now remove all past files from the first page of this thread.


Gary

Actually, to prevent such confusion, the LLRnet server automatically removes numbers from its input file when it hands them out to a client. Thus, srfile would only be dealing with the remaining candidates.

[gd_barnes]

Originally Posted by Anonymous

Actually, to prevent such confusion, the LLRnet server automatically removes numbers from its input file when it hands them out to a client. Thus, srfile would only be dealing with the remaining candidates.

Sounds good. You guys do what you think is best for the project in that regard.

[gd_barnes]

Right after posting all of the n=120K-140K files with all k-values in them...

16390*16^102651+1 is prime (123609 digits)

-or-

16390*2^410604+1

-or- as submitted

8195*2^410605+1


We need 1-2 more top-5000 primes to be visible in the top-20 projects.


Gary

[gd_barnes]

Originally Posted by Anonymous

Taking 104K-120K for LLRnet.

I don't know if you guys have started the LLRNet search for n=104K-120K yet. If not, I have files for that range available with k=16390 removed. The links aren't posted here but I can add them.


Gary

[mdettweiler]

Originally Posted by gd_barnes

I don't know if you guys have started the LLRNet search for n=104K-120K yet. If not, I have files for that range available with k=16390 removed. The links aren't posted here but I can add them.


Gary

Sorry, already started. Carlos can simply remove it with srfile, though--pretty easy to do with the way LLRnet works with its input files, as described earlier.

[gd_barnes]

Originally Posted by Anonymous

Sorry, already started. Carlos can simply remove it with srfile, though--pretty easy to do with the way LLRnet works with its input files, as described earlier.

If that's easy enough to do, I'd say go for it.

Is removing the k in this manner using Srfile similar to what they do on base 5 with their .dat files when a prime is found?

I'm all for not reinventing the wheel, although I am in favor of 'tweaking' the wheel for our own interests.


Gary