After we find a twin, our next exponent will be...

[KEP]

Originally Posted by pacionet

I vote too for 333,333.

It would be better if we decide the NEXT N (5, 10 or 50,.. ?) exponents to test; this way, soon, we can start parallel sieving for these exponents.

Good point, it will also ensure, that there is a sustaineable amount of work availeable, for users to crunch. Maybe 1 of our goals should also be to concour the top 20 list of twin primes... anyway, I stated the current n and suggested an additional 9 n to work with. I think they are all reasonable to attack, since many of them don't take long to do, and since it will give us the opportunity to involve a lot of sievers :) Also if we works on n bringing us into the top 5000 list, we could also very soon reach the no. 1 submitter of primes, place :) Anyway, let's all keep our computers busy, and then lets see if we can't hit the twin within summer 2007, then the next by summer 2008 etc.

Btw "Who cares what n we are crunching as long as we all make progress"

[MooMoo2]

Originally Posted by pacionet

It would be better if we decide the NEXT N (5, 10 or 50,.. ?) exponents to test; this way, soon, we can start parallel sieving for these exponents.

The problem with that is that there are too many uncertainties, since it's too far in the future. For example, if any of these change:

- Number of participants
- Chip makers failing/exceeding Moore's law expectations
- Dedication of participants (people staying longer and/or putting more CPUs on the project)

then our premature vote for the next 5 n's means that those n's could either be set too high or too low.

The more important thing now is to decide who will do the sieving. Gribozavr? Someone who has many athlons and few/no Pentium 4's (or Pentium D's, since the architecture is very similar)? Distributed sieving isn't available now, so this has to be decided before Jan 1st, when the poll closes.

[jasong]

Originally Posted by MooooMoo

Distributed sieving isn't available now, so this has to be decided before Jan 1st, when the poll closes.

While it may not be a preferable method, there IS a way to do distributed sieving. There is an option in NewPGen to split up the range across computers.

The question is whether, if we do split up the range, do we need to sieve every single one of the resultant files in order for NewPGen to be able to recombine them. I'm guessing it's possible to only do up to a certain level and quit whenever we want, but I'm not sure.

All we would really need is a Sticky instructing people on how to effectively use the Priority settings, since when one file ends we want the next one to start up immediately. Unless of course someone wants to do something else when their sieving ends.

Btw, I've got a Linux based Athlon if anyone wants me to do some work. Although I haven't been able to get NewPGen to behave properly.(Could use some help with that)

[gribozavr]

We can do distributed sieving. It won't be automatic, though. First 1000T need to be sieved quickly by few people so the sieving rate becomes near-constant. Then other people should download the datafile, it's going to be more than 40Mb compressed, more than 200Mb uncompressed. Also I suggest everyone who does sieving to keep at least one backup copy of previous datafile, so hard disk demands grow at least to 400Mb.

Before sieving people will have to modify the first line of the file according to their reservation. Notepad refuses to load such a large file. Vim works for me on all platforms :), but I think we should write a simple program to do that.

To report results people don't have to upload the entire datafile, just factors. Is there a tool to compare two newpgen files and show the differences?

[Skligmund]

I'd like to help out with this, but to tell the truth I'm not much for code/programming. I've never run any of the programs used in the search. (I'm a BOINCer) However, should you need some crunching power for something, and don't mind giving me a brief tutorial, I'd be very willing.

Available for use 24/7:

A64 3000 @ 2520 MHz
AXP 2100 @ 2150 MHz
2 x PIII 1000 MHz

My 3700+ gets used too often for constant crunching, and my old K-6's aren't exactly fast...

Shortly I'll have another A64 3000 and an A64 3500 for use.

[jmblazek]

Please pardon my lack of understanding...but explain further the sieving process for TPS.

I've been a part of Riesel Sieve (fully automated with BOINC) and Seventeen or Bust (semi-automated/thread reservation) and they seem to be sieving successfully.

I did notice that their dat files were much smaller...SoB 6M and RS 20M. They only submit factors...and update their dats only when major changes take place. The Sob dat wasn't updated for almost a year.

Why is TPS sieving so difficult to distribute?

Skligmund: If you can post a message...you can sieve! And with all those AMDs you'd sieve very, very well. Leave your intels to LLRing.

[gribozavr]

It is not difficult to distribute. We just need to write two helper programs:
1. a program which will edit the datafile according to your reservation. A 150Mb+ file can be easily screwed up by manual editing.
2. a program which will find the differences between the original and sieved datafile. It will make a small file with factors, which can be easily sent by email or uploaded somewhere.

[jmblazek]

I still do not understand...

Seventeen or Bust, the Prime Sierpinski Problem, and RS all use programs created by Mikael Klasson...Sobistrator and Rieselator.

SoB and PSP which uses Sobistrator and JJsieveSSE2 or JJsieveCMOV6 as their sieve client (there are other jjsieves but these are the top two)

Manual RS which uses Rieselator and Proth_Sieve as their sieve client

Are these programs of any use? Can they be altered to meet the TPS needs? If so, then maybe we can use them with permission from Mikael Klasson instead of starting from scratch.

[axn]

Originally Posted by jmblazek

Are these programs of any use? Can they be altered to meet the TPS needs?

No, and no. Those programs sieve fixed-k variable-n ranges (Here k,n are as in k*2^n+/-1). Whereas TPS is using a variable-k fixed-n approach. As it stands, NewPGen (written by Paul Jobling) does a kickass job of sieving the latter form and is very adequate for TPS.

The difficulty with distributing the sieving for TPS (as opposed to RS or PSP or SOB) is the size of the dat file and the size of the factor files. Because getting a twin prime has much lower probability than getting a "regular" prime, you have to expect to test _many_ more candidates, and therefore have to sieve much larger ranges, and finding much more factors. So coordination is going to be more difficult.

Plus, NewPGen doesn't have as clean an interface as proth_sieve, etc. for doing the distributed sieving. Which is fine, since a couple of scripts can do that for you.

Crazy idea: If someone can get the source of NewPGen (or even the source of a fast mulmod / expmod routine), a custom sieve application can be written from scratch - the math behind fixed-n sieving is so simple that the whole thing would be < 50 lines

[Rytis]

Not that crazy :)

If we can get the source (or maybe even a modified version having support for command line arguments to pass input files, etc) we could probably start sieving in PrimeGrid in a week or two :)

[pacionet]

In my opinion it would be better for the moment that PrimeGrid does LLR test only, becoming stable and going out of testing phase.
After we (... Rytis ) can start thinking to go Boinc also with sieving.

Moreover, if PrimeGrid takes also the sieving task, we'll do nothing and we'll become simple users