Sierp. base 6 team sieve
 

[B]Note to all: at this point (p=21T) we are well past optimal sieve depth for the entire range up to n=400K. As such, no more sieving will be needed for quite a while, and I'll lock this thread until then. (Actually, we'll probably end up starting a new thread for future sieving after that point, anyway...)[/B]

Hi all,

Gary and I have decided to do a team sieve for all the remaining Sierpinski base 6 k's, similar to the [URL="http://www.mersenneforum.org/showthread.php?t=9996"]doublecheck sieving[/URL] that we did at NPLB. Everything is just the same as with the doublecheck sieving, except that there's a lot less k's, and of course that the k's and ranges are different. :smile:

The sieve will be for the range of n=100K-400K. As we progress, we will calculate the optimal depth for various ranges (i.e. 100K-200K, 200K-300K, etc.) and break them off for PRPing as soon as the sieve reaches that depth.

Reservations of all sizes are welcome--feel free to take whatever you feel you can complete in a reasonable amount of time. (Please give status reports at least every two weeks, preferably more frequently). :smile:

The sieve file can be downloaded [URL="http://www.mersenneforum.org/attachment.php?attachmentid=2395&d=1208153814"]here[/URL]. It contains one file, "sr2data.txt", which is our sieve file. Extract it to the folder containing your copy of sr2sieve (if you don't have the latest version already, get it [URL="http://www.geocities.com/g_w_reynolds/sr2sieve/"]here[/URL]--be sure to get version 1.7.6 or later, since a big speed boost was added in that version!). Then, make a new text file called "sr2work.txt". Open it in a text editor, and enter your range on the first line, like in this example (for 10G-20G):
[code]10-20[/code]You can queue up additional ranges by adding more lines, each containing another range in that same format.

When your range is done, email the factors.txt file to me at [EMAIL="bugmesticky@googlemail.com"]bugmesticky@googlemail.com[/EMAIL] (as an attachment, please, not in the body of the message). Then, report the range as complete here in this thread, and, if you wish, reserve another range and start the process over again! :smile:

[code]Range Reserved by Status
------------------------------------
8210G-21000G KriZp complete
8200G-8210G CedricVonck complete
8000G-8200G grobie complete
7000G-8000G KriZp complete
6510G-7000G gd_barnes complete
6500G-6510G Anonymous complete
6000G-6500G KriZp complete
5200G-6000G em99010pepe complete
4700G-5200G gd_barnes complete
3500G-4700G em99010pepe complete
3400G-3500G gd_barnes complete
3250G-3400G grobie complete
3000G-3250G gd_barnes complete
2500G-3000G KriZp complete
2000G-2500G tnerual complete
1750G-2000G Anonymous complete
1500G-1750G gd_barnes complete
1200G-1500G KriZp complete
1000G-1200G tnerual complete
750G-1000G KriZp complete
500G-750G gd_barnes complete
210G-500G KriZp complete
200G-210G Anonymous complete
125G-200G KriZp complete
70G-125G gd_barnes complete
20G-70G KriZp complete
0-20G Anonymous complete
[/code]As we break off ranges of n, they will be added to the 3rd Drive. All k's are included in the drive for n>100K.

Let's get rolling! :maybeso:

Reserving 10G-20G. :smile:

reserving 20-40

[quote=KriZp;129747]reserving 20-40[/quote]
Thanks for helping out, and welcome to Conjectures 'R Us! :smile:

thanks for the warm welcome, you guys seem like a friendly bunch :) I'll take another 30G to keep my Athlon64 from running out of work while I sleep. I'm sieving @1500kp/s.

reserving 40G-70G

[quote=KriZp;129754]thanks for the warm welcome, you guys seem like a friendly bunch :) I'll take another 30G to keep my Athlon64 from running out of work while I sleep. I'm sieving @1500kp/s.

reserving 40G-70G[/quote]
Okay, great! :smile:

And while I'm at it, 10G-20G is finished. :smile:

A new sieve file is now available, sieved to p=20G. You can get it [url=http://bugmesticky.googlepages.com/CRUS-sierp6_20G.zip]here[/url]; I also updated the link in the first post of this thread.

Note: In case anyone was wondering, yes, you can switch to a newer sieve file in the middle of a range--just replace sr2data.txt with the new one, and shut down/restart sr2sieve. :smile:

[quote=Anonymous;129761]A new sieve file is now available, sieved to p=20G. You can get it [URL="http://bugmesticky.googlepages.com/CRUS-sierp6_20G.zip"]here[/URL]; I also updated the link in the first post of this thread.

Note: In case anyone was wondering, yes, you can switch to a newer sieve file in the middle of a range--just replace sr2data.txt with the new one, and shut down/restart sr2sieve. :smile:[/quote]

Very good. I didn't know that. I just always started an entirely new sieve. That'll become necessary as we find some more primes for n<100K and you're able to remove those k's from the file.


Gary

[quote=gd_barnes;129771]Very good. I didn't know that. I just always started an entirely new sieve. That'll become necessary as we find some more primes for n<100K and you're able to remove those k's from the file.


Gary[/quote]
Well, remember, when sr2sieve uses the checkpoint.txt file, it essentially starts a new range when it's restarted--the only difference is that it includes the entire range, and all the factors already found, in the numbers it gives for factors found and % done, etc. :smile:

My home dual-core Athlon will be done with its range for NPLB sieving on Thursday morning and I'll put its 2 cores on this.

Just to make the ranges nice and uneven, I'll reserve P=70G-125G. And to keep things complicated, maybe I'll split it between the 2 cores as 70G-97.45G and 97.45G-125G. :smile:

Thanks KriZp for chipping in with a good-sized range! This is a fun and important base. It's the lowest reasonably doable base that is or has not being done by other projects, it has a good # of k's remaining for a team drive, and it isn't too difficult to find primes for like base 5 and base 19 are.

Edit: Anon, we may as well include all k's in the team drive for n>100K. There has been little interest in individiual-k reservations for n<100K. I'm going to have to hassle with testing the current 3 individual k's that are not in the team drive for n<100K for n=60K-100K before we begin n>100K and I'd rather not mess with doing that in the future. So you don't need to fool around with splitting out the individual k's for n>100K when posting files for LLRing or PRPing or PFGWing or whatever people want to use. lol


Gary

20-70 complete
reserving 125-200

[quote=gd_barnes;129783]My home dual-core Athlon will be done with its range for NPLB sieving on Thursday morning and I'll put its 2 cores on this.

Just to make the ranges nice and uneven, I'll reserve P=70G-125G. And to keep things complicated, maybe I'll split it between the 2 cores as 70G-97.45G and 97.45G-125G. :smile:

Thanks KriZp for chipping in with a good-sized range! This is a fun and important base. It's the lowest reasonably doable base that is or has not being done by other projects, it has a good # of k's remaining for a team drive, and it isn't too difficult to find primes for like base 5 and base 19 are.

Edit: Anon, we may as well include all k's in the team drive for n>100K. There has been little interest in individiual-k reservations for n<100K. I'm going to have to hassle with testing the current 3 individual k's that are not in the team drive for n<100K for n=60K-100K before we begin n>100K and I'd rather not mess with doing that in the future. So you don't need to fool around with splitting out the individual k's for n>100K when posting files for LLRing or PRPing or PFGWing or whatever people want to use. lol[/quote]
Actually, I had an idea about those 3 k's. :smile: Since the LLRnet server will most likely run out of Sierp. base 6 work before we finish this sieving, why not simply put those three k's into the server when it's ready for more work? :smile:

[quote=Anonymous;129801]Actually, I had an idea about those 3 k's. :smile: Since the LLRnet server will most likely run out of Sierp. base 6 work before we finish this sieving, why not simply put those three k's into the server when it's ready for more work? :smile:[/quote]

Works for me. I suggest going ahead and sending the file to IronBits to load up in the server anytime now to keep it from running dry. That is unless you think we should wait for a little while to see if someone picks them up first. I suppose we could wait on that until the server gets past about n=90K on all other k's.


Gary

[quote=KriZp;129787]20-70 complete
reserving 125-200[/quote]

KriZp,

If you'd like, feel free to reserve 1-2 weeks of work. Optimum depth on this will be into the trillions so we won't mind. lol :smile: As a wild guess, I'll say P=2T-3T for breaking off n=100K-200K since the non-powers-of-2 bases test much more slowly.

After my initial pass on P=50G-125G to get an idea of timings and a reasonable estimate on optimum sieve depth, I'll probably reserve a 200G-300G range for 4 cores.


Gary

[quote=gd_barnes;129809]Works for me. I suggest going ahead and sending the file to IronBits to load up in the server anytime now to keep it from running dry. That is unless you think we should wait for a little while to see if someone picks them up first. I suppose we could wait on that until the server gets past about n=90K on all other k's.


Gary[/quote]
Okay, we've got two different possible courses of action we could take:

1.) Continue loading work from the drive into the server until the drive hits n=100K, then load up the 3 unreserved k's that are at n=60K.

2.) Next time IronBits needs more work, load up the 3 unreserved k's, and leave the 90K-100K portion of the drive for manual reservations.

Opinions? :smile:

Taking 200G-210G. :smile:

[quote=Anonymous;129814]Okay, we've got two different possible courses of action we could take:

1.) Continue loading work from the drive into the server until the drive hits n=100K, then load up the 3 unreserved k's that are at n=60K.

2.) Next time IronBits needs more work, load up the 3 unreserved k's, and leave the 90K-100K portion of the drive for manual reservations.

Opinions? :smile:[/quote]

Option 3: After the server processes everything to n=90K, load the 3 k's into the server and then load n=90K-100K in after it.

Option 4: After the server is at about n=88K, stop the server, load the n=90K-100K k/n pairs in after the current k/n pairs, and then load the 3 k's k/n pairs after that. Then restart the server.

Option 4 has the advantage of not having the server run dry for hours if IronBits is not babysitting it.

It won't hurt that it processes one range from n=60K-100K and then processes another range from n=90K-100K.

That was an excellent idea to put it in the server. It gives us more time for sieving here and less downtime for the server.

On a related note, do you think it makes sense to set up servers for Riesel base 16 and Sierp base 16 again? I know I would use them starting next week so we could let IronBits know that he could set them up to start around April 1st. I'm currently manually running Riesel base 16 to catch it up to close to where Sierp base 16 is at. After sieving k=300-400 at NPLB is done, I'll have some available machines. I'll use many of them to catch up on some other stuff and really push the sieving in this effort quickly but there will be a few remaining that I'm hoping that I could put 1-2 each on 3 different servers here for the different bases.


Gary

[quote=gd_barnes;129835]Option 3: After the server processes everything to n=90K, load the 3 k's into the server and then load n=90K-100K in after it.

Option 4: After the server is at about n=88K, stop the server, load the n=90K-100K k/n pairs in after the current k/n pairs, and then load the 3 k's k/n pairs after that. Then restart the server.

Option 4 has the advantage of not having the server run dry for hours if IronBits is not babysitting it.

It won't hurt that it processes one range from n=60K-100K and then processes another range from n=90K-100K.

That was an excellent idea to put it in the server. It gives us more time for sieving here and less downtime for the server.[/quote]
Yeah, option 4 sounds good. We know we're going to want to load all of those k/n pairs into the server eventually, so why not do it all at once? :smile:

[quote]On a related note, do you think it makes sense to set up servers for Riesel base 16 and Sierp base 16 again? I know I would use them starting next week so we could let IronBits know that he could set them up to start around April 1st. I'm currently manually running Riesel base 16 to catch it up to close to where Sierp base 16 is at. After sieving k=300-400 at NPLB is done, I'll have some available machines. I'll use many of them to catch up on some other stuff and really push the sieving in this effort quickly but there will be a few remaining that I'm hoping that I could put 1-2 each on 3 different servers here for the different bases.[/quote]
Hmm...I don't think we should start up a Sierp. or Riesel base 16 server at this time. Remember, CRUS is a project with relatively few resources, and thus we have to be especially careful about spreading ourselves too thin. I think that until we grow to a point where we can keep multiple servers busy, we should stick to one server at a time. Thus, we should probably hold off on a base 16 server until the base 6 server is almost out of work.

Anon :smile:

[quote=Anonymous;129845]Yeah, option 4 sounds good. We know we're going to want to load all of those k/n pairs into the server eventually, so why not do it all at once? :smile:


Hmm...I don't think we should start up a Sierp. or Riesel base 16 server at this time. Remember, CRUS is a project with relatively few resources, and thus we have to be especially careful about spreading ourselves too thin. I think that until we grow to a point where we can keep multiple servers busy, we should stick to one server at a time. Thus, we should probably hold off on a base 16 server until the base 6 server is almost out of work.

Anon :smile:[/quote]

That's fine. Another thing: If we finish Sierp base 6 long before we're done with sieving here, would it be a big hassle to switch the server over to Riesel or Sierp base 16? I'm thinking it's just easier to manage work if having the option of the server.

One more thing I should mention about how different this project is: Regardless of resources, we could in theory have 60+ servers here, one for each base and type because each server can only handle one type of k/n pairs. Since we haven't been doing any specific scoring and the fact that most servers would sit dormant most of the time, even if we have lots of resources, I wouldn't see that as a big maintenance issue except initially for the person setting up the servers (and we wouldn't have them all set up at once; just over a long period of time). They'd be reasonably easy to maintain if IronBits or whomever doesn't mind that 80-90% of them would be dormant at any one time.

It would be the ultimate flexibility: Having every base and type sieved and loaded into a separate server. Just having that available would increase interest I think.

That's kind of where I was going with the base 16 servers while we're still doing base 6. Even if not all servers have activity, is there a crime in having them sit inactive for periods of time?

This project is totally different than most. Most projects process 1-2 types of k/n pairs with no more than 2 servers. For that reason, I think one could make the case for having many servers here.


Gary

[QUOTE=gd_barnes;129857]

It would be the ultimate flexibility: Having every base and type sieved and loaded into a separate server. Just having that available would increase interest I think.


Gary[/QUOTE]

impossible ... every server has to load the whole k/n pairs stuff in memory ... each server base 16 was using about 256Mb on carlos's computer

let people play with their own k or own base

server are good if they are used on a large scale ... they are there to clean up some stuff, manage large number of core ... run a server on near to end base (to kill the lasts k and so kill the base)

[quote=tnerual;129865]impossible ... every server has to load the whole k/n pairs stuff in memory ... each server base 16 was using about 256Mb on carlos's computer

let people play with their own k or own base

server are good if they are used on a large scale ... they are there to clean up some stuff, manage large number of core ... run a server on near to end base (to kill the lasts k and so kill the base)[/quote]
I agree with tnerual--the overhead involved with keeping track of all those servers would be immense.

Also, we want to leave some bases and k's open for manual crunching and individual reservation. Remember how when the project first started, we emphasized that there was work available for all tastes--team drives, individual k's, whole bases, and later, LLRnet? We need to keep that in mind as we progress.

In my opinion, we should limit the number of LLRnet servers to, say, 3 or 4 at the max--and even then, only if we had enough resources to sustain that many servers. Otherwise, we'll be spread so thin, that we'll hardly make any actual progress on anything, just some dabbling around throughout the spectrum of conjectures.

Remember what happened when we had both Sierp. and Riesel base 16 servers? Once NPLB was launched and participation in CRUS went downhill, we only had a few people left doing LLRnet here. Thus, when tnerual took his machines off the Sierp. server for the first NPLB rally, the Sierp. server literally went dormant for a while!

We need to be sure to keep all the above factors in mind when deciding whether to add more LLRnet servers.

Anon :smile:

yea, I suppose I should take a larger chunk, anon's tiny starting ranges made me think a small range would be appropriate :) Also a small range this early in the sieve would shorten the interval between sr2data.txt updates, wich I suppose would speed the sieve up marginally. I will reserve a slightly larger range now, but split it in the sr2work.txt file so I get more factorsXXX.txt files and mail them as they get done.

125G-200G complete KriZp
reserving 210G-500G KriZp

[quote=KriZp;129908]yea, I suppose I should take a larger chunk, anon's tiny starting ranges made me think a small range would be appropriate :) Also a small range this early in the sieve would shorten the interval between sr2data.txt updates, wich I suppose would speed the sieve up marginally. I will reserve a slightly larger range now, but split it in the sr2work.txt file so I get more factorsXXX.txt files and mail them as they get done.

125G-200G complete KriZp
reserving 210G-500G KriZp[/quote]
Actually, at this point in the sieve, the marginal improvement from removing candidates from the sieve file is so marginal that it's often not worth the trouble. I'll still be releasing updates to the sieve file, but I'll probably only do so every 100G or so. :smile: But, of course, it certainly won't do any harm to submit factors more often.

Meanwhile, 200G-210G is complete. :smile:

[QUOTE=Anonymous;129909]Actually, at this point in the sieve, the marginal improvement from removing candidates from the sieve file is so marginal that it's often not worth the trouble. I'll still be releasing updates to the sieve file, but I'll probably only do so every 100G or so.[/QUOTE]

Ah, I thought it would be less marginal this early, since there are thousands of candidates removed just by sieving a few G. I know that removing ks is what really counts regarding speed. In any event, don't burn yourself out on the administrative tasks. :uncwilly:

[quote=KriZp;129908]yea, I suppose I should take a larger chunk, anon's tiny starting ranges made me think a small range would be appropriate :) Also a small range this early in the sieve would shorten the interval between sr2data.txt updates, wich I suppose would speed the sieve up marginally. I will reserve a slightly larger range now, but split it in the sr2work.txt file so I get more factorsXXX.txt files and mail them as they get done.

125G-200G complete KriZp
reserving 210G-500G KriZp[/quote]


And I haven't even started on my range yet. lol It starts tomorrow morning.

At this rate, we'll easily be done sieving before the base has been tested up to n=100K!

[quote=gd_barnes;129920]And I haven't even started on my range yet. lol It starts tomorrow morning.

At this rate, we'll easily be done sieving before the base has been tested up to n=100K![/quote]

My range started ~9 AM CDT this morning. ETA is 7 AM CDT Friday morning so this is going to zoom right along.

Therefore, I'd like to go ahead and reserve the range of P=500G-750G. If 75G took 1 day, then 250G should take ~3.5 days on the same Athlon DC, although should be a little faster since higher P-ranges sieve faster, even with the same # of k/n pairs remaining.

Anon, once you get the completed range from KriZp up to P=500G, can you remove the factors and re-post the sieved file? (I'm assuming he'll be done before I'm done with my 2nd reservation of P=500G-750G.) I'll then re-download it and should be able to get a reasonable estimate on the optimum sieve depth for breaking off n=100K-200K using the LLR time of an n=170K k/n pair.

Optionally since the LLR times are much longer here than powers-of-2 bases, we could break off n=100K-150K when the removal rate is about that of an n=135K k/n pair. It'd be somewhat more CPU-efficient in the long run but it'd be a little more upfront work here while sieving.


Gary

I'm at p=335G atm, doing around 150G/day, so 210-500 should be done in perhaps 30 hours. sr2sieve reports ~1,6 Mp/sec, 27 sec/factor. I'll keep this core on this project untill it is decided that the sieve is deep enough.

[quote=KriZp;130030]I'm at p=335G atm, doing around 150G/day, so 210-500 should be done in perhaps 30 hours. sr2sieve reports ~1,6 Mp/sec, 27 sec/factor. I'll keep this core on this project untill it is decided that the sieve is deep enough.[/quote]

Very speedy siever. What kind of machine? My 1.6 Ghz Athlon DC laptop is only getting ~450P/sec on each core.

I'm running both cores on it just for my total speed to be a little over half your single-core speed. (lol) Of course I bought it before starting prime-searching so it wasn't intended for speed in the first place.


Gary

Sounds like you are running 32bit :) I put 64bit linux on my 64bit processors back when sr2sieve came with a 64bit version, IIRC it more or less doubled in speed, very fun.

/proc/cpuinfo says
model name : AMD Athlon(tm) 64 Processor 3000+
cpu MHz : 2430.709
cache size : 512 KB

[quote=gd_barnes;130014]My range started ~9 AM CDT this morning. ETA is 7 AM CDT Friday morning so this is going to zoom right along.

Therefore, I'd like to go ahead and reserve the range of P=500G-750G. If 75G took 1 day, then 250G should take ~3.5 days on the same Athlon DC, although should be a little faster since higher P-ranges sieve faster, even with the same # of k/n pairs remaining.

Anon, once you get the completed range from KriZp up to P=500G, can you remove the factors and re-post the sieved file? (I'm assuming he'll be done before I'm done with my 2nd reservation of P=500G-750G.) I'll then re-download it and should be able to get a reasonable estimate on the optimum sieve depth for breaking off n=100K-200K using the LLR time of an n=170K k/n pair.

Optionally since the LLR times are much longer here than powers-of-2 bases, we could break off n=100K-150K when the removal rate is about that of an n=135K k/n pair. It'd be somewhat more CPU-efficient in the long run but it'd be a little more upfront work here while sieving.


Gary[/quote]
Okay, I'll be sure to post an updated sieve file when you finish your 70G-125G range. :smile:

As for when to break off n=100K-150K--I don't get it, isn't n=135K the standard 70% anyway?

[quote=Anonymous;130075]Okay, I'll be sure to post an updated sieve file when you finish your 70G-125G range. :smile:[/quote]

No, I suggested to post an updated file when KriZp finishes his 210G-500G range, which will be after my small reservation. I'll be done tomorrow morning with my file. He should be done later in the day. It makes more sense to wait a few hours to get more than twice the sieved range factors removed.


[quote]
As for when to break off n=100K-150K--I don't get it, isn't n=135K the standard 70% anyway?[/quote]

No, again. :smile: If we break off n=100K-200K, then n=170K is the 70% point of the range. If we break off n=100K-150K, THEN n=135K is the 70% point. It's the 70% point of the range you break off.

Effectively, what you're looking for is the approximate average LLR time of only the range that you're breaking off as a reference for the optimum removal rate of the sieve. The 70% point approximately accomplishes that.

If we wanted to be lazy and sieve the entire n=100K-400K range all to exactly the same depth, then n=310K would be the 70% point and the most optimum. It would be very inefficient when LLRing at the higher n-levels to do it that way but as far as the optimal depth if that depth was the SAME for the entire range, then that would be as good as we could do. I've done that for some smaller efforts on base 2, perhaps for n=25K-200K or something when I didn't want to mess with optimizing the sieving and LLRing. The time saved wasn't worth my extra hassle.

Edit: I just looked closer at the timing of of KriZp's post. It would be closer to 1 AM EDT late night tomorrow when he is done. Regardless, go ahead and wait and remove the factors then. I'll then temporarily stop my P=500G-750G range, copy in the file with less candidates remaining in it on Saturday during the day, and restart it.


Gary

[quote=gd_barnes;130094]No, I suggested to post an updated file when KriZp finishes his 210G-500G range, which will be after my small reservation. I'll be done tomorrow morning with my file. He should be done later in the day. It makes more sense to wait a few hours to get more than twice the sieved range factors removed.


No, again. :smile: If we break off n=100K-200K, then n=170K is the 70% point of the range. If we break off n=100K-150K, THEN n=135K is the 70% point. It's the 70% point of the range you break off.

Effectively, what you're looking for is the approximate average LLR time of only the range that you're breaking off as a reference for the optimum removal rate of the sieve. The 70% point approximately accomplishes that.

If we wanted to be lazy and sieve the entire n=100K-400K range all to exactly the same depth, then n=310K would be the 70% point and the most optimum. It would be very inefficient when LLRing at the higher n-levels to do it that way but as far as the optimal depth if that depth was the SAME for the entire range, then that would be as good as we could do. I've done that for some smaller efforts on base 2, perhaps for n=25K-200K or something when I didn't want to mess with optimizing the sieving and LLRing. The time saved wasn't worth my extra hassle.[/quote]
Ah, I see what you mean now. I didn't know you were comparing it with the possibility of breaking off 100K-200K. :smile:

[quote]Edit: I just looked closer at the timing of of KriZp's post. It would be closer to 1 AM EDT late night tomorrow when he is done. Regardless, go ahead and wait and remove the factors then. I'll then temporarily stop my P=500G-750G range, copy in the file with less candidates remaining in it on Saturday during the day, and restart it.[/quote]
Okay, sounds good. :smile:

ETA of my range is now 15 hours.

P=75G-150G complete; factors sent in an Email to Anon.

Now working on P=500G-750G; ETA is mid-morning 3/31.


Gary

210-500 complete
750-1000 reserved

New sieve file is now available, with all factors removed up to p=500G. :smile: You can get it [URL="http://bugmesticky.googlepages.com/CRUS-sierp6_500G.zip"]here[/URL]; I also updated the link in the first post of this thread.

1000-1200 for me

[quote=tnerual;130241]1000-1200 for me[/quote]
Glad to have you join the fun! :grin:

750G-1000G complete
1200G-1500G reserved

[quote=KriZp;130286]750G-1000G complete
1200G-1500G reserved[/quote]
I didn't get the factors for 750G-1000G yet, and it's over 6 hours later. Did you forget to send them by any chance?

Hi all,

Since two primes have just been found in the team drive for Sierp. base 6, I've removed the respective k's from the sieve file. You can download the updated sieve file [url=http://bugmesticky.googlepages.com/CRUS_sierp6-20080331.zip]here[/url]; I also updated the first post of this thread. :smile:

yes I did: I'll send them right away

500G-750G complete; Emailed to Anon

Reserving 1500G-1750G.

Anon, I think I'll use KriZp's P-rate/sec and your LLR speed here for optimum sieve depth calculations.

Can you LLR a candidate at n=135K and at n=170K sometime today? We can then decide whether we want to break off n=100K-150K or n=100K-200K.

KriZp, what is your P-rate/sec at P=1200G?

Using the fastest siever and a fast LLRer will be more accurate. The optimum depth will be deeper than calculating it using a slower machine but we'll get there faster so the total time spent sieving should be only slightly longer but will save much more time LLRing.


Gary

p=1320074545843, 1729588 p/sec, 552 factors, 40.0% done, 125 sec/factor

with the new sieve-file.
When I shut it down in order to change to the new sievefile it reported this:
sr2sieve 1.7.9 stopped: at p=1288626833551 because SIGINT was received.
Found factors for 420 terms in 52927.273 sec. (expected about 432.00)=126 sec/factor
and now
sr2sieve 1.7.9 stopped: at p=1320447776779 because SIGINT was received.
Found factors for 552 terms in 71263.464 sec. (expected about 560.65)=129.1 sec/factor

[quote=gd_barnes;130354]500G-750G complete; Emailed to Anon

Reserving 1500G-1750G.

Anon, I think I'll use KriZp's P-rate/sec and your LLR speed here for optimum sieve depth calculations.

Can you LLR a candidate at n=135K and at n=170K sometime today? We can then decide whether we want to break off n=100K-150K or n=100K-200K.

KriZp, what is your P-rate/sec at P=1200G?

Using the fastest siever and a fast LLRer will be more accurate. The optimum depth will be deeper than calculating it using a slower machine but we'll get there faster so the total time spent sieving should be only slightly longer but will save much more time LLRing.


Gary[/quote]
Okay, I'll be sure to do that ASAP. :smile:

New sieve file available, sieved to a depth of p=1T (1000G). :smile: You can get it [url=http://bugmesticky.googlepages.com/CRUS-sierp6_1T.zip]here[/url].

Okay, here are my timings for PRPing two test candidates at n=135K and n=170K respectively:
[code]124221*6^135003+1 is not prime. RES64: 7A0C21629EA30E82. OLD64: 6E246427DBE92B83 Time: 876.532 sec.
51255*6^170000+1 is not prime. RES64: B70F935942F0540A. OLD64: 252EBA0BC8D0FC1A Time: 1316.149 sec.[/code]

[quote=Anonymous;130385]Okay, here are my timings for PRPing two test candidates at n=135K and n=170K respectively:
[code]124221*6^135003+1 is not prime. RES64: 7A0C21629EA30E82. OLD64: 6E246427DBE92B83 Time: 876.532 sec.
51255*6^170000+1 is not prime. RES64: B70F935942F0540A. OLD64: 252EBA0BC8D0FC1A Time: 1316.149 sec.[/code][/quote]


Whew! Ugly! :smile: Thanks for doing that.

So...LOTs of sieving to go. I think it makes sense to break off n=100K-150K with that big of a difference in LLR times.

Now, with a more educated guess, with KripZp at an est. removal rate of 129 secs/factor at P=1.3T, for the n=100K-150K range, optimum would be 1.3T * 877 / 129 ~= 8.8T. Since the removal rate is not linear in it's reduction as we remove factors, I'd round down to say optimum will be P=7.5-8T for breaking off n=100K-150K.

I'll do a more exact calculation a little later this evening.

The optimum is much higher than usual because we're sieving a large n-range, using a speedy siever here, and of course it's a non-power-of-2 base.

This shows that people can go ahead and start reserving P=500G chunks if they want to. I'll add 2 cores to this effort on Wed. or Thurs. for a total of 4 and will start reserving P=500G chunks at that point.

We'll see if we can at least knock out n=100K-150K before the Sierp base 6 server runs dry. With Beyond on it, I think I'm going to pull my 2 cores off of it later today or tomorrow and put them where they can be better utilized.


Gary

Using the formula "current depth * LLR time / removal rate = optimal depth" with KriZp's sieve timings and my PRP timings, I got the following optimal depth when using my n=135K test candidate:

[B]1320G * 876.532 / 125 = 9256G[/B]

For the n=170K test candidate:

[B]1320G * 1316.149 / 125 = 13899G[/B]

Obviously, we have our work cut out for us. :smile:

Reserving 1750G-1800G. :smile:

[quote=Anonymous;130389]Using the formula "current depth * LLR time / removal rate = optimal depth" with KriZp's sieve timings and my PRP timings, I got the following optimal depth when using my n=135K test candidate:

[B]1320G * 876.532 / 125 = 9256G[/B]

For the n=170K test candidate:

[B]1320G * 1316.149 / 125 = 13899G[/B]

Obviously, we have our work cut out for us. :smile:[/quote]


See my prior analysis above. It's probably closer to P=7.5T-8T for the n=100K-150K range since the removal rate reduction is not linear as we progress upward and the true removal rate is 129 / sec.

In getting the true removal rate, we use the rate based on the expected number of factors as opposed to the actual number of factors. The expected is a straight calculation and doesn't vary. The actual can vary quite a bit from what it should be.

We'll definitely want to break off the smaller range of n=100K-150K to have a chance of completing a portion of it before the server runs dry and the fact that the timing difference between n=135K and n=170K is so great. We could even do n=100K-125K or 100K-130K but it becomes too much of a hassle at such small increments until the n-values become very high.


Gary

[quote=gd_barnes;130391]See my prior analysis above. It's probably closer to P=7.5T-8T for the n=100K-150K range since the removal rate reduction is not linear as we progress upward and the true removal rate is 129 / sec.

In getting the true removal rate, we use the rate based on the expected number of factors as opposed to the actual number of factors. The expected is a straight calculation and doesn't vary. The actual can vary quite a bit from what it should be.

We'll definitely want to break off the smaller range of n=100K-150K to have a chance of completing a portion of it before the server runs dry and the fact that the timing difference between n=135K and n=170K is so great. We could even do n=100K-125K or 100K-130K but it becomes too much of a hassle at such small increments until the n-values become very high.


Gary[/quote]
Ah, I see. Okay, I guess it's probably more close to 7.5-8T then. :smile:

Either way, though, we still have plenty of work ahead of us--I've decided to put one core on this effort steadily for a while. Thus, I'll reserve 1800G-2000G too. :smile:

[quote=Anonymous;130385]Okay, here are my timings for PRPing two test candidates at n=135K and n=170K respectively:
[code]124221*6^135003+1 is not prime. RES64: 7A0C21629EA30E82. OLD64: 6E246427DBE92B83 Time: 876.532 sec. [/code][/quote]

Mine:
[code]124221*6^135003+1 is not prime. RES64: 7A0C21629EA30E82. OLD64: 6E246427DBE92B83 Time: 613.748 sec. [/code]

1000-1200 done (sending results just after posting this message)

reserving 2000-2500 (5 day of work)

[quote=em99010pepe;130412]Mine:
[code]124221*6^135003+1 is not prime. RES64: 7A0C21629EA30E82. OLD64: 6E246427DBE92B83 Time: 613.748 sec. [/code][/quote]

Anon, I suppose if we are using the fastest siever, we should use the fastest LLRer to compute the optimum depth. Carlos's and Karsten's quad(s) are the fastest LLRing machines that I've seen.

Using Carlos's time will reduce optimum depth for breaking off n=100K-150K. It would now be:

1.3T * 614 / 129 ~= 6.2T.

So...round down to P=~5.5T-6T to allow for future factor removal additionally reducing the sieving removal rate.

This is still only a 'ball park' estimate. When we hit about P=4T and have all factors removed to that point, then I would consider the factor removal rate at that point close enough to extrapolate an optimum sieve depth.

Then, we'll get to do it all over again for n=150K-200K starting from P=~5.5T-6T. :smile:

If anyone has a faster sieving or LLRing machine -AND- you will be either helping with sieving or LLRing Sierp base 6 now or in the future, let me know. I want to get as close as possible to an apples-to-apples comparison.


Thanks,
Gary

[quote=gd_barnes;130494]Anon, I suppose if we are using the fastest siever, we should use the fastest LLRer to compute the optimum depth. Carlos's and Karsten's quad(s) are the fastest LLRing machines that I've seen.

Using Carlos's time will reduce optimum depth for breaking off n=100K-150K. It would now be:

1.3T * 614 / 129 ~= 6.2T.

So...round down to P=~5.5T-6T to allow for future factor removal additionally reducing the sieving removal rate.

This is still only a 'ball park' estimate. When we hit about P=4T and have all factors removed to that point, then I would consider the factor removal rate at that point close enough to extrapolate an optimum sieve depth.

Then, we'll get to do it all over again for n=150K-200K starting from P=~5.5T-6T. :smile:

If anyone has a faster sieving or LLRing machine -AND- you will be either helping with sieving or LLRing Sierp base 6 now or in the future, let me know. I want to get as close as possible to an apples-to-apples comparison.


Thanks,
Gary[/quote]
Well, for an apples-to-apples comparison, probably a non-overclocked Core 2 (Duo or Quad) would be best--I think they're about equally good at sieving and LLR/PRPing. So, maybe this p-rate information from my Core 2 Duo 2.2Ghz would be helpful:
[code]p=1796383025029, 1221822 p/sec, 153 factors, 92.8% done, 248 sec/factor
Expected factors in range 1750G-1800G: 159.22[/code]My machine is not overclocked, and is running 32-bit Linux (so it's probably a pretty good apples-to-apples comparison of sieving and LLR). :smile:

[quote=Anonymous;130497]Well, for an apples-to-apples comparison, probably a non-overclocked Core 2 (Duo or Quad) would be best--I think they're about equally good at sieving and LLR/PRPing. So, maybe this p-rate information from my Core 2 Duo 2.2Ghz would be helpful:
[code]p=1796383025029, 1221822 p/sec, 153 factors, 92.8% done, 248 sec/factor
Expected factors in range 1750G-1800G: 159.22[/code]My machine is not overclocked, and is running 32-bit Linux (so it's probably a pretty good apples-to-apples comparison of sieving and LLR). :smile:[/quote]

Good point. I agree with this and is the way I do the optimum sieve depths on NPLB. We'll get the more exact depth a little later using this method instead.


Gary

1750G-1800G complete. :smile:

1200G-1500G KriZp complete
reserving 2500G-3000G KriZp

Adding 2 more cores...

Reserving P=3T-3.25T

1.5T-1.75T should be done very early Thursday morning.

Reserving 3250 to 3400 ETA Apr 5th

1500G-1750G complete; factors to be Emailed

Reserving 3400G-3500G...a small range to sync up the 4 machines for a large reservation next time.

Reserving 3500-4100
and 4100-4700

ETA~less than 2 days.

So how deep are we going? Just asking because a heat wave is passing Portugal and sieving reduces the CPU temps by 5 ºC. If this goes on I prefer to sieve without having the necessity to reduce the CPU speed. lol

BTW, 3500-4100 at 83%.

Carlos

Reserving 4700G-5200G for my 4 machines. My 2 ranges will finish up this morning and afternoon; will send factors then.


Carlos, we still have to do a calculation but I'm guessing 6000G = 6T for breaking off n=100K-150K; closer to 9T-10T for n=150K-200K; then it goes up from there. We're sieving n=100K-400K so plenty of work to do.

As soon as Anon gets all contiguous factors up to P=~3000G-3500G, he can remove them and run a test at P=~5000G to see what his remove rate is and we can do the calculation.

Once we hit optimal for n=100K-150K, we'll stop, remove that n-range, add it to drive 3, and continue sieving n=150K-400K.


Gary

3500-4100 done, factors sent.

[quote=em99010pepe;130711]So how deep are we going? Just asking because a heat wave is passing Portugal and sieving reduces the CPU temps by 5 ºC. If this goes on I prefer to sieve without having the necessity to reduce the CPU speed. lol

BTW, 3500-4100 at 83%.

Carlos[/quote]
As Gary said, even after we've broken off 100K-150K, we'll still have [i]plenty[/i] of sieving left to do. :smile: Our sieve file goes up to n=400K, which for base 6 means verrrrrryyyyyyy lllloooooonnnnngggg PRP tests. :smile:

So, even after this sieve's reached optimal depth for 100K-150K, don't worry, there will still be plenty of work to be done. :smile:

Taking 5200-6000

New sieve file available, with k=66520 and all factors removed. :smile: You can get it [URL="http://bugmesticky.googlepages.com/CRUS-sierp6-20080404.zip"]here[/URL].

6000-6500 reserved
2500-3000 finished in 3h, but I'm tired and slightly drunk ;) I'll ,mail the factors when I wake up.

3T-3.25T and 3.4T-3.5T complete; no primes :lol:

3.4T-3.5T mailed. 3T-3.25T is on currently non-accessible machines and will be mailed on Saturday.

The 4.7T-5.2T range should be complete late Monday.

Anon, after you get my 3T-3.25T and Tnerual's 2T-2.5T factors and you finish your range of 1.8T-2T, we'll have all factors up to 3.25T. Can you remove them all and then give me your P-rate per second on your machine at 5T?

I passingly mentioned to Carlos that I thought optimum for n=100K-150K might be 6T but I suspect it will be closer to 7T.


Gary

[quote=gd_barnes;130788]3T-3.25T and 3.4T-3.5T complete; no primes :lol:

3.4T-3.5T mailed. 3T-3.25T is on currently non-accessible machines and will be mailed on Saturday.

The 4.7T-5.2T range should be complete late Monday.

Anon, after you get my 3T-3.25T and Tnerual's 2T-2.5T factors and you finish your range of 1.8T-2T, we'll have all factors up to 3.25T. Can you remove them all and then give me your P-rate per second on your machine at 5T?

I passingly mentioned to Carlos that I thought optimum for n=100K-150K might be 6T but I suspect it will be closer to 7T.


Gary[/quote]
Okay, I'll be sure to do that as soon as I've got all the necessary factors. :smile:

1800G-2000G complete. :smile:

3T-3.25T now mailed

4100-4700 done, factors sent by email.

2000-2500 done and results sent to anonymous

Taking 6500G-6510G for an older machine. :smile:

Range 3250 to 3400 Complete. Factors sent by e-mail.

I would take another range but I will be out for about 2 weeks or so.

[quote=grobie;130852]Range 3250 to 3400 Complete. Factors sent by e-mail.

I would take another range but I will be out for about 2 weeks or so.[/quote]
Well, if you want, you could always just take a reservation that's a little ways ahead of the leading edge of this sieving, if you're worried about holding it up--maybe you could grab a range >8000G (since that's past our estimated optimal depth for n=100K-150K, but we'll definitely still need to go up that high for the higher ranges). :smile:

Now that factors have been received and removed from the sieve file up to p=4.7T, I calculated the optimal depth of [B]5417G[/B] based on the n=135K test candidate I ran earlier, and my machine's p/sec. rate at p=5T, as Gary had suggested.

I was quite surprised to see that the optimal depth was so low--though, of course, we would probably want to wait until factors have been removed up to p=6T anyway before releasing files for PRPing (it's usually a good idea to sieve a little bit higher than your optimal depth calculation shows, to iron out differences between machines and all that).

Gary, what's your opinion? Does 6T sound good to you?

Just post here the new sieve file before I go to bed!

[quote=em99010pepe;130855]Just post here the new sieve file before I go to bed![/quote]
Okay, the new sieve file (sieved to p=4.7T) is attached. Enjoy! :smile:

6500G-6510G done. :smile:

5200-6000 done.

4700-5200 done; factors Emailed

Anon, after you remove these factors, we're complete to P=6000G. Please do a quick start and stop of the range of P=6000G-6100G. Please post your sieve rate and expected # of factors. You can start and stop it after one minute or when you find out what your sieve rate is.

Instead of using the removal rate, we'll be using an actual calculation based on expected # of factors, your sieve rate, and the range that would be tested, i.e. 100G.

If that comes in close to your n=135K LLR time, we're ready to break off n=100K-150K.


Gary

[quote=gd_barnes;130948]4700-5200 done; factors Emailed

Anon, after you remove these factors, we're complete to P=6000G. Please do a quick start and stop of the range of P=6000G-6100G. Please post your sieve rate and expected # of factors. You can start and stop it after one minute or when you find out what your sieve rate is.

Instead of using the removal rate, we'll be using an actual calculation based on expected # of factors, your sieve rate, and the range that would be tested, i.e. 100G.

If that comes in close to your n=135K LLR time, we're ready to break off n=100K-150K.


Gary[/quote]
Okay, I'll do that as soon as I can get to it. :smile:

[quote=Anonymous;130960]Okay, I'll do that as soon as I can get to it. :smile:[/quote]
Here you go:
[code]Expecting to find factors for about 82.98 terms in this range.
sr2sieve 1.7.9 started: 100003 <= n <= 400000, 6000000000000 <= p <= 6100000000000
p=6000239731867, 1338246 p/sec, 0 factors, 0.2% done, ETA 07 Apr 22:51
sr2sieve 1.7.9 stopped: at p=6000267475511 because SIGINT was received.
Found factors for 0 terms in 201.046 sec. (expected about 0.22)[/code]

[quote=Anonymous;130962]Here you go:
[code]Expecting to find factors for about 82.98 terms in this range.
sr2sieve 1.7.9 started: 100003 <= n <= 400000, 6000000000000 <= p <= 6100000000000
p=6000239731867, 1338246 p/sec, 0 factors, 0.2% done, ETA 07 Apr 22:51
sr2sieve 1.7.9 stopped: at p=6000267475511 because SIGINT was received.
Found factors for 0 terms in 201.046 sec. (expected about 0.22)[/code][/quote]


OK, I'll do some calculation here within a couple of hours.

In the mean time...reserving 6510G-6600G for filler work for a couple of cores.

Anon,

P=6T (6000G) is almost right at optimal sieve depth for n=100K-150K.

Analysis for P=6T-6.1T:

Given by you:
Expected factors: 82.98
P-range: 0.1T (100G)
P-rate/sec: 1338246

Time to complete range: 100G / 1338246 secs. = 74725 secs.

Removal rate: 74725 secs. / 82.98 facs. = 900.5 secs. / fac.

LLR test at n=135K: 876.5 secs.


We're just slightly past optimal depth at P=6T, which is the way I think it should be. I was thinking it would be a little higher but finding the prime for k=66520 helped reduce it a little bit.

Go ahead and remove n=100K-150K from the big sieved file that has had all its factors removed to P=6T and re-post a new file for n=150K-400K only. People with current reservations can decide if they want to use the new file for continuing in the middle of their reservation.

Since Beyond is still working on his machines or doing other work, there's still a fair amount of LLRnet work for n<100K so you can hold off on adding it to the LLRnet queue for now. See next para. I've had 2 cores on it over the weekend and at this moment, it's almost right at n=99K but then there are 3 k's for n=60K-100K that are in the queue that still need to be processed; which is a lot of work.

Can I get some opinions on whether we should post manual reservations for Sierp base 6? Does anyone feel that there are some people that would work on this base using manual reservations? The response to the manual reservations for n<100K was rather tepid, although I/we didn't promote it much.


Thanks,
Gary

[quote=gd_barnes;130995]Anon,

P=6T (6000G) is almost right at optimal sieve depth for n=100K-150K.

Analysis for P=6T-6.1T:

Given by you:
Expected factors: 82.98
P-range: 0.1T (100G)
P-rate/sec: 1338246

Time to complete range: 100G / 1338246 secs. = 74725 secs.

Removal rate: 74725 secs. / 82.98 facs. = 900.5 secs. / fac.

LLR test at n=135K: 876.5 secs.


We're just slightly past optimal depth at P=6T, which is the way I think it should be. I was thinking it would be a little higher but finding the prime for k=66520 helped reduce it a little bit.

Go ahead and remove n=100K-150K from the big sieved file that has had all its factors removed to P=6T and re-post a new file for n=150K-400K only. People with current reservations can decide if they want to use the new file for continuing in the middle of their reservation.[/quote]
Okay, I'll do that. :smile:

[quote]Since Beyond is still working on his machines or doing other work, there's still a fair amount of LLRnet work for n<100K so you can hold off on adding it to the LLRnet queue for now. See next para. I've had 2 cores on it over the weekend and at this moment, it's almost right at n=99K but then there are 3 k's for n=60K-100K that are in the queue that still need to be processed; which is a lot of work.[/quote]
Okay, got it. :smile:

[quote]Can I get some opinions on whether we should post manual reservations for Sierp base 6? Does anyone feel that there are some people that would work on this base using manual reservations? The response to the manual reservations for n<100K was rather tepid, although I/we didn't promote it much.[/quote]
I'm thinking that with all the recent attention surrounding phrot, we might get some interest in individual k reservations for Sierp. base 6; thus, how about we leave two k's open for manual reservation? Then, if nobody takes them, maybe you or I can get them caught up to a level where we can include them in the team drive. :smile:

As soon as you give the all-clear on whether leaving 2 k's for manual reservation is OK, I'll go ahead and split up the 100K-150K chunk of the sieve file for PRPing and post some files in the Drive #3 thread. :smile:

Hi all,

Here's a new sieve file, with the range 100K-150K removed now that we've broken it off for PRPing. Thus, this sieve file contains a total range of 150K-400K. :smile: It is highly recommended that you switch to this new sieve file, even in the middle of a range--it should have a noticeable speed increase over the old one, because of the smaller range. You can continue running your range with the old one if you want, but you'll probably want to switch to the new one. :smile: Just download the zip file, replace sr2data.txt in your sr2sieve folder with the one in the new zip file, and stop and restart sr2sieve.

Anon :smile:

Gary, I sent you the 100K-150K portion of the sieve file that I broke off, so now both you and I have a copy. :smile:

[quote=Anonymous;131009]Okay, I'll do that. :smile:


Okay, got it. :smile:


I'm thinking that with all the recent attention surrounding phrot, we might get some interest in individual k reservations for Sierp. base 6; thus, how about we leave two k's open for manual reservation? Then, if nobody takes them, maybe you or I can get them caught up to a level where we can include them in the team drive. :smile:

As soon as you give the all-clear on whether leaving 2 k's for manual reservation is OK, I'll go ahead and split up the 100K-150K chunk of the sieve file for PRPing and post some files in the Drive #3 thread. :smile:[/quote]

Good point about the interest in Phrot. Let's do 3 individual k reservations...the 3 lowest k's...10107, 13215, and 14505, like we did up to n=100K until we recently added them at the end of the LLRnet server.

Don't post any n>100K files for anything yet until LLRnet has tested everything to n=100K including the 3 k's above. It'd be duplicate work to be testing the same k's at 2 different n-values.

Edit: You could go ahead and have IronBits load n=100K-110K in the server for all k's except the 3 above but it should still be a while until that is needed.


Gary

[quote=gd_barnes;131087]Good point about the interest in Phrot. Let's do 3 individual k reservations...the 3 lowest k's...10107, 13215, and 14505, like we did up to n=100K until we recently added them at the end of the LLRnet server.

Don't post any n>100 files for anything yet until LLRnet has tested everything to n=100K including the 3 k's above. It'd be duplicate work to be testing the same k's at 2 different n-values.

Edit: You could go ahead and have IronBits load n=100K-110K in the server for all k's except the 3 above but it should still be a while until that is needed.


Gary[/quote]
Okay, that sounds good. I'll hold off on giving 100K-110K to IronBits--as you said, we don't need to put it in the server quite yet, especially with all the attention on port 5000 at NPLB right now. :smile:

P=6510G-6600G complete; factors sent.

Reserving P=6600G-7000G.

6000G-6500G KriZp complete
reserving 7000G-8000G

Anon,

Like before, when you have received all of the factors up to P=8T and have removed them, please run a quickie test for P=8T-8.1T and post the same stats as before. I like doing the math but if you want to do the calculation, that works for me.

An educated guess says the optimal for n=150K-200K will be P=~9T-10T.


Gary