Sierp. base 6 team sieve

[mdettweiler]

Originally Posted by gd_barnes

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.

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

Actually, I had an idea about those 3 k's. 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?

[gd_barnes]

Originally Posted by Anonymous

Actually, I had an idea about those 3 k's. 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?

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

[gd_barnes]

Originally Posted by KriZp

20-70 complete
reserving 125-200

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 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

[mdettweiler]

Originally Posted by gd_barnes

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

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?

[mdettweiler]

Taking 200G-210G.

[gd_barnes]

Originally Posted by Anonymous

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?

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

[mdettweiler]

Originally Posted by gd_barnes

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.

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?

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.

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

[gd_barnes]

Originally Posted by Anonymous

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?


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

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

[tnerual]

Originally Posted by gd_barnes

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

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)

[mdettweiler]

Originally Posted by tnerual

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)

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

[KriZp]

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