mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Conjectures 'R Us (https://www.mersenneforum.org/forumdisplay.php?f=81)
-   -   Software/instructions/questions (https://www.mersenneforum.org/showthread.php?t=9742)

pokemonlover123 2021-04-18 13:41

[QUOTE=rogue;576120]I'm impressed that you went the PRPNet route and am happy to see that you have it working.

Temp files are created to retain results so a crash won't cause problems unless one of those temp files is corrupted, but you would know that when you restart the client. Is the client crashing or is the server crashing? Which version of the client are you using? 5.4.5 is on sourceforge. I've been running it on Windows without problems.[/QUOTE]
Lemme try 5.4.5. I have 5.4.0a for some reason. It was the clients that were crashing. The server is working fine. I'll keep you posted. I'm glad I don't have to redo everything.

pokemonlover123 2021-04-18 15:07

Doesn't look like 5.4.5 fixes the issue.

pokemonlover123 2021-04-18 16:21

It's not confirmed, but i think i figured it out? It seems to be the case that the crashes happen if you set the client to request a large number of work units at once in prpclient.ini. I had set it to 600 to reduce the frequency of work requests and thats when i noticed the issue started. I have reduced it to 100 on that suspicion and it seems to br working fine now? Will keep you updated. Seems requesting a large number of work units might overrun a heap-allocated buffer on the client?

pokemonlover123 2021-04-18 17:24

[QUOTE=pokemonlover123;576136]overrun a heap-allocated buffer on the client?[/QUOTE]
Note, I forgot to mention this, that after I updated to 5.4.5 the dumps changed from reported errors related to invalid pointers to heap corruption errors, which led me to the heap buffer overrun hypothesis.

pokemonlover123 2021-04-18 17:40

I have a couple questions now that I have resolved the crashing issue. 1) It seems that not all n values have all ks from the sieve file when i converted it to PFGW format. Am I correct in assuming that is on purpose (i.e. is ittrivial to preclude certain ks for certain n values from testing?). 2) It seems that (at least according to entries in the results table) the program it is using to run the PRP tests is llr rather than pfgw, even though 3 is not a power of 2 and the option to use llr anyways is not enabled in the server's ini. Will this cause problems or is it also on purpose?

rogue 2021-04-18 18:11

[QUOTE=pokemonlover123;576139]I have a couple questions now that I have resolved the crashing issue. 1) It seems that not all n values have all ks from the sieve file when i converted it to PFGW format. Am I correct in assuming that is on purpose (i.e. is ittrivial to preclude certain ks for certain n values from testing?). 2) It seems that (at least according to entries in the results table) the program it is using to run the PRP tests is llr rather than pfgw, even though 3 is not a power of 2 and the option to use llr anyways is not enabled in the server's ini. Will this cause problems or is it also on purpose?[/QUOTE]

If you count the number of rows in the Candidate table, it should match the number of k/n pairs from the ABCD file. The number of rows in the CandidateGroupStats table should match the number of distinct k from the ABCD file. When you ran srfile did it generate the name number of candidates as it read? Were all of them loaded into the server? If you notice a discrepancy, please track it down because I haven't seen this particular issue.

The default setting in the server for usellroverpfgw is 1. You can set to 0 to force all clients to use pfgw. You can use the stats to determine which is truly faster. The main problem is that if pfgw finds a PRP it will need to run a second test to verity primarily whereas llr will not require a second test, although the one test it runs might take longer.

You just want to ensure that you have onekperinstance=1 in preserver.ini so that multiple clients are not working on the same k concurrently, which can lead you to running more tests than you need to run.

I set my clients to get a maximum of 100 tests at a time. More seems to cause problems. I have thought about solving this by switching the protocol between client and server to something more flexible, such as JSON, and by making the socket logic more robust, but nobody has been pressing for that.

pokemonlover123 2021-04-18 18:41

[QUOTE=rogue;576141]If you count the number of rows in the Candidate table, it should match the number of k/n pairs from the ABCD file. The number of rows in the CandidateGroupStats table should match the number of distinct k from the ABCD file. When you ran srfile did it generate the name number of candidates as it read? Were all of them loaded into the server? If you notice a discrepancy, please track it down because I haven't seen this particular issue..[/QUOTE]
srfile did generate the same as it read. I was referring to the generated file itself as opposed to what's in the server (as i'm still loading candidates into the server, since that process was interrupted last night cause of the memory test i ran). In the pfgw file, what i noticed is that not all ks have tests at all ns. The number of unique ks in my server rn is 3294, which matches the number of ks remaining for the 45G range as checked against the list of remaining ks provided at noprimeleftbehind. Assuming there were candidates for all ks remaining at all values of n, that would mean 50k (ns) * 3k (ks) = 150 million tests. There aren't even that many lines in the sieve file I downloaded, so I don't think there's a problem. I believe the rows in the candidate table will end up matching the number of k/n pairs, but my question was regarding the fact that not all possible k/n pairs appear in the original file.

pokemonlover123 2021-04-18 18:46

I believe I managed to find the answer to my question. In the ABCD file, for each k, there seems to be a starting n (at the end of the ABCD line for each k, in square brackets), then a whole bunch of numbers. I realized that those numbers match exactly the gaps between tested n values I was wondering about. I suppose I just misunderstood the ABCD format. And I suppose the certain n candidates that are not tested were sieved out, hence the sieving in the first place. I misunderstood the process and forgot to consider that sieving had happened and that I was generating candidates FROM that sieve file.

rogue 2021-04-18 19:53

[QUOTE=pokemonlover123;576150]I believe I managed to find the answer to my question. In the ABCD file, for each k, there seems to be a starting n (at the end of the ABCD line for each k, in square brackets), then a whole bunch of numbers. I realized that those numbers match exactly the gaps between tested n values I was wondering about. I suppose I just misunderstood the ABCD format. And I suppose the certain n candidates that are not tested were sieved out, hence the sieving in the first place. I misunderstood the process and forgot to consider that sieving had happened and that I was generating candidates FROM that sieve file.[/QUOTE]

Yes. The file that you started with had already been sieved to 35G so a large percentage of possible candidates had already been removed.

ABCD format is used because it is the most compact format. But PRPNet does not support that format. I have wanted to add support, but have not done so as nobody has asked.

gd_barnes 2021-04-18 21:26

One thing that I will bring up that I don't think was mentioned here about the PRPnet server. Make sure that servertype=1 for Sierpinski/Riesel in the prpserver.ini file. This will stop searching a k after a prime has been found. Otherwise you will do a lot of extra tests.

pokemonlover123 2021-04-18 22:05

[QUOTE=gd_barnes;576158]One thing that I will bring up that I don't think was mentioned here about the PRPnet server. Make sure that servertype=1 for Sierpinski/Riesel in the prpserver.ini file. This will stop searching a k after a prime has been found. Otherwise you will do a lot of extra tests.[/QUOTE]
Yep I set that option.


All times are UTC. The time now is 13:17.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.