[quote=hhh;104177]Me too. What is your factor/time ratio now? Do you still get a factor per day? How fast would your computers be in LLR?
In other words: how many times sieving is still more efficient than LLR?

I' make the update this afternoon, I think. Anyways, the speed increase will be less than 5%, I think. H.[/quote]

26433 sec/factor on my home machine. At work I have access to three 3.0GHz HT P4 machines and one 2.8GHz P4 dual core machine but I never tried LLR on them.

Carlos

That means that we can keep sieving fo rhte moment. But we can start LLR as well and take out the lower numbers from the sieve.

What's our goal on sieve, going up to 10T, 20T....?

Carlos

I don't think more than 5T.
2.5T might be enough.

As long as you can find 1 factor a day on a fast athlon, then you should sieve, else start with LLR.

edit: If we are removing candidates as we are LLRing them, then this would change things and we might be able to go deeper as the sieve would become faster.

:smile:

We don't even need to LLR to take candidates out. We can take them out just like this as well. That's what I'm going to do with the next import, as we almost don't find any factors below 2M, thanks to P-1. As for the rest, I vote for sieving rather too deep than too shallow (native speeker assistance please!), as there are too many undersieved projects and I'd like to invert this.
But as usual, everybody is free to do whatever he is pleased to do. H.

I'm going to finish the current ranges then I am out.

Carlos

[QUOTE=em99010pepe;104454]I'm going to finish the current ranges then I am out.

Carlos[/QUOTE]

That's a pity. Thank you anyway for the nice boost you gave to this project.
H.

On my 2.9GHz P4, LLR with exponent 3,250,000 should take about 32500 seconds (9 hours) at 10.0 ms/bit. LLR with exponent 5,000,000 should take about 82500 sec (23 hours) at 16.5 ms/bit.

I think sieving up to 2.5T-3T is probably about right, if we are not taking double checking into account. Maybe up to 5T allowing for double checks.

If the project doesn't find a prime below exponent 5,000,000 then my guess is that there won't be a lot of interest in double checking, people would be more interested in doing first time tests on higher ranges to find the first prime.

If a prime is found below exponent 5,000,000 then there could be more interest in double checking, to prove that it is the smallest such prime.

Tests at different levels take different amount of time. I think we are still under sieved for the tests with n=4M to 5M.

The best approach would be to continue sieving and removing candidates as they are LLRed. For example, I think we are sieved well to n=2.5M. So we should assign all these candidates to LLR and then remove them from the sieve.

This will make the sieve client much faster and the time per factor should drop, thus we can effectively sieve beyond 2.5T.

I created a dat file, only above 2.4M, if any one wants to try it to see what speeds and time per factor we get. (see attached)
:smile:

Please decide which approach is better because I'm really inclined to move to another project.

Carlos

Up to 2M, we have sieved nicely and done a decent P-1, such that we almost don't find factors by sieve anymore.

Up to 2.5M, I'm going to write out a decent P-1 as well.

So I vote for just deleting the lines below 2.5M from the sieve.txt, and to continue sieving.

This way, we won't be getting more factors per time, but the factors we are going to find will be worth more, on average.

For the moment, everybody feel free to use the sieve.txt Citrix posted. The next official release will be truncated at 2.5M anyways.

This is to be sure that no cycles are wasted.

Yours H.