mersenneforum.org  

Go Back   mersenneforum.org > Prime Search Projects > No Prime Left Behind

Reply
 
Thread Tools
Old 2008-11-12, 00:22   #298
gd_barnes
 
gd_barnes's Avatar
 
May 2007
Kansas; USA

2×3×7×241 Posts
Default

Quote:
Originally Posted by mdettweiler View Post
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.
gd_barnes is offline   Reply With Quote
Old 2008-11-12, 00:31   #299
Wabbit98
 
Sep 2008

11 Posts
Default

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
Wabbit98 is offline   Reply With Quote
Old 2008-11-12, 01:35   #300
mdettweiler
A Sunny Moo
 
mdettweiler's Avatar
 
Aug 2007
USA (GMT-5)

3·2,083 Posts
Default

Quote:
Originally Posted by Wabbit98 View Post
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.
mdettweiler is offline   Reply With Quote
Old 2008-11-12, 02:48   #301
gd_barnes
 
gd_barnes's Avatar
 
May 2007
Kansas; USA

278A16 Posts
Default

Quote:
Originally Posted by mdettweiler View Post
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

Last fiddled with by gd_barnes on 2008-11-12 at 02:50
gd_barnes is offline   Reply With Quote
Old 2008-11-12, 02:53   #302
mdettweiler
A Sunny Moo
 
mdettweiler's Avatar
 
Aug 2007
USA (GMT-5)

3·2,083 Posts
Default

Quote:
Originally Posted by gd_barnes View Post
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.
mdettweiler is offline   Reply With Quote
Old 2008-11-12, 03:08   #303
gd_barnes
 
gd_barnes's Avatar
 
May 2007
Kansas; USA

2·3·7·241 Posts
Default

Quote:
Originally Posted by mdettweiler View Post
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
gd_barnes is offline   Reply With Quote
Old 2008-11-12, 03:53   #304
mdettweiler
A Sunny Moo
 
mdettweiler's Avatar
 
Aug 2007
USA (GMT-5)

3×2,083 Posts
Default

Quote:
Originally Posted by gd_barnes View Post
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:
Code:
(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
mdettweiler is offline   Reply With Quote
Old 2008-11-12, 04:03   #305
IronBits
I ♥ BOINC!
 
IronBits's Avatar
 
Oct 2002
Glendale, AZ. (USA)

3·7·53 Posts
Default

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.

Quote:
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 is offline   Reply With Quote
Old 2008-11-12, 04:06   #306
IronBits
I ♥ BOINC!
 
IronBits's Avatar
 
Oct 2002
Glendale, AZ. (USA)

3·7·53 Posts
Default

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.

Last fiddled with by IronBits on 2008-11-12 at 04:09
IronBits is offline   Reply With Quote
Old 2008-11-12, 04:08   #307
gd_barnes
 
gd_barnes's Avatar
 
May 2007
Kansas; USA

2×3×7×241 Posts
Default

Quote:
Originally Posted by mdettweiler View Post
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:
Code:
(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 is offline   Reply With Quote
Old 2008-11-12, 04:11   #308
gd_barnes
 
gd_barnes's Avatar
 
May 2007
Kansas; USA

2×3×7×241 Posts
Default

Quote:
Originally Posted by IronBits View Post
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!
gd_barnes is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
PRPnet servers for NPLB mdettweiler No Prime Left Behind 228 2018-12-26 04:50
Servers for NPLB gd_barnes No Prime Left Behind 0 2009-08-10 19:21
LLRnet servers for CRUS gd_barnes Conjectures 'R Us 39 2008-07-15 10:26
NPLB LLRnet server discussion em99010pepe No Prime Left Behind 229 2008-04-30 19:13
NPLB LLRnet server #1 - dried em99010pepe No Prime Left Behind 19 2008-03-26 06:19

All times are UTC. The time now is 06:09.

Mon May 25 06:09:07 UTC 2020 up 61 days, 3:42, 0 users, load averages: 1.26, 1.39, 1.39

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.