LLRnet servers for NPLB

[mdettweiler]

Originally Posted by gd_barnes

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

Okay, sounds good.

[mdettweiler]

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!>

Hmm...I hadn't heard anything about port 5000 results being missing, just port 8500 results. Maybe you misread my post?

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

Originally Posted by gd_barnes

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

Aha! Those would be the missing results. Thus, I would recommend that if you switched any machines over yet to the newly reinstated port 8500, you remove them--hopefully, we won't need to re-process those k/n pairs after all.

It's getting late in my time zone right now, so I won't be able to do anything tonight, but tomorrow I'll see about getting the results from the file IronBits linked to above added to my IB8500 master results file, and try the processing again.

[IronBits]

hehehe, each day the results.txt file is moved out of the working directory (where the server is handing out pairs and creating results.txt etc.)
the dates are converted from unix to windows (because someone said it needed to be done)
The results.txt is scanned for prime! and if found the user name, date/time and the prime number is captured into another file (sometimes emailed to user that found it on some servers)
then the results.txt is renamed by date/time it was processed (on my servers anyways)
If it's not moved out of there so the llrnet server can create a new one, the data is constantly appended, each results_date/time.txt file contains the previous days runs since the server started...
It has to be moved out daily, it does so flawlessly on the other servers/ports, only that one seems to have kept the results.txt file intact since I brought that port online.
knpairs-473-478_8500.txt dated 5-27 is what it was working with...

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

Server port 8500 is down until Anon gets everything sorted out. I don't think anyone hit the server during the short time it was up.

[gd_barnes]

Originally Posted by IronBits

hehehe, each day the results.txt file is moved out of the working directory (where the server is handing out pairs and creating results.txt etc.)
the dates are converted from unix to windows (because someone said it needed to be done)
The results.txt is scanned for prime! and if found the user name, date/time and the prime number is captured into another file (sometimes emailed to user that found it on some servers)
then the results.txt is renamed by date/time it was processed (on my servers anyways)
If it's not moved out of there so the llrnet server can create a new one, the data is constantly appended, each results_date/time.txt file contains the previous days runs since the server started...
It has to be moved out daily, it does so flawlessly on the other servers/ports, only that one seems to have kept the results.txt file intact since I brought that port online.
knpairs-473-478_8500.txt dated 5-27 is what it was working with...

Aha, that's interesting and now I understand.

Based on that, I have 2 thoughts for you:

Possibility 1: When a server is dried out perhaps the fact that there is nothing left causes it to not process the last results file from the working directory.

Possibility 2: After we noted here in the forum that port 8500 was dried out, could it be that you shut the server down before it was able to process the last results?

Had I known it was the very last results file, I would have known immediately that the problem was likely to be one of the above 2 things. I wasn't running port 8500 the last day on my machines so I wasn't aware of all the dates that we were running it. I had moved to port 300 and let Bruce finish it up.


Gary

[gd_barnes]

Originally Posted by Anonymous

Hmm...I hadn't heard anything about port 5000 results being missing, just port 8500 results. Maybe you misread my post?



Aha! Those would be the missing results. Thus, I would recommend that if you switched any machines over yet to the newly reinstated port 8500, you remove them--hopefully, we won't need to re-process those k/n pairs after all.

It's getting late in my time zone right now, so I won't be able to do anything tonight, but tomorrow I'll see about getting the results from the file IronBits linked to above added to my IB8500 master results file, and try the processing again.

Anon,

On port 5000, there were 2 problems:

1. Some of my port 8000 results got combined with one of the days. I sent David corrected files for one day each on port 5000 and 8000 and he re-posted them to his site. I confirmed that the correct results were there.

2. There was one day in which the results were "missing" on port 5000 but as it turns out, the aforementioned (by David) process that runs to put the results file on his web pages did not run on that day for some reason so it only "looked" like they were missing. Hence, the results showed up in a larger file on his site with the next day's run. As David said, it just keeps concatenating results until the process that runs to post them on the site.

So at this point, there are no missing port 5000 results that I am aware of.

I was waiting for a definitive answer on whether the results were actually missing and had not switched any machines over to port 8500. David, you can delete the file that Anon sent you from the server. It should be dry now.


Gary

[gd_barnes]

David,

Please leave my personal port 8000 and NPLB port 8500 intact even though they are dried out.

I will likely have some work for port 8000 within the next 1-2 weeks. We'll use port 8500 for rallies.


Gary

[IronBits]

No problem, both server directories are still there, just in need of knpairs.txt to take off with

And, Possibility 2: is possible

[gd_barnes]

David,

This is something that I've noticed for quite a while on different servers but now I finally have proof. The below is what is shown on your site currently for port 400:

Port 400 has 87301 remaining
File size of 960,604
first k/n pair 955 500181
last k/n pair 915 525000


Note the first k/n pair remaining of 955 500181

BUT...that one was processed nearly two days ago in this results file from July 7th on your results page:

user=gd_barnes
[07/06/08 23:02:08]
955*2^500181-1 is not prime. Res64: 149006251D0A5D84 Time : 743.0 sec.


I did this as a test to demonstrate that the first k/n pair remaining is not working properly as I have suspected for quite a while. Can you look into that?

The first k/n pair remaining is important for us to be able to tell if there are straggling k/n pairs before processing the results files.


Thanks,
Gary

[Brucifer]

So I assume that all the controversy on 8500 is finished? And I have no missing results? And I also have no primes? I had sent one PM inquiring into whether the results.txt stuff was impacting 8500. And all the results have been added to the score? Reason I ask about all this is I had been running along on at getting a prime average every other day. then went a week without anything. And after going over to 300 nothing either. Just seemed a bit out of the ordinary, specially when some others were popping them up right and left. :) Like maybe a little confidence in the system sorta strayed a bit. :)

[gd_barnes]

Originally Posted by Brucifer

So I assume that all the controversy on 8500 is finished? And I have no missing results? And I also have no primes? I had sent one PM inquiring into whether the results.txt stuff was impacting 8500. And all the results have been added to the score? Reason I ask about all this is I had been running along on at getting a prime average every other day. then went a week without anything. And after going over to 300 nothing either. Just seemed a bit out of the ordinary, specially when some others were popping them up right and left. :) Like maybe a little confidence in the system sorta strayed a bit. :)

Correct, no more controversy on port 8500. Everything should be fine on the results now. It was just a large primeless gap. I to a lesser extent had a gap on port 8500 and then for 2+ days on port 300 (running 22 cores) before finally finding a prime. What you expierenced is unusual but not terribly so. These higher n-ranges will have larger prime gaps.

Reference finding them right and left, Anon's was from a manual range unrelated to ours and Ozzy's was from a long while back also. I've also had 30000+ manual tests on the individual-k reservations without a prime. Unfortunately it's just bad luck for all of us at once.

Unfortunately Anon had to leave on another family situation again and won't be back for a week, I'll attempt to get the n=473K-478K results processed and sent to Adam by tomorrow. Anon had an automated process set up to verify that they are all there but I don't so it'll take a little longer. I also need to ask what Adam has received from Anon. Adam processed n=458K-463K to me but I'm not sure if he sent it to Adam.


Gary

[IronBits]

Originally Posted by gd_barnes

David,

This is something that I've noticed for quite a while on different servers but now I finally have proof. The below is what is shown on your site currently for port 400:

Port 400 has 87301 remaining
File size of 960,604
first k/n pair 955 500181
last k/n pair 915 525000

Note the first k/n pair remaining of 955 500181

BUT...that one was processed nearly two days ago in this results file from July 7th on your results page:

user=gd_barnes
[07/06/08 23:02:08]
955*2^500181-1 is not prime. Res64: 149006251D0A5D84 Time : 743.0 sec.

I did this as a test to demonstrate that the first k/n pair remaining is not working properly as I have suspected for quite a while. Can you look into that?
The first k/n pair remaining is important for us to be able to tell if there are straggling k/n pairs before processing the results files.

Thanks,
Gary

I'm looking into it, and asking Bok to take a look to see why the permissions/groups keep changing on that server.
It's odd, and I'm not sure what it could be but I'll keep looking for a reason.
If necessary, I'll move all the Servers back to a Windows Server and be done with it.
I remember moving them to the Linux server because the sockets on the Windows servers puke when hammered hard and the llrnet server will stop responding.