PRPNet 5.4.3 Released

[rogue]

Originally Posted by rebirther

From the last change I have seen. The client doesnt starting if:

main dir
|_dir core1
|_dir core2
|_dir core3
|_dir core4

Only one client starting. The fix should be active if 2x the same client starting from any of the sub directories not main.

I don't fully understand. In which directory(is) is the client and the ini file for the client? What is your current directory when you start the client, main or core1/2/3/4?

[rebirther]

Originally Posted by rogue

I don't fully understand. In which directory(is) is the client and the ini file for the client? What is your current directory when you start the client, main or core1/2/3/4?

I have f:/maindir with 4 sub dirs for all 4 cores, every single client start in sub dir 1, 2, 3, 4

[rogue]

Originally Posted by rebirther

I have f:/maindir with 4 sub dirs for all 4 cores, every single client start in sub dir 1, 2, 3, 4

You probably have the same clientid specified in the prpclient.ini file for each client. On Windows the code uses that id to create a lock to prevent other clients with the same id from running at the same time.

[Xentar]

Ehh.. I am doing it the same way.
All my clients on the same machine use the same clientid, so that doublechecks at the server works:

// doublechecker= indicates who can double-check the number
// 1 - a different person and client machine than the first (default)
// 2 - a different person than the first tester
// 3 - a different client machine than the first client machine
// 4 - anybody
doublechecker=3

or how is "different client machine" identified, when not using the clientid?

[rogue]

Originally Posted by Xentar

Ehh.. I am doing it the same way.
All my clients on the same machine use the same clientid, so that doublechecks at the server works:

// doublechecker= indicates who can double-check the number
// 1 - a different person and client machine than the first (default)
// 2 - a different person than the first tester
// 3 - a different client machine than the first client machine
// 4 - anybody
doublechecker=3

or how is "different client machine" identified, when not using the clientid?

I see your problem. Double-checking hasn't been used heavily, so this went unnoticed. If your clients only connected to your server, then I suggest changing the client userid and using option 2. I'll need to address this discrepancy in a future release.

You should be safe using option 3 and changing the client id. It is extremely unlikely for two failed tests to return the same incorrect residue, barring a bug in gwnum.

[rebirther]

Originally Posted by rogue

You probably have the same clientid specified in the prpclient.ini file for each client. On Windows the code uses that id to create a lock to prevent other clients with the same id from running at the same time.

Correct, can you change that? If I change the clientid in any of the directory and run the master.ini update all is back again. clientid check is the wrong way. dir/subdir check if one client is running should be fine.

[rogue]

Originally Posted by rebirther

Correct, can you change that? If I change the clientid in any of the directory and run the master.ini update all is back again. clientid check is the wrong way. dir/subdir check if one client is running should be fine.

I know. Windows uses different code than *nix. It isn't quite as easy as one would think. I have an idea, so we'll see what I come up with.

[henryzz]

Originally Posted by henryzz

I will investigate this once my machine with a server on it has internet after the 10th.

How does the server work out what to put in the smallest prime field? When it finds a prime does it update the field with that value? If so does it check whether there is a smaller prime there already?

[rogue]

Originally Posted by henryzz

How does the server work out what to put in the smallest prime field? When it finds a prime does it update the field with that value? If so does it check whether there is a smaller prime there already?

For Sierpinski/Riesel servers, I believe that it puts the first prime found for the k/b/c into the CandidateGroupStats table (what you see on server_stats.html). If a smaller one happens to be found, I believe that it does not update that table.

[henryzz]

Originally Posted by rogue

For Sierpinski/Riesel servers, I believe that it puts the first prime found for the k/b/c into the CandidateGroupStats table (what you see on server_stats.html). If a smaller one happens to be found, I believe that it does not update that table.

Going back to the problem case. When the server finishes loading the pairs from admin how does it go through the tests already done to check if there is a prime. I suspect it will be the same code that would be run when changing server type from non-seirp/riesel to seirp/riesel.
It seems like whatever it is checks from the larger tests down(assuming no replacement if smaller found). Would it be possible to switch the order?

[rogue]

Originally Posted by henryzz

Going back to the problem case. When the server finishes loading the pairs from admin how does it go through the tests already done to check if there is a prime. I suspect it will be the same code that would be run when changing server type from non-seirp/riesel to seirp/riesel.
It seems like whatever it is checks from the larger tests down(assuming no replacement if smaller found). Would it be possible to switch the order?

When a prime is returned by a client, the server will mark all n for that k,b,c for that prime in such a way that no more candidates for higher n are sent out.

When server stats are recomputed every 20 minutes (or however you have the server configured), it selects the min(CandidateName) with a prime for that k,b,c. Obviously that code is wrong as it should choose from the candidate with the smallest decimal length.