NPLB LLRnet server discussion
 

Note by Anonymous: This thread, originally called "NPLB LLRnet server testing?!", has been renamed to "NPLB LLRnet server discussion" now that it's out of the testing phase. :smile:
----------------------------
Should I set up one?

Carlos

i think a good reason for a NPLB-LLRnet-server could be:

- a/some very high k-values so 'normal' testfiles become smaller for everyone

- doublecheck effort for k's to complete the check Gary startet last year and many errors were found

- beginning testing range n>600k for some k's, for example 300<k<400.

more opinions?

[quote=em99010pepe;124411]Should I set up one?
Carlos[/quote]

Yes, go for it. We'll decide what to put on it after getting more input in this thread.

[quote=kar_bon;124430]i think a good reason for a NPLB-LLRnet-server could be:

- a/some very high k-values so 'normal' testfiles become smaller for everyone

- doublecheck effort for k's to complete the check Gary startet last year and many errors were found

- beginning testing range n>600k for some k's, for example 300<k<400.

more opinions?[/quote]

What does everyone think of the current file sizes? Too big; too small; or just right? I can certainly reduce them at any point. I have not checked when the next fftlen change is but we haven't encountered one yet (since n=333.3K) with the last range that I reserved for n>340K. An fftlen change would be a natural point to decrease the file sizes. I'm sure there was one between n=260K-333.3K due to the significant timing difference.

Also, if one file is too big for anyone's resources, I'll be glad to split it up for him. Just tell me you're taking "half of 3500-3502". We'll show you as reserving 3500-3501 and leave 3501-3502 for someone else. I'm sure most people won't mind picking up an n=100 range 'left-over' file here-and-there.

I would like to avoid the tendency to split various k-ranges up much. What makes this effort "maintenance-friendly" is not having many small side-efforts going or too many drives going. Coming up in early March, I would like to start a team drive 3 for 300<k<400 for n=260K-600K while still allowing for individual-k reservations in that range. Sieving will continue on the k-range for n=600K-1M both for individual-k reservations for k's that have already been searched to n=600K and for perhaps a team drive 4 later on for the k's that have not been.

Karsten, this goes back to something you mentioned to me in a PM when I asked for your input on goals about 300<k<400. You said it would be too much hassle to have 2 more drives, one each for n=260K-333K and 333K-600K, and I agreed.

Please know, though, that I'm open to all input. If a majority of people would like to split off the higher k's; perhaps 800<k<=1001 to make the files smaller, then I'll be glad to do that. If the majority are happy, the project prospers.

On what to put on the LLRNet server, can we set up 2 of them, one for each drive? For drive 1, load up ~n=2K or so (10 files) at a time. For drive 2, load up about ~n=1K (5 files) at a time (more or less; you guys who have run servers would know the best amount). When the server is down to 1-2 files left, then take 5 or 10 more files. This allows for both non-server and server reservations so that everyone can join in the fun!

If we have only 1 of them, I'm somehwat undecided. Should they be drive 1 files because they are more popular or drive 2 files because they are less so? What do people think? I lean slightly towards the less-popular files because you can just let your computer 'pick up' the work and not mess with loading up less interesting files.

Using the server for double-checking is an excellent idea. For everyone's info., Anon and I double-checked all 300<k<=1001 up to n=100K in 2007. We found about a 2% error-rate in this range :sad::surprised; ~90% was missing primes and the rest were incorrect primes or simply composites. One was a PROTH prime! :surprised Anyway...we decided shortly after that was done that n=100K-260K needed to be double-checked also. Since then, Anon has started sieving n=100K-260K in the last 3 months.

My question on using a server for double-checking would be: Would anyone use it much? Also, we don't have a sieved file ready yet for n=100K-260K and sieving 300<k<400 for n>260K is clearly higher priority at this point to get as many primes on top-5000 for n>333.3K for historical reference before they start dropping off.

So in answer to what the best thing to put on ONE server right now, IMHO that would be drive 2 files followed closely by drive 1 files with the possibility of puting double-check files for n=100K-260K after that range has been properly sieved.


Gary

[quote=gd_barnes;124439]Yes, go for it. We'll decide what to put on it after getting more input in this thread.[/quote]
I'd be glad to be the 'go-between' in charge of reserving the files, processing the results, etc, like I am at CRUS--I've already got all the scripts set up for converting LLRnet results files to conventional lresults files and so forth. :smile:
[quote]What does everyone think of the current file sizes? Too big; too small; or just right? I can certainly reduce them at any point. I have not checked when the next fftlen change is but we haven't encountered one yet (since n=333.3K) with the last range that I reserved for n>340K. An fftlen change would be a natural point to decrease the file sizes. I'm sure there was one between n=260K-333.3K due to the significant timing difference.[/quote]
The one that I've processed (for the 2nd drive) seemed to be pretty good size-wise--but I can't speak for the 1st drive, since I haven't done anything for it yet. :smile:

[quote]Also, if one file is too big for anyone's resources, I'll be glad to split it up for him. Just tell me you're taking "half of 3500-3502". We'll show you as reserving 3500-3501 and leave 3501-3502 for someone else. I'm sure most people won't mind picking up an n=100 range 'left-over' file here-and-there.

I would like to avoid the tendency to split various k-ranges up much. What makes this effort "maintenance-friendly" is not having many small side-efforts going or too many drives going. Coming up in early March, I would like to start a team drive 3 for 300<k<400 for n=260K-600K while still allowing for individual-k reservations in that range. Sieving will continue on the k-range for n=600K-1M both for individual-k reservations for k's that have already been searched to n=600K and for perhaps a team drive 4 later on for the k's that have not been.

Karsten, this goes back to something you mentioned to me in a PM when I asked for your input on goals about 300<k<400. You said it would be too much hassle to have 2 more drives, one each for n=260K-333K and 333K-600K, and I agreed.

Please know, though, that I'm open to all input. If a majority of people would like to split off the higher k's; perhaps 800<k<=1001 to make the files smaller, then I'll be glad to do that. If the majority are happy, the project prospers.

On what to put on the LLRNet server, can we set up 2 of them, one for each drive? For drive 1, load up ~n=2K or so (10 files) at a time. For drive 2, load up about ~n=1K (5 files) at a time (more or less; you guys who have run servers would know the best amount). When the server is down to 1-2 files left, then take 5 or 10 more files. This allows for both non-server and server reservations so that everyone can join in the fun![/quote]
That's what I was thinking--just like it's done at CRUS. It seems to work well there, so it should work well here.

[quote]If we have only 1 of them, I'm somehwat undecided. Should they be drive 1 files because they are more popular or drive 2 files because they are less so? What do people think? I lean slightly towards the less-popular files because you can just let your computer 'pick up' the work and not mess with loading up less interesting files.[/quote]
I would agree--people might be more willing to search the lower ranges if it's balanced with the added convenience of LLRnet. Of course that would only work if there wasn't a separate server for the 1st drive (because if there was, that would negate any such advantage, with the 1st drive having the LLRnet convenience, too).

[quote]Using the server for double-checking is an excellent idea. For everyone's info., Anon and I double-checked all 300<k<=1001 up to n=100K in 2007. We found about a 2% error-rate in this range :sad::surprised; ~90% was missing primes and the rest were incorrect primes or simply composites. One was a PROTH prime! :surprised Anyway...we decided shortly after that was done that n=100K-260K needed to be double-checked also. Since then, Anon has started sieving n=100K-260K in the last 3 months.[/quote]
I've only sieved the file to p=2G; I'd be able to do more, but volunteers for sieving are highly welcome, as I only have one machine (Core 2 Duo 2.2Ghz, but only on during the day for the most part) available for crunching. :smile: I was considering opening it up to the public with a reservation thread, but for a job this small, it might just be better to have somebody with an always-on machine do the job themselves. It should only take a week or two, running 24/7.

[quote]My question on using a server for double-checking would be: Would anyone use it much? Also, we don't have a sieved file ready yet for n=100K-260K and sieving 300<k<400 for n>260K is clearly higher priority at this point to get as many primes on top-5000 for n>333.3K for historical reference before they start dropping off.[/quote]
I imagine people would work for a doublecheck server. At Riesel Sieve, they used to have a second LLRnet server for doublechecks, and from what I can tell from the forums it got a decent amount of "business". (Since then the LLRnet server for doublechecking has been replaced by their BOINC server, which now handles all doublechecks exclusively.)
[quote]So in answer to what the best thing to put on ONE server right now, IMHO that would be drive 2 files followed closely by drive 1 files with the possibility of puting double-check files for n=100K-260K after that range has been properly sieved.[/quote]
Agreed. :smile:

Before starting here a new server I need to dry out CRUS servers. This follows my intention to rename the server path. Which name should I give to the server for both projects?

[B][COLOR=SeaGreen]something.dynip.telepac.pt

[/COLOR][/B]Post your suggestions...
[B][/B]Carlos

[quote=em99010pepe;124544]Before starting here a new server I need to dry out CRUS servers. This follows my intention to rename the server path. Which name should I give to the server for both projects?

[B][COLOR=SeaGreen]something.dynip.telepac.pt

[/COLOR][/B]Post your suggestions...
Carlos[/quote]
Hmm...would it be possible just to have two different domain names pointing to the same server? Then we could have both "crus.dynip.telepac.pt" and "nplb.dynip.telepac.pt" (or whatever may be chosen for NPLB). That would be MUCH better than drying out the CRUS servers--which would be a little hard considering that both servers have more than 10K worth of numbers loaded into them right now. :smile:

Or, if it wouldn't be possible to have two domain names pointing to the same server, you can simply leave the name as "crus.dynip.telepac.pt" for both projects--I don't think anybody will mind. :smile:

[quote=Anonymous;124545]

Or, if it wouldn't be possible to have two domain names pointing to the same server, you can simply leave the name as "crus.dynip.telepac.pt" for both projects--I don't think anybody will mind. :smile:[/quote]

That's the case...If I move all my cores I can dry the servers in no time...

[quote=em99010pepe;124547]That's the case...If I move all my cores I can dry the servers in no time...[/quote]
Hmm...well, okay, I guess that sounds good if it entails you moving all your cores over to CRUS LLRnet! :wink:

Okay, let's do that. :smile: In the meantime, I suggest "crus-nplb.dynip.telepac.pt". Maybe not too imaginative, but I can't think of much else. :smile:

Edit: You could also register for free dynamic DNS at no-ip.com or dyndns.com, and simply run that dynamic DNS client on your server in addition to whatever else is running there to provide the existing dynamic DNS--then both domains would point to the same server. But then you wouldn't have to move all your cores to CRUS LLRnet to clean it out. :wink:

If you need mersenneforum redirects we can do those.

crus.mersenneforum.org -> ?
nplb.mersenneforum.org -> ?

[quote=Xyzzy;124560]If you need mersenneforum redirects we can do those.

crus.mersenneforum.org -> ?
nplb.mersenneforum.org -> ?[/quote]
They'd need to work with a dynamic IP--maybe you could have it forward to a dynamic DNS address such as nplb.no-ip.com or something like that?

[quote]They'd need to work with a dynamic IP--maybe you could have it forward to a dynamic DNS address such as nplb.no-ip.com or something like that?[/quote]That would work.