Sierp base 63 - team drive #5

[Lennart]

Sierp 63 G06 done 7643 primes

Lennart

Edit:
There are 3 k's that have 2 primes each so there are 7640 k's with primes and 2360 k's remaining for this group.

The k's and primes are:
k=9313088 for n=1966 and 1967
k=9474514 for n=2185 and 2186
k=9832868 for n=2003 and 3267

[rogue]

Taking Group 7.

Come on guys. We're almost a third the way done with this drive.

[gd_barnes]

Some good news: I've now finished a complete doublecheck for all 37M+ k's to n=1000. No additional problems were found.

I think KEP did an excellent job running all k's to n=1000. Only 3 discrepencies were noted out of 237K+ k's remaining without any kind of starting script. All 3 k's had primes for n=1K-10K so no adjustments need to be made to the drive. Very nice.

I'd like to ask you Mark: After you have finished sieving, how are you running your ranges here? I'm assuming that 5M+ k/n pairs are too many for a single PRPnet server. Are you using multiple PRPnet servers running concerruntely or are you reloading the same server and running them in consecutive succession a 1000 or so k's at a time? Or can a single server handle such a huge load or are you doing something completely different? So far, I've only run clients on the 3.2.5/6 servers. I haven't attempted to load one with pairs yet.

I guess the above leads to another question: How many pairs can a PRPnet server handle at one time? Is that related to the memory of the machine or is there a server memory or pairs limit?

This would be a truly extreme stress test for a PRPnet server. I've been running PRPnet servers on port 9000 at NPLB and a personal port for my base 26 effort here but both have large tests...nothing that would stress it much. I sure like the output on the clients now and I've not had any problems.

Thanks.

[gd_barnes]

After approval from Lennart by PM, I deleted the discussion about k's with more than one prime. I was unnecessarily verbose. There was no clear setup related problem nor problem related to PRPnet. It was simply related to splitting things up over multiple machines due to the large volume of k/n pairs that need to be tested in each group.

The edited posts show the # of k's with primes and k's remaining for each group so that is sufficient for administrative purposes.

I did want to post one request that was part of the discussion:

If everyone could kindly check his primes file before posting it on any base for more than one prime on a k, that would really help speed up the balancing of # of k's with primes and k's remaining on the various bases, especially bases with large conjectures like S63 here. If there is more than one prime for a k, please remove the higher prime(s). Also helpful on these large-conjectured bases would be to sort the primes by k-value before posting. For smaller-conjectured bases, sorting by n-value is perfectly fine since that is usually how people prefer to search higher n-ranges.


Thanks,
Gary

[rogue]

Originally Posted by gd_barnes

I'd like to ask you Mark: After you have finished sieving, how are you running your ranges here? I'm assuming that 5M+ k/n pairs are too many for a single PRPnet server. Are you using multiple PRPnet servers running concerruntely or are you reloading the same server and running them in consecutive succession a 1000 or so k's at a time? Or can a single server handle such a huge load or are you doing something completely different? So far, I've only run clients on the 3.2.5/6 servers. I haven't attempted to load one with pairs yet.

I guess the above leads to another question: How many pairs can a PRPnet server handle at one time? Is that related to the memory of the machine or is there a server memory or pairs limit?

I am not using PRPNet for S63. The vast majority of tests take less then a second and the overhead of communication between client(s) and server (including database updates) would more then double the time needed to do a range. If you take a look at the first post you will see that I recommend using PFGW with the number_primes option.

My recommendation for those wanting to run one group on multiple cores is to split the file into multiple files, e.g. 2 cores means two files with 5000 k each. Sieve each file independently with srsieve (to 1e10) and use the -w option to create a .pfgw file. Change the first line of the .pfgw file to set up number_primes. Run each .pfgw file through independent instances of PFGW.

At home I have loaded a PRPNet server with over 500,000 pairs (R928/S928) and it handled that load without any problems. There are no hard-coded limits in the server WRT number of candidates. There is a setting (in 3.3.0) that limits the number of concurrent clients. I made that change because I have some anecdotal evidence that many hundreds of concurrent clients can crash the server. My recommendation has always been to steer clients towards getting enough work for at least one hour before communicating with the server because that helps to reduce the load on the server. There is no reason why thousands of clients couldn't work on the same server, as long they don't all try to get work at the same time.

[gd_barnes]

OK, thanks Mark. I had forgotten about your suggestion in the 1st post. The funny thing is, the way you suggested is almost exactly the way I run a large majority of my new bases here if I feel I need no more than 2-3 cores for a base. For anything more than 3 cores, then I've had Max load them into a personal PRPnet or LLRnet (if running NPLB) server. Usually that's for high n-ranges and few k's.

I do wonder, though, if it would be worth it to go with your suggestion for, perhaps, n=1K-5K, remove all of the k's with primes in the sieve files, and then load the remainder in a PRPnet server. Nah, probably still too much manual intervention needed and overhead from the server. Tests at n=5K are pretty fast too. It's best to divide it up in 1000k to 2500k chunks and let it rip on a quad or 2 running good ole PFGW with the stop-on-prime option until all cores hit n=10K.

That's cool you were able to load 500K pairs into a server. It's nice to know that it can handle that.

[rogue]

I wouldn't load a PRPNet server until the PRP tests take at least 30 seconds each. The communication overhead adds too much relative time for faster tests.

[KEP]

@Gary:

Glad to see that there is only 3 missed k's in the entire range. Good job on completing the doublecheck.

@The rest of you: Good job on completing more and more of this drive. Do you think you can have it complete before the end of June? Anyone who feels like taking it higher?

Regards

Kenneth

[rogue]

Originally Posted by KEP

@The rest of you: Good job on completing more and more of this drive. Do you think you can have it complete before the end of June? Anyone who feels like taking it higher?

No and not me. I would be surprised if it were done by the end of the year. At two months a range and 16 ranges, that is 32 months. So far only three individuals have shown interest in helping this drive.

[kar_bon]

Reserving Group 15

[gd_barnes]

Originally Posted by rogue

No and not me. I would be surprised if it were done by the end of the year. At two months a range and 16 ranges, that is 32 months. So far only three individuals have shown interest in helping this drive.

I'm not so pessimistic on it. I'll probably do one range at some point. I'd say we'll be done by the end of Sept.

Where do you get 2 months per range? Surely it doesn't take 2 months for a full quad to do a range. That is what I would put on it.