LLRnet servers for NPLB

[mdettweiler]

I was processing the results for IB8500 just now, when I found that there were ~5000 missing results! Most likely this is due to the little mix-up we had earlier with results; I checked in the results files for all the other servers that they could have possibly been misdirected to, but didn't find anything. So, it looks like those results are gone for good--they'll need to be reprocessed.

I'm going to email these to IronBits to be loaded into a temporary server shortly; to avoid confusion, I'll suggest that the server be on nplb.ironbits.net port 9000, rather than the original llrnet.no-ip.info port 8500.

[gd_barnes]

Originally Posted by IronBits

for llrnet and nplb servers
jobMaxTime = 3 * 24 * 3600 -- 3 days

for crus port 6
jobMaxTime = 14 * 24 * 3600 -- 14 days

Is 3 days the limit for all NPLB servers now? If so, great! Let's go with that.

For CRUS port 6, let's change that to 7 days. I can think of no reason to have it longer, even for a GIMPS-sized test, which takes ~1 day to test.


Thanks,
Gary

[gd_barnes]

Originally Posted by Anonymous

I was processing the results for IB8500 just now, when I found that there were ~5000 missing results! Most likely this is due to the little mix-up we had earlier with results; I checked in the results files for all the other servers that they could have possibly been misdirected to, but didn't find anything. So, it looks like those results are gone for good--they'll need to be reprocessed.

I'm going to email these to IronBits to be loaded into a temporary server shortly; to avoid confusion, I'll suggest that the server be on nplb.ironbits.net port 9000, rather than the original llrnet.no-ip.info port 8500.

Ugh! I hope we finally have these results issues fixed. It's very possible that those k/n pairs were never processed. That's what I'm hoping. That could be a partial explanation for the huge primeless gap for port 8500.

When IronBits gets port 9000 set up and the file loaded in, I'll redirect all of my port 300 resources at it (22 cores) until it's dry.

On another note, did Beyond say that he was done with n=486K-496K? I thought he did. If so, there was a large primeless gap for n=~493K-496K there too. I realize primes get less as n-values rise but these huge primeless gaps we've been having on several different ranges at once are much more than that. Bleh!

I hope that all/most of the results have been processed on port 300 for n=478K-485K.


Gary

[mdettweiler]

Originally Posted by gd_barnes

Is 3 days the limit for all NPLB servers now? If so, great! Let's go with that.

For CRUS port 6, let's change that to 7 days. I can think of no reason to have it longer, even for a GIMPS-sized test, which takes ~1 day to test.


Thanks,
Gary

About changing the port 6 time to 7 days: actually, I thought that's what it was already. (Port 4, on the contrary, was set to 14 days because of its larger numbers.)

One correction I must make, though: you said that a GIMPS-sized test only takes ~1 day to test. Actually, the leading edge of GIMPS tests consists of exponents taking upwards of a month apiece on a fast machine. Doublechecks are about 5 days to a week depending on the exact range.

[mdettweiler]

Originally Posted by gd_barnes

Ugh! I hope we finally have these results issues fixed. It's very possible that those k/n pairs were never processed. That's what I'm hoping. That could be a partial explanation for the huge primeless gap for port 8500.

When IronBits gets port 9000 set up and the file loaded in, I'll redirect all of my port 300 resources at it (22 cores) until it's dry.

On another note, did Beyond say that he was done with n=486K-496K? I thought he did. If so, there was a large primeless gap for n=~493K-496K there too. I realize primes get less as n-values rise but these huge primeless gaps we've been having on several different ranges at once are much more than that. Bleh!

I hope that all/most of the results have been processed on port 300 for n=478K-485K.


Gary

Yes, Beyond sent me the results for 486K-496K sometime while I was away. I'll try to get them processed today.

As for port 300's 478K-485K, according to the http://nplb.rieselprime.org home page, there are at least a few unprocessed results in that range. I can process the incomplete results, and then find out the exact number of unprocessed results--I'll see about doing that later today when I process Beyond's results.

[gd_barnes]

Originally Posted by Anonymous

About changing the port 6 time to 7 days: actually, I thought that's what it was already. (Port 4, on the contrary, was set to 14 days because of its larger numbers.)

One correction I must make, though: you said that a GIMPS-sized test only takes ~1 day to test. Actually, the leading edge of GIMPS tests consists of exponents taking upwards of a month apiece on a fast machine. Doublechecks are about 5 days to a week depending on the exact range.

What the world was I smoking? Aw, one day vs. one month, what the heck's the difference? lol Obviously a very poor example. I knew it was a month because I tested one for them.

If I remember right, if you're lucky enough to get an exponent left over that's right near a 10M digit number, you can test it in 20 days with the newer faster machines. But for n>40M, I'm sure the newer machines would need a month.

Assuming that port 6 is at 7 days, I'm wondering now if we shouldn't just make it 3 days also. Even if testing times approach 1 hour, which they haven't yet, 3 days should be sufficient. I'll broach the subject at CRUS.


Gary

[gd_barnes]

Originally Posted by Anonymous

Yes, Beyond sent me the results for 486K-496K sometime while I was away. I'll try to get them processed today.

As for port 300's 478K-485K, according to the http://nplb.rieselprime.org home page, there are at least a few unprocessed results in that range. I can process the incomplete results, and then find out the exact number of unprocessed results--I'll see about doing that later today when I process Beyond's results.

OK cool on Beyond's range.

Unless you really want to, don't waste time messing with n=478K-485K right now. Wait until 3 days after when it started handing out pairs for n>485K or when you see 'active minimum n' is n>485K. There's no use for you to waste your time on it until we wait for any outstanding k/n pairs to get tested or returned to the server for testing.


Gary

[IronBits]

Ok, it's back up, but on port 8500

9000 is a CSlistner / Transmission Control Protocol and would not work here.

8500 is not being used anyways and that's where it came from, so, back on it again until it's finished.
I can't believe there are 5000 results missing, that makes absolutely no sense.
Let me send you my results.txt file and see if you can find them in there.
<argh!>

[gd_barnes]

Originally Posted by IronBits

Ok, it's back up, but on port 8500
9000 is a CSlistner / Transmission Control Protocol and would not work here.

8500 is not being used anyways and that's where it came from, so, back on it again until it's finished.
I can't believe there are 5000 results missing, that makes absolutely no sense.

Let me send you my results.txt file and see if you can find them in there.
<argh!>

OK, when we verify that none of the missing results are in that file, I'll move the house to port 8500. 22 cores should dry it in < 1 day.


Gary

[IronBits]

http://llrnet.no-ip.info/results/res...t_8500_RAW.txt

I can't figure this one out, so am leaving it to the professionals!
I just looked at this file and it starts with (/me scratches head)
user=Brucifer
[02/07/2008 06:34:41 AM]
813*2^477532-1 is not prime. Res64: B8690845A1CF64AC Time : 1131.0 sec.

ends with

user=Brucifer
[03/07/2008 11:46:08 AM]
983*2^478000-1 is not prime. Res64: 14C64E28EB13007F Time : 1137.0 sec.

I'm guessing the file never got MOVED out of the working directory - probably permissions, and no one caught it?
No primes either

[gd_barnes]

Originally Posted by IronBits

http://llrnet.no-ip.info/results/res...t_8500_RAW.txt

I can't figure this one out, so am leaving it to the professionals!
I just looked at this file and it starts with (/me scratches head)
user=Brucifer
[02/07/2008 06:34:41 AM]
813*2^477532-1 is not prime. Res64: B8690845A1CF64AC Time : 1131.0 sec.

ends with

user=Brucifer
[03/07/2008 11:46:08 AM]
983*2^478000-1 is not prime. Res64: 14C64E28EB13007F Time : 1137.0 sec.

I'm guessing the file never got MOVED out of the working directory - probably permissions, and no one caught it?
No primes either

Anon,

Working directory? Permissions? No one caught it? I haven't a clue what all of this means. How is it that we're supposed to catch something that should not have happened in the first place? Can you clarify in non-techie terms?

Regardless, are these the missing results? An n=468 range should be close to 5000 results. If so, I'm staying on port 300.


Gary