LLRnet servers for NPLB

[gd_barnes]

Originally Posted by mdettweiler

First of all, here's a link to the port 5000 primes list, in case this helps:

http://nplb.ironbits.net/primes_5000.txt
(even though the link was taken offline, I was still able to get to it by reverse-engineering the URL to the port 400 primes list. )

Secondly, I just took a look at the results file I sent you from my Sent Items folder, and I found that the lines for primes that are erroneously listed as "not prime" all contain this exact string of text where the "is prime! Time :" string should be:

"is not prime. LLR Res64: Time : "

Thus, I can do a search/replace on that string, replacing it with "is prime! Time : 0.0 sec." The times are not important, since they are practically useless anyway. Thus, a quick search/replace of this sort produces the desired effect.

I'll email you the results, fixed using the above method, shortly.

Max

Very good. Thanks. I'll verify them shortly after I get them.

[Wabbit98]

I am using server #2 I believe and I was looking at the results that I seem to have reported, and it does not seem all of my results are in, and the times are way off from my results file. I have completed about 38 numbers. All have said they have reported back to the server. Yet only a few show up in the results on the server page.

Ni

[mdettweiler]

Originally Posted by Wabbit98

I am using server #2 I believe and I was looking at the results that I seem to have reported, and it does not seem all of my results are in, and the times are way off from my results file. I have completed about 38 numbers. All have said they have reported back to the server. Yet only a few show up in the results on the server page.

Ni

Hmm...that's odd. I don't see any results from you whatsoever on the sever's status page. Could you possibly put your llr-clientconfig.txt and lresults.txt files into a zip file and attach them here? I'm wondering if maybe something's misconfigured somewhere or other.

[gd_barnes]

Originally Posted by mdettweiler

Hmm...that's odd. I don't see any results from you whatsoever on the sever's status page. Could you possibly put your llr-clientconfig.txt and lresults.txt files into a zip file and attach them here? I'm wondering if maybe something's misconfigured somewhere or other.

?? The results are there: 20 results from "The Knights Who Say Ni!_Wabbit98" were returned in the Nov. 11th file that ended at 7 AM Arizona time this morning (2 PM GMT). 20 more results were returned in today's file from 7 AM to 7 PM Arizona time today. The total is 40 results, which is close to what he said.

The only issue seems to be that his results aren't getting tallied on the page. Could that have something to do with having the team name in his user ID?

Wabbit, I believe it was determined that David (Ironbits) doesn't want the team name in the user ID.

And finally: The timings on the server will not correspond to what is in your results file. Your results file will contain the actual CPU time it took your computer to test a k/n pair. The timing on the server will be the amount of time between when it sent the k/n pair to you and when you returned it to the server. If your WUcache is more than 1 or you stop your computer for a while, those 2 timings will be substantially different. For me, I leave my cache at 1 and rarely stop my machines so the server timings are almost always within a fraction of a second of my results file time.


Gary

[mdettweiler]

Originally Posted by gd_barnes

For me, I leave my cache at 1 and rarely stop my machines so the server timings are almost always within a fraction of a second of my results file time.

Hmm...this brings up something I've been wanting to tell you for a while. Even though you have a pretty reliable internet connection, I would still recommend setting your WUCacheSize's to at least 2, since otherwise the client runs out of work for the 1 second or so that it takes to submit the result, and grab a new k/n pair. May not seem like much, but it adds up over time.

[gd_barnes]

Originally Posted by mdettweiler

Hmm...this brings up something I've been wanting to tell you for a while. Even though you have a pretty reliable internet connection, I would still recommend setting your WUCacheSize's to at least 2, since otherwise the client runs out of work for the 1 second or so that it takes to submit the result, and grab a new k/n pair. May not seem like much, but it adds up over time.

Thanks for the info. You told me that long ago and for that reason, I had my cache at 2 for a long time but changed it to 1 in the last month. Since I always like to clear out my queue when I change servers or work, I was spending 15 mins. clearing the queues out of all of my machines with more than one candidate. But since people showed me the -c option, I suppose it's the same clearing out more than one candidate vs. just one.

Regardless, I tested it and could not detect a difference. At most, it might be 0.1-0.25 secs. with a high-speed connection. Over time at 400-500 secs. per candidate, that's ~1/2000 to 1/5000th of total testing time, which just doesn't add up to much. 1000 candidates equal 100-250 secs. or ~2-4 CPU mins. out of 400K-500K secs. or 5-6 CPU days. I could clean out or otherwise somehow reduce the heat in my machines and save far more time. For that matter, I could manage my work better and not let my machines sit idle for 6 hours like what happened yesterday.

More than anything, I like testing the leading edge of the server instead of what was handed out 5 or 10 mins. ago or several hours ago.

Now...if I was using dial-up, it'd be a different story.


Gary

[mdettweiler]

Originally Posted by gd_barnes

Thanks for the info. You told me that long ago and for that reason, I had my cache at 2 for a long time but changed it to 1 in the last month. Since I always like to clear out my queue when I change servers or work, I was spending 15 mins. clearing the queues out of all of my machines with more than one candidate. But since people showed me the -c option, I suppose it's the same clearing out more than one candidate vs. just one.

Regardless, I tested it and could not detect a difference. At most, it might be 0.1-0.25 secs. with a high-speed connection. Over time at 400-500 secs. per candidate, that's ~1/2000 to 1/5000th of total testing time, which just doesn't add up to much. 1000 candidates equal 100-250 secs. or ~2-4 CPU mins. out of 400K-500K secs. or 5-6 CPU days. I could clean out or otherwise somehow reduce the heat in my machines and save far more time. For that matter, I could manage my work better and not let my machines sit idle for 6 hours like what happened yesterday.

More than anything, I like testing the leading edge of the server instead of what was handed out 5 or 10 mins. ago or several hours ago.

Now...if I was using dial-up, it'd be a different story.


Gary

Hmm...I kept thinking that the idle spaces between each candidate were more than that. Maybe my internet connection just has a much higher latency than yours, or something like that. Usually when I set a WUCacheSize to 1 it's somewhere around 0.5-2 seconds (depending on which server I'm connecting to) of idle time between each number.

I've noticed that when I connect to, say, servers hosted by Carlos (in Portugal) the latency is noticeably longer than when I connect to servers hosted by David (in Arizona, USA). Maybe the reason why you're getting significantly lower latencies than me is because you're somewhat closer to Arizona than I am?

I was going to try VNC'ing into one of your machines and running a speed test from your network to compare with mine, but apparently the test requires Flash Player to be installed and your Linux quads don't have it. I didn't want to bother installing it right now, so instead I decided to try pinging the various LLRnet servers. Here's what I got:

(pinging IronBits' server, from your network):
max@crunchford:~$ ping nplb.ironbits.net
PING nplb.ironbits.net (98.174.238.119) 56(84) bytes of data.
64 bytes from wsip-98-174-238-119.ph.ph.cox.net (98.174.238.119): icmp_seq=1 ttl=53 time=119 ms
64 bytes from wsip-98-174-238-119.ph.ph.cox.net (98.174.238.119): icmp_seq=2 ttl=53 time=126 ms
64 bytes from wsip-98-174-238-119.ph.ph.cox.net (98.174.238.119): icmp_seq=3 ttl=53 time=118 ms
64 bytes from wsip-98-174-238-119.ph.ph.cox.net (98.174.238.119): icmp_seq=4 ttl=53 time=126 ms
64 bytes from wsip-98-174-238-119.ph.ph.cox.net (98.174.238.119): icmp_seq=5 ttl=53 time=118 ms

(IronBits' server, from my network):
max@max:~$ ping nplb.ironbits.net
PING nplb.ironbits.net (98.174.238.119) 56(84) bytes of data.
64 bytes from wsip-98-174-238-119.ph.ph.cox.net (98.174.238.119): icmp_seq=1 ttl=51 time=194 ms
64 bytes from wsip-98-174-238-119.ph.ph.cox.net (98.174.238.119): icmp_seq=2 ttl=50 time=166 ms
64 bytes from wsip-98-174-238-119.ph.ph.cox.net (98.174.238.119): icmp_seq=3 ttl=51 time=184 ms
64 bytes from wsip-98-174-238-119.ph.ph.cox.net (98.174.238.119): icmp_seq=4 ttl=50 time=183 ms
64 bytes from wsip-98-174-238-119.ph.ph.cox.net (98.174.238.119): icmp_seq=5 ttl=50 time=186 ms

(Carlos's server, from your network):
max@crunchford:~$ ping nplb.dynip.telepac.pt
PING nplb.dynip.telepac.pt (85.240.224.187) 56(84) bytes of data.
64 bytes from bl7-224-187.dsl.telepac.pt (85.240.224.187): icmp_seq=1 ttl=111 time=187 ms
64 bytes from bl7-224-187.dsl.telepac.pt (85.240.224.187): icmp_seq=2 ttl=111 time=187 ms
64 bytes from bl7-224-187.dsl.telepac.pt (85.240.224.187): icmp_seq=3 ttl=111 time=189 ms
64 bytes from bl7-224-187.dsl.telepac.pt (85.240.224.187): icmp_seq=4 ttl=111 time=187 ms
64 bytes from bl7-224-187.dsl.telepac.pt (85.240.224.187): icmp_seq=5 ttl=111 time=189 ms

(Carlos's server, from my network):
max@max:~$ ping nplb.dynip.telepac.pt
PING nplb.dynip.telepac.pt (85.240.224.187) 56(84) bytes of data.
64 bytes from bl7-224-187.dsl.telepac.pt (85.240.224.187): icmp_seq=1 ttl=110 time=272 ms
64 bytes from bl7-224-187.dsl.telepac.pt (85.240.224.187): icmp_seq=2 ttl=110 time=271 ms
64 bytes from bl7-224-187.dsl.telepac.pt (85.240.224.187): icmp_seq=3 ttl=110 time=257 ms
64 bytes from bl7-224-187.dsl.telepac.pt (85.240.224.187): icmp_seq=4 ttl=110 time=230 ms
64 bytes from bl7-224-187.dsl.telepac.pt (85.240.224.187): icmp_seq=5 ttl=110 time=240 ms

It seems your connection produced 34.4% shorter latencies than mine, on average, when connecting to IronBits' server, and 23.2% shorter on Carlos's server. This would be consistent with the fact that you have cable broadband and I have DSL, and cable is usually somewhat faster than DSL (at least in the U.S.) The smaller difference on Carlos's server vs. IronBits' server would probably be because of my closer proximity to Carlos.

Given all this, I guess it's not a big deal after all for you to have your WUCacheSize's set to 1.

Max

[IronBits]

1 - I finished a vbscript that is more robust and takes less than a second to parse 40,000 lines. I'll re-run it against the original results.txt files and replace what's out there soon. I understand that it messes up others attempts at gathering stats so I'll try to finish it by this week-end.

2 - I was planning on leaving the links on the page so you can get to them with a hyperlink, but as Max says, the files are still there if you know the links.

Originally Posted by gd_barnes

David,

Two things:

1. Can you make it a priority to fix the verbiage in the results file when a prime is found? It needs to show "is prime!" as well as the CPU time. Besides affecting Karsten's scripts, it has also affected one of Max's scripts. Looking for "is prime" is fairly common when automating the processing of results.

2. Can you leave the info. up on your web page for a port for 1-2 weeks after it has dried? Because Max's scripts didn't work correctly when creating results files for processing to me, I'm having a difficult time finding a couple of primes in the file in the manner that I normally would, i.e. by just doing a find on "prime!". Regardless of that, frequently there will be something that I/we need to refer to right after the drive is done.

Gary

[IronBits]

Please REMOVE the TEAM_UserName
The Knights Who Say Ni!_Wabbit98
change it to Wabbit98
The TEAM _ UserName is not a proper UserName and unnecessary for stats and only causes problems with the parsing of the results.txt to .csv to import the data into the database.

Please remove all verbage of such Team_UserName where ever you can find it.

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.

[gd_barnes]

Originally Posted by mdettweiler

Hmm...I kept thinking that the idle spaces between each candidate were more than that. Maybe my internet connection just has a much higher latency than yours, or something like that. Usually when I set a WUCacheSize to 1 it's somewhere around 0.5-2 seconds (depending on which server I'm connecting to) of idle time between each number.

I've noticed that when I connect to, say, servers hosted by Carlos (in Portugal) the latency is noticeably longer than when I connect to servers hosted by David (in Arizona, USA). Maybe the reason why you're getting significantly lower latencies than me is because you're somewhat closer to Arizona than I am?

I was going to try VNC'ing into one of your machines and running a speed test from your network to compare with mine, but apparently the test requires Flash Player to be installed and your Linux quads don't have it. I didn't want to bother installing it right now, so instead I decided to try pinging the various LLRnet servers. Here's what I got:

(pinging IronBits' server, from your network):
max@crunchford:~$ ping nplb.ironbits.net
PING nplb.ironbits.net (98.174.238.119) 56(84) bytes of data.
64 bytes from wsip-98-174-238-119.ph.ph.cox.net (98.174.238.119): icmp_seq=1 ttl=53 time=119 ms
64 bytes from wsip-98-174-238-119.ph.ph.cox.net (98.174.238.119): icmp_seq=2 ttl=53 time=126 ms
64 bytes from wsip-98-174-238-119.ph.ph.cox.net (98.174.238.119): icmp_seq=3 ttl=53 time=118 ms
64 bytes from wsip-98-174-238-119.ph.ph.cox.net (98.174.238.119): icmp_seq=4 ttl=53 time=126 ms
64 bytes from wsip-98-174-238-119.ph.ph.cox.net (98.174.238.119): icmp_seq=5 ttl=53 time=118 ms
 
(IronBits' server, from my network):
max@max:~$ ping nplb.ironbits.net
PING nplb.ironbits.net (98.174.238.119) 56(84) bytes of data.
64 bytes from wsip-98-174-238-119.ph.ph.cox.net (98.174.238.119): icmp_seq=1 ttl=51 time=194 ms
64 bytes from wsip-98-174-238-119.ph.ph.cox.net (98.174.238.119): icmp_seq=2 ttl=50 time=166 ms
64 bytes from wsip-98-174-238-119.ph.ph.cox.net (98.174.238.119): icmp_seq=3 ttl=51 time=184 ms
64 bytes from wsip-98-174-238-119.ph.ph.cox.net (98.174.238.119): icmp_seq=4 ttl=50 time=183 ms
64 bytes from wsip-98-174-238-119.ph.ph.cox.net (98.174.238.119): icmp_seq=5 ttl=50 time=186 ms
 
(Carlos's server, from your network):
max@crunchford:~$ ping nplb.dynip.telepac.pt
PING nplb.dynip.telepac.pt (85.240.224.187) 56(84) bytes of data.
64 bytes from bl7-224-187.dsl.telepac.pt (85.240.224.187): icmp_seq=1 ttl=111 time=187 ms
64 bytes from bl7-224-187.dsl.telepac.pt (85.240.224.187): icmp_seq=2 ttl=111 time=187 ms
64 bytes from bl7-224-187.dsl.telepac.pt (85.240.224.187): icmp_seq=3 ttl=111 time=189 ms
64 bytes from bl7-224-187.dsl.telepac.pt (85.240.224.187): icmp_seq=4 ttl=111 time=187 ms
64 bytes from bl7-224-187.dsl.telepac.pt (85.240.224.187): icmp_seq=5 ttl=111 time=189 ms
 
(Carlos's server, from my network):
max@max:~$ ping nplb.dynip.telepac.pt
PING nplb.dynip.telepac.pt (85.240.224.187) 56(84) bytes of data.
64 bytes from bl7-224-187.dsl.telepac.pt (85.240.224.187): icmp_seq=1 ttl=110 time=272 ms
64 bytes from bl7-224-187.dsl.telepac.pt (85.240.224.187): icmp_seq=2 ttl=110 time=271 ms
64 bytes from bl7-224-187.dsl.telepac.pt (85.240.224.187): icmp_seq=3 ttl=110 time=257 ms
64 bytes from bl7-224-187.dsl.telepac.pt (85.240.224.187): icmp_seq=4 ttl=110 time=230 ms
64 bytes from bl7-224-187.dsl.telepac.pt (85.240.224.187): icmp_seq=5 ttl=110 time=240 ms

It seems your connection produced 34.4% shorter latencies than mine, on average, when connecting to IronBits' server, and 23.2% shorter on Carlos's server. This would be consistent with the fact that you have cable broadband and I have DSL, and cable is usually somewhat faster than DSL (at least in the U.S.) The smaller difference on Carlos's server vs. IronBits' server would probably be because of my closer proximity to Carlos.

Given all this, I guess it's not a big deal after all for you to have your WUCacheSize's set to 1.

Max

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.

[gd_barnes]

Originally Posted by IronBits

Please REMOVE the TEAM_UserName
The Knights Who Say Ni!_Wabbit98
change it to Wabbit98
The TEAM _ UserName is not a proper UserName and unnecessary for stats and only causes problems with the parsing of the results.txt to .csv to import the data into the database.

Please remove all verbage of such Team_UserName where ever you can find it.

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.

Don't mess with the server guy. He might mess with your stats!