Organizational tuning
 

I don't know how much these issues are already discussed in past...
The more the candidates grow, the bigger is the influence of an improvement of the strategy and algorithms.

FFT Limits of different architectures:
Will it be possible in future with the new primenet server to assign different ranges to different cpus?
33M to 34.56M to SSE2 Machines like P4
34.56M to 35.1M to Computers with the non SSE2 FFT limits etc. first?

FFT sizes:
I know I is a great effort to introduce new FFT sizes like 9*2^N, 11*2^N, 13*2^N, 15*2^N (like glucas) into prime95 because there is a lot of programming and testing necessary.
Are the 9*2^N, 15*2^N easier because they are combinations of alread implemented 3 * 2^N and 5 * 2^N (3*3) and (5*3)?

They could improve the range 35.1M to ~37.5M and 40.25M to ~45M which are important for the 10M digits primes.


Reorder factoring:
Now we trial factor first, then P-1.
Some Factors can be found with both P-1 and TF.
If we trial factor less, we might more P-1 facotors.
We could speed up the whole if we (for example)

1. Factor to 1 - 2 bits less.
2. Run the P-1 test (maybe with higher limits)
3. Factor the last bit.
Maybe factoring to half bits or quarter bits is possible. (1000.... to 1100... )


Simultaneous double checking. The larger the exponents get on the same architecture, the larger is also the error rate.
A wrong test causes at least a third run.
How about simultaneous double checking?
Two people with a computer of a similar speed start a candidate at the same time. after every (say) 1 Million iterations they synchronize their Res64. In case they are not matching, one of these computers reruns that slice. After reaching the end the exponent is already doublechecked.
Of course it is possible to do that in the same instance, but that might not be optimal due to security reasons.

Any ideas?

Reto :cat:

[QUOTE=biwema]Simultaneous double checking. The larger the exponents get on the same architecture, the larger is also the error rate.
A wrong test causes at least a third run.
How about simultaneous double checking?
Two people with a computer of a similar speed start a candidate at the same time. after every (say) 1 Million iterations they synchronize their Res64. In case they are not matching, one of these computers reruns that slice. After reaching the end the exponent is already doublechecked.
Of course it is possible to do that in the same instance, but that might not be optimal due to security reasons.

Any ideas?

Reto :cat:[/QUOTE]
I like this strategy, but I think it would work better if the exponents weren't assigned to only 2 computers, in case one lags behind or is taken off-line. It would be better to coordinate if only a segment of a test were assigned to a computer, and then that computer would check-in with the server, then start another segment of a different test. This way, no computer is waiting for another to finish a segment.

The server would need to maintain a database of residues, but it wouldn't need to be many because it can hand them back out as they come in. Each client would store the starting and expected ending point of each test so the system doesn't lose track of residues. Perhaps a peer-to-peer exchange of information could be implemented to alleviate the server load.

This would certainly cut down on a lot of wasted CPU cycles if an error occurs. But it gets rid of the 'ownership' aspect of a particular test, so a user wouldn't be able to make a claim for the result (I don't know how important that is).

Drew

[QUOTE=biwema]FFT Limits of different architectures:
Will it be possible in future with the new primenet server to assign different ranges to different cpus?
33M to 34.56M to SSE2 Machines like P4
34.56M to 35.1M to Computers with the non SSE2 FFT limits etc. first?[/QUOTE]

Scott and I have talked about this for v5, but it isn't trivial. Also, the number of non-SSE2 CPUs doing LL testing is fading fast.

[QUOTE=biwema]Reorder factoring:
Now we trial factor first, then P-1.
Some Factors can be found with both P-1 and TF.
If we trial factor less, we might more P-1 facotors.
We could speed up the whole if we (for example)

1. Factor to 1 - 2 bits less.
2. Run the P-1 test (maybe with higher limits)
3. Factor the last bit.
[/QUOTE]

v5 server will implement this. It is already coded on the server and client side.

[QUOTE=drew]I like this strategy, but I think it would work better if the exponents weren't assigned to only 2 computers, in case one lags behind or is taken off-line. It would be better to coordinate if only a segment of a test were assigned to a computer, and then that computer would check-in with the server, then start another segment of a different test. This way, no computer is waiting for another to finish a segment.[/QUOTE]
Note that the network traffic would increase with a factor of maybe a million. Checking in an exponent in the middle of a test--for someone else to check out--would require the full say 35062633 bit residue for M35062633 which is more than 4 MB. (Just the 64 bit residue would not do.) And we would have to do it a number of times per test (depending on how many segments per test we want to have).

A suggestion that has been discussed on the mailing list several times is to send 64 bit residues to the server every n iterations i.e. n=1000000. During the double check, the intermediate residues can be compared. In case of a mismatch, a third check can be run to see which of the first two was erroneous. This will save the double checker about 50% of the work on exponents that had errors during the first time check. It will not, however, save the first time tester anything. The changes to the client and server for implementing this should be relatively easy.

Alex

[QUOTE=akruppa] It will not, however, save the first time tester anything. The changes to the client and server for implementing this should be relatively easy.
[/QUOTE]


In Case the first time tester keeps a safefile every n iterations, he could start from there again, if it turns out that the first time llt was erroneous from that point on. It is necessary that the primenet server contacts the first time tester in that case (he needs to recomplete the test in order not to loose credit (wrong test))

The thing that gives me pause about simultaneous double-checking is that it makes it easier for a group of malicious users to conspire to cheat.

[QUOTE=ColdFury]The thing that gives me pause about simultaneous double-checking is that it makes it easier for a group of malicious users to conspire to cheat.[/QUOTE]
I suppose it could be done, but why? Is there incentive to cheat? You wouldn't accept a prime result without an independent confirmation, anyway. Such a confirmation can be done in parallel with all of the available residues.

Patrik, you have a good point about server traffic. I don't know what the current load is, but maybe a peer-to-peer exhange of data would be necessary in this case. It would be completely changing the way the system works, though, so it's probably not be the right approach.

Drew

[QUOTE]I suppose it could be done, but why? Is there incentive to cheat?[/QUOTE]

Because people are jerks and will sometimes go to great lengths to make trouble.

[QUOTE=ColdFury]Because people are jerks and will sometimes go to great lengths to make trouble.[/QUOTE]
They'll have to encrypt the communications protocol, then.

Anyone on these boards know how to do that kind of thing? :wink: