Re: Mersenne: V20 beta #4 (will the beta never end?)
Hi all, Seeing that not every time a stage 1 gcd will result in a factor found, are we not better to wait until the end of stage 2? This way, we could factor deeper. Perhaps this could be yet another option? some preleminary data (on my machine at home): Total P-1 test = 91 Stage 1 factor = 2 Stage 2 factor = 1 So on my machine the stage 1 gcd saved me 2 stage 2, so about 2 hour of cpu, but at the cost of about 90 * 230 sec of stage 1 gcd = 20700sec or 5:45 hours. Seems to me that we could save a little bit by forgoing stage 1 gcd. regards, David Campeau _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: V20 beta #4 (will the beta never end?)
On 20 Apr 00, at 7:47, David Campeau wrote: Seeing that not every time a stage 1 gcd will result in a factor found, are we not better to wait until the end of stage 2? This way, we could factor deeper. Perhaps this could be yet another option? Maybe I'm guilty here; the very first pre-pre-release didn't run the GCD after Stage 1 unless an "undocumented" option was set in prime.ini (Stage1GCD=1). I commented on this to George and he changed it. My reasoning was that early timings on exponents typical of "real" PrimeNet assignments seemed to suggest that it made sense to run the Stage1 GCD automatically. There's also a slight edge in clarity from this approach. If you run a GCD at the end of each stage then you know where you are. If you run GCD only at the end of Stage 2 but then don't run Stage 2 because of memory constraints (which is effectively the default option, given DayMemory = NightMemory = 8 MBytes) you might as well not bother running Stage 1 either, since you won't find any factors that Stage 1 uncovered until you eventually run the GCD. There's another consideration, too, in so far that running Stage 2 is expensive in terms of memory resources; avoiding this complication tends to push the balance in favour of running the extra GCD. However, there may be a case for changing the strategy - either just running one GCD when you're not going to go any further, or to (optionally) omit the Stage 1 GCD. This becomes more relevant as exponent sizes increase, as the stage run time appears to be (more or less) linearly related to both exponent size and B limit, whereas the run time of the GCD is independent of the B limit but increases very non-linearly with exponent size. The cost/benefit of running the extra Stage 1 GCD is zero if GCD run time is equal to Stage 2 run time * probability of finding a factor in Stage 1. If the GCD runs more quickly than this, it's definitely worth running. The point is that running Stage 2 is a waste of time if you already have a factor in Stage 1 but you just haven't bothered to unearth it. If you're working with small exponents, it may be that, although the extra GCD is relatively cheap, it's still not worth running it because e.g. heavy trial factoring has made the chance of actually finding a factor in Stage 1 very low - i.e. in this case we're running Stage 1 only as a means of getting to Stage 2. It _may_ be sensible cost effective to automate this decision (i.e. "guess" the probability of finding a factor in Stage 1 from the B1 limit and the trial factoring depth, and estimate the GCD Stage 2 run times) use that as the default option. In which case we should probably have manual override capability in _both_ directions. Regards Brian Beesley _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: V20 beta #4 (will the beta never end?)
Hi, At 07:47 AM 4/20/00 -0400, David Campeau wrote: Seeing that not every time a stage 1 gcd will result in a factor found, are we not better to wait until the end of stage 2? This way, we could factor deeper. Brian Beesley's timings showed that running the Stage 1 GCD will save time in the long run for exponents above 4 or 5 million. Perhaps this could be yet another option? It is an option. Set Stage1GCD=0 in prime.ini. some preleminary data (on my machine at home): Total P-1 test = 91 Stage 1 factor = 2 Stage 2 factor = 1 So on my machine the stage 1 gcd saved me 2 stage 2, so about 2 hour of cpu, but at the cost of about 90 * 230 sec of stage 1 gcd = 20700sec or 5:45 hours. Seems to me that we could save a little bit by forgoing stage 1 gcd. I know you are working on the smallest double-checks (about 3 million or so). Thus, it is not surprising you would be better off not running the stage 1 GCD. First-time testers will be better off running the stage 1 GCD, and most double-checkers will be neutral to slightly better off. The GCD cost grows at an N (log N)^2 rate. The stage 2 cost grows at N log N (the cost of an FFT multiply) times something (the stage 2 bounds grow as N increases). I don't know if that something is O(N) or worse. It doesn't matter. It does show that at some point you are better off doing the stage 1 GCD for a 2% chance of saving the cost of stage 2. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: V20 beta #4 (will the beta never end?)
From: George Woltman [EMAIL PROTECTED] To: "David Campeau" [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Mersenne: V20 beta #4 (will the beta never end?) Date: Thu, 20 Apr 2000 11:43:46 -0400 Hi, At 07:47 AM 4/20/00 -0400, David Campeau wrote: Seeing that not every time a stage 1 gcd will result in a factor found, are we not better to wait until the end of stage 2? This way, we could factor deeper. Brian Beesley's timings showed that running the Stage 1 GCD will save time in the long run for exponents above 4 or 5 million. This will, of course, be almost every exponent within a month or so of v20's release to the public - as it stands, most of the lower exponents are being taken by those of us who connect immediately after they expire. some preleminary data (on my machine at home): Total P-1 test = 91 Stage 1 factor = 2 Stage 2 factor = 1 So on my machine the stage 1 gcd saved me 2 stage 2, so about 2 hour of cpu, but at the cost of about 90 * 230 sec of stage 1 gcd = 20700sec or 5:45 hours. Seems to me that we could save a little bit by forgoing stage 1 gcd. Of course, some users will be inconvenienced by the memory usage in Stage 2 and may want to take that into consideration. Since I myself have 128 megs of memory, and rarely run anything except Netscape, AIM, MS Office and shareware games, P-1 for PrimeNet is not a major problem for me, aside from the slight delay in my assignments when I get new work. I know you are working on the smallest double-checks (about 3 million or so). Thus, it is not surprising you would be better off not running the stage 1 GCD. First-time testers will be better off running the stage 1 GCD, and most double-checkers will be neutral to slightly better off. And, of course, double-checkers tend to be people who have more of an interest in the project, and may be running multiple clients. They are, therefore, more likely to take the time to analyze the documentation. Not to be stereotyped, that's just a general pattern that my common sense leads me to expect. The GCD cost grows at an N (log N)^2 rate. The stage 2 cost grows at N log N (the cost of an FFT multiply) times something (the stage 2 bounds grow as N increases). I don't know if that something is O(N) or worse. It doesn't matter. It does show that at some point you are better off doing the stage 1 GCD for a 2% chance of saving the cost of stage 2. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers __ Get Your Private, Free Email at http://www.hotmail.com _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: V20 beta #3
A question to all you linux users with modems: I assume that the /proc/net/route file exists when you are not connected. Let me know if this is not the case (I'll need to change the default setting of RouteRequired above). I have a modem and an Ethernet card on one box. The file exists whether I'm on or off line, but the "ppp0" lines are there only when I'm on line. To tell when you're on line, look for a gateway in the "Flags" column, which says 4003 for the gateway and 1 for an Ethernet connection. (I don't know which bit means gateway.) This will work only if the dialup machine is the one running mprime. If mprime is behind an IPmasq box, you have to ask the IPmasq box if it's online. phma _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: V20 beta #3
On Sat, 15 Apr 2000, Brian J. Beesley wrote: On 15 Apr 00, at 4:22, Henrik Olsen wrote: I just tried downloading 20.3, both mprime and sprime, as well as tried with mprime 19.0.2 . None of them where able to detect the network as being available on a machine running Mandrake Linux, kernel version 2.2.14-15mdksecure, probably due to /proc/net not being readable by non-root on such a system, which is a bit of a bummer, as I as I don't want to have to run it as root. :( Does a solution exist for running mprime on such a system or will I have to use this one as well for SNFS sieving instead of GIMPS? Could I suggest three things to try: 1) Install mprime with suid privelege. This should enable mprime to read /proc/net as though it were running under root even though it's actually running under an unpriveleged user. With all the respect due to George, I haven't seen anything to indicate that mprime was written with suid in mind, with in any security concient person would raise big red flags when contemplating this solution. Actually, if I setuid it, I might as well run it as root, which is what I wanted to avoid in the first place. 2) Get out your hacker's hat and fix the problem in the source code. I'd guess that all you need to change is the code which creates the /proc pseudofilesystem at boot time. As you've probably found, you don't seem to be able to change the permissions on "files" in the /proc tree on a running system - even if you _are_ root. There isn't one piece of code generating the /proc fs, it's done dynamically by linking in inodes with relevant callback functions for the operations on them, one call passing one struct per inode, so it can happen everywhere and tracking down the call/struct for a specific inode is a real pain. 3) Is Mandrake really linux, or just a linux clone? I think the latter. If I'm right, then perhaps switching to a genuine linux (Red Hat, or SuSe) might be a sensible thing to do. Though the official Red Hat distribution retail package is expensive, you can get just the CD for about $2, or download the distribution FoC (not reccomended unless you have fast internet access!) Mandrake is really Linux (whatever that means), it's essentially RedHat with the security holes fixed, and all rpm's compiled for the Pentium. (as for my connection it's only 2Mb/s) Regards Brian Beesley -- Henrik Olsen, Dawn Solutions I/S URL=http://www.iaeste.dk/~henrik/ Should we throw another human wave of structural engineers at stabilizing the Leaning Tower of Pisa, or should we just let the damn thing fall over and build a tower that doesn't suck? Neal Stephenson about cruft, In The Beginning... Was The Command Line _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: V20 beta #3
On 15 Apr 00, at 4:22, Henrik Olsen wrote: I just tried downloading 20.3, both mprime and sprime, as well as tried with mprime 19.0.2 . None of them where able to detect the network as being available on a machine running Mandrake Linux, kernel version 2.2.14-15mdksecure, probably due to /proc/net not being readable by non-root on such a system, which is a bit of a bummer, as I as I don't want to have to run it as root. :( Does a solution exist for running mprime on such a system or will I have to use this one as well for SNFS sieving instead of GIMPS? Could I suggest three things to try: 1) Install mprime with suid privelege. This should enable mprime to read /proc/net as though it were running under root even though it's actually running under an unpriveleged user. 2) Get out your hacker's hat and fix the problem in the source code. I'd guess that all you need to change is the code which creates the /proc pseudofilesystem at boot time. As you've probably found, you don't seem to be able to change the permissions on "files" in the /proc tree on a running system - even if you _are_ root. 3) Is Mandrake really linux, or just a linux clone? I think the latter. If I'm right, then perhaps switching to a genuine linux (Red Hat, or SuSe) might be a sensible thing to do. Though the official Red Hat distribution retail package is expensive, you can get just the CD for about $2, or download the distribution FoC (not reccomended unless you have fast internet access!) Regards Brian Beesley _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: V20 beta #3
Hi,
At 10:56 AM 4/15/00 -0700, Will Edgington wrote:
near line
761 of linux/primenet.c, where there's an fopen("/proc/net/route",
"r") inside an #ifdef __linux__. Look lower down, after the #endif,
and note that __FreeBSD__ doesn't have a similar check; it simply
always returns TRUE. Looks to me like it would be very simple to add
a check for the fopen() failing due to permissions or whatever under
Linux and return TRUE (i.e., that the system is connected to the
network), perhaps based on a new flag in one of the .ini files.
This is a good fix. The next v20 release will return TRUE if /proc/net/route
is not readable. You can keep the current behavior by setting
"RouteRequired=1" in primenet.ini.
A question to all you linux users with modems: I assume that the
/proc/net/route file exists when you are not connected. Let me know
if this is not the case (I'll need to change the default setting of
RouteRequired above).
Regards,
George
_
Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: V20 beta #3
George Woltman wrote:
Hi,
At 10:56 AM 4/15/00 -0700, Will Edgington wrote:
near line
761 of linux/primenet.c, where there's an fopen("/proc/net/route",
"r") inside an #ifdef __linux__. Look lower down, after the #endif,
and note that __FreeBSD__ doesn't have a similar check; it simply
always returns TRUE. Looks to me like it would be very simple to add
a check for the fopen() failing due to permissions or whatever under
Linux and return TRUE (i.e., that the system is connected to the
network), perhaps based on a new flag in one of the .ini files.
This is a good fix. The next v20 release will return TRUE if /proc/net/route
is not readable. You can keep the current behavior by setting
"RouteRequired=1" in primenet.ini.
A question to all you linux users with modems: I assume that the
/proc/net/route file exists when you are not connected. Let me know
if this is not the case (I'll need to change the default setting of
RouteRequired above).
Regards,
George
From memory, it should still exist, as the loopback device will always
be present, and thus there will always be a loopback route.
Kind Regards, Martijn
--
http://jkf.penguinpowered.com
Linux distributies voor maar
Fl 10 per CD, inclusief verzendkosten!
_
Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: V20 beta #3
On Sat, 15 Apr 2000, George Woltman wrote:
Hi,
At 10:56 AM 4/15/00 -0700, Will Edgington wrote:
near line
761 of linux/primenet.c, where there's an fopen("/proc/net/route",
"r") inside an #ifdef __linux__. Look lower down, after the #endif,
and note that __FreeBSD__ doesn't have a similar check; it simply
always returns TRUE. Looks to me like it would be very simple to add
a check for the fopen() failing due to permissions or whatever under
Linux and return TRUE (i.e., that the system is connected to the
network), perhaps based on a new flag in one of the .ini files.
This is a good fix. The next v20 release will return TRUE if /proc/net/route
is not readable. You can keep the current behavior by setting
"RouteRequired=1" in primenet.ini.
A question to all you linux users with modems: I assume that the
/proc/net/route file exists when you are not connected. Let me know
if this is not the case (I'll need to change the default setting of
RouteRequired above).
/proc/net/route exists as long as the kernel is compiled with networking
capabilities, it's the content that varies with the configured devices,
ie. its presence alone is not a good indication whether there's currently
a dialled up connection.
Regards,
George
--
Henrik Olsen, Dawn Solutions I/S URL=http://www.iaeste.dk/~henrik/
ZOOLOGY, n.
The science and history of the animal kingdom, including its king, the
House Fly (Musca maledicta).The Devil's Dictionary, Ambrose Bierce.
_
Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: V20 beta #3
On Sun, 16 Apr 2000, Harald Tveit Alvestrand wrote: At 14:51 15.04.2000 +0200, Henrik Olsen wrote: On Sat, 15 Apr 2000, Brian J. Beesley wrote: On 15 Apr 00, at 4:22, Henrik Olsen wrote: I just tried downloading 20.3, both mprime and sprime, as well as tried with mprime 19.0.2 . None of them where able to detect the network as being available on a machine running Mandrake Linux, kernel version 2.2.14-15mdksecure, probably due to /proc/net not being readable by non-root on such a system, which is a bit of a bummer, as I as I don't want to have to run it as root. :( Does a solution exist for running mprime on such a system or will I have to use this one as well for SNFS sieving instead of GIMPS? Check /etc/fstab. There's a line there that says something like none/proc procsomething 0 0 If you change "something" (whatever that is) to "defaults", and umount and mount /proc, everyone can probably read it. It's already none /proc proc defaults 0 0 in /etc/fstab, the 550 permissions for /proc/net isn't due to a mount option, but looks like it's modified in the source. No idea why Mandrake would choose not to make it world readable It's essentially a paranoid version of RedHat, which is actually a Good Thing (tm), as RH has more holes than a sieve out of the box. Harald -- Henrik Olsen, Dawn Solutions I/S URL=http://www.iaeste.dk/~henrik/ ZOOLOGY, n. The science and history of the animal kingdom, including its king, the House Fly (Musca maledicta).The Devil's Dictionary, Ambrose Bierce. _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: V20 beta #3
Hi, I just tried downloading 20.3, both mprime and sprime, as well as tried with mprime 19.0.2 . None of them where able to detect the network as being available on a machine running Mandrake Linux, kernel version 2.2.14-15mdksecure, probably due to /proc/net not being readable by non-root on such a system, which is a bit of a bummer, as I as I don't want to have to run it as root. :( Does a solution exist for running mprime on such a system or will I have to use this one as well for SNFS sieving instead of GIMPS? -- Henrik Olsen, Dawn Solutions I/S URL=http://www.iaeste.dk/~henrik/ Many are my names in many countries. [EMAIL PROTECTED] among the Elves, [EMAIL PROTECTED] to the Dwarves; [EMAIL PROTECTED] I was in my youth in the West that is forgotten, in the South [EMAIL PROTECTED], in the north [EMAIL PROTECTED]; to the East I go not. With thanks to Tolkien _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: V20 beta #4 (will the beta never end?)
Martijn Kruithof wrote: Hello, all Furthermore since the 20.62 % is completed it is only stepping percentage as fast as the P-1 phase normally went, the other instance finished the P-2 withing 6 hours! (This one clearly not) Could anyone provide me with a beta #3 mprime so that I can rerun the P-2 stage with a backup? Kind Regards, Martijn Hello all, This happened on my machine while switching from beta 3 to beta 4 is this correct? Starting P-1 factoring on M33237229 with B1=33, B2=264 Chance of finding a factor is an estimated 4.08% P-1 on M33237229 with B1=33, B2=264 M33237229 stage 2 is 12.08% complete. Time: 1822.421 sec. (789108274292 clocks) And after installing beta 4: (Stage 1 was not redone!) Starting P-1 factoring on M33237229 with B1=305000, B2=1525000 Chance of finding a factor is an estimated 3.58% P-1 on M33237229 with B1=305000, B2=1525000 M33237229 stage 2 is 20.62% complete. Time: 1767.363 sec. (765268138179 clocks) Furthermore a feature would be very nice that it does not recalculate the bounds without the users consent. (even if it violates the memory bounds) The way to run the memory constraints on a dual machine is by the way configuring day/nighttime differently for the two cpu's as the stage 2 is only very short, it does not matter if that's only 4 hours (it can resume the next day anyway). (i.e.) one has daytime from 6 pm to 6 am, the other from 6 am to 6 pm. (real daytime from 19 to 23 pm might yield : daytime from 19 to 6 and one daytime from 6 to 23) Kind Regards, Martijn -- http://jkf.penguinpowered.com Linux distributies voor maar Fl 10 per CD, inclusief verzendkosten! _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: V20 beta #4 (will the beta never end?)
Hi, At 07:34 AM 4/13/00 +0200, Martijn Kruithof wrote: This happened on my machine while switching from beta 3 to beta 4 is this correct? Starting P-1 factoring on M33237229 with B1=33, B2=264 Chance of finding a factor is an estimated 4.08% P-1 on M33237229 with B1=33, B2=264 M33237229 stage 2 is 12.08% complete. Time: 1822.421 sec. (789108274292 clocks) And after installing beta 4: (Stage 1 was not redone!) Starting P-1 factoring on M33237229 with B1=305000, B2=1525000 Chance of finding a factor is an estimated 3.58% P-1 on M33237229 with B1=305000, B2=1525000 M33237229 stage 2 is 20.62% complete. Time: 1767.363 sec. (765268138179 clocks) The above looks fine! As was mentioned in whatsnew.txt the program now does a better job estimating its memory use. More precisely, beta 3 calculated the amount of FFT data used, beta 4 adds in the sine/cosine and other data used during the FFT process. For your HUGE exponent that's another 4MB or so. So what happened is beta 4 decided it couldn't allocate as many temporary variables for FFT data as beta 3 did. Therefore, stage 2 will be less efficient and thus it is not "worthwhile" to run stage 2 as deep as beta 3 wanted to. Stage 1 was not redone since you had already done more stage 1 than beta 4's new stage 1 limit. Also, since stage 2 bound decreased your percentage complete jumped from 12% to 20%. One final note. Whatsnew.txt indicates a relatively rare bug in computing optimal P-1 bounds was fixed. You probably ran into this case. When beta 3 only had enough memory for 4 temporary variables it computed P-1 bounds assuming it could allocate 5 temporary variables. Furthermore a feature would be very nice that it does not recalculate the bounds without the users consent. (even if it violates the memory bounds) I'm reluctant to do this. I don't want prime95 to get a reputation of degrading performance due to thrashing. Anyway, once you've set your memory parameters and no longer download a new beta every week, then the computed P-1 bounds will not change. The way to run the memory constraints on a dual machine is by the way configuring day/nighttime differently for the two cpu's as the stage 2 is only very short, it does not matter if that's only 4 hours (it can resume the next day anyway). (i.e.) one has daytime from 6 pm to 6 am, the other from 6 am to 6 pm. (real daytime from 19 to 23 pm might yield : daytime from 19 to 6 and one daytime from 6 to 23) That's one way to do it. You should be aware however that if prime95 does not have enough memory to run stage 2 and there is no other work to do, then it will start the LL test. This LL work will be wasted if P-1 later finds a factor. Giving stage 2 only 4 hours a day increases the chance that this will happen - not a major concern, but worth taking into consideration. Best regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: V20 beta #4 (will the beta never end?)
Hello all, This happened on my machine while switching from beta 3 to beta 4 is this correct? Starting P-1 factoring on M33237229 with B1=33, B2=264 Chance of finding a factor is an estimated 4.08% P-1 on M33237229 with B1=33, B2=264 M33237229 stage 2 is 12.08% complete. Time: 1822.421 sec. (789108274292 clocks) And after installing beta 4: (Stage 1 was not redone!) Starting P-1 factoring on M33237229 with B1=305000, B2=1525000 Chance of finding a factor is an estimated 3.58% P-1 on M33237229 with B1=305000, B2=1525000 M33237229 stage 2 is 20.62% complete. Time: 1767.363 sec. (765268138179 clocks) Furthermore a feature would be very nice that it does not recalculate the bounds without the users consent. (even if it violates the memory bounds) The way to run the memory constraints on a dual machine is by the way configuring day/nighttime differently for the two cpu's as the stage 2 is only very short, it does not matter if that's only 4 hours (it can resume the next day anyway). (i.e.) one has daytime from 6 pm to 6 am, the other from 6 am to 6 pm. (real daytime from 19 to 23 pm might yield : daytime from 19 to 6 and one daytime from 6 to 23) Kind Regards, Martijn George Woltman wrote: Hi all, The fourth beta is available. It fixes a few more bugs. See the whatsnew.txt at the end of this email. An upgrade from earlier betas is not required, but it can't hurt. You can download it from ftp://entropia.com/gimps/v20/p95setup.exe or ftp://entropia.com/gimps/v20/prime95.zip or ftp://entropia.com/gimps/v20/mprime.tgz or ftp://entropia.com/gimps/v20/sprime.tgz Regards, George 1) Another fairly uncommon ECM bug was fixed. The bug caused "Factor does not divide N!" errors. 2) A couple of minor bugs in computing the optimal P-1 bounds to use prior to a Lucas-Lehmer test were fixed. The program now does a better job at estimating the memory required in P-1 stage 2. Finally, although P-1 stage 2 working set size is unchanged, the program allocates less memory in stage 2. 3) Prime95 no longer searches for a smaller factor when trial factoring discovers a factor. The reasons are two-fold. 1) Version 19 had a bug where stopping and restarting the program bypassed the search for smaller factors. Thus, my database may already be missing smaller factors. 2) As we factor larger exponents to a deeper depth it may no longer be a quick job to determine if there are smaller factors. Note, that version 20 will still look for smaller factors if you are looking for factors below 2^60 with the FactorOverride option in undoc.txt. 4) The undocumented AMPM feature controls how times are formatted in the Options/CPU dialog box. _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers -- http://jkf.penguinpowered.com Linux distributies voor maar Fl 10 per CD, inclusief verzendkosten! _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: V20 beta #4 (will the beta never end?)
Hi all, The fourth beta is available. It fixes a few more bugs. See the whatsnew.txt at the end of this email. An upgrade from earlier betas is not required, but it can't hurt. You can download it from ftp://entropia.com/gimps/v20/p95setup.exe or ftp://entropia.com/gimps/v20/prime95.zip or ftp://entropia.com/gimps/v20/mprime.tgz or ftp://entropia.com/gimps/v20/sprime.tgz Regards, George 1) Another fairly uncommon ECM bug was fixed. The bug caused "Factor does not divide N!" errors. 2) A couple of minor bugs in computing the optimal P-1 bounds to use prior to a Lucas-Lehmer test were fixed. The program now does a better job at estimating the memory required in P-1 stage 2. Finally, although P-1 stage 2 working set size is unchanged, the program allocates less memory in stage 2. 3) Prime95 no longer searches for a smaller factor when trial factoring discovers a factor. The reasons are two-fold. 1) Version 19 had a bug where stopping and restarting the program bypassed the search for smaller factors. Thus, my database may already be missing smaller factors. 2) As we factor larger exponents to a deeper depth it may no longer be a quick job to determine if there are smaller factors. Note, that version 20 will still look for smaller factors if you are looking for factors below 2^60 with the FactorOverride option in undoc.txt. 4) The undocumented AMPM feature controls how times are formatted in the Options/CPU dialog box. _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: V20 beta #3
Hi all, The third beta is available. It fixes three more bugs. See the whatsnew.txt at the end of this email. If your day and night available memory settings are unequal, then you should replace version 20.1 with this one. You can download it from ftp://entropia.com/gimps/v20/p95setup.exe or ftp://entropia.com/gimps/v20/prime95.zip or ftp://entropia.com/gimps/v20/mprime.tgz or ftp://entropia.com/gimps/v20/sprime.tgz Regards, George New features in Version 20.2 of prime95.exe --- 1) If P-1 stage 1 completed and there was not enough memory to start stage 2 immediately, then an incorrect save file was generated. This bug was introduced in version 20.1. Upon restart of the P-1 factoring job a crash or other unpredictable behavior was possible. This bug was fixed and this version has special code to properly read these incorrect save files. 2) P-1 will restart any time the memory settings change. This is done so that the optimal P-1 bounds can be computed with the new memory settings. 3) A bug in ECM testing was fixed. _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: V20 beta for Linux
Hi all, As requested, I've ported the v20 beta to Linux. Please let me know of any problems. You can download it from ftp://entropia.com/gimps/v20/mprime.tgz or ftp://entropia.com/gimps/v20/sprime.tgz Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: V20 beta - round 2
Hi all, Thanks to all the beta testers of v20, you found a lot of bugs!! The 2nd beta is now ready. If you downloaded the first beta you should replace it with the new beta. You can download it from ftp://entropia.com/gimps/v20/p95setup.exe (the fancy installation program) or ftp://entropia.com/gimps/v20/prime95.zip (a plain old zip file) The whatsnew.txt file reads as follows: New features in Version 20.1 of prime95.exe --- 1) A bug in the new GCD code was fixed. 2) Timings in the P-1 stage are no longer cumulative. There is a new feature in undoc.txt for those that prefer cumulative timings. 3) Messages are now output prior to beginning the lengthy GCD. 4) The FactorOverride undocumented feature (not for use with PrimeNet) now supports factoring to a deeper level than prime95 would ordinarily factor. 5) A bug where the worktodo.ini entry was not removed if P-1 found a factor was fixed. 6) If P-1 finds a factor it now deletes any Lucas-Lehmer intermediate files. 7) A crash bug when continuing from a P-1 stage 2 save files with different available memory parameters was fixed. 8) Resuming an LL test now outputs a line to the screen, 9) The Test/Status display now correctly calculates the estimated completion time for an LL test when P-1 factoring is in progress. 10) Advanced/Factor menu choice was deleted. 11) A bug in computing P-1 stage 2 percentage complete was fixed. Have fun, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: V20 beta - bug? or fuctioning as designed?
Hi all, At 09:10 PM 3/17/00 -0600, someone wrote: Is it just me, or did you forget to reset the number of seconds after you display them when doing the P-1 factoring? The time keeps incrementing (by 32 seconds) for each iteration. someone else wrote: Is the P-1 factoring supposed to display the output in a cumulative manner? I'm not sure how long it should run, but it seems that a long run could cause the time and clock cycles to get unwieldly large. This was intentional and can easily be changed. Since it is different than the way trial factoring and LL testing is done, I suppose I should change it. If you have any strong reasons why it should be left cumulative, then let me know. Otherwise, expect the final v20 release to reset the timer after each screen output. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
RE: Mersenne: V20 beta
1) The program now does some P-1 factoring prior to running first time and double-checking Lucas-Lehmer tests. This will increase overall GIMPS throughput. If you install version 20 in the middle Does this mean that the exponent's that we've already done factoring on will be repopened for P1 tests when Prime95 v20 is released? G-Man _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
RE: Mersenne: V20 beta
I just upgraded and am now getting an 2250 error when attempting to contact the primenet servers. Am I doing something wrong??? G-Man _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
RE: Mersenne: V20 beta
From: "Geoffrey Faivre-Malloy" [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: "George Woltman" [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: Mersenne: V20 beta Date: Fri, 17 Mar 2000 13:37:07 -0500 I just upgraded and am now getting an 2250 error when attempting to contact the primenet servers. Am I doing something wrong??? G-Man I was getting that error this morning during a routine new-dates send with v 19.2. I think PrimeNet must have had a momentary service interruption. Which brings me to a question for everyone: How much work should I have cached in case of such interruptions? Currently I'm set through May 9. Nathan Russell __ Get Your Private, Free Email at http://www.hotmail.com _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: V20 beta
Hi all, If you feel up to it, please give the beta of version 20 a try. The QA group has verified that the FFT code is working, but have not spent much time verifying all the interactions with the PrimeNet server. You can download it from ftp://entropia.com/gimps/v20/p95setup.exe (the fancy installation program) or ftp://entropia.com/gimps/v20/prime95.zip (a plain old zip file) Remember to set the available memory in the Options/CPU dialog box. Please report any bugs you find directly to me. The whatsnew.txt file reads as follows: New features in Version 20.0 of prime95.exe --- 1) The program now does some P-1 factoring prior to running first time and double-checking Lucas-Lehmer tests. This will increase overall GIMPS throughput. If you install version 20 in the middle of an LL test the program will run the P-1 step if the LL test is less than 50% complete. 2) The Options/CPU dialog box now asks how much memory the program can use during the P-1 factoring. See the "Setting Available Memory" section in the readme.txt file. 3) Stage 1 of P-1 factoring is now faster. 4) The GCD used in P-1 and ECM factoring is now faster. 5) The Test/Manual Operation menu choice has been deleted. 6) The memory options in P-1 and ECM dialog boxes have been deleted. 7) The "send new completion dates" checkbox was moved from the Test/Primenet dialog box to the Advanced/Manual Communication dialog box. 8) A bug in estimating time remaining for a factoring job was fixed. 9) AdvancedFactor now writes a line to the worktodo.ini - just like all the other work types. Have fun, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
