LLRnet servers for NPLB

[IronBits]

I never said anything would be fixed
I said I would make the changes to the server config files and restart the servers.
If it's still doing the same thing, then I don't have a clue why.

[gd_barnes]

Originally Posted by IronBits

I never said anything would be fixed
I said I would make the changes to the server config files and restart the servers.
If it's still doing the same thing, then I don't have a clue why.

Can you please check the joblist.txt file?

If the 955 500181 k/n pair is still in there, please manually delete it. It may have something to do with the fact that the result was returned to the server BEFORE you changed the prune period from 3 days to 1 hour but the results were returned to the server in < 3 days. Hence, they were not pruned BEFORE you changed it because it hadn't reached 3 days yet and they weren't pruned AFTER you changed it because the results had already been returned. Therefore it never "registered" with the server that they needed to be pruned.

I also have a feeling there is a whole group of k/n pairs in the joblist.txt file that have already had results returned to the server that may never be pruned from joblist.txt for the exact same reason as above. Most are likely in the range of n=500100-500200.

Based on the above possibility, please check joblist.txt for the following pairs that results have already been returned for in the past 3-5 days and manually delete any of them that are still in there:

663 500168
525 500172
749 500172
837 500172
867 500172
895 500173
979 500173
407 500174
423 500174
453 500174
501 500174
663 500179
685 500179
693 500179
723 500179
759 500179
769 500179
813 500179
859 500179
885 500179
601 500181
615 500181
621 500181
657 500181
681 500181
709 500181
819 500181
895 500181
907 500181
955 500181
565 500199
793 500199
615 500689
649 500689
747 500689

To the best of my knowledge, port 400 is not being used at the moment so it is probably best to bring it down, delete the pairs that should not be there in joblist.txt, and then restart it.

I'm not saying that these are all remaining in joblist.txt. Only that some of them MAY be remaining. At least by getting rid of these from joblist.txt, the current first k/n pair remaining should be correct.

Note that that the CURRENT pruning process may be working correctly. Whenever anything is changed midstream like this, even though future processing is working correctly, frequently some cleanup is needed on past processing.


Thanks,
Gary

[IronBits]

jobList = {
["955/500181"] = {
["seconds"]=1215409785,
["user"]="gd_barnes",
["date"]="06/07/2008 10:49:45 PM",
["k"]="955",
["status"]="solved",
["n"]="500181",
["result"]="149006251D0A5D84",
["resultdate"]="06/07/2008 11:02:08 PM",
},

[IronBits]

Here is the joblist for port 400, tell me more and I'll get er done

[gd_barnes]

Originally Posted by IronBits

Here is the joblist for port 400, tell me more and I'll get er done

David, I know little about the servers other than what I've been able to closely srutinize with the various files and the such.

The "status" of all of these shows "solved", which means they have a "result" in them and all except one of them were "solved" on July 6th or before. The other one was "solved" yesterday.

I don't know how the pruning process works but if the pruning is now at 1 hour, once the k/n pair is returned and joblist.txt is updated to show "solved" on the pair, then within 1 hour of that, the pair should be deleted from joblist.txt.

Have I analyzed this correctly? If so, then ALL k/n pairs in joblist.txt should be deleted because they are all at least 16 hours old. That is, joblist.txt should be empty.

One more thing: With no k/n pairs in joblist.txt, where will your web page get the first k/n pair that is remaining? It should be the first k/n pair in the knpairs.txt file.


Gary

[gd_barnes]

David,

Now that I'm understanding this a little more (I think), here is how I think the logic should work for your first k/n pair remaining:

1. First scan joblist.txt for the first k/n pair that has a "status" of "working". That is, it is NOT in "solved" status. THAT pair should be the first k/n pair remaining.

2. If there are no k/n pairs in joblist.txt that are in "working" status, then the first k/n pair in the knpairs.txt file is the first k/n pair remaining.

3. If there are no k/n pairs in the above two, then obviously the server is dry, and a message showing "none" should be displayed as the first k/n pair remaining.

On #3, even if there are pairs remaining in joblist.txt, if they are all in "solved" status, then you should not be picking those up for the first k/n remaining and hence show "none" remaining.

Let me know if this sounds logical to you.


Gary

[Lennart]

Originally Posted by IronBits

Here is the joblist for port 400, tell me more and I'll get er done

Try run in windoze llrserver -s
In linux ./llrnet llrserver.lua -s

See if it helps.

/Lennart

[IronBits]

Removing solved pair 955 500181
Removing solved pair 565 500199
Removing solved pair 793 500199
Removing solved pair 615 500689
Removing solved pair 649 500689
Removing solved pair 747 500689

joblist.txt still showed work as 'solved' so ran it a second time, no it is empty as it should be.
knpairs.txt now shows this on the 2nd line
799 500689

Thanks for the tip!

[gd_barnes]

Originally Posted by gd_barnes

David,

Now that I'm understanding this a little more (I think), here is how I think the logic should work for your first k/n pair remaining:

1. First scan joblist.txt for the first k/n pair that has a "status" of "working". That is, it is NOT in "solved" status. THAT pair should be the first k/n pair remaining.

2. If there are no k/n pairs in joblist.txt that are in "working" status, then the first k/n pair in the knpairs.txt file is the first k/n pair remaining.

3. If there are no k/n pairs in the above two, then obviously the server is dry, and a message showing "none" should be displayed as the first k/n pair remaining.

On #3, even if there are pairs remaining in joblist.txt, if they are all in "solved" status, then you should not be picking those up for the first k/n remaining and hence show "none" remaining.

Let me know if this sounds logical to you.


Gary

Originally Posted by IronBits

Removing solved pair 955 500181
Removing solved pair 565 500199
Removing solved pair 793 500199
Removing solved pair 615 500689
Removing solved pair 649 500689
Removing solved pair 747 500689

joblist.txt still showed work as 'solved' so ran it a second time, no it is empty as it should be.
knpairs.txt now shows this on the 2nd line
799 500689

Thanks for the tip!

Great! The web page looks good now.

Can I assume that you will also be changing your script? I think you'll still need to change it to something close to what I suggested above because the first k/n pair remaining should never reflect anything that has been "solved" in joblist.txt.

We essentially had two problems here. The file issue and the program (script) issue. If we don't fix both, we could end up with a first k/n pair remaining being one that is already "solved".


Gary

[gd_barnes]

Originally Posted by em99010pepe

No problem. Here are all files from my server:

joblist.txt
knpairs.txt
results.txt

Anon,

When you get back, you'll just need to use the results in this file above to combine with results that you previously got from Carlos when compiling them for n~=505K-506.3K to send to me. I've now sent these results in a .CSV file to Adam for uploading into his server for total-keeping purposes.

I will be forwarding the k/n pairs in knpairs.txt to Adam for loading into port 300 for testing with one exception:
485 506286

This pair was in both results.txt and knpairs.txt because it was in "solved" status in joblist.txt and had not been pruned yet.


Gary

[IronBits]

I'm just reporting what knpairs.txt has on the 2nd line, and the last line.
Haven't dealt with joblist.txt because it doesn't always contain anything.
I just looked at port nplb400 joblist.txt and it has nothing.
I could see if I can find something in a joblist.txt and report what it finds...
I'll see what I can come up with as a test.
After looking at port 5000, there are a ton of solved and working in joblist.txt
What's up with this *nix Server version of llrnet ??? Why isn't it doing what it's supposed to be doing?
This makes no sense, it appears prune/purge is not functioning as it should be.