Join PrimeGrid
Returning Participants
Community
Leader Boards
Results
Other
drummers-lowrise
|
1)
Message boards :
Project Staging Area :
2016 PRPNet April Challenge
(Message 93961)
Posted 2617 days ago by mdettweiler
Sadly, my participation in the Challenge has been cut slightly short due to some network maintenance which took the machines I'm using temporarily offline. :-( It looks like they'll be off until after the end of the Challenge.
In any case, though, I'm pretty happy with my showing...looks like I'll have either 5th or 6th place depending on how fast those below me can move in the remaining 7 hours, during which I'll be a "sitting target". Anyone want to try and bump me down? :-)
|
2)
Message boards :
Project Staging Area :
2016 PRPNet April Challenge
(Message 93840)
Posted 2620 days ago by mdettweiler
Just moved about 20 quad Haswells over to the GCW server for the duration of the challenge. I am fortunate to have some fairly heavy resources at my disposal now (at least in the short term), so let's see if I can pull a Lennart on this one. :-D
|
3)
Message boards :
Project Staging Area :
2016 PRPNet April Challenge
(Message 93837)
Posted 2620 days ago by mdettweiler
Just wanted to stop by and join in the fond remembrance of Lennart. As Gary mentioned, he invested a lot of time and effort (both personal and computational) at NPLB and CRUS, frequently at the times where it was most needed. He had a knack for "showing up with the cavalry" just when we needed a boost to get momentum going or finish an important subproject! :-)
In particular, let me extend a public thank-you to Lennart (whether he ever gets the chance to read it) for all the assistance he provided with debugging PRPNet issues and sharing tips on how to keep the servers running smoothly. That collaboration contributed greatly to making PRPNet the stable and versatile tool it is today.
Thanks Lennart for all you've done for these projects - I think we can safely say they would not be where they are today without your contributions!
|
4)
Message boards :
General discussion :
PRPnet rally at No Prime Left Behind project: April 18-25
(Message 53173)
Posted 4068 days ago by mdettweiler
Hi all,
Yes, I do apologize for the extremely short notice on this one (especially after pulling similarly short notice last time as well)...I've been busy as ever but nonetheless really should have gotten this out much earlier. :-| Hopefully people will still see this in enough time to catch the start of the rally, or at least not miss too much at the beginning...
We will be having another week-long rally on our port 2000 PRPnet port from Wednesday, April 18 at 7:00 PM GMT to Wednesday, April 25 at 7:00 PM GMT. (That is, 3 PM EDT and 2 PM CDT in the United States.) As last time, we'll be focusing on the 14th Drive, which covers the range of k=600-1001, n=1M-2M, and are presently in the vicinity of n=1.12M. Primes found at this level are nice, big juicy ones--they come in at about 1000th-1500th place on the Prime Pages' top-5000 list. :-)
My past announcements here have grown increasingly verbose with each passing rally, so I'll cut out a lot of the largely unnecessary dross this time and cut to the chase. :-) If you are interested in more general information/historical background about the project, you can check out this thread over at the NPLB forum and get a much more concise intro. So without further ado:
-The server for this rally is running PRPnet, on noprimeleftbehind.net port 2000. The line to put in prpclient.ini is:
server=NPLB_2000:100:1:noprimeleftbehind.net:2000
(A cache size of 1-3 pairs is recommended. The tests will be in the vicinty of n=1M-1.1M during the rally. They've been taking about 7-8 minutes apiece on my Core i7-2620M computer with llrAVX; reasonably modern computers without AVX will probably take about 12-18 minutes per test.)
-Any primes you find should be reported as "[your name], NPLB, srsieve, psieve, LLR" at the Prime Pages website.
-Stats for the rally will be posted at http://www.noprimeleftbehind.net and updated hourly. Once the rally is complete, the stats will be archived here.
-If you have any questions about NPLB or the rally, please feel free to post either here or in our main rally thread at the NPLB forum--both places will be monitored by the NPLB admin squad. You can also email me at max@noprimeleftbehind.net.
Hope to see you there!
Max :-)
|
5)
Message boards :
The Riesel Problem :
TRP DC Effort
(Message 49693)
Posted 4130 days ago by mdettweiler
You'd have to ask Lennart to look at the server log. It will indicate when the server expired the workunit. Can you verify when your client was given the workunits vs. when it tried to send them back to the server?
Sure--here's a relevant excerpt from one of the client logs:
[2012-02-15 13:51:17 EST] PG_TRPDC: Getting work from server 10.23.102.251 at port 14000
[2012-02-15 13:51:18 EST] PG_TRPDC: INFO: Server has a limit of 10 work units.
[2012-02-15 13:51:20 EST] PG_TRPDC: PRPNet server is version 5.0.2
[2012-02-15 13:53:49 EST] PG_TRPDC: Could not open file [lresults.txt] for reading. Assuming user stopped with ^C
/* Note: this is where I stopped the client manually. */
[2012-02-15 13:53:49 EST] Total Time: 9:16:55 Total Work Units: 57 Special Results Found: 0
[2012-02-15 13:53:49 EST] Client shutdown complete
[2012-02-15 17:46:14 EST] PRPNet Client application v5.0.6 started
[2012-02-15 17:46:14 EST] User name mdettweiler at email address is max@noprimeleftbehind.net
[2012-02-15 17:52:06 EST] PG_TRPDC: 450457*2^864849-1 is not prime. Residue 7ED4FA19C03CE3A4
[2012-02-15 18:00:31 EST] PG_TRPDC: 275293*2^864851-1 is not prime. Residue 40E87F881701E37B
[2012-02-15 18:04:30 EST] PG_TRPDC: Could not open file [lresults.txt] for reading. Assuming user stopped with ^C
[2012-02-15 18:04:30 EST] Total Time: 0:18:23 Total Work Units: 2 Special Results Found: 0
[2012-02-15 18:04:31 EST] PG_TRPDC: Returning work to server 10.23.102.251 at port 14000
[2012-02-15 18:04:32 EST] PG_TRPDC: INFO: Test for 450457*2^864849-1 was ignored. Candidate and/or test was not found
[2012-02-15 18:04:32 EST] PG_TRPDC: INFO: Test for 275293*2^864851-1 was ignored. Candidate and/or test was not found
[2012-02-15 18:04:33 EST] PG_TRPDC: INFO: 0 of 2 test results were accepted
[2012-02-15 18:04:33 EST] Client shutdown complete
Please ignore the strange-looking IP address in place of the real server location--I'm behind a proxy server and use an SSH tunnel on one of my other computers to get through to the server. (The 10.23.102.251:14000 shown in the log is tunneled to prpnet.mine.nu:14000.) :-) As far as I know, this shouldn't have any bearing on the issue at hand.
|
6)
Message boards :
General discussion :
PRPnet rally at No Prime Left Behind project: February 18-25
(Message 49692)
Posted 4130 days ago by mdettweiler
Hi all,
After a rather long hiatus from rallies at NPLB, we're getting back into the swing of things with another one coming up soon--starting this Saturday, February 18 and running through February 25 a week later! We recently launched a subproject covering k=600-1001 for n=1M-2M, and this rally will be held on the new range to give it a "housewarming". This is our first rally covering n>1M, so we should pull in quite a few big, juicy megabit primes. :-)
I do apologize for the extremely short notice on this--I have been insanely busy in "offline" life of late and wasn't able to post the announcment here until now. The "official" announcement in our own forum (http://www.mersenneforum.org/showthread.php?t=16491) has been up for a few weeks now, so some of you who also keep up with the mersenneforum may already be aware of it. This time of year is a bit tricky to schedule rallies in since it's a popular time for them (ours is bracketed by PrimeGrid PRPnet and BOINC challenges on both ends--though there's a couple days of rest time both ways so there should be plenty of room for people to move their computers around).
For those of you not familiar with the No Prime Left Behind project, is covers a good chunk of the k-ranges for Riesel primes (k*2^n-1)--the counterpart to PrimeGrid's Proth Prime Search (k*2^n+1). Since the inception of PrimeGrid's PPS effort, we have enjoyed a friendly rivalry between the two projects and a good deal of participant crossover. You can find more information in our forum at http://www.mersenneforum.org/forumdisplay.php?f=82, and specifically our welcome thread at http://www.mersenneforum.org/showthread.php?t=9887, which gives a general idea of what our priorities and philosophy are.
Periodically, we hold "rallies", which are much like PrimeGrid's Challenge Series. (I believe our rallies came first, but we don't mind--imitation is the sincerest form of flattery. :-)) The PrimeGrid admin squad has graciously allowed us to announce our rallies here in addition to the usual places (our own forum and a few team forums). Thanks Lennart for spearheading that! :-)
NPLB is not a BOINC project, so we don't even try to compete with PrimeGrid for #1 on the 5000 Largest Primes list. ;-) Instead we aim for second place, to be the premier non-BOINC prime search project on the web. We use much of the same software that PrimeGrid's off-BOINC Project Staging Area uses--PRPnet and LLRnet for primality testing, and ppsieve for sieving. In fact, both projects collaborated on a sieve for k<10000, n=4M-6M which was conducted jointly in NPLB's forum and in the PST forum here. (This sieve in its later stages is now being run here at PrimeGrid in the PPS Sieve subproject.)
Weeklong rallies have tended to be the most popular, so this one will be for a week as well. The rally will start on Saturday, February 18 at 7:00 PM GMT and finish 168 hours later on Saturday, February 25 at 7:00 PM GMT. (For those of you who can't convert GMT to local time :-P, that's 2:00 PM EST and 1:00 PM CST.)
As mentioned above, we're using the same PRPnet software for our rally that PrimeGrid uses in the Project Staging Area. Many of you are therefore already familiar with the PRPnet client, and already have it set up on your machines; if not, you can get the latest version and instructions for using it in the PSA PRPnet thread. The only difference is that instead of PrimeGrid's server= lines as detailed in that thread, you'll need to use this one for NPLB:
server=NPLB_2000:100:1:noprimeleftbehind.net:2000
Note that this is a different server than we've had for our past rallies (port 9000 on the 9th Drive, now running the 13th Drive). The one you want for this rally is port 2000, running the 14th Drive.
A cache size of 1-3 pairs is recommended. The tests will be in the vicinty of n=1M-1.1M during the rally. They've been taking about 7-8 minutes apiece on my Core i7-2620M computer with llrAVX; reasonably modern computers without AVX will probably take about 12-18 minutes per test.
Any primes you find should be reported as "[your name], NPLB, srsieve, psieve, LLR" at the top-5000 website. When you submit your first result to our server, at our next hourly stats update your username will be added to our stats database (see http://www.noprimeleftbehind.net for stats--during the rally the home page will change to an hourly breakdown of all tests submitted on the rally servers). If you're using PRPnet, one of the admins will get your email address out of the logs and add it to our database so you will receive automatic email notifications of primes. You can also post in our teams thread to be added to the team of your choice (or start one if yours is not yet represented at NPLB).
In our last rally, PrimeSearchTeam reclaimed the first place title for the first time since three rallies ago (the intervening titles having been taken by Raiders of the Lost Primes and AMD Users, respectively), returning more than double the amount of results the second-place team (ROLP) did. On the individual side, Lennart (sm5ymt) took the first place title, and Gary (gd_barnes) second place; we had an extremely close race between Vaughan in third place and Lumiukko in fourth. This rally should be an interesting race as always--we've had our fair share of surprise upsets in past rallies, so nothing is guaranteed!
If you have any questions about NPLB or the rally, or are interested in participating, please don't hesitate to post in our official rally thread at mersenneforum.org or here--both places will be monitored by the NPLB admin squad and responded to as quickly as possible. You can also email me at max@noprimeleftbehind.net to ask questions directly.
Hope to see you there!
Max :-)
|
7)
Message boards :
The Riesel Problem :
TRP DC Effort
(Message 49690)
Posted 4130 days ago by mdettweiler
I've been running a couple cores from a laptop on the PRPnet TRP DC port off and on for the last week or so. Since I use the laptop for "real work" as well, I need to turn off the PRPnet clients during parts of the day when I'm carrying the computer around and running it on battery. However, I've noticed that my reserved candidates on the server keep expiring--somewhat sooner than they should, in fact, based on the expiry deadlines reported on the server.
As an example, I had the clients running (with a batch size of 10 each) earlier today up to about 2:00 PM EST. I then turned off the clients until about 5:30 PM or so when I got back home; yet when I did so, the results were rejected by the server. I checked ]http://prpnet.mine.nu:14000/all.html and saw that my candidates were no longer listed in the pending tests table, even though the deadline is 8 hours and it had been much less than that (only about 3.5-4 hours) since the clients had last communicated with the server. The laptop's CPU is a Sandy Bridge i7 dual-core and I'm running llrAVX, so it's quite fast and definitely wasn't having any problems finishing the tests in time. When I last checked it was taking about an hour to get through a batch of 10 candidates.
Does anyone know why this is happening? Are older tests perhaps being expired manually from the backend prior to the 8 hour deadline?
Thanks,
Max :-)
|
8)
Message boards :
General discussion :
Lowest prime listed on your Top 5k page
(Message 49353)
Posted 4136 days ago by mdettweiler
How about this one?
http://primes.utm.edu/primes/page.php?id=7845
at a whopping 23225 digits. Added on June 2001 and it survived about 11 weeks. I don't know how NBLB got it added to their project. It was added before their project even existed. I guess I need to talk to Chris Caldwell about it.
I think it is more interesting to have a collection of primes from different projects (or different comments). At the time (back in 2005) I had the largest known Cullen and Woodall primes, found within weeks of one another and both in top 100. The Woodall found in 2007 is not mine, although he did use my software. I should ask Chris to remove my name from it.
Ah, yes...I can see how that would be a bit confusing. :-) When NPLB got started in 2008, we actually did so as an extension of the existing PrimeSearch project that previously worked the k=300-1001 range; Gary had talked with Michael Hartley, PrimeSearch's founder, and had received his go-ahead to continue the project, which by then had lapsed into inactivity due to website hosting issues. For the first year or so NPLB actually still used the old "PrimeSearch" code at the top-5000 for all its primes, until Gary got around to emailing Chris Caldwell about updating the project entry to reflect the changes to its organization, at which point the code was renamed to "NPLB". The projects are in fact one and the same, hence the "grandfathering" of prior PrimeSearch primes (of which 50-60 or so remained on the list at the time) into the NPLB label.
|
9)
Message boards :
Project Staging Area :
llrCUDA testing
(Message 46921)
Posted 4163 days ago by mdettweiler
is it possible to check primes from here http://www.mersenneforum.org/showpost.php?p=145066&postcount=1 with llrcuda?
Yes, but llrCUDA will only be able to say that they're PRP (probably prime), which has already been verified in the case of these numbers. What's tricky about them is that they are not of the standard k*b^n+-1 form (the 1 at the end is something else) and thus the LLR test doesn't work on them; LLR can only perform a PRP test. As it turns out, the only way to prove full primality for these numbers is by using the ECPP method, which is much slower--to the point that a prime LLR could do in 30 seconds would take millions of years to prove with ECPP on a modern computer. Hence, why the progress of proving the remainder of the numbers listed there is rather gradual.
|
10)
Message boards :
Project Staging Area :
llrCUDA testing
(Message 46706)
Posted 4166 days ago by mdettweiler
The GTX550 should produce the same error like GeneferCUDA on the same card.
This problem seems to have all cards with a 192bit memory interface and 1GB VRAM like the GTX460_V2...
I tested it some months ago at prpnet with my GTX550Ti, before I tested Genfercuda. Curiously, without Problems. I'd running PPSE (before the port retired), 121, 27 and also Riesel Prime and Twin Prime search on ports from NPLB.
Only the LLR search of Operation Megabit Twin failed, but I did not analysed this.
But runtimes and especially CPU utilization did not convince me, actually LLR runs much more efficient on CPU.
Regards Odi
Your observations make sense. As far as I can determine, the problem with the 550 TI isn't actually a malfunction. The GPU is just a little bit different, and in this particular instance (for reasons not fully understood) the code executes differently enough such that slightly more rounding errors occur.
Rounding errors are a correct and normal consequence of how these programs work. As long as you can ensure that the rounding errors don't actually change the numbers you're working with, that's fine. It's only when the rounding errors accumulate and get large enough to actually affect the significant portion of the numbers that there's a problem.
With small numbers (e.g., PPSELow), this doesn't make a difference, but with larger numbers (GFN or Megabit) the rounding errors are getting close to affecting the actual data. For some reason, the rounding errors seem to be slightly larger on the 550 TI. That "slightly" is just enough to make a difference when the numbers you're working with are pushing the precision limitations of the software.
As a side note, I think the root of the problem is actually a bit different in the case of Operation Megabit Twin candidates; I've tested llrCUDA myself before on numbers of all sorts of sizes (including others at n=1000000, which is where OMT searches), and they did fine. The tricky part with OMT is that it's a fixed-n search, which means k gets increasingly larger as the search progresses--much like PrimeGrid's Sophie Germain Search project. llrCUDA has a much lower maximum-k limit than CPU LLR, which is why it fails on present-level OMT candidates. (That is, it's an algorithmic limit of llrCUDA as presently written, rather than simply a point at which rounding errors become critically large as in GeneferCUDA.)
Regarding llrCUDA's speed, one thing to keep in mind is that GPU primality-testing programs tend to do best on large candidates. For GeneferCUDA, rounding errors keep it from working on small n's to begin with, so it's only used on large n's where the GPU boost is significant (typically, where the tests would take multiple days on a CPU and minutes or hours on a GPU depending on how fast it is). llrCUDA, however, *can* be used on large and small candidates alike, in that it will complete the test successfully and produce an accurate result; but the smaller the candidate, the less advantage it has over a CPU, to the point where sufficiently small candidates are actually slower on a GPU than a CPU. Basically, llrCUDA will see the biggest speed advantage on long tests like those done in the PSP, SoB, Woodall and Cullen subprojects (and the mega-prime search on PRPnet).
To put this into perspective with an example, in my earlier testing (on a slightly-factory-overclocked GTX 460 with 768 MB RAM), I found that the GPU was about as fast, throughput-wise, as two cores of a Q6600 combined in the vicnity of n=1M (1e6). By contrast, the same version (this was a few versions back) could complete SoB tests (n=25M or so) in less than two days!
|
Next 10 posts
|
