Re: Mersenne: P-1
-Original Message- From: George Woltman <[EMAIL PROTECTED]> To: Daran <[EMAIL PROTECTED]>; [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: 24 July 2001 21:17 Subject: Re: Mersenne: P-1 >I'll see if I can work out a solution with Scott. A minimum solution would >have >the server return whether or not the exponent has already had P-1 factoring >done. Better, perhaps (but more work to implement) would be to have the server return the B1 and B2 values used. The client could compare these to the values it would use if it were going to do this, based upon its available memory, and caculate whether a rerun would be economical. >A better solution would include giving CPU credit for P-1 >factoring and making it a separate work type. That might be a little complicated, since a machine which has high memory availability only at night might be better off getting two different types of work to do. >I'll keep y'all posted. > >Best regards, >George Daran G. _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Re: Mersenn: 1000 Barrier
Russel Brooks wrote: > > I've been with GIMPS for about two years and yesterday achieved > a personal milestone; I finally broke thru the 1000 barrier and > made it to 996 on the top producers list. Each step forward is > getting smaller and smaller though; I think I'm approaching the > knee of the curve and will eventually start going backwards. > > ID: rlbrooks > 866MHz P3 & 450MHz P2 (& 133MHz P1 doing factoring) Was glad to hear that you seem likely to keep moving forward for a while. I have been playing here for almost 3 years, and have been in the 500's or 600's for a while. I have a P166 factoring, a PIII-650 double-checking (it's at work, and I don't want to share the fame and glory of finding a new prime with my employer). At home, I just upgraded a dual Celeron 500MHz to dual P-III 1GHz, and a Celeron 333MHz to P-IV 1.3GHz, so I should crack the 500 barrier among top producers fairly soon. After that I may have one of my dual processors work on something else (if that speeds up the other significantly). Great fun, ain't it? Gerry -- mailto:[EMAIL PROTECTED] _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Resurrecting an lapsed machine?
You could even make a shadow mprime install on your own pc that you use exclusively to keep your mothers exponent alive. You could also set the auto check in time on your mothers machine to a large value. (maybe even + holidays (on / no comm) when you are there) - Original Message - From: "Daran" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, July 24, 2001 10:07 AM Subject: Mersenne: Resurrecting an lapsed machine? > I've just noticed in my personal account report, that I've only got the one > machine listed. I should have two (this one, and my mother's.) The most > likely explanation is that her machine is configured to comunicate manually, > and she hasn't been doing this. > > I visited her a couple of weeks ago, and it was still happily hacking > through a DC. I won't be visiting her for some time, and I can't ask her to > do any more than trivial admin. Would it be sufficient just to tell her how > to set it to automatic communication? Would this upset the primenet server? > > Regards > > Daran G. > > > _ > Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm > Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers > _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: P-1
Hi, At 06:35 AM 7/24/2001 +0100, Daran wrote: >As far as I can tell, both first time and DC LLs do P-1 factoring, but not >trial factoring. (I suspect they will trial factor first if the exponant >has not already been trial factored far enough, but I don't recall >encountering this.) Both will do trial factoring if necessary. It is pretty rare that a DC needs more trial factoring. >if the historical error rate for P-1s is the same as for LLs, >(which is a reasonable assumption, given that they use the same FFT code*), >then the probability of a second P-1 (using the same bounds) finding a >factor that a first misses will be about 1% of this, i.e 0.02-0.05%, and >only a single DC would be saved. Clearly not economical. You are correct. Since P-1 factoring was introduced over a year ago, I'm sure there have been quite a few needless P-1 runs. This happens primarily on triple-checks and first-time tests that were abandoned after the P-1 run completed. On the plus side, double-checking has still not reached the point where first-time checking was when P-1 factoring was released. > >Saying all that doesn't mean we couldn't break out work into more work > >unit types, it would just mean we'd also have to have a factoring DC work > >unit type if it was to be removed from the LL runs. I'll see if I can work out a solution with Scott. A minimum solution would have the server return whether or not the exponent has already had P-1 factoring done. A better solution would include giving CPU credit for P-1 factoring and making it a separate work type. I'll keep y'all posted. Best regards, George _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Resurrecting an lapsed machine?
I've just noticed in my personal account report, that I've only got the one machine listed. I should have two (this one, and my mother's.) The most likely explanation is that her machine is configured to comunicate manually, and she hasn't been doing this. I visited her a couple of weeks ago, and it was still happily hacking through a DC. I won't be visiting her for some time, and I can't ask her to do any more than trivial admin. Would it be sufficient just to tell her how to set it to automatic communication? Would this upset the primenet server? Regards Daran G. _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Re: Mlucas FFT Timing Questions...
Michael VAng <[EMAIL PROTECTED]> writes: > Does there only need to be one FFT line in mlucas.cfg, for the one that > matches your exponent, or do they all have to be there? I've run tests > for the FFT that matches my exponent (352K), but I really do not want to > run tests for all of them... Especially since there are two possible > binary versions for my system... You only need the one for your current FFT length, although if you've got several exponents queued up and they will use different FFT lengths, you'll want to make sure you have an entry for each length. Also, even if you keep the full set of FFT lengths in the .cfg file, it's not necessary to tune each entry prior to running the program - your current FFT length is the only one for which it matters to have the optimal radix set, obviously. > The times between having error correcting on and having it off are not > that far apart in some cases... The shortest non-error corrected time > (33.4s for prefetching off/radix 2) is very close to the shortest error > corrected time (36.0s for prefetching on/radix 6)... In this case would > using error correction be advisable? IMO, a speedup of 7% is nothing tp sneeze at. Also note (as explained in more detail below) the program always does at least the first few hundred thousand iterations with error checking on, and then decides whether to leave it on or turn it off for the rest of the run, depending on whether any roundoff error warnings were generated in this initial phase. Also note: It's not error CORRECTION that's going on, it's error DETECTION, in the sense that if your current exponent is really close to the limit your machine's floating-point precision allows, and you happen to get a dangerously large roundoff error at some point in the computation, the program will be able to detect it and either warn you, or (if the error is dangerously close to the 0.5 mark, at which point it's a coin toss as to whether the number in question should have been rounded up or down) halt the current run. Currently the program can't automatically restart the aborted run and work around the error (there will be such a capability in the next release), but users can do this manually, as follows: 1) temporarily switch to a different FFT radix set than the one that was being used; 2) restore the exponent to the worktodo.ini file; 3) restart the program (which will restart from the last savefile); 4) assuming it gets safely past the problem iteration to the next checkpoint, switch back to the original (and presumbaly more efficient) radix set. Yes, it's not very elegant. but it happens rarely, and as I said, will be automated in the next release a few months from now. But I digress - note that you don't have the simple option of turning off error checking in production (as opposed to interactive timing) runs - instead, on line 4 of mlucas.cfg there is a number N which tells the program ``do at least the first N iterations of every LL test with error checking on.'' If the run of a given exponent gets to this point with no roundoff error warnings, error checking is turned off for the rest of the run. If there were error warnings in the first N iterations, error checking remains on for the rest of the run. On some systems running sans error checking is not significantly slower than running with it, and on these you might want to make N large enough (i.e. larger than the largest exponent you plan to test in the near future, but still small enough to be interpreted as a positive 32-bit signed integer) that error checking is always on. (On my Alphas things run 5-7% faster sans error checking, so I don't do things this way). Hope this helps, and sorry about the long-winded explication. -Ernst _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
