LLRnet rally Apr. 30th to May 2nd

[mdettweiler]

I've moved my dualcore to the rally server now, and I see that vaughan and gamer007 are present in kind as well. I'll move my quad over tomorrow morning, and Gary mentioned yesterday that he'd move the rest of his machines probably sometime tonight, which makes for an additional good-sized handful of cores.

Anyone else gonna show up? Remember that the rally starts at 7 PM GMT tomorrow (or 3 PM EDT/2 PM CDT), so if you're planning to participate you'll want to get your cores moved over soon so as to not miss the start of the rally!

[gd_barnes]

I'll be moving the rest of my machines over mid-morning Friday.

[kar_bon]

Here is a small batch to start several LLRnet-clients with one call (for WIN):

Assume there're 4 folders, each folder contains all files of a LLRnet-client, like:

[client1]
[client2]
[client3]
[client4]
run_all.bat

Now create the file "run_all.bat" with these lines:

@ECHO off
start "LLRnet 1" /Dclient1 /MIN do.bat
start "LLRnet 2" /Dclient2 /MIN do.bat
start "LLRnet 3" /Dclient3 /MIN do.bat
start "LLRnet 4" /Dclient4 /MIN do.bat
EXIT

Calling "run_all.bat" (or doubleclick) will start all 4 clients in a separate window.

Karsten

[gd_barnes]

Interesting. Just to clarify for everyone: The run_all.bat batch job is one directory "above" the LLRnet client folders. Is that correct?

I'm asking because initially I didn't know how run_all.bat would know which subdirectory (folder) to find do.bat in.

Vaughan, this would be very helpful getting much of your pharm moved over.

[kar_bon]

Yes, 'run_all.bat' is one dir-level above all client-folders.

And the parameter '/D' from command start, gives the directory to start the program/command from.

If needed, I also can provide a batch for a local LLRnet-server and several clients, too:
Starting the llrserver first and then all clients!

[mdettweiler]

Quad moved over now. This is the first time I'm running the new LLRnet clients on that machine (it having used almost exclusively PRPnet for the last year or so), so I had to install the new clients...it was a quite a bit of a pain due to the hassle involved in adding four new application services manually. (I had to do the same thing with the old LLRnet client a while back and then with PRPnet later--because LLRnet's built-in service mode doesn't work with Vista and PRPnet doesn't have one.) But now that it's over and done with, I should be able to switch back and forth between PRPnet and new LLRnet in the future with reasonable ease.

[vaughan]

Added one AMD X2 6000 using the old LLR. Its just too hard to do the new stuff via LogMeIn when I'm over 300KMs away from the machines from my iPhone.

[gd_barnes]

The rally started about 1-1/2 hours ago. Good luck everyone and may you all find a prime!

It looks like Vaughan already found a prime just a little more than an hour before the rally started.

So no one is disappointed: There is one already-known prime in the range that we will likely find during the rally: 405*2^765777-1

At our current rate, we're running about 2n per minute, so for 2880 minutes, we would process a range of n=~5700 for the rally (allowing for a small amount of test time increase as we go higher), which would put us near n=769K at the end. Hopefully a couple of others will join the fun and we'll make n=770K.

I (think) we have one new person for the rally: Jamers. Welcome to NPLB Jamers! Let us know if you have any questions. You can also choose to join a team or give us your Email and we can have any primes found automatically Emailed to you.


Gary

[kar_bon]

Originally Posted by gd_barnes

I (think) we have one new person for the rally: Jamers. Welcome to NPLB Jamers! Let us know if you have any questions. You can also choose to join a team or give us your Email and we can have any primes found automatically Emailed to you.

He's an 'old-timer'! See here: member of AMD Users, place 45 by knpairs-points at NLPB for now.

[mdettweiler]

Originally Posted by gd_barnes

So no one is disappointed: There is one already-known prime in the range that we will likely find during the rally: 405*2^765777-1

At our current rate, we're running about 2n per minute, so for 2880 minutes, we would process a range of n=~5700 for the rally (allowing for a small amount of test time increase as we go higher), which would put us near n=769K at the end. Hopefully a couple of others will join the fun and we'll make n=770K.

I ran the numbers through your odds of prime spreadsheet and got the following (for the range of 764K-770K):

Odds of all candidates 89.964%
1 in 1.11
expected # of primes 2.299

If you subtract 1 prime from there to account for the already-known prime, that leaves only 1.299 primes to be found during the whole rally at this processing rate. Eh? Only one new prime? (And of course, with my 6 cores only making up a small fraction of our total rally resources, the chances of me being the lucky guy are even more dismal. )

Come on guys, we can do better than that!

[Mini-Geek]

Originally Posted by mdettweiler

If you subtract 1 prime from there to account for the already-known prime, that leaves only 1.299 primes to be found during the whole rally at this processing rate.

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 unsearched 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.
To take it to the extreme:
Say we find 5 primes in the first n=1000. Now how many do you expect in the rest of the range? About 2.299-5 or around 2.

(to put it in slightly more technical terms: whether a number is prime is independent of whether any other number that happens to be near it is prime; they are independent events, not dependent events, so past events do not influence future events)

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.

Boy, I sure said the same thing in a lot of ways!