Opinions wanted on direction of drive 3

[Mini-Geek]

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?

[mdettweiler]

Originally Posted by Mini-Geek

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.

[gd_barnes]

Originally Posted by Mini-Geek

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

Originally Posted by Mini-Geek

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]

Originally Posted by Anonymous

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

[mdettweiler]

Originally Posted by gd_barnes

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?

[henryzz]

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

[Flatlander]

Choice no. 3 is my preference.

[gd_barnes]

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

[Beyond]

2 servers max, and as for the servers the old adage "dance with the one that brung ya" comes to mind.

[Mini-Geek]

Originally Posted by Anonymous

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

Originally Posted by gd_barnes

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

[kar_bon]

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.