llrnet Server Date/Time stamps in logs

[mdettweiler]

Originally Posted by IronBits

Ok, so... would anyone have any heartburn if we did this?

--displayFormat = "%s*2^%s+1" -- use this for PRP type test
displayFormat = "%s*2^%s-1" -- use this for LLR type test (default

to this
displayFormat = "%s,2,%s,-,1," -- use this for LLR type test (default

We can get rid of the * and ^ to make it easier to parse ;)

(I know, we already have everything parsing as it was, but it would be easier...)
Just asking... not knowing how important the 'data line' is...

Actually...that is the most critically important line of all of them--I probably would have a little heartburn if we changed those around. In fact, the Perl scripts that I use for results processing throw the user and date/time lines right out the window--the main purpose for those scripts is to extract the actual results from the results files, sort them, and output them to a file containing just the results lines, ordered first by n, then by k--exactly as if they were originally run with manual LLR, in order. (Though we feed the k/n pairs into the LLRnet server in order, the results file ends up putting them out of order due to the fact that some are returned before others, etc.)

So, long story short: if it's not too big a deal, that's the one line in the results file that we really, really don't want to mess with. I mean, I guess I *could* fix my scripts to deal with the commas instead of the * and ^ symbols--but hey, as the saying goes, if it ain't broke, don't fix it.

[IronBits]

Ok, delete my question, your response, and this message, so we don't clutter up our good conversation on the date/time format.
Forget I even asked the question ;)

[mdettweiler]

Originally Posted by IronBits

Ok, delete my question, your response, and this message, so we don't clutter up our good conversation on the date/time format.
Forget I even asked the question ;)

LOL--nah, don't worry, it was a good question, nothing wrong with that.

[mdettweiler]

Well, I've finally gotten all the CSV/results/timestamp stuff sorted out for server G4000! (For the unenlightened--namely, anyone other than David and I, who have been discussing this via email for a while--I've been working on fixing my CSV/results processing scripts so that they are fully compatible with the new CSV and timestamp formats.) David, I've gone back and fixed all of G4000's old results files to the ISO format we're using. A lot of the timestamps were "fixed" by simply using a text editor to get rid of the AM/PM stuff with search/replace, so some of the times are off by 12 hours, but that shouldn't be a big deal as we're not using the times for much right now, especially in light of G4000 being sort of a "testbed" server anyhow. At any rate, it shouldn't be a problem at all--just wanted to give you a heads up so that you don't think something's wrong if some of the results at the end of some of the files may appear to have come in prior to the ones at the beginning of the file.

Anyway, all the fixed scripts should be running daily on a cron job, and G4000's llr-serverconfig.txt is set to use our ISO time format. Thus, G4000 should produce correct daily results files and csv files at the respective linked locations--thus, David, you now officially have to go-ahead to import all the CSV files from from G4000 whenever you're ready, and continue to do so automatically once you eventually get all that set up over on your stats server.

Oh, and David, I'll send you the fixed csv.pl file tomorrow (getting too late right now, it's ~3AM and I need to get to bed); just use it to replace the one I sent you earlier with my llrnet-copyoff-results.pl script, and that should complete the long-awaited set of scripts to handle results copying off on Linux.

Phew! Glad to have all that finally off my plate.

Max

[kar_bon]

new problems?

see http://www.mersenneforum.org/showpos...&postcount=321

[gd_barnes]

Originally Posted by mdettweiler

A lot of the timestamps were "fixed" by simply using a text editor to get rid of the AM/PM stuff with search/replace, so some of the times are off by 12 hours, but that shouldn't be a big deal as we're not using the times for much right now, especially in light of G4000 being sort of a "testbed" server anyhow. At any rate, it shouldn't be a problem at all--just wanted to give you a heads up so that you don't think something's wrong if some of the results at the end of some of the files may appear to have come in prior to the ones at the beginning of the file.

Originally Posted by kar_bon

new problems?

see http://www.mersenneforum.org/showpos...&postcount=321

He answered the 'problem' in his post here. See above.

[IronBits]

I'll get them all fixed, no worries. Let's see what happens today in about an hour or so, and I'll take a look when I get home.
I'll stop the servers, make a manual stats run, change the logformat, restart the servers, then make the necessary changes to the scripts, and we should be good to go.

Originally Posted by kar_bon

David:
the last 2 result-files for port 400 you alternate the day and month!
example (last pair from results_20081113_0657_IB_nplb_400.txt):
user=IronBits
[2008/13/11 06:56:51]
471*2^546367-1 is not prime. Res64: E3E427F429745FD9 Time : 429.0 sec.

this should be
[2008/11/13 06:56:51]

[IronBits]

Everything is good to go now.

[IronBits]

Found this in the llr-client.cfg
Wonder if we could put this into the server.cfg and get it to fire off a script for auto notification?

-- Uncomment the two functions below to launch some script each
-- time you respectively find a prime, and submit a new result

--function OnPrime(t, k, n)
-- local script = "onprime.sh"
-- if WIN32 then
-- script = "onprime.bat"
-- end
-- execute(format("%s %d %d %d", script, t, k, n))
--end