Sierp base 6 - team drive #3

[MyDogBuster]

98860*6^119849+1 is prime! (908.3771s+0.0042s)

Found on IB6. Can someone please update the candidates on that server to reflect this.

[mdettweiler]

Originally Posted by MyDogBuster

98860*6^119849+1 is prime! (908.3771s+0.0042s)

Found on IB6. Can someone please update the candidates on that server to reflect this.

Well, we're actually not removing the primed k's from the LLRnet server reservations in the middle of the range; instead, we just remove them from all further files that are sent. Otherwise, it messes up the server and the results processing immensely.

It shouldn't be too big a deal, though--it won't add too much more work, and it will only be up to the end of the currently loaded range (n=130K).

[MyDogBuster]

Well, we're actually not removing the primed k's from the LLRnet server reservations in the middle of the range; instead, we just remove them from all further files that are sent. Otherwise, it messes up the server and the results processing immensely.

Okay no problem.

[gd_barnes]

Our golden boy strikes again! Ian has been on an amazing prime streak lately. To find a prime on base 6 after less than n=2K processing after we had waited more than n=20K on the last one...truly remarkable. Perhaps we should let him start testing all 7 of our Sierp conjectures for bases <= 32 that have only one k remaining. He'd probably prove half of them in no time! lol

On another note:

After LLRnet reaches n=130K on this server, I'm going to recommend that we dismantle it and not run LLRnet for any non-power-of-2 bases at CRUS.

With Phrot running 30-40% faster than LLR and "regular" LLR running 5-10% faster than "LLRnet" LLR, we're losing too much in the way of CPU resources. Couple those things with not easily being able to remove k's from files and manual Phrot becomes as much as 50% faster than LLRnet.

It's simply not worth it to run LLRnet for non-power-of-2 bases. I found that out when running an LLRnet rally on the base 5 project for about 36 hours.

Any other opinions on this?


Gary

[MyDogBuster]

Our golden boy strikes again! Ian has been on an amazing prime streak lately. To find a prime on base 6 after less than n=2K processing after we had waited more than n=20K on the last one...truly remarkable. Perhaps we should let him start testing all 7 of our Sierp conjectures for bases <= 32 that have only one k remaining.

Just point me to where you need me. I'll finish up port 6 then. Ya never know when another prime might pop up.

[rogue]

Originally Posted by gd_barnes

After LLRnet reaches n=130K on this server, I'm going to recommend that we dismantle it and not run LLRnet for any non-power-of-2 bases at CRUS.

With Phrot running 30-40% faster than LLR and "regular" LLR running 5-10% faster than "LLRnet" LLR, we're losing too much in the way of CPU resources. Couple those things with not easily being able to remove k's from files and manual Phrot becomes as much as 50% faster than LLRnet.

It's simply not worth it to run LLRnet for non-power-of-2 bases. I found that out when running an LLRnet rally on the base 5 project for about 36 hours.

Of note, I am working on new software that I am calling PRPNet. It should be possible to replace LLRNet with it. The client can run either LLR or Phrot. I have a long way to go, but if I'm lucky I might have something ready for testing by the end of the year.

This software is neither designed to compete with BOINC (PrimeGrid) nor work like LLRNet. In fact, it will be very similar to ECMNet. Eventually I'll start a new thread containing the software and from there solicit users for enhancements.

[mdettweiler]

Originally Posted by rogue

Of note, I am working on new software that I am calling PRPNet. It should be possible to replace LLRNet with it. The client can run either LLR or Phrot. I have a long way to go, but if I'm lucky I might have something ready for testing by the end of the year.

This software is neither designed to compete with BOINC (PrimeGrid) nor work like LLRNet. In fact, it will be very similar to ECMNet. Eventually I'll start a new thread containing the software and from there solicit users for enhancements.

I can't wait!

BTW: If you'd like a testbed server for getting the bugs worked out initially, I'd be glad to host one one at http://nplb-gb1.no-ip.org/llrnet/. I've already got two LLRnet servers running there, and would easily be able to add more LLRnet (or PRPnet! ) servers.

[mdettweiler]

Originally Posted by gd_barnes

Our golden boy strikes again! Ian has been on an amazing prime streak lately. To find a prime on base 6 after less than n=2K processing after we had waited more than n=20K on the last one...truly remarkable. Perhaps we should let him start testing all 7 of our Sierp conjectures for bases <= 32 that have only one k remaining. He'd probably prove half of them in no time! lol

On another note:

After LLRnet reaches n=130K on this server, I'm going to recommend that we dismantle it and not run LLRnet for any non-power-of-2 bases at CRUS.

With Phrot running 30-40% faster than LLR and "regular" LLR running 5-10% faster than "LLRnet" LLR, we're losing too much in the way of CPU resources. Couple those things with not easily being able to remove k's from files and manual Phrot becomes as much as 50% faster than LLRnet.

It's simply not worth it to run LLRnet for non-power-of-2 bases. I found that out when running an LLRnet rally on the base 5 project for about 36 hours.

Any other opinions on this?


Gary

Yes, I agree--we should dismantle CRUS port 6 after it dries, in favor of manual testing in the meantime, and then possibly in the future the PRPnet system that Rogue is developing. But in the meantime, I've got a little suggestion about how to dry the server without having to crunch the remaining numbers suboptimally.

We can use a variation on the system that I use to manually crunch numbers from NPLB LLRnet servers on LLR 3.7.1c. (I think Carlos uses a similar system sometimes.) The same system can also be used to crunch LLRnet numbers with Phrot.

I was going to post here how it works, but...on second thought, it's somewhat complex and may not work too well for anyone who isn't quite familiar with the intricacies of my process for doing this. So, I've got a better idea:

How about I use my little method to grab reasonably-sized manual files from the server, post them here, and then users can crunch them, and I'll submit the results back to the server in their name using my litlte method? This shouldn't be hard at all, especially if David increases the jobMaxTime on the server to, say, two weeks (instead of 7 days as it currently is), to avoid people accidentally stepping on in-progress manual reservations.

I know it sounds somewhat convoluted, but in actual practice, I'm thinking that it wouldn't be too bad.

Max

[gd_barnes]

Originally Posted by mdettweiler

Yes, I agree--we should dismantle CRUS port 6 after it dries, in favor of manual testing in the meantime, and then possibly in the future the PRPnet system that Rogue is developing. But in the meantime, I've got a little suggestion about how to dry the server without having to crunch the remaining numbers suboptimally.

We can use a variation on the system that I use to manually crunch numbers from NPLB LLRnet servers on LLR 3.7.1c. (I think Carlos uses a similar system sometimes.) The same system can also be used to crunch LLRnet numbers with Phrot.

I was going to post here how it works, but...on second thought, it's somewhat complex and may not work too well for anyone who isn't quite familiar with the intricacies of my process for doing this. So, I've got a better idea:

How about I use my little method to grab reasonably-sized manual files from the server, post them here, and then users can crunch them, and I'll submit the results back to the server in their name using my litlte method? This shouldn't be hard at all, especially if David increases the jobMaxTime on the server to, say, two weeks (instead of 7 days as it currently is), to avoid people accidentally stepping on in-progress manual reservations.

I know it sounds somewhat convoluted, but in actual practice, I'm thinking that it wouldn't be too bad.

Max

VERY good idea! If we can use Phrot to crunch the manual ranges, send the results to you, you convert them to LLRnet format, and then send them to the server, sign me up! I'll definitely crunch a few ranges to help Ian dry this puppy out!

BTW, I meant to ask, do we have sieve files for the 1st 3 k's that are not in the drive that I left for manual-k reservations? I'm sorry, I know I could figure it out by browsing through some posts or on one of my machines somewhere but if you know off the top of your head, that would help.

What I'm finding is that manual-k reservations aren't popular at CRUS and really aren't serving much useful purpose. What I'd like to do, perhaps with Ian's or other's help, is to get those 3 k's up to n=130K like the rest of the k's and then include them in future manual files for n>130K.

These two things would make this effort nice and clean and easy to adminster in the future. At this high n-range, it would be easy to remove k's for primes found from manual files because it would only be very sporadic.

Easy to administer efforts make for happy admins that in turn make for happy crunchers!


Gary

[mdettweiler]

Originally Posted by gd_barnes

VERY good idea! If we can use Phrot to crunch the manual ranges, send the results to you, you convert them to LLRnet format, and then send them to the server, sign me up! I'll definitely crunch a few ranges to help Ian dry this puppy out!

Okay, cool. I'll send an email to David later tonight asking him to up the jobMaxTime to 20 days, to give everyone a more reasonable amount of time to complete such manual reservations. However, I would have to produce the manual files on request--i.e., I can't post a bunch of them ahead of time and let people pick them up from there. If I did that, then most of them would probably expire on the server before people even get the chance to pick them up.

However, having them generated on request can also be somewhat beneficial: the files can be custom-tailored to whatever size the requestee wishes.

BTW, I meant to ask, do we have sieve files for the 1st 3 k's that are not in the drive that I left for manual-k reservations? I'm sorry, I know I could figure it out by browsing through some posts or on one of my machines somewhere but if you know off the top of your head, that would help.

Yes, we do have sieve files for them, up to at least n=150K if memory serves. (I think we might in fact have them available up to n=200K, but I don't think I ever got around to breaking them off from the now-dormant team sieve effort's big file. However, the sieve is completed more than adequately for up to 200K.)

I'll email them to you later tonight. (Bug me if you haven't got them by tomorrow. )

What I'm finding is that manual-k reservations aren't popular at CRUS and really aren't serving much useful purpose. What I'd like to do, perhaps with Ian's or other's help, is to get those 3 k's up to n=130K like the rest of the k's and then include them in future manual files for n>130K.

Okay, that sounds good.

These two things would make this effort nice and clean and easy to adminster in the future. At this high n-range, it would be easy to remove k's for primes found from manual files because it would only be very sporadic.

One thing to keep in mind, though: once we've loaded a given range into a server, we *cannot* remove any k's from the files, especially once the server has started giving out k/n pairs in that given range. We tried that when we were first experimenting with LLRnet on CRUS efforts, and it was a huge mess. Not so much of a mess on the server end, but on the processing end...well, I'm sure you can imagine all the troubles it would cause to try to verify things with the original sieve file in such a case.

Max

[mdettweiler]

Okay, I've just gotten email confirmation from David that IB6 is now set to have a jobMaxTime of 14 days. That should give plenty of time for users to complete their pseudo-manual reservations from the server.

I'll add a note about this new little system to the first post of this thread. In the meantime, anyone who wants to grab a chunk, just post here in this thread saying how many k/n pairs you want.