mersenneforum.org  

Go Back   mersenneforum.org > Prime Search Projects > No Prime Left Behind

Reply
 
Thread Tools
Old 2008-03-04, 18:55   #1
gd_barnes
 
gd_barnes's Avatar
 
May 2007
Kansas; USA

276516 Posts
Default Opinions wanted on direction of drive 3

My original thinking and what I've heard from people is that it would be best to merge drive 3 with drive 1. But I would like to throw out another possibility here:

See how quickly we can get k=300-400 tested to n=600K. I'm currently sieving this k-range for n=600K-1M to P=11T-12T, which will be complete 3rd-4th week in March.

Although we'll have a few k's that we can test for n>600K because others have previously searched that high, if we can get this k-range quickly tested to n=600K, it would open up fully 50 k's for searching n>600K!! (As far as I know, there are no reservations anywhere for this k-range/n-range.)

Thoughts, opinions, complications, feedback?


Gary

Last fiddled with by gd_barnes on 2008-03-04 at 19:22
gd_barnes is online now   Reply With Quote
Old 2008-03-04, 19:16   #2
mdettweiler
A Sunny Moo
 
mdettweiler's Avatar
 
Aug 2007
USA (GMT-5)

3×2,083 Posts
Default

How about we not merge this with Drive #1, and instead try to pull this drive up to n=600K like you suggested? I'm thinking that way, we can get up to n=600K faster (so we don't have a huge gap in between the leading edge of Drive #3 and whatever drive does the n>600K testing). Not to mention that it will make things a little easier on us LLRnet server folks.

Thus, long story short, I vote that we keep 300<k<400 and 400<k<1001 separate, but try to generally keep them within n=50K or 100K of each other.
mdettweiler is offline   Reply With Quote
Old 2008-03-04, 19:53   #3
em99010pepe
 
em99010pepe's Avatar
 
Sep 2004

54168 Posts
Default

Quote:
Originally Posted by Anonymous View Post
I vote that we keep 300<k<400 and 400<k<1001 separate..
Me too.
em99010pepe is offline   Reply With Quote
Old 2008-03-04, 19:58   #4
henryzz
Just call me Henry
 
henryzz's Avatar
 
"David"
Sep 2007
Cambridge (GMT)

160F16 Posts
Default

i would say get 300-400 to catch up to 400-1000 and then maybe conbine at n=600k
i dont see any point in keeping them separate longer that we have to
henryzz is online now   Reply With Quote
Old 2008-03-04, 20:02   #5
Mini-Geek
Account Deleted
 
Mini-Geek's Avatar
 
"Tim Sorbera"
Aug 2006
San Antonio, TX USA

10AB16 Posts
Default

I think them being two separate drives is okay, but I think that the LLRnet servers shouldn't have a distinction (i.e. servers testing high ranges should reserve from both, as necessary to keep them at about the same n-level, not just from one or the other).
Mini-Geek is offline   Reply With Quote
Old 2008-03-04, 20:14   #6
mdettweiler
A Sunny Moo
 
mdettweiler's Avatar
 
Aug 2007
USA (GMT-5)

186916 Posts
Default

Quote:
Originally Posted by Mini-Geek View Post
I think them being two separate drives is okay, but I think that the LLRnet servers shouldn't have a distinction (i.e. servers testing high ranges should reserve from both, as necessary to keep them at about the same n-level, not just from one or the other).
Unfortunately ,that might be a bit of a hassle for the people involved in administrating the LLRnet servers; thus, I'm thinking that we should still have separate servers for the 300<k<400 and 400<k<1001 range.
mdettweiler is offline   Reply With Quote
Old 2008-03-04, 20:31   #7
em99010pepe
 
em99010pepe's Avatar
 
Sep 2004

2×5×283 Posts
Default

Quote:
Originally Posted by Mini-Geek View Post
I think them being two separate drives is okay, but I think that the LLRnet servers shouldn't have a distinction (i.e. servers testing high ranges should reserve from both, as necessary to keep them at about the same n-level, not just from one or the other).
Agree.


Quote:
Originally Posted by Anonymous View Post
Unfortunately ,that might be a bit of a hassle for the people involved in administrating the LLRnet servers; thus, I'm thinking that we should still have separate servers for the 300<k<400 and 400<k<1001 range.
False, it's very easy, you just need to keep adding more work independently of its type but always on the same base (2). One server only, not two but that's my humble and wise opinion. I keep saying that we don't have 100,000 cores but only 100 at our disposal. You people still don't get it?!? Time will give me reason because with the increase of the number of servers the idle ones will also increase, that happened with the CRUS servers, duh!
Sob only has one server, RieselSieve only one server, RS Base 5 two, PSP one...

Last fiddled with by em99010pepe on 2008-03-04 at 20:34
em99010pepe is offline   Reply With Quote
Old 2008-03-04, 20:46   #8
mdettweiler
A Sunny Moo
 
mdettweiler's Avatar
 
Aug 2007
USA (GMT-5)

11000011010012 Posts
Default

Quote:
Originally Posted by em99010pepe View Post
False, it's very easy, you just need to keep adding more work independently of its type but always on the same base (2). One server only, not two but that's my humble and wise opinion. I keep saying that we don't have 100,000 cores but only 100 at our disposal. You people still don't get it?!? Time will give me reason because with the increase of the number of servers the idle ones will also increase, that happened with the CRUS servers, duh!
Sob only has one server, RieselSieve only one server, RS Base 5 two, PSP one...
Okay. I wasn't as much thinking of hassles on the part of you or any of the other individual LLRnet server administrators, but instead more along the lines of the work I need to do to turn the LLRnet results files into contiguous lresults-format files. I could do it, but I was thinking it would be a little easier if we kept the two ranges on separate servers.

And yes, I have been keeping in mind our project's current resources--once your servers have been dried and shut down, NPLB shouldn't have any more than 3 servers at any given time. Thus, we shouldn't have the problem of idle servers, as long as we don't go over ~3 servers.
mdettweiler is offline   Reply With Quote
Old 2008-03-04, 23:44   #9
gd_barnes
 
gd_barnes's Avatar
 
May 2007
Kansas; USA

1008510 Posts
Default Instead, what makes a project FUN?! :-)

We'll get down to fewer servers eventually so let's set aside the server issue for the moment.

Instead, everyone let us know what makes for the most fun project of all!

The aim of this project intially was to search the ranges as quickly as possible. That quickly changed when I heard several people say that this was one the most fun projects they've been on. I believe that happened largely as a result of the rallies (Thanks Anon/Carlos for bringing those to NPLB!) but I think having sieved files readily available, a good scoring system, and prompt updates of all information on web pages, posts, etc. contributes a large part to that also.

So we've changed...instead of getting the ranges searched quickly, the objective is to keep it as the most fun project of all.

In throwing out the suggestion of not merging drives 1 and 3, keep in mind that if we get a small subset of the big range of k=300-1001 searched to n=600K and begin testing above that, there may be a couple of people here or even people that aren't currently interested that may become very interested if we are searching larger n-ranges. It would also help heavy hitters. With longer testing times, it would be less likely to crash servers.

Yes, many projects have only 1 server but many are BORING projects! I mean no offense to any of them at all because in particular SOB may be one of the best run projects this side of GIMPS. I just can't personally stomach 1000's of secs. per LLR test with virtually only one option of what to search. They just aren't fun to me. I want a project that is fun but is also going places.

If a project is fun for everyone, then people will want to search any and all ranges that we throw out there. And that was the original intent anyway so both objectives are accomplished and everyone has a blast!


Gary

Last fiddled with by gd_barnes on 2008-03-04 at 23:49 Reason: Add next-to-last para
gd_barnes is online now   Reply With Quote
Old 2008-03-06, 04:35   #10
gd_barnes
 
gd_barnes's Avatar
 
May 2007
Kansas; USA

5·2,017 Posts
Default

Quote:
Originally Posted by Mini-Geek View Post
I think them being two separate drives is okay, but I think that the LLRnet servers shouldn't have a distinction (i.e. servers testing high ranges should reserve from both, as necessary to keep them at about the same n-level, not just from one or the other).
Quote:
Originally Posted by Anonymous View Post
Unfortunately ,that might be a bit of a hassle for the people involved in administrating the LLRnet servers; thus, I'm thinking that we should still have separate servers for the 300<k<400 and 400<k<1001 range.

I think what you're both saying here is leading to close to the same thing. Anon, it WOULD be easy to administer if they were at the same n-level. It'd be no more difficult than k=400-1001; only with a few more candidates in each n-range. That was my original thinking but I started this thread to propose a different idea that I thought would be more fun.

I can conclude from this thread 3 things:

1. It's a virtual consensus to keep the drives separate for the time being so that's what we'll do. We can revisit the issue again later.

2. We're almost split on having separate severs for them, with Anon and I in favor of it and Carlos, Mini-geek, and henryzz against with some variations.


Let me throw out what we're looking at regarding servers as it relates to keeping the project fun:

Choice 1; one server:

If we only had one server but the drives were at different n-ranges, it would not be fun for the admins to manage, namely Karsten and Anon, and somewhat me on the back end. In the future, you'd have k=400-1001 candidates at n=400K mixed in with k=300-400 candiates at n=500K or higher. They would have to all be sorted out on the back end and it would be much more error prone. Also, you would not know what n-range your searching at any one time. I think it would be messy.

Choice 2; one server:

If we only had one server but the drives were at the same n-range, this would be very easy for the admins. but would have limited options for searches. We would have:
a. k=300-1001 somewhere around n=425K or so when the drives were able to merge.
b. k=300-400 for n>600K available for ~5-6 k's only that have been previously searched to n=600K. Since we only have the one server, this would have to be a manual-LLR range.


Choice 3; 2 servers:

a. One server for k=300-400 to LLR as quickly as possible to n=600K.
b. One server for k=400-1001 to continue as we are currently.
c. The server from a. changes over to k=300-400 n>600K for a full 50 k's when we reach that limit.

Choice 3 is easy to administer and gives more choices for everyone.

There's one more factor in all of this. The lower k-range of k=300-400 will LLR quite a bit faster at certain n-levels. This is virtually insificant now but will be much more so for n>600K.


My questions to all of you:

Which choice above causes the most people collectively to have fun on the project?

Do you have a better choice than any of the above?


Gary
gd_barnes is online now   Reply With Quote
Old 2008-03-06, 06:11   #11
mdettweiler
A Sunny Moo
 
mdettweiler's Avatar
 
Aug 2007
USA (GMT-5)

3×2,083 Posts
Default

I'm completely in favor of choice #3. That way, we avoid all headaches with administration completely, and give users plenty of flexibility for what to crunch (and hence the most fun IMO), yet without spreading our resources too thinly.

Just my $0.02.

Anon

Last fiddled with by mdettweiler on 2008-03-06 at 06:11
mdettweiler is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Move 19 game direction MooMoo2 Other Chess Games 8 2016-02-01 17:50
NPLB future direction gd_barnes No Prime Left Behind 16 2009-05-13 16:45
Opinions/Suggestions for Data Collection thread kar_bon No Prime Left Behind 19 2008-11-27 09:27
Future direction of NPLB gd_barnes No Prime Left Behind 33 2008-09-11 15:26
Opinions on team drive #3 gd_barnes Conjectures 'R Us 8 2008-01-24 01:01

All times are UTC. The time now is 10:23.

Tue Mar 31 10:23:42 UTC 2020 up 6 days, 7:56, 0 users, load averages: 2.00, 1.36, 1.20

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.