LLRnet rally Apr. 30th to May 2nd

[mdettweiler]

Originally Posted by Mini-Geek

Fortunately, you shouldn't do that.
The expectations deal with unknowns. If you expect 2.299 in the whole range, but know one of them to be prime, you still expect 2.299 in the whole range (minus some small amount for the removal of the one known-prime candidate; in some cases of ridiculously small numbers this might actually be significant).
It's more like this:
For each number, what fraction of the expected number of primes should we expect to find there?
Or another way:
For untested numbers, you should expect 1*(expected number, ignoring other factors). For single-tested numbers, assuming a 0.1% error rate, you should expect 0.001*(expected). For double-tested numbers, assume a 2^-64 chance of a false negative, so 2^-64*(expected). But for known primes, you can assume a 0 chance that it's an undiscovered prime.
Or to think of it a different way:
What if we happened to accidentally not include 405*2^765777-1 in our file. We would still expect 2.299 primes.

It would be more accurate to remove that one prime from the equation (so have one less candidate in the file...not a big difference ) and, for any others that we know or think to have been checked once, (e.g. k=405 in the range seems pretty likely) divide their chance of a prime by, say, 1000, and for any we know or think to have been checked twice, divide their chance of a prime by, say, 2^64.

Ah, right, that makes sense when you put it that way. Well, that makes me feel a little better...2 new primes and 1 confirmed prime is not too terribly bad for a 48-hour rally given our current level of participation and the size of the numbers being tested.

[mdettweiler]

As I mentioned over in the 5th Drive thread, Lennart sent me an email not long ago informing me that he was interested in joining the rally. Since all of his clients are set up for PRPnet 3.x and not for LLRnet (and for such a large farm, it would be a huge pain to switch them over for just 48 hours), I've set up a new PRPnet 3.2.5 server on port 9000 and loaded it with 780K-785K from the 5th Drive. Lennart has informed me that his clients have received work and are now happily crunching away.

Of course, this is by no means exclusively for Lennart's use--anyone else who wants to give the new server can feel free to use it. Note that due to the short notice on this, I don't have the latest PRPnet client packages posted over in the PRPnet thread; however, they can be downloaded from PrimeGrid's website just as well. You can also use the old 2.4 clients if you want, though doing so may void your warranty. (Seriously, in my experience they do work with 3.x servers, but not always as smoothly as they should--error messages here and there, etc.)

As with our previous PRPnet servers, a status report for this server can be found at:
http://www.noprimeleftbehind.net/prpnet/
Note that since PRPnet 3.2.5 stores its candidates in a database, my status page generator script cannot access them like it can for an LLRnet server. Therefore in place of such info I've put up links to the server's own built-in status pages, which provide more or less the same information my script would.

Since this is for a rally, time is of the essence when it comes to getting results into the DB, so I finally did what I'd put off for months with the old PRPnet servers (!) and which turned out to be not so hard as I'd thought: I set my backend scripts to copy off the PRPnet server results every 15 minutes, like with the LLRnet servers, so they will be imported into the DB that often. The only discrepancy is that all times on the results are 5 hours behind since PRPnet reports times in GMT rather than local time like LLRnet does (and therefore as the DB expects); unfortunately, I didn't have the time to dive into reprogramming my PRPnet-to-LLRnet results conversion script to convert the times to CDT, so the times will just have to be 5 hours off for now. If we need to retroactively fix the times in the DB so that it doesn't thow off the rally stats, it shouldn't be too hard to code up a script to do it.

[Lennart]

Hehe That was fast "User sm5ymt has found 1 prime, 1 is hidden"






Lennart

[mdettweiler]

Originally Posted by Lennart

Hehe That was fast "User sm5ymt has found 1 prime, 1 is hidden"






Lennart

Bah, I though I told that thing not to hide the primes...and to send notification emails, too. Oh, wait...I forgot, it can take up to 10 minutes for primes to show up. Perhaps the same holds true for emails?

[Lennart]

Originally Posted by mdettweiler

Bah, I though I told that thing not to hide the primes...and to send notification emails, too. Oh, wait...I forgot, it can take up to 10 minutes for primes to show up. Perhaps the same holds true for emails?

Yes it can take some minutes.. btw it was allredy found last year :(

Lennart

[mdettweiler]

Originally Posted by Lennart

Yes it can take some minutes.. btw it was allredy found last year :(

Lennart

Oh, right...that one. Whoops.

BTW, I see that it's shown up on the server report page now but hasn't generated an email; do those generally happen at the same time, or does the email still take a while longer? (Hmm, wouldn't it be something if the DB actually got its email out before PRPnet did? Considering the end of the hour is near, it may well do that...)

[mdettweiler]

Originally Posted by mdettweiler

Oh, right...that one. Whoops.

BTW, I see that it's shown up on the server report page now but hasn't generated an email; do those generally happen at the same time, or does the email still take a while longer? (Hmm, wouldn't it be something if the DB actually got its email out before PRPnet did? Considering the end of the hour is near, it may well do that...)

Aha, I think I see what the problem is. The email never went out--well, the server tried to send it, but failed. It seems that it's trying to authenticate to the SMTP server using "AUTH LOGIN", yet emailpassword= is left blank in prpserver.ini to indicate that authentication should be turned off (correctly so, since the SMTP server is on localhost and doesn't require authentication). I compared the prpserver.ini files between this server and the G7465 test server that we ran a while back on version 3.2.0, and found no relevant difference between the two--yet I know that one's emails worked (correctly NOT authenticating). Therefore this must be something that cropped up since that version.

I'll send the log file to Mark and see if he can see what's wrong. Meanwhile, though, the problem is not of particular consequence since the DB can handle notifications just as easily, and the only one that was missed altogether was a confirmed prime anyway. Since we've been aware of that one since practically the moment it was found, that's no big deal.

[mdettweiler]

Originally Posted by mdettweiler

Aha, I think I see what the problem is. The email never went out--well, the server tried to send it, but failed. It seems that it's trying to authenticate to the SMTP server using "AUTH LOGIN", yet emailpassword= is left blank in prpserver.ini to indicate that authentication should be turned off (correctly so, since the SMTP server is on localhost and doesn't require authentication). I compared the prpserver.ini files between this server and the G7465 test server that we ran a while back on version 3.2.0, and found no relevant difference between the two--yet I know that one's emails worked (correctly NOT authenticating). Therefore this must be something that cropped up since that version.

I'll send the log file to Mark and see if he can see what's wrong. Meanwhile, though, the problem is not of particular consequence since the DB can handle notifications just as easily, and the only one that was missed altogether was a confirmed prime anyway. Since we've been aware of that one since practically the moment it was found, that's no big deal.

Actually, scratch that--would you know, I switched the server over to use the RoadRunner SMTP server directly (rather than talking to the local SMTP server which forwards to the RR server), and it worked shortly after. The strange thing is, though, a look through the logged communication with the SMTP server reveals that it didn't try any of the weird "AUTH LOGIN" stuff--so it seems that it must have been doing that for some other reason earlier. At any rate, whatever was the matter, it's fixed now...I'll continue to poke around as we find more primes and I get the opportunity to see this in action again. This might be one of those strange "random flukes" that happen once in a while due to some hidden misinterpretation of a config file that was fixed after I poked around with the config file when I diagnosed the problem.

BTW @Gary: if all this talk about SMTP server stuff is confusing the heck out of you, don't worry about it. It's not affecting anything critical (since the DB sends out its own email notifications which we know work fine).

[AMDave]

Stats are up
apologies for the delay
CDT is GMT -5 atm from what I can tell
there were some bugs in the rally script and rally page due to minor changes to the db in the last 12 months
should all be fixed now.

Maybe I'll get a client running myself tonight :D

[gd_barnes]

I'll just ignore the techie talk about the PRPnet server. It sounds like it's under control.

And...it goes without saying...thanks a bunch for joining the rally Lennart! It's nice to finally put a little more dent in these higher n-ranges.

[mdettweiler]

I've added a table of primes found during the rally to the first post of this thread. So far it's just Lennart's two (one confirmed and one new), but I see jamers has found a (not yet reported) confirmed prime as well.

Edit: Whoops, I forgot about Gary's that I got a notification of earlier today (and which he just reported). I'll add that now.