[quote=gd_barnes;193340]Tim,

I just thought I'd verify that you've started on n=200K-220K.[/quote]
Yep, started a few days ago. Complete for n<211K, no primes.
I'm running it on a personal PRPnet server hosted on my own machine. (mainly so that if I find a PRP it will run a primality check and stop running the rest; and since it's all local there're very few fail points) It will automatically run a primality check, right? Or am I confusing it with something else. Oh well, either way it means both cores are searching together from the beginning, and will stop once they find a PRP (the clients will fall back to CRUS's PRPnet server once my server runs out of work, which it will when it finds a (PR)prime).

Sounds great and I think that's the best way to do it. It sounds like you'll be nearly done by the time I'm ready to start so we're in sync on the timing of things.

When I start, I'll be stopping my testing of CRUS's PRPnet server on Sierp base 22, which should be at a little over n=220K by then so you'll have plenty of work to keep you busy there if you want. After that, I'll be back to Sierp base 26 for n=200K-250K before finishing up the CRUS server to n=250K if there is still work in it.

[quote=Flatlander;193344]Yes. r-base 31 is [I]very [/I]heavy. I won't be taking it anywhere near 150k. Just enough to lift it a bit and leave a sieve file to encourage someone else to take the baton.

I've also started sieving r-base 30. I might test it a bit or just leave the sieve file for someone else to have a go.

Both of these will be under-sieved.
I need more cores![/quote]

What n-range are you sieving on the 2 of them?

R base 31 is sieving n=100k-1m. I will have it at 2T on the 23rd Oct.
(I should have chosen a smaller range. I might bite off 100k-200k and sieve that afterwards.)
PFGW is at 100539 on 1 core using the sieve to 1T. Sloooow progress.

R base 30 will be sieved n=100k-200k, P=2T on the 27th Oct.
No testing done or reserved for this base.

btw
What would you say is the optimum depth for R base 23? Testing is at 221696; I have pushed the sieve file to 10T.

Reserving Sierp Base 12 (1k - 404) from n=400K-1M

[quote=Flatlander;193366]btw
What would you say is the optimum depth for R base 23? Testing is at 221696; I have pushed the sieve file to 10T.[/quote]

It kind of depends on how you look at these things. How far are you going to test it? If you are going to test n=200K-300K, I would suggest the following approach:

Run PFGW on a candidate at n=270K (70% of n-range for 200K-300K)

Assuming that you are sieving n=200K-1M, sieve (using sr1sieve) until your removal rate times 8 equals the testing time of your candidate. Calculation: n=800K (n=200K-1M) file / n=100K (n=200K-300K) range = 8.

So if your test time at n=270K is 56 mins. and your removal rate is one every 7 mins. for the entire file, you're effectively removing one k/n pair every 56 mins. from the n=200K-300K portion of the file and you are at your optimum sieve depth.

Now...if it is done like the Riesel base 6 drive, we mostly know that everyone is going to be testing the entire file within the next 1-2 years. So we made no adjustment for the "portion" of the file that would be tested in the near term since we assumed that the entire file would be tested. So...if you were only sieving n=200K-400K and knew you would be testing the entire file in a reasonable time frame, like Riesel base 6, there would be no "portion adjustment" as shown above. You'd just PFGW an n=340K (70% of n=200K-400K) candidate and sieve until your removal rate equalled that testing time. [Optionally you could break it off in n=200K-300K and n=300K-400K pieces for an additional efficiency gain like we did for Riesel base 6 but I won't get into that here.]

There are 2 ideas at work here:

1. You are only taking into account the removal rate of the candidates from your testing portion of the file but still gaining some efficiency for others by sieveing the entire file.

2. As a project, we make a "portion adjustment" on optimum sieve depth if we believe we cannot test the entire file within perhaps 1-2 years. The reasoning is that computer and software optimization makes it inefficient to use too many of today's computer resources to sieve something that will be tested > 2 years from now.


Gary

[quote=Flatlander;193366]R base 31 is sieving n=100k-1m. I will have it at 2T on the 23rd Oct.
(I should have chosen a smaller range. I might bite off 100k-200k and sieve that afterwards.)
PFGW is at 100539 on 1 core using the sieve to 1T. Sloooow progress.[/quote]

I recommend against this. Suggestion: Stop PFGW, pick a range that you think you'll be able to test...say n=100K-125K, sieve until the optimum depth as described in the prior post, than PFGW n=100K-125K.

Look at it this way (examples only):

Would you rather this:

Sieve for 3 days
PFGW for 50 days

Or this:

Sieve for 10 days
PFGW for 40 days

(The difference may be greater.)

Your call...I know what I'd rather do. :smile:

Editors note: As a general rule sieving is 5-10% of any total effort. But when only testing a small portion of a large file such as in Chris's scenario, that percentage becomes much higher, which is why the above more optimal figures don't reflect it as such. For those of you testing, this is a good guideline to use if you are going to test your entire sieved file. If you could determine the approximate total time that it will take to PFGW the entire file, which could be done after sieving for a while, and sieve only for 5-10% of that PFGW time plus the sieve time, you should be at close to optimum sieve depth.


Gary

Wouldn't it be better, to collect those general information in a separate thread?

@Gary

Okay. I'll bear all that in mind. I was kinda thinking "I'm sieving for the next guy as well as me" but I think I'm biting off more than I can chew and giving myself well undersieved files. (I was also thinking "My 64bit Windows 7 RC will expire in the spring, so if I have any sieving to do ...")
I had also forgotten about the increase in processor speed/not likely to be tested within a couple of years stuff.

Thanks.
Chris

edit:
I think from now on, when I start a sieve file, I will sieve a large range to some lowish P. Then decide how far I wish to test and snap that off for further sieving. This will give me optimum sieving and leave a 'starter file' for the next guy. There is a file-famine imho.



[QUOTE=Xentar;193422]Wouldn't it be better, to collect those general information in a separate thread?[/QUOTE]

Good idea.

Unreserving R base 23 at 226k.

"pfgw.out" and new sieve file to 10T attached.

edit:
You might want to change the header.

[quote=Flatlander;193444]Unreserving R base 23 at 226k.

"pfgw.out" and new sieve file to 10T attached.

edit:
You might want to change the header.[/quote]

OK, thanks for posting the additionally sieved file. I'm sorry if I confused you a little there. I wondered if you might be biting off a little more than you wanted to. Keep in mind that I'm not suggesting to leave the next guy hanging by only taking into account the range that you'll be testing when sieving the whole file. You're actually doing the next guy a favor by including the higher ranges with yours.

One note here: P=10T is likely sieved close to far enough for testing to at least n=250K and possibly to n=300K on this base.

Everyone, I'm going to ask that we "save" Riesel base 23 for Max until after he gets back on Thursday to see if he would like to continue it. He was kind of wanting to do a base <= 32 with 1 k remaining before he left but a couple of us beat him to the punch just a few days before he was going to take one. Since Chris found a prime for it, it convieniently leaves R23 with one k remaining. If Max doesn't want it within a couple of days of getting back, then it will be open to anyone.

Xentar, my thoughts on optimum sieveing depth are mostly entirely my own except for the 70% of the n-range thing, which I learned at RPS. They've been discussed in several places throughout the project at different times. The fact that it really is more of an art than a science is part of the reason as to why I haven't separated it into its own thread. I've evolved in my own thinking over time on what is best. I allude to doing the calculation that I described to Chris here in the Riesel base 6 sieving thread. I suppose I can separate out the relavent posts but it will still be piecemeal information that is really my opinion on how it "should" be done. In other words, it's not scientifically set it stone.

The problem is that determining optimum sieve depth on a large file for testing over several years is an extraordinarily difficult thing to conceptualize. You really need to take into account the rate of computer and software increases in speed/capacity as well as the chance of finding prime(s), hence making part (or most) of the file obsolete. The latter could be calculated. The former is more guesswork and where the "art" of it comes in.


Gary