Re: Mersenne: Double-check assignment lost?
At 08:39 PM 2/22/03 -0500, Walt Mankowski wrote: So someone's poaching double-checks now?! *Sigh* On Sun, Feb 23, 2003 at 03:06:54AM +0200, Nuutti Kuosa wrote: > Check Hourly World Test Status, Cleared Exponents Report: > http://mersenne.org/primenet/cleared.txt > and there : > 8970673 65 D 0x45932E28306E98__21-Feb-03 19:10 S93724 > C4159C890 > > Someone has done it. I don't know why. It's unlikely to be a deliberate poach. This person was probably assigned this exponent previously, and it expired but their computer continued to work on it and eventually turn it in. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Factoring hiccup?
At 10:49 PM 2/13/03 -0600, Steve Harris wrote: I can't tell you what is causing that, but I can tell you that it has happened to me as well. I have only noticed it on a machine which I switched to factoring because it consistently got errors during LL testing. With TF I get no errors, but do get the occasional hiccup, maybe once every six months. I have a machine that when my son played a certain kids game, it would mark a factoring assignment that was in a 64 bit or higher pass as complete immediately and return the result. I discovered it was because of a bad sound driver. I fixed that and reran the two exponents it prematurely ended. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Why is trial factoring of small exponents slower than large ones?
At 05:00 PM 2/7/03 +1300, G W Reynolds wrote: I am using mprime 22.12 on a pentium 166 MMX to do trial factoring. For the exponents currently being assigned from primenet it takes this machine about 12 minutes to factor from 2^57 to 2^58. I thought I would try factoring some small exponents (under 1,000,000) from the nofactors.zip file. I put FactorOverride=64 into prime.ini and started mprime as usual but progress is _much_ slower, it will take about 8 hours to factor from 2^57 to 2^58. Others have given great explanations, but I would like to suggest that if you want to work in ranges outside of PrimeNet that you "stake your claim" with the Lone Mersenne Hunters so as to avoid duplicating work of others who may also be working in the same area (and I know there is at least one person working in that region). The LMH have communicated via a Yahoo groups email list in the past, but may be moving to the GIMPS BBS (www.teamprimerib.com/gimps) for future communications. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: SV: Mersenne: An officially sanctioned poach....
At 01:19 AM 1/29/03 +0100, =?utf-8?Q?Torben_Schl=C3=BCntz?= wrote: 17914693 at helly will expire very soon according to the 60 days rule. And I can't do anything about it. It just will happen. No biggee. I think I've already picked up and completed one of helly's expiries. Most likely either I or one of the other people who pick up factoring expiries will get it and finish it quickly. The Jansta run very well. The 6. november last year it completed 17950937. It's probably now a 100 mhz running irregularily - it has had a better reputation. If anybody think I should get finished with these 18.2xx.xxx assignments I will complete them in only a few days. Do you know what version jansta is running? It may be an older version which George mentioned may do the "restart iterations at every bit level" thing. But I have records of those trailing edge exponents and jansta has been working on 18112949 since at least Nov. 20th. There is no urgency in getting them done, just concern that if the machine is having problems and continuing to restart the exponent over and over, it will never finish it. If the machine is fine, and just working slowly, then just leave it be, especially if it is running version 18 or earlier, because IIRC those versions can't cope with the higher exponents being assigned now. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: An officially sanctioned poach....
At 10:08 AM 1/28/03 -0500, George Woltman wrote: At 09:36 PM 1/27/2003 -0800, Mary K. Conner wrote: Garo identified some Team_Prime_Rib exponents in there. I'll exempt all Team_Prime_Rib exponents Looking at the other exponents in the factoring range I'm not worried about reclaiming factoring assignments right now. The tsc machines show some very odd behavior. The exponents do a "red light, green light" game. One exponent I've been following started at 5, went to 2, back up to 5, then ran all the way up to 15 before dropping back to nothing and now it shows a 1. Others are similarly dancing around When factoring, the iterations will increase from 1 to 15 for each bit level. In other words, the field provides no useful information for trial factoring assignments. Far be it from me to tell you that you are wrong, but that is not at all consistent with what I observe with my own exponents. For instance, exponent 19373911 shows a 9 right now, it connected a short while ago and the machine is early in the 66 bit pass. The percent complete is about to hit 12.5%, at which time I should be able to force a manual connect and then it will show a 10. Yep, it now shows a 10. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: red light - green light (was Re: Mersenne: An officially sanctioned poach....)
At 10:00 AM 1/28/03 +0100, [EMAIL PROTECTED] wrote: > The tsc machines show some very odd behavior. The exponents do a "red > light, green light" game. One exponent I've been following started at 5, > went to 2, back up to 5, then ran all the way up to 15 before dropping back > to nothing and now it shows a 1. Others are similarly dancing around. I Are you talking about factoring assignments? It seems they start at iteration 1 again for each bit of factoring depth. Yes, factoring assignments. Having done a lot of these I know how the usual progression goes. It ranges from 1 to 16, with the final bit depth showing 9 to 16, the one before that 5 to 8, before that 3 or 4, before that 2, and before that 1. So an exponent destined to go up to 66 bits that starts at or below 62 bits will show a 1 until it hits 63 bits, then a 2 until 64 bits, 3 until halfway through 64, 4 until all the way through 64, 5 through 8 while it is in 65 bits, and 9 through 16 while it is doing the 66 bit pass. This up and back behavior is not normal. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Re: Mersenne Digest V1 #1039
At 12:04 AM 1/28/03 +, Gordon Spence wrote: [snip] From: "Mary K. Conner" <[EMAIL PROTECTED]> Subject: Re: Mersenne: Re: Mersenne Digest V1 #1036 [snip] There are plenty of triple checks that happen accidentally. There is no GIMPS need to do some on purpose, especially to the detriment of a participant that is following the rules. If someone feels a personal need to do triple checks, they should do them on exponents that are already double checked. Actually the project *does* deliberately do a fair number of triple checks. You just see them as double checks that's all. Why? where the residue bits returned from the first and second, do not match. Different animal. I know about extra checks when residues don't match. I'm speaking of triple or higher checks where all residues agree. The only reason to do those other than the exponents that have only 16 bit residues is to check for cheating. If those kinds of checks need to be done, they ought to be done with intelligence, not by random poaching. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
RE: Mersenne: Re: Mersenne Digest V1 #1038
At 12:08 AM 1/28/03 +0200, Nuutti Kuosa wrote: Hmm. Your name seems oddly familiar. ;) 1. Punishment (capital punishment?) and making poaching hard to do. 2. trying to understand causes behind poaching and then change the server software more milestone friendly. I think that we are like to reach milestones. I personally refer option 2. I concur. Honey, vinegar and all that. But I still bet there will be some who just don't give a damn, and regardless of how far up we move the trailing edge through improving procedures, it won't be fast enough for them. I used to work expiries in the doublechecks, and I learned that helping to move the trailing edge forward faster just exposed more slower machines to poachers. I like when we reach milestones and here are few things I would like to change : 1. Why one size fits to all? 60 days expiry time to all task is not a good idea. Smaller tasks should have lower one. Like 30 days. 2. I would like to assign bottom 5 % of double check assignments to trusted searches (who have shown that they return their jobs fast and reliably. 3. When George release small exponents to triple check then these should assigned to trusted searches. 4. very slow computers should concentrate to trial factoring. 5. maximum time limit to bottom 5% double checks (like 6 months) The reality is that given the amount of CPU time wasted by poachers through duplication of work, we would be reaching milestones faster if they were just doing legitimate assignments. A poacher helps reach milestone X a little faster at the expense of it taking longer to reach milestone X+1 because the poachers could have eliminated some exponents between X and X+1 instead, which would help reach milestone X+1 faster. Not to mention the loss of contribution by those who quit because they're disgusted with poachers and the project doesn't seem to be able to stop them. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: An officially sanctioned poach....
At 03:29 PM 1/27/03 -0500, George Woltman wrote: It's been quite awhile since I've done a release of exponents that seem to be stuck - probably over a year. I've identified 185 exponents that have had NO progress reported and are either: a) Below 12,000,000 and been assigned for 200 days or more, or b) Between 12 and 20 million and been assigned for 300 days or more Does anyone see any problems with releasing these exponents back into the pool? Garo identified some Team_Prime_Rib exponents in there. Two of them are exponents I reclaimed a couple of weeks ago from another TPR member that were about to expire. There were originally a dozen or so, I'm down to the last three, and the third has progress on it. I expect to finish them within a month, but I've some exponents that are lower than these to work off. Here are the two that meet those criteria, I'd like to ask that they be exempted: 18595361 F 59 347.8 2.2 60.2 25-Jan-03 12:23 12-Feb-02 14:04 Team_Prime_Rib trif_pest 18652897 F 59 338.3 3.2 60.2 25-Jan-03 12:23 22-Feb-02 02:09 Team_Prime_Rib trif_pest Looking at the other exponents in the factoring range, over half are assigned to one machine. JohnMartin has several machines most of which cause no problem whatsoever. But the Don machine is very "streaky". It'll take a couple of months to finish one assignment and then bam, run off several in a row. If the machine didn't have such a deep queue, it wouldn't take so long to get through them all. It also connects very infrequently. I've even seen this machine get to within a hairsbreadth of expiring all its exponents, only to connect and refresh them. But it does eventually complete its assignments. There's no good way of telling how many completed exponents it may be sitting on waiting for its next connect. The tsc machines show some very odd behavior. The exponents do a "red light, green light" game. One exponent I've been following started at 5, went to 2, back up to 5, then ran all the way up to 15 before dropping back to nothing and now it shows a 1. Others are similarly dancing around. I find myself wondering if restores from backup are causing the behavior. The ones currently showing no progress ought to be safe to nuke. The other three I don't know, they're just randoms. Probably safe to nuke. 17035867 351.0 JohnMartin Don 17137801 351.0 JohnMartin Don 17211269 351.0 JohnMartin Don 17914693 384.5 tschelly 18207929 349.0 JohnMartin Don 18235439 434.7 tscjansta 18235507 434.7 tscjansta 18423907 371.3 JohnMartin Don<---the lead exponent 18423931 371.3 JohnMartin Don 18454609 367.5 JohnMartin Don 18454627 367.5 JohnMartin Don 18458879 367.2 S07370 C18BF6A13 18580313 353.2 JohnMartin Don 18827209 330.3 jemh24 jorge <---shows 5809 days to completion! 18875687 323.2 JohnMartin Don 18918859 319.1 tfritz tfritz_work _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Re: Mersenne Digest V1 #1038
At 10:06 PM 1/26/03 -0500, Paul Missman wrote: I know that this might be earth shattering news for you, but there is no such thing as "poaching". Neither GIMPS or Primenet have any license to these numbers, nor are they the only entities testing large numbers for primality. If my sister reads from her math book a method of testing large primes, knows nothing of Primenet or GIMPS, tests the numbers on her home computer, and finds a large prime, she is gonna publish it. She might choose to send any results to GIMPS, or not. She might double check it using GIMPS provided software, or not. But for sure nobody has any reason to prevent her from doing any of this. There simply is no real problem here that is begging for solution. Anyone is entitled to test any number they want for primality. GIMPS isn't the prime number police, nor would they have any right to be. I never meant to suggest that people outside of GIMPS have no right to be doing testing. If someone scoops GIMPS to a prime (and it has happened), then c'est la vie. If someone just wants to test some numbers (even using Prime95) without using the cooperative Primenet data, and even report their results to George, that's fine. What I'm suggesting is that if someone decides to participate in GIMPS and use Primenet (including the databases and reports), then they should most definitely not be using those databases and reports to pick candidates for testing that have been assigned to other people. If they want the benefits of the cooperation, then they should respect the assignment process that produces those benefits. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Poaching -- Discouragement thereof
At 10:45 PM 1/26/03 +, Brian J. Beesley wrote: On Sunday 26 January 2003 19:55, Mary K. Conner wrote: > > [ big snip - lots of _very_ sensible ideas!!! ] > > Primenet, and Primenet should preferentially give work over 64 bits to SSE2 > clients, and perhaps direct others to factor only up to 64 bits unless > there aren't enough SSE2 clients to handle the over 64 bit work (or if the > owner of a machine asks for over 64 bit work). Umm. Last time I checked, it seemed to be a waste of an SSE2 system to be running trial factoring ... the LL testing performance is so good that they really should be doing that. It would only apply to SSE2 machines that want to run factoring. We can't force SSE2 owners to run LL if they want to run factoring. At least this would put the SSE2 power where it shines in factoring, instead of the bit ranges where it is abysmally bad. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Re: Mersenne Digest V1 #1038
At 10:01 PM 1/26/03 +, Gordon Spence wrote: 4. Get it into perspective. The number of times this actually happens is miniscule. Out of the millions we have checked what are the "poached" items? Dozens, a few hundred?? Given that nobody poaches factoring assignments and the vast majority of those were weeded out before entering public testing, I will exclude factoring assignments. There have been 214,935 first time LL's and 184,754 doublechecks completed. That's nowhere near "millions". I don't know the history of every exponent, but there are patterns that definitely indicate poaching (i.e when you look at exponents just below a milestone and observe an exponent returned six times). There have been at least several thousand exponents poached. One poacher I looked at had between half and two-thirds of exponents he completed as triple checks. This was a "blind do the leading edge without checking" poacher. Even when no milestone is looming, I estimate there is an average of at least one poach every day, and these are not "inadvertent poaches" where a previous assignee ends up completing an exponent. These are known poaches by known poachers. The only time poaching activity drops to "miniscule" is when the spotlight is thrown on poaching by this list. 5. It has correctly been pointed out that life doesn't end if a milestone slips. Well guess what? That is a double-edged sword - life doesn't end if an exponent gets poached either. The fact that life doesn't end is not an excuse to poach. Poaching hurts the project because it drives away participants. It is not harmless. I don't know why people keep defending it. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Re: Mersenne Digest V1 #1036
At 04:27 PM 1/24/03 +, Gordon Spence wrote: Of course, as this is a *public* volunteer project, there are a lot of us, who have been in the project for a long-time (6+ years) who regularly look through these for no other reason than we *want* to. Aye, I like having as detailed an access as possible. All of these discussions about strategies couldn't be taking place unless we could see and analyze these trends and problems. No. If I was setting out to "poach" numbers - which in itself is a moot point. You don't *own* an exponent, they are after all simply numbers. However, I digress. If I was setting out to "poach" numbers, then I would simply setup a few 3.06 Ghz P4's and just start at the bottom of the list (smallest exponents) and let rip. Complete an exponent every day or so. So some of them might be completed before me, so what, we then have a "triple" check. If someone wants to do it, you won't stop them. While participants don't "own" exponents, there are rules for using Prime95, and participating using Primenet that one has to agree to in order to use them. The rules are explicit about agreeing to how credit is given and prizes awarded. It should be a rule that if one uses Prime95 or Primenet or any of its reports, that one does not use it or the information in the reports to target exponents assigned to others. If one wants the benefits that arise from this cooperative scheme, one needs to agree to participate in a cooperative manner. You are missing the point about it being useful to have "triple" checks. Nothing is redundant. There are plenty of triple checks that happen accidentally. There is no GIMPS need to do some on purpose, especially to the detriment of a participant that is following the rules. If someone feels a personal need to do triple checks, they should do them on exponents that are already double checked. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Poaching -- Discouragement thereof
I also have a proposal. This would need to be for the overhaul of Primenet. 1. When someone who has not held an assignment in the last year checks it in completed (in other words almost always a poacher), that submission is not acknowledged publically in any way. The exponent remains listed on the AER, no entry is made to the completed exponents page, the poacher receives no credit, and if the exponent expires before the original assignee finishes it (or is checked in with no progress made), the original assignee receives the public credit for it, and only the private database notes the poacher. There are a number of poachers who could care less about credit, but they do want to see those entries fall off the AER and milestones reached. If that didn't happen, and if it were impossible to even tell if another poacher had already poached an exponent, I believe these poachers would give up. It might not stop those who dash off an exponent just before it expires, but only if they don't care about credit. 2. The vast majority of "exponents out for a long time" happen because people who only have their computers on a very short time every day have exponents hang out in their queue for a very long time because Prime95 has a hard time dealing with estimating true times to completion when computers are on for short times or not turned on very often. If someone takes a year to complete an exponent, that's no big deal, but if they have five exponents in their queue (because Prime95 doesn't realize it will take five years to finish them all), it will be five years to finish the last. The best way to deal with that (even with the existing client base) is for Primenet to estimate the client's true progress and to take back those exponents that report no work done (IOW those that are in the queue behind the exponent that is being worked on) when they do check in (giving them an "exponent not assigned to this computer" error), and then give that client exponents on the leading edge when it asks for some to replace those errored out. That way when the year is up and that first exponent is completed, the next exponent that computer starts on will be one is much closer to the leading edge. 3. I like that Primenet should choose whether to give an expired exponent to a computer based on its history. However, I would like to suggest that the expiries that are the very closest to the trailing edge (perhaps the bottom 10%, if there are 4000 of that type outstanding, any expiries in the bottom 400 would fall in this criteria) should go to computers that not only pass Primenet requirements but whose owners have explicitly decided to ask for them. It should be an advanced checkoff or undoc option. It should be suggested to only use this option for computers that the GIMPSter has regular direct access to. 4. Primenet requirements for getting expiries in the bottom half of the active range should include using version XX.XX of Prime95, which has as a feature that it automatically sorts the worktodo list when rewriting it, placing the lowest exponents to be completed first. Exponents that have work in progress should sort to the top, and the sort should only be within work types. If one is working on factoring, and decides to switch to doublechecks, the doublechecks should not be popped above the factoring assignments or the factoring assignments will be a long time getting done (at least until Primenet perceives that a situation like 2 above is happening and reclaims the factoring assignments in the queue). 5. Version XX.XX of Prime95 and the overhaul of Primenet should support factoring limits and checkins of partial factoring progress. Right now if an exponent starts at 58 and needs to go to 66 bits, and someone factors through 65 and then expires that exponent, the new assignee has to start all over again at 58. The undoc factoring limits option should work with Primenet, and Primenet should preferentially give work over 64 bits to SSE2 clients, and perhaps direct others to factor only up to 64 bits unless there aren't enough SSE2 clients to handle the over 64 bit work (or if the owner of a machine asks for over 64 bit work). Okay, I'll stop. I keep thinking up things. :) _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Factoring Top 100
At 12:07 AM 1/22/03 +, Russel Brooks wrote: Well I've recently reached my 2nd GIMPS goal of getting into the top 100 factoring. Last summer I made it to the top 1000 LL testers and then switched from double checks to factoring to make my mark there. Now what to try for? :-) Bah, top 100 factoring isn't that hard! :) I just checked my ranking and with only four computers I'm sitting at 140 and top 100 looks quite doable. You could make your mark by poaching the last remaining exponent under M38, assuming that Draco Malfoy doesn't beat you to it. :) _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Runaway machine sucked up all the factoring assignments
The machine novarese/NSPC19 has gotten itself into a loop and reserved tons of factoring assignments and PrimeNet is now out of them. Damn Y2.003K bug! :) _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: SV: SV: SV: Mersenne: Drifting UP(!) in Top Producers ranking?
At 11:04 PM 11/25/02 +0100, =?utf-8?Q?Torben_Schl=C3=BCntz?= wrote: No, and I am not the GIMPS police. It would offcourse be quite easy simply to check all accounts having done 5+ years TF and having more than 0,6 years pr. foundfactor. On the other hand some accounts could be very old and back in those days a factor could have been found in less effort than now a days appr. 0,5 y/ff. NetForce and Challenge seems to be good candidates for accounts with a very low effort pr. ff. Well, you'd nail me. I do expired exponents for the most part, which makes it much less likely that I will find a factor because almost all of those expired exponents have already been done part way, and if there had been a factor in the parts already done, they wouldn't have expired. So I have 8.783 P90 years in factoring, and only 6 factors found. Unless you count the pre-factoring work I turn in manually to George. Lots of factors found there for much less CPU expended. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Drifting UP(!) in Top Producers ranking?
At 11:27 PM 11/20/02 +, Russel Brooks wrote: I have 3 pcs doing factoring. I have been checking my position on the Primenet Top Producers Factoring list. I have noticed my position drifting up in the standing while I haven't found any factors. How does happen? You get credit for your work doing factoring even if you're not finding factors. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Poach?
At 01:30 PM 11/19/02 +0100, [EMAIL PROTECTED] wrote: Individual Account Report 15 Nov 2002 16:54 (Nov 15 2002 9:54AM Pacific) 11976787 65 447705659.6 11.0 61.0 15-Nov-02 15:43 17-Sep-02 02:26 hl 1196 v19/v20 Individual Account Report 19 Nov 2002 08:00 (Nov 19 2002 1:00AM Pacific) 11976787 D 65 447705663.3 7.3 57.3 15-Nov-02 15:43 17-Sep-02 02:26 hl 1196 v19/v20 Last week this was a 1st test assignment, now it's a double check? Unfortunately there was a server sync in the meantime, so I can't check the cleared.txt. But I find in hrf3.txt: 11976787,berra,WV1 It's probably an assignment that expired, but the original holder was still working on it on a very intermittently connected computer, and eventually finished it. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: My numbers have been re-assigned to someone else...
At 06:15 PM 10/4/02 +0100, Barry Stokes wrote: >Was using 21.4.2, now on 22.9.2 (upgraded today). It only grabbed a few >exponents when I started it, and it wasn't that the program released them, >they were just re-assigned by the server. The trouble is, I have now >completed one of these factoring jobs, and it's no longer assigned to me, >which is quite annoying, as it means that work is going to be duplicated by >whoever now has the number. Not necessarily. If you return that result, then the next time that person checks in with PrimeNet, it will give them a "exponent already tested" error and remove the exponent from their worktodo. If they haven't already started work on it, then no work will be duplicated. I work almost exclusively on expired exponents, and even though they are expired, sometimes whoever was previously assigned will finish the work, and since I have my "days between checkins" set at 1, it gets removed from my worktodo quickly (and then my box fetches new work to replace it). I highly recommend that you get that result back to PrimeNet ASAP, wipe the others from your worktodo, and get new work. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
RE: Mersenne: Which changes have been made to the server
At 03:13 AM 4/2/02 -0800, Aaron wrote: >I think there's always some of that when they do a database sync. > >What truly puzzles me is that I *still* have exponents showing up on my >status page (thus, apparently not synchronized) going back to March of >*last* year. Again, that has always been the case, where some exponents >I have finished don't get cleared, but I think there are some now that >have survived 2 or 3 database syncs and yet they remain. Looking at the status report right after the synch, I could see that a very few results from between 7.7M and 9.9M or above 16.8M were removed, and most were left behind. For the 7.7 and 9.9 range, it seems that the left behind results in this range are actually doublechecks (even if PrimeNet believed they were first times), and since the active doublecheck range hasn't gotten this far yet, the results were for some reason left behind. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: A runaway P95 install script?
At 11:40 PM 3/21/02 -0500, C. Garrison wrote: >Hi all. There was some discussion earlier about a team that reserved >several thousand exponents only to let them expire after 60 days. I'm not >sure we ever resolved what was happening then, but we have something >similar on another team now. Is there anyone who can speak for BART >(machine) on netconx (team)? This machine began acquiring 33Ms every few >minutes for the past day or two, and has amassed several hundred by >now. If it is intentional fine. If not, since it is still reserving >away, I thought bringing up the fact might lessen the longer term >reservation impact. It seems to be reserving one exponent every 2 minutes. Since a malicious person could reserve exponents much faster, and would probably not be so steady over so many hours doing it by hand, I suspect it is a matter of a Prime95 process that has lost access to its disk space, thinks it has no work, and keeps downloading exponents, trying to save them, and then noting two minutes later (perhaps the timeout for a Windows share or other network mounted space) that it either has no worktodo, or the worktodo is empty, and looping. It is odd that it has gone on for so long though. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: 11438839 Lost !?
At 02:28 AM 3/3/02 +0200, Daidalos wrote: >Hmm... Do I remember having finished one more exponent? > >Indeed. According to my prime.log file, I send the result for >exponent 11438839 on Wed Nov 07 17:42:43 2001. > >I also seem to remember that it used to appear on my result report >before. I don't recall when it stop appearring there, but it must >have been since early January, when my place in the Producers List >moved to its current area. > >Anyway, what we do now? And where's my exponent? There was a database synchronization on Dec. 12th. When that happens, most of the results submitted since the last synchronization are cleared out of PrimeNet (they are always held in the master database, however). Your PrimeNet credit for the exponent stays, however. If you want to look in the master databases, you can download them from the bottom of this page: http://www.mersenne.org/status.htm _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: error: Another mprime is already running!
At 08:58 PM 3/1/02 +, Brian J. Beesley wrote: >That would be a crude and surely unusual way of economising. Definitely so, but it's the only way I can think of that someone might use a hard link when installing mprime. For someone coming from Windows, that might be the way they think to do it. I couldn't think of any other "non-freak-error" way for this error to occur when no process named mprime was running. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Re: Mersenne Digest V1 #941
At 12:06 AM 3/1/02 -0600, [EMAIL PROTECTED] wrote: >Was there _really_ no posting made to the Mersenne mailing list >between Mon, 18 Feb 2002 (02:19:32 -0500 From: "Justin Valcourt") >and Tue, 26 Feb 2002 (19:46:54 +0100 From: Henk Stokhorst) ?? > >A span of over eight days with no message? Really? > >Were the Olympics *that* interesting? > >Or is it only _my_ copy of the Mersenne Digest V1 #941 that is missing >any posting between those two dates? Go check the mailing list archives. But yeah, it was pretty dead for awhile. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: error: Another mprime is already running!
At 05:17 PM 2/28/02 -0500, George Woltman wrote: >mprime should only raise this error if the pid in the local.ini file and the >current pid are both running mprime (actually comparing the inode values). >If there are any Linux experts that can tell me where this test is going >wrong, I'd appreciate any insights. > >This is the first reported failure in 2 years. I mucked about with it a bit, and it does appear that if the process running under the pid in the local.ini file is not mprime, it will not raise the error. Comparing inodes, if there is a hard link under two different names, it would raise the error. I.e. someone does 'ln mprime ll', runs ll, then tries to run mprime, the inodes will match although there is no process named 'mprime' running (it is possible to force the process to be named mprime by overwriting argv[0], at least on some systems). Someone might do the hard link if they are trying to save space on installations to run on multiple CPU's, I don't have a multiCPU machine, so I've never done such an installation. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: error: Another mprime is already running!
At 08:57 PM 2/28/02 +, Brian J. Beesley wrote: >The test could be reinforced by checking the program name associated with the >PID. If it _is_ mprime, then another copy using the same local.ini file >really _is_ running. If it _isn't_ mprime, then the PID in the local.ini file >is _wrong_ and can be ignored. > >This is still somewhat less than 100% since there _could_ be an unrelated >program called mprime running, or the user might be running mprime under a >different program name. But it is sufficient to squash this particular >problem, which might be fairly common on systems where mprime is started >automatically in the system startup scripts. It also fails (although in the other direction, starting more than one copy), if mprime has been named to something else. There are ways around that though. It could check to see if the other process has a program of the same name attached, instead of checking for mprime. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: error: Another mprime is already running!
At 09:48 PM 2/27/02 -0500, Marcel van de Vusse wrote: >I just rebooted my machine so my daughter could play a game in Windows. >Booted back to Linux afterwards, and now mprime keeps (wrongly) giving >me the above error. > >Does anybody know how mprime detects another copy already running, and >how to work around the above error. I double and triple checked. There >is NO copy of mprime running. Look in local.ini. There is an entry in there for Pid, which is the process ID of the mprime that last ran. What probably happened is that when you rebooted, another process was given the PID that mprime used to have, and when you try to start mprime, it sees a process running with that PID and refuses to run. Remove the Pid entry from local.ini, and all should be well. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
