[quote=gd_barnes;148941]Wow, a true detail geek like me. lmao

I averaged the testing times of 1000 k/n pairs at the same n-range over the same interval on 2 different machines that I knew had virtually identical testing times when there was no difference in the cache between them. Nothing statistically significant popped up.

Your way is easier and more accurate if I was a techno geek as much as I was a detail geek. :smile:[/quote]
Hmm...I'm not sure how your method would say anything about the gap between k/n pairs. All it would tell you about is potential statistical deviations in the actual LLR testing times of the numbers. Not that there's much of any gap between k/n pairs anyway. :smile:

[quote=mdettweiler;148943]Hmm...I'm not sure how your method would say anything about the gap between k/n pairs. All it would tell you about is potential statistical deviations in the actual LLR testing times of the numbers. Not that there's much of any gap between k/n pairs anyway. :smile:[/quote]


Well there you go...my test wasn't even the correct test. lol

[quote=IronBits;148940]I don't think the current parsing scripts has an entry for " The Knights Who Say Ni!" so that will cause the name to be wrong in the database now, and Bok will have to do additional work to get it removed.[/quote]


This does bring up something: Wabbit requested a new team a day or 2 ago and Max added it to our team list in that thread. How long does a person need to wait after stating his intent to add a new team before it is entered into the server database such that his team will get credited for the results?

Wabbit, it looks like the team name is definitely the issue on you not seeing your total results processed on Ironbits web page.


Gary

[quote=gd_barnes;148945]This does bring up something: Wabbit requested a new team a day or 2 ago and Max added it to our team list in that thread. How long does a person need to wait after stating his intent to add a new team before it is entered into the server database such that his team will get credited for the results?

Wabbit, it looks like the team name is definitely the issue on you not seeing your total results processed on Ironbits web page.


Gary[/quote]
I added Wabbit's team info both to this thread and to the stats database at [url]http://stats.ironbits.net[/url]. The only thing that it didn't get added to yet is the list of teams that David's script uses to parse out team names (which ideally shouldn't need to be used anyway).

That's right Max, as soon as you enter a Team name into the database and assign someone to it, it should show up. I don't think they are static pages, in that when you click on an link for a specific stats page, it goes directly to the database to fetch the data.
Importing of the .csv is done sometime after 8am automatically everyday.
I strip all TeamNames from the username, so it's a waste of time and a potential way to put crap into the database that Bok would have to weed out and should be highly discouraged.

I located the lines that were missing the text for "is not prime." and "is prime!" in the output.
Hopefully, tomorrow mornings run will be back to normal.

I have multiple output files to create - sorry I missed an entry ...

1 - web page output for each project and port
2 - All linux converted to windows formatted Results.txt files for each project and port
3 - results.csv for importing into the database for each project and port
4 - Today's Processing Log for each project
5 - Local processing logs for each project and port for debugging purposes
6 - All Primes found so far for each project and port

I also generate web page content for each project and port every hour on the hour.

You folks have more data, stats and information to look at than you have ever had,
and it just keeps getting better with time. :wink:

All of the above is handled by just two Windows CMD script files to. :smile:

I wrote a vbscript that converts results.txt to the .csv and .txt files, but haven't been able to put it into service yet, but, from testing I've done so far, it is super fast!

Max is working on a Perl script version, so soon, anybody that wants to run an llrnet server in linux or windows will have everything they would need.

The DATE/TIME format in llr-serverconfig.txt needs to be modified so that we have consistency in results.txt.
Max has that information now...

Gary, your servers were not using the 'standard' format, so I sent Max a copy of mine and it works perfectly now.
He's modifying the Perl script to handle the changes.

I still have to work into the vbscript, a way to test if it's a Windows or Linux formated DATE/TIME so it can handle either, but we are getting there.

As to what you see for stats in the database is from some old .php code that needs to be tweaked so you can see all the data you might want to see.
Bok will have to handle that part of it, so just be patient, the DATA is getting into the db.
Currently it only shows you a partial of the entire amount of data is has the potential to show you...

To toss my ping rates into the arena :wink:
[code]
Pinging nplb.dynip.telepac.pt [85.240.224.187] with 32 bytes of data:

Reply from 85.240.224.187: bytes=32 time=197ms TTL=118
Reply from 85.240.224.187: bytes=32 time=197ms TTL=118
Reply from 85.240.224.187: bytes=32 time=198ms TTL=118
Reply from 85.240.224.187: bytes=32 time=197ms TTL=118

Ping statistics for 85.240.224.187:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 197ms, Maximum = 198ms, Average = 197ms


Pinging nplb-gb1.no-ip.org [70.94.216.38] with 32 bytes of data:

Reply from 70.94.216.38: bytes=32 time=95ms TTL=52
Reply from 70.94.216.38: bytes=32 time=93ms TTL=52
Reply from 70.94.216.38: bytes=32 time=96ms TTL=52
Reply from 70.94.216.38: bytes=32 time=104ms TTL=52

Ping statistics for 70.94.216.38:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 93ms, Maximum = 104ms, Average = 97ms
[/code]

Here is pinging myself :smile:

[code]
Pinging nplb.ironbits.net [98.174.238.119] with 32 bytes of data:

Reply from 98.174.238.119: bytes=32 time<1ms TTL=64
Reply from 98.174.238.119: bytes=32 time<1ms TTL=64
Reply from 98.174.238.119: bytes=32 time<1ms TTL=64
Reply from 98.174.238.119: bytes=32 time<1ms TTL=64

Ping statistics for 98.174.238.119:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
[/code]

Strange bug
 

There is an odd bug when the results files are processed over to the "Index of / results" page each day. It puts an extra " 0" after the k/n pair tested if the pair is not prime and an extra " 1" after the pair if it is prime.

Note that this ONLY occurs when the file is converted over to the Index of / results for the day. Also the bug with the not showing of the time on primes only occurs on this conversion.

As the results are updated hourly, both the primes and non-primes appear perfectly including the time on primes. I saw the primes that I had in the results file yesterday before it was converted to the daily file and they looked perfect up until the file got moved over to the index.


Very odd!


Non-primes:

[code]
user=MyDogBuster
[11/13/08 06:56:23]
893*2^546366-1[B] 0[/B] is not prime. Res64: 63652A4C375771E9 Time : 450.0 sec.
user=gd_barnes
[11/13/08 06:56:39]
677*2^546366-1[B] 0[/B] is not prime. Res64: 83A31C472EB313CC Time : 478.0 sec.
user=gd_barnes
[11/13/08 06:56:49]
815*2^546366-1[B] 0[/B] is not prime. Res64: E15D7E9CE30DF168 Time : 478.0 sec.
user=IronBits
[11/13/08 06:56:51]
471*2^546367-1[B] 0[/B] is not prime. Res64: E3E427F429745FD9 Time : 429.0 sec.
[/code]

primes:

[code]
user=gd_barnes
[11/12/08 14:02:09]
453*2^545863-1[B] 1[/B] is prime! Time : sec.
user=gd_barnes
[11/12/08 19:57:04]
849*2^546031-1[B] 1[/B] is prime! Time : sec.
[/code]


Gary

Hmm...I think I've got an idea about what may be causing that. There's a field in the CSV file called "is_prime", which is 0 for not prime and 1 for prime--but that's only supposed to go in the CSV file, not in the results file. David, is your new VB script somehow accidentally outputting the is_prime variable to both files?

EXACTLY! You guys are SHARP :smile:

I'll try to get it resolved, re-run the results to purge todays data from the results directory so it goes away...
It runs in the morning, after I go to work, so I can't see what happens until I get home.

[B]Fixed![/B]

I am not using the vbscript just yet, because I have to migrate it into my current scripts...
I am only using it to fix problems right now.
This week-end, we should be good to go.

I have added in the cscript /nologo results.vbs %INPUTFILE% to the dos script.
Hopefully tomorrow morning, all the problems will be gone.

Then, once I change the llr-serverconfig.txt to use
[B]return date("%F\ %R:%S")
[/B]I'll have to adjust the vbscript, the perl script and the windows dos script:smile:

Probably do that on Saturday, so I'll have a full days run of the correct return date time stamps...