Short term goal

[IronBits]

Working fine now. It seems to have stalled for a bit.
jobMaxTime = 1 * 6 * 3600 -- 6 hours
prunePeriod = 1800 -- 30 min

8 cores full time over here until it is dry.

Port 7000 has 1302 lines in knpairs.txt
File size of 14,342
first k/n pair 743 264244
last k/n pair 797 264954

[gd_barnes]

Well, guys...I obviously had not read a large portion of this thread.

We do have a conflict here. In attempting to lead a project, there is a very fine line between allowing others to make decisions about the direction of the project and being a wishy-washy leader who is indecisive. I'm generally quite flexible and like others to be involved in the decision making process but there are times when a leader must step in and be firm about the direction of the project.

This is one of the tougher cases to make a decision about so let me spell out what I think is going on and should be done:

1. k=1003 is not in the scope of the original NPLB project.

2. Anon requested that it be done as a side effort but somehow it is getting mixed up in the same server with NPLB work. Do I have that correct? If so, I am against mixing the two on the same server.

3. IronBits had offered and/or Anon suggested in a CRUS thread that IronBits could host 100's of servers for individuals side efforts. This is an OUTSTANDING idea in my opinion BUT...read on...because it has to be managed appropriately.

What #3 effectively does is allow a single person to more easily handle their own k/n pairs. For instance at work, I have serveral cores manually running k=37/41/43/61/63 and I try to keep them synced up at the same testing range so that there are not gaps in testing. Inevitably someone turns one of the machines off at some point or some get more use than others. There is nothing I can do about this. If a machine is left off for a day, it causes that machine to get n=3K behind the others if left off for a day.

If I were running those machines on my own "personal IronBits server", there would be no gaps in testing because I would keep cache at 1 on all machines (except maybe 1-5 k/n pairs at times). Even if the machines run at different speeds (they're all 2.66 Ghz but invariably some are slightly faster than others), there would still be no gaps. That is what I want for such an effort.

This is a personal example that relates to what IronBits is offering and what Anon is attempting to do. So here is my opinion:

Picking k=1003 as inclusion for a sub-project of NPLB...good in 2 ways; not so good in 1 other. It's good because it's right by our range and good because frankly it's testing range is a mess; only consecutively tested to n=10K by yours truly. It's bad because it's probably already been tested to n=600K. It's good enough that I'm fine with it being tested through NPLB.

Any top-5000 primes found from it SHOULD be reported as NPLB simply because it is being worked on here as a 'quasi-extension' of this effort even if it is not an official one. For the same reason that RPS had the right to pick k's > 300 that were neither high-weight nor low-weight nor divisible by 15 and report them as RPS. Many were simply logical extensions of their effort there.

So I think running k=1003 on IronBits server is a resonable idea and a logical extension of NPLB BUT we have to rein it in this manner:

1. It cannot be run on the same server as an 'official' NPLB effort.

2. A separate thread should be created for 'personal IronBits server' efforts.

3. A subproject of NPLB is to 'catch up' k's that are behind in testing. Any k's outside of k=300-1001 should probably be discussed publicly ahead of time. Exceptions should be made to this in cases where the k's are 'sensitive and problematic', usually due to dormant reservations and the like. Many times in those cases, it's best to discuss them privately. In the case of k=1003, that should probably be discussed publicly because it has no reservation and is clearly full of unknown testing gaps.


Based on all of this, I think this is what we need for k=1003:

1. Anon, please create a separate thread for testing of this k and any related server work that is needed for it.

2. Anon, please make sure that any related k/n pairs are kept in a separate server.

3. Whoever starts an effort like this, it is their responsibility to match up the original sieved file for all k/n pairs on the results file of the server. Anon, that would be you here. Please get the sieved file back from IronBits so that you have it for future matching.

4. I suggest NOT listing the server in our list of servers for NPLB. I do not want to create any more work for Karsten. The server info. should just be kept in the separate thread for such efforts.

5. There would be no scoring for such efforts. This can be revisited at a later time. If we collectively as a team decide to take up a group of k's < 300 or > 1001, then we can discuss possible scoring at that time. Once again, this would require some new and different scoring calculations.


And finally...no, I do not think Anon is taking on too many efforts for his smaller resources. I initially thought that might be the case but I have found it not to be. Yes, he takes on lots of efforts for his resources but he always completes what he starts and provides detailed info. and/or accurate results as requested by the projects that he is doing the work for. That is all that I ask of anyone, regardless of their size of resources.

My personal tolerance on this project for people completing what they reserve is about 4-6 weeks due to the aggressive goals that we have. On CRUS, they can take as long as they want as long as status reports are received every 1-2 months and they are progressing. That's just me because as everyone knows, I like to keep all phases of projects moving ahead on all cylinders where possible. If someone is biting off more than they can chew, I'll let them know about it pretty quickly as Jasong found out.



Gary

[IronBits]

I was trying to say I have the resources to help you with running Servers/Ports here.
YOU just need to tell me what you need, when and which port and as soon as I get the knpairs.txt to put up, it will be running.
It would be nice to have *official* project ports that remain constant and busy.
Occasionally to have a clean up port created and everyone hitting it is fine to.
I really don't want to be a personal proxy server...

[em99010pepe]

crus.dynip.telepac.pt port 300 has less than 2000 pairs. What should I do? Add more work or dry it...

I prefer to dry it because I want to upgrade the server to a quad-core machine.
kar_bon, Flatlander and Free-DC_Helix-Von-Smelix, pay attention to your clients. I suggest to move the cores to:
NPLB LLRnet server #3:
maintained by Adam Sutton (AES)
server = "nplb.rieselprime.org"
port = 300
current range: 401 <= k <= 1001, n = ~ 396.4k (upto 400k ~ 41,000 pairs)
Stats: http://nplb.rieselprime.org/stats/stats.php?a=reset

Carlos

[mdettweiler]

Originally Posted by IronBits

I was trying to say I have the resources to help you with running Servers/Ports here.
YOU just need to tell me what you need, when and which port and as soon as I get the knpairs.txt to put up, it will be running.
It would be nice to have *official* project ports that remain constant and busy.
Occasionally to have a clean up port created and everyone hitting it is fine to.
I really don't want to be a personal proxy server...

Okay, that sounds good. I only suggested the idea of running personal servers for people in response to your musings about what to do with 100's of available ports left. But if you'd rather not do that, that's fine with me.

[IronBits]

7000 is dry.
jobList = {
}
nothing in knpairs.txt

[mdettweiler]

Originally Posted by em99010pepe

crus.dynip.telepac.pt port 300 has less than 2000 pairs. What should I do? Add more work or dry it...

Carlos

Your call. I guess it hinges on one question: do you want to get out of the LLRnet server business like you previously have indicated, or would you like to keep on hosting the port 300 server? If you'd rather dry it, that won't be a problem, as we have Adam's port 300 server doing the same range (currently as a backup, though it could become a primary server if need be), and if we needed to I'm sure IronBits would be glad to set up a server for the 1st Drive. But, as I was saying, it's completely your call.

[mdettweiler]

Originally Posted by IronBits

7000 is dry.
jobList = {
}
nothing in knpairs.txt

Are you serious? Oh man, I guess that means all 1050 of the k/n pairs I have my manual cores working on have been expired! *hits head* Duh, I should have used the "normal" LLRnet method since the server was this close to being dried out. (I hadn't expected it to dry out so fast!)

[em99010pepe]

Originally Posted by Anonymous

Are you serious? Oh man, I guess that means all 1050 of the k/n pairs I have my manual cores working on have been expired! *hits head* Duh, I should have used the "normal" LLRnet method since the server was this close to being dried out. (I hadn't expected it to dry out so fast!)

Don't ever download such amount of work before asking the host of the server its settings ( jobMaxTime, etc...)

[mdettweiler]

Originally Posted by gd_barnes

...

Based on all of this, I think this is what we need for k=1003:

1. Anon, please create a separate thread for testing of this k and any related server work that is needed for it.

2. Anon, please make sure that any related k/n pairs are kept in a separate server.

Well, actually, I don't really need any help on k=1003 (it's quite low-weight, so it's relatively easy for someone with few resources like me), though of course it would be nice. What would really be a good subproject for us, though, is to do all of 1003<k<1500. That whole range is all just as messy as k=1003 is in regard to testing ranges--it's only known to be tested contiguously to n=10K, though there are a bunch of already-found top-5000 primes.

I suggest that we do a team sieve (sort of like the doublecheck sieving effort; I'm sure that there are some users out there who prefer sieving to LLRing, and would be glad to help out) for 1003<k<1500 (actually, we'd leave out k=1003 since I've already got it sieved to n=500K), 10K<n<400K. Then, we can LLR it as a separate team drive (though we could make a note that it is lower priority than the main NPLB ranges).

3. Whoever starts an effort like this, it is their responsibility to match up the original sieved file for all k/n pairs on the results file of the server. Anon, that would be you here. Please get the sieved file back from IronBits so that you have it for future matching.

Actually, I was able to get my original sieve file for that range back by simply redownloading the file that I had posted here as an attachment for IronBits. (IronBits also sent me the k/n pairs by email that he had removed from the server.) So, no problem there.

4. I suggest NOT listing the server in our list of servers for NPLB. I do not want to create any more work for Karsten. The server info. should just be kept in the separate thread for such efforts.

5. There would be no scoring for such efforts. This can be revisited at a later time. If we collectively as a team decide to take up a group of k's < 300 or > 1001, then we can discuss possible scoring at that time. Once again, this would require some new and different scoring calculations.

Okay, that sounds good.

Any opinions?

[mdettweiler]

Originally Posted by em99010pepe

Don't ever download such amount of work before asking the host of the server its settings ( jobMaxTime, etc...)

I had assumed (wrongly) that it was at 3 days or more, like IronBits' other servers. You're right, I should have asked--and I should have considered the possibility that the server could be dried as quickly as it was.