Sierp base 6 - team drive #3

[mdettweiler]

Carlos, I've noticed a few results from you coming into the PRPnet server with odd results, like this:

[2009-01-04 22:44:37 GMT] 10107*6^140219+1:  User: em99010pepe@gmail.com  Program: phrot0.exe  Residue: 000000009975F7CB  DoubleCheck? No
[2009-01-04 22:44:37 GMT] 10107*6^140879+1:  User: em99010pepe@gmail.com  Program: phrot1.exe  Residue: 00000000D4E7C7C9  DoubleCheck? No
[2009-01-04 22:44:38 GMT] 10107*6^141247+1:  User: em99010pepe@gmail.com  Program: phrot2.exe  Residue: 0000000084FCD222  DoubleCheck? No
[2009-01-04 22:44:38 GMT] 10107*6^141947+1:  User: em99010pepe@gmail.com  Program: phrot3.exe  Residue: 000000000EACE168  DoubleCheck? No

Are you by chance using an old version of Phrot? I think some older versions have been known to produce bad results like this sometimes.

[rogue]

Originally Posted by mdettweiler

Carlos, I've noticed a few results from you coming into the PRPnet server with odd results, like this:

[2009-01-04 22:44:37 GMT] 10107*6^140219+1:  User: em99010pepe@gmail.com  Program: phrot0.exe  Residue: 000000009975F7CB  DoubleCheck? No
[2009-01-04 22:44:37 GMT] 10107*6^140879+1:  User: em99010pepe@gmail.com  Program: phrot1.exe  Residue: 00000000D4E7C7C9  DoubleCheck? No
[2009-01-04 22:44:38 GMT] 10107*6^141247+1:  User: em99010pepe@gmail.com  Program: phrot2.exe  Residue: 0000000084FCD222  DoubleCheck? No
[2009-01-04 22:44:38 GMT] 10107*6^141947+1:  User: em99010pepe@gmail.com  Program: phrot3.exe  Residue: 000000000EACE168  DoubleCheck? No

Are you by chance using an old version of Phrot? I think some older versions have been known to produce bad results like this sometimes.

You definitely need version 0.62 to address this issue. If it is happening with 0.62, please let me know the CPU you are running it on.

[gd_barnes]

Originally Posted by mdettweiler

Actually, the idea that both of you guys proposed has in fact been present in PRPnet ever since version 1.0.0--there's an option in prpserver.ini that lets you opt to have the server automatically mark all candidates for a given k as inactive as soon as a prime is found for it. I've had this option enabled in the G3000 PRPnet server from the start and in fact it was seen in action when Nugget found a PRP a few days ago on the server's Riesel base 3 candidates.

OUTSTANDING!! Way to go Rogue!...extremely helpful!!

Yes, this could actually now be used for base 3 if we wanted although I'd personally like to use it for some less boring bases. lmao Finding millions of small primes does nothing for me after the first few million of them.


Gary

[henryzz]

Originally Posted by gd_barnes

OUTSTANDING!! Way to go Rogue!...extremely helpful!!

Yes, this could actually now be used for base 3 if we wanted although I'd personally like to use it for some less boring bases. lmao Finding millions of small primes does nothing for me after the first few million of them.


Gary

we would certainly want to turn off email notification for base 3 lol
what sort of load do you think the server will cope with
if we set our cache sizes to be 10mins worth of work would it cope with taking base 3 from 1k upwards with lots of clients

[gd_barnes]

Originally Posted by henryzz

we would certainly want to turn off email notification for base 3 lol
what sort of load do you think the server will cope with
if we set our cache sizes to be 10mins worth of work would it cope with taking base 3 from 1k upwards with lots of clients

Please don't anyone jump the gun on doing this. We need to load the exact correct k's in first. For remaining k's that are divisible by 3, we only want to load k's where k-1 is prime (Riesel) or k+1 is prime (Sierp).

This must be thought out to avoid a mess in the server that causes extra CPU time for everyone.


Gary

[em99010pepe]

Originally Posted by rogue

You definitely need version 0.62 to address this issue. If it is happening with 0.62, please let me know the CPU you are running it on.

Originally Posted by mdettweiler

Carlos, I've noticed a few results from you coming into the PRPnet server with odd results, like this:

[2009-01-04 22:44:37 GMT] 10107*6^140219+1:  User: em99010pepe@gmail.com  Program: phrot0.exe  Residue: 000000009975F7CB  DoubleCheck? No
[2009-01-04 22:44:37 GMT] 10107*6^140879+1:  User: em99010pepe@gmail.com  Program: phrot1.exe  Residue: 00000000D4E7C7C9  DoubleCheck? No
[2009-01-04 22:44:38 GMT] 10107*6^141247+1:  User: em99010pepe@gmail.com  Program: phrot2.exe  Residue: 0000000084FCD222  DoubleCheck? No
[2009-01-04 22:44:38 GMT] 10107*6^141947+1:  User: em99010pepe@gmail.com  Program: phrot3.exe  Residue: 000000000EACE168  DoubleCheck? No

Are you by chance using an old version of Phrot? I think some older versions have been known to produce bad results like this sometimes.

I really don't know which version I am using. Sorry.

[rogue]

Originally Posted by em99010pepe

I really don't know which version I am using. Sorry.

Type in "phrot0" on the command line without any arguments. It will tell you which version you are using. Starting with 0.62 the version is output when the program starts up.

[mdettweiler]

Originally Posted by gd_barnes

Please don't anyone jump the gun on doing this. We need to load the exact correct k's in first. For remaining k's that are divisible by 3, we only want to load k's where k-1 is prime (Riesel) or k+1 is prime (Sierp).

This must be thought out to avoid a mess in the server that causes extra CPU time for everyone.


Gary

Hmm...indeed, I agree that it even though the server may well be able to handle very small candidates, if we make them too small there's going to be so many primes and whatnot that it's going to be a huge nightmare for me to sort the results out in the end. Thus, I would recommend that we don't put anything below n=10K into the server (or, for base 3, n=25K), at least until I've picked up a LOT more experience with this stuff and gotten some better scripts written up.

[michaf]

Originally Posted by gd_barnes

Please don't anyone jump the gun on doing this. We need to load the exact correct k's in first. For remaining k's that are divisible by 3, we only want to load k's where k-1 is prime (Riesel) or k+1 is prime (Sierp).

This must be thought out to avoid a mess in the server that causes extra CPU time for everyone.


Gary

Totally agreed :)

First let's struggle 'by hand' to get them to 25k, sort out the mob's, and then run them in a server. (If the server can handle the load with n=25k, if not, continue by hand to 100k)

[mdettweiler]

Originally Posted by michaf

Totally agreed :)

First let's struggle 'by hand' to get them to 25k, sort out the mob's, and then run them in a server. (If the server can handle the load with n=25k, if not, continue by hand to 100k)

Based on what I've seen, I'd guess that the server *should* be able to handle base 3 n=25K tests okay. Though, of course, we don't know for sure until we try it...I'm thinking that as soon as Gary gets the Sierp. base 3 mini-drive II up and running, I'll try the first file from that drive on the server and see how it works.

[gd_barnes]

Originally Posted by mdettweiler

Based on what I've seen, I'd guess that the server *should* be able to handle base 3 n=25K tests okay. Though, of course, we don't know for sure until we try it...I'm thinking that as soon as Gary gets the Sierp. base 3 mini-drive II up and running, I'll try the first file from that drive on the server and see how it works.

I'm going to run that drive by k-value. It will reduce admin time dramatically. I haven't thought through all the particulars for manual reservations yet but it will likely be something like a file with 10-15 k's for n=25K-40K, another with 10-15 k's for n=25K-40K, etc.

Of course that is for manual reservations. Since PRPnet is able to stop processing a k when it finds a prime, then that works great! I'd still want to sort files by k-value though so somebody doesn't reserve a manual range above the server, find a prime for a k, then the server finds a lower prime for the same k. I'm tired of that mess. I'm saying this thinking we would allow manual reservations in addition to the server running some ranges.

Starting from n=25K in the server after we've appropriately analyzed MOB should work fine.


Gary