mersenneforum.org  

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

Reply
 
Thread Tools
Old 2008-03-06, 13:09   #12
Mini-Geek
Account Deleted
 
Mini-Geek's Avatar
 
"Tim Sorbera"
Aug 2006
San Antonio, TX USA

17·251 Posts
Default

I'm okay with Choice 3, but prefer Choice 2.
I guess it really wouldn't matter all that much if people that want to use LLRnet have to choose whether it's k=300-400 or 400-1001. Would it be easier to administrate 3?
I just think that if you don't want to go through the trouble of manual reservations, you wouldn't really care what the k is. It's more complicated to have separate servers, making new people less interested IMHO. Unfortunately, 2 does limit the options for people who run LLRnet and want to choose.

BTW I think Choice 1 is pretty bad for both the back-end people and clients...why was it even there, other than to make it look like we have more than 2 options?
Mini-Geek is offline   Reply With Quote
Old 2008-03-06, 16:02   #13
mdettweiler
A Sunny Moo
 
mdettweiler's Avatar
 
Aug 2007
USA (GMT-5)

3×2,083 Posts
Default

Quote:
Originally Posted by Mini-Geek View Post
I'm okay with Choice 3, but prefer Choice 2.
I guess it really wouldn't matter all that much if people that want to use LLRnet have to choose whether it's k=300-400 or 400-1001. Would it be easier to administrate 3?
I just think that if you don't want to go through the trouble of manual reservations, you wouldn't really care what the k is. It's more complicated to have separate servers, making new people less interested IMHO. Unfortunately, 2 does limit the options for people who run LLRnet and want to choose.

BTW I think Choice 1 is pretty bad for both the back-end people and clients...why was it even there, other than to make it look like we have more than 2 options?
I see where you're coming from--but I beg to differ as to it being more complicated with 3 servers rather than 2. In fact, we currently have way more than 3 servers (though of course we're trying to clean up some of them), so 3 servers should be a piece of cake for us back-end folks.

Also, please keep this in mind: since 300<k<400 and 400<k<1001 are going to be separate on the team drive end, it would be a huge mess to try to run them together with LLRnet. It may not look like that at first, but imagine this scenario: Files are merged to make a big 300<k<1001 file for LLRnet. LLRnet crunches it, all fine and dandy. But then when the results files are sent to me, and I have to process them and report them on the respective drive threads...how do I do it? Do I sit at a text editor for 12 hours a day sorting 300<k<400 from 400<k<1001? Conversely, you could keep the results files for both ranges together when dealing with LLRnet, but then we'd have to worry about having the two results files intermingled.

Long story short, I can foresee both choice #1 and #2 becoming hugely messy (though #2 slightly less than #1). To me, the logical way to go seems to be choice #3, since we don't have to worry about any mess (since we won't be putting files from more than one team drive together in the same server at the same time), it would still be quite easy to administrate, and as a side benefit we offer LLRnet users a full gamut of numbers to crunch.
mdettweiler is offline   Reply With Quote
Old 2008-03-06, 16:14   #14
gd_barnes
 
gd_barnes's Avatar
 
May 2007
Kansas; USA

276516 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 Mini-Geek View Post
BTW I think Choice 1 is pretty bad for both the back-end people and clients...why was it even there, other than to make it look like we have more than 2 options?
It was there because I inferred that from your original suggestion shown first here. That is, having two separate drives but having server(s) reserve from both. To me, that implies we have 2 drives that are at 2 different testing limits with 1 or 2 (not sure which) LLRnet server(s) not having a distinction and pulling from both drives.

Can you be more specific about what you are impling by your original suggestion? i.e... 2 servers or 1? Drives at the same n-range or not?

If the 2 drives are at the same n-range, we may as well only have one server. If not, I think we need 2 servers for administrative reasons.


Gary
gd_barnes is offline   Reply With Quote
Old 2008-03-06, 16:30   #15
gd_barnes
 
gd_barnes's Avatar
 
May 2007
Kansas; USA

5×2,017 Posts
Default

Quote:
Originally Posted by Anonymous View Post
Long story short, I can foresee both choice #1 and #2 becoming hugely messy (though #2 slightly less than #1). To me, the logical way to go seems to be choice #3, since we don't have to worry about any mess (since we won't be putting files from more than one team drive together in the same server at the same time), it would still be quite easy to administrate, and as a side benefit we offer LLRnet users a full gamut of numbers to crunch.
No...no...

Choice 2 would be very clean and easy! Actually the easiest of all but IMHO, make for a more BORING project!

When I said we would merge the DRIVES, I mean that drive 3 would be completely eliminated (actually just completed). There would be no worrying about separating primes/results between the 2 drives. Drive 3 becomes kind of like drive 2 in that it has a specifically defined upper limit (to be determined later).

Upon merging of the drives, there will be a little bit of scoring hassle/setup from Karsten's perspective. We'd probably need to score the 'combined drive' ranges 7/6ths times as much since it would be 7/6ths times as many k's. But we would anticipate that by deciding a specific n-limit that the drives were to merge at so that Karsten would have a very defined rule as to when the scoring changes.

The scoring issue is just a one-time hassle. After that, it would be extremely easy.

Bottom line...

If everyone is looking for easy to administer and understand, choose option 2. Ultimately, we'd need only 1 server total on the project. One to search k=300-1001 up to n=600K. Optionally, we could have a 2nd server to search the few k's for k=300-400 (~5-6 of them) for n>600K that have already been searched that high.

If everyone is looking for more choices and IMHO more fun, choose option 3. Ultimately, we'd need 2 total servers on the project. One for k=300-400 and one for k=400-1001. When k=300-400 completes to n=600K, we'd just load the higher range into the k=300-400 server. No need for a 3rd server except for backup (which is probably a good idea).

I think we're really down to 2 main reasonable choices here. Perhaps I should take a poll on this but I have another question: Should I take a poll to see if I should take a poll? LMAO


Gary

Last fiddled with by gd_barnes on 2008-03-06 at 16:32
gd_barnes is offline   Reply With Quote
Old 2008-03-06, 17:25   #16
mdettweiler
A Sunny Moo
 
mdettweiler's Avatar
 
Aug 2007
USA (GMT-5)

3×2,083 Posts
Default

Quote:
Originally Posted by gd_barnes View Post
No...no...

Choice 2 would be very clean and easy! Actually the easiest of all but IMHO, make for a more BORING project!

When I said we would merge the DRIVES, I mean that drive 3 would be completely eliminated (actually just completed). There would be no worrying about separating primes/results between the 2 drives. Drive 3 becomes kind of like drive 2 in that it has a specifically defined upper limit (to be determined later).

Upon merging of the drives, there will be a little bit of scoring hassle/setup from Karsten's perspective. We'd probably need to score the 'combined drive' ranges 7/6ths times as much since it would be 7/6ths times as many k's. But we would anticipate that by deciding a specific n-limit that the drives were to merge at so that Karsten would have a very defined rule as to when the scoring changes.

The scoring issue is just a one-time hassle. After that, it would be extremely easy.

Bottom line...

If everyone is looking for easy to administer and understand, choose option 2. Ultimately, we'd need only 1 server total on the project. One to search k=300-1001 up to n=600K. Optionally, we could have a 2nd server to search the few k's for k=300-400 (~5-6 of them) for n>600K that have already been searched that high.

If everyone is looking for more choices and IMHO more fun, choose option 3. Ultimately, we'd need 2 total servers on the project. One for k=300-400 and one for k=400-1001. When k=300-400 completes to n=600K, we'd just load the higher range into the k=300-400 server. No need for a 3rd server except for backup (which is probably a good idea).

I think we're really down to 2 main reasonable choices here. Perhaps I should take a poll on this but I have another question: Should I take a poll to see if I should take a poll? LMAO


Gary
Ah, I see what you mean. I thought you were talking about having the drives separate, but with LLRnet reserving ranges from both that would be merged together (which would be quite messy). Sorry, my fault for misunderstanding you.

With that in mind, as for my opinion on whether we should do choice #2 or #3--I'll still vote for #3. As you said, it makes for a much more fun and interesting project--and hey, isn't that what our goal is now? Thus, #3 is the logical choice.

As for whether we should take a poll--how about we do a poll if we don't come to a clear consensus here?
mdettweiler is offline   Reply With Quote
Old 2008-03-06, 17:33   #17
henryzz
Just call me Henry
 
henryzz's Avatar
 
"David"
Sep 2007
Cambridge (GMT)

130178 Posts
Default

i was looking for an easy solution i think if people are will to spend the extra effort on 3 then do 3 i am fine with that
henryzz is offline   Reply With Quote
Old 2008-03-06, 18:02   #18
Flatlander
I quite division it
 
Flatlander's Avatar
 
"Chris"
Feb 2005
England

31·67 Posts
Default

Choice no. 3 is my preference.
Flatlander is offline   Reply With Quote
Old 2008-03-06, 19:57   #19
gd_barnes
 
gd_barnes's Avatar
 
May 2007
Kansas; USA

1008510 Posts
Default

Carlos, Karsten, any others? What do you think of us working towards the following:

1. k=300-400 with one server as we have currently.

2. k=400-1001 with one server after lower ranges are filled in.

3. When drive 2 completes, the servers for it will be eliminated with a possible exception of putting one server temporarily on the higher ranges of the double-check effort.

4. At least one server as backup that does no work except temporarily in 2 situations:
(a) One of our main 2 servers needs an upgrade or goes down for a period of time for whatever reason.
(b) We anticipate an unusually heavy load on one of the 2 servers such as during a rally where Beyond or another person with large resources wants to participate.

The bottom line is that after completing drive 2 and the double-check effort, it should only be very rarely that we're running more than 2 servers.

An option for WHO on the servers: I'm thinking IronBits' for our main 2 servers on both drives with Adam or possibly Carlos or BlisteringSheep 'on call' as backup servers in case we need another temporarily. In other words, they would only run work in 'emergency' situations.


Gary

Last fiddled with by gd_barnes on 2008-03-06 at 19:58
gd_barnes is offline   Reply With Quote
Old 2008-03-06, 20:14   #20
Beyond
 
Dec 2002

22·3·37 Posts
Default

2 servers max, and as for the servers the old adage "dance with the one that brung ya" comes to mind.
Beyond is offline   Reply With Quote
Old 2008-03-06, 21:08   #21
Mini-Geek
Account Deleted
 
Mini-Geek's Avatar
 
"Tim Sorbera"
Aug 2006
San Antonio, TX USA

102538 Posts
Default

Quote:
Originally Posted by Anonymous View Post
I see where you're coming from--but I beg to differ as to it being more complicated with 3 servers rather than 2. In fact, we currently have way more than 3 servers (though of course we're trying to clean up some of them), so 3 servers should be a piece of cake for us back-end folks.
Actually, I was referring to "Choice 3", not "3" as in "3 servers".
Quote:
Originally Posted by gd_barnes View Post
It was there because I inferred that from your original suggestion shown first here. That is, having two separate drives but having server(s) reserve from both. To me, that implies we have 2 drives that are at 2 different testing limits with 1 or 2 (not sure which) LLRnet server(s) not having a distinction and pulling from both drives.

Can you be more specific about what you are impling by your original suggestion? i.e... 2 servers or 1? Drives at the same n-range or not?

If the 2 drives are at the same n-range, we may as well only have one server. If not, I think we need 2 servers for administrative reasons.


Gary
My suggestion was one "logical" (defined later) server with drives at the same n-range. My confusing wording came from that I was picturing one "logical", if you will, server, which may be made up of multiple physical servers (i.e. multiple servers reserving the same sort of things and effectively acting as one).

I currently think #2 and #3 are good, with a slight preference to #2 (less of a preference to it than before, after reading posts since my last one).
Mini-Geek is offline   Reply With Quote
Old 2008-03-06, 23:51   #22
kar_bon
 
kar_bon's Avatar
 
Mar 2006
Germany

1010110011002 Posts
Default

i prefer 2 servers too.
one for 300<k<400 and 400<k<1002 each.
so it's the easiest way to switch around and the best way for admins to manage and for Anon/me to evaluate the results.
kar_bon 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:51.

Tue Mar 31 10:51:12 UTC 2020 up 6 days, 8:24, 0 users, load averages: 1.50, 1.21, 1.15

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.