LLRnet servers for CRUS

[IronBits]

Nice! Thanks James
I spent most of last night and most of the day today re-working all the scripts for all projects/servers/ports

I think you will like it better. http://crus.ironbits.net

I went through all the results.txt files since I opened the first port and found all the primes anyone found and broke them out into different files for the ports they were found on.

There is a specific file for each project/server/port that contains the primes each has had primes found in.
or something like that. :p ;)

[mdettweiler]

Originally Posted by IronBits

Nice! Thanks James
I spent most of last night and most of the day today re-working all the scripts for all projects/servers/ports

I think you will like it better. http://crus.ironbits.net

I went through all the results.txt files since I opened the first port and found all the primes anyone found and broke them out into different files for the ports they were found on.

There is a specific file for each project/server/port that contains the primes each has had primes found in.
or something like that. :p ;)

Nice work!

[IronBits]

Thanks. While I was at it, I've completely re-written the results gathering and processing script.
Now there is only one script that does each type of server and all it's ports.

I've tested it all I can so will run it tomorrow moring and see what we come up with.
Then I'll do the same thing for the hourly knpairs status run and we should be good to go.

If you think I should create a .csv to help import whatever into the SQL databases, please let me know what you want, and how you want it.
I'll have it create the same filenames so he can fetch it automatically, like Bok does for all his stats.
That way AES can come get the .csv data and get it imported automagically without intervention.

[mdettweiler]

Originally Posted by IronBits

Thanks. While I was at it, I've completely re-written the results gathering and processing script.
Now there is only one script that does each type of server and all it's ports.

I've tested it all I can so will run it tomorrow moring and see what we come up with.
Then I'll do the same thing for the hourly knpairs status run and we should be good to go.

If you think I should create a .csv to help import whatever into the SQL databases, please let me know what you want, and how you want it.
I'll have it create the same filenames so he can fetch it automatically, like Bok does for all his stats.
That way AES can come get the .csv data and get it imported automagically without intervention.

Okay, great! I'll look into it when I get back from vacation (7/5).

[IronBits]

The first live run was 'early' and I guess it messed up some things for Gary and you. :(
I also didn't have the Unix to Windows times program in the right directory, so had to finish it up manually.
It's set to fire off tomorrow morning automatically just before 7am Arizona time.
If you want that time changed to something else, let me know.

Have a very relaxing vacation!

[em99010pepe]

How many candidates are left on port 4?

[IronBits]

http://crus.ironbits.net
Port 4 has 261 lines in knpairs.txt
File size of 3,661
first k/n pair 64494 1858922
last k/n pair 64494 1999418

[em99010pepe]

Originally Posted by IronBits

http://crus.ironbits.net
Port 4 has 261 lines in knpairs.txt
File size of 3,661
first k/n pair 64494 1858922
last k/n pair 64494 1999418

That information is not the real one.

[gd_barnes]

Originally Posted by IronBits

http://crus.ironbits.net
Port 4 has 261 lines in knpairs.txt
File size of 3,661
first k/n pair 64494 1858922
last k/n pair 64494 1999418

Carlos,

I just checked the sieved file sent to David vs. the last k/n pair that you processed as of 14:00 GMT today. The number of pairs remaining appears correct but...

David,

The last k/n pair remaining appears correct but the first k/n pair remaining does not.

The first k/n pair has been 64494 1858922 for a long time yet as of 14:00 GMT today (7:00 AM Arizona time), Carlos received and tested the pair 64494 1938506 per the last test in the most recent results file.

The question is: Why is the first k/n pair less than the pair being handed out? It wasn't an issue of the pair being returned to the server since 7 AM your time this morning because that same pair has been the first k/n pair for many days now.

Perhaps it is an issue that the first k/n pair is the lowest one that has been sent to someone but has not yet had a result returned to the server? If that is the case and it is sitting in someone's queue, then that first k/n pair should be returned to the server within 7 days for handing out again. Yet it seems like it has been far longer than that.

Regardless, what should be reflected there as the first k/n pair is the first one remaining to be handed out, not what hasn't had a result returned to the server. (I'm just guessing that is the issue.)

As far as I can tell, this is an issue on all of the servers. The first k/n pair is frequently less than what is being handed out. That should not be. It also creates confusion when I update the n-range processing for each server in post 1 of these threads. The first k/n pair on your website is usually lower because I go by the highest k/n pair processed in the latest results file. The first pair shown should always be higher than the range that I show unless a lower k/n pair just happened to recently be returned to the server because it had sat idle in someone's queue.

Blah-blah-blah I know. I'm just trying to present all of the details so that both you and I can understand what is going on here.


Gary

[em99010pepe]

I just wanted to know how many candidates are left on the server because I would like to run the rest, in case no one else is running llrnet, with the manual client. If impossible just take off 48 candidates from the server and I'll process them.

[gd_barnes]

Originally Posted by em99010pepe

I just wanted to know how many candidates are left on the server because I would like to run the rest, in case no one else is running llrnet, with the manual client. If impossible just take off 48 candidates from the server and I'll process them.

David,

Can you temporarily stop the server and send me a file of the remaining k/n pairs that still need to be processed?

Carlos,

I can send you the remaining pairs to be processed manually but the only problem with that is someone could have some k/n pairs in their queue unprocessed that haven't been returned back to the server. In that case, we'd end up missing processing them. As David showed, ~260 remaining should be a fairly accurate count as of 14:00 GMT today (July 1st)...Less if you've been processing against the server since then.

The only way I'd know for sure is to pull all of the results files from port 4 and match them against the original sieved file. This would take a little while as Anon usually does it with an automated process but he is out of town until July 5th. I'd have to do it manually but it shouldn't be too bad.

Regardless, I see no problem with you running them manually but there may be some remaing pairs that we will need to process later on. At the end of yesterday, you were the only one running the server. Both Beyond and Ironbits had pulled off of it by then.


Gary