Re: Mersenne: prime95 - v21 progress
On 9 Mar 2001, at 17:27, Jeff Woods wrote: Actually, the next obvious milestone is checking all below M(6972593) for the first time. There are 67 exponents unchecked at all below that exponent, and that number has been VERY VERY slow to reduce, mainly due to number campers or 386's trying to test that number. Or fast systems slowing because an animated screensaver is being run? This can easily happen if you ask someone else to run Prime95 on their system as a favour. I also massaged today's assignments report, and found that there are over 200 exponents assigned over a year ago (and some as far back as 1998), NOT including those expected to take that long (i.e. 33 million+). Some exponents have been run for over a year, and have "days to run" estimates of 2900 days or more -- yes, nearly EIGHT YEARS. I remember getting "wound up" about this shortly after I joined the project. George replied that these problems have a way of sorting themselves out; experience proves him right. The point is that we could crank through these laggards if the Primenet server would have simply ensured they were assigned to a "top 1000" producer, or to a machine of sufficient calibre and reliability (historically, per prior test results). To which [EMAIL PROTECTED] (Mikus Grinbergs) replied: Is that what we want - an elitist organization which SEGREGATES those participants to whom we do not attribute "sufficient calibre" Well _I_ don't! Back to Jeff Woods: You said you had a good reason not to do that, but didn't want to post it here (you were going to mail it privately to Henk). Why not discuss it here? Now I believe Henk is a responsible individual, and I've no reason to suspect Jeff is any less so. The system we have at the moment is reasonably robust and will stand a certain amount of abuse. However, abuse on a large scale will break it. I don't want to be responsible for that. What I mailed to Henk privately amounts to a minor form of abuse of the system. One paragraph of that private message reads: (start quote) Obviously you should be careful when doing this, else you are likely to be accused of "pirating" assignments. Also there would be chaos if several people were doing this, which is why this reply is being sent to you only and not to the list. (end quote) Jeff, if you (or anyone else, for that matter) want to take advantage of the idea I mailed to Henk, I suggest you mail Henk privately and discuss amongst yourselves how you're going to coordinate your combined effort. My contribution to your "sturmgruppe" ends here because I don't believe that anyone's CPU cycles are inherently more valuable than anyone else's. Oh, and if you happen to find a new Mersenne prime whilst you're working in this mode, I would hope that you'd be prepared to share the credit with any other person who happens to "own" the PrimeNet assignment at the time. 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: prime95 - v21 progress
Hello, because of the discussion about the speed on the slowest exponents I did some calculations: Result: The limits like 750 MHz or even 350 MHz for the smalles exponents are completely ridiculous, certainly if we do not take into account the number of it is on, a 1000 MHz machine on for 8x5 hours a week will take longer than PII 233 on 24x7. If we want to get it done as soon as possible we must calculate what would be fastest: Observation the relatively slow machines are often used as servers / private firewalls and on 24x7 On the other hand relatively slow machines may be hardly on. Some calculations (benchmark page) on the fictive exponent 400 yields 24x7 on a: 486@33: 1Y+182 days (Ok that seems long) PI@60: 43 days (Seems we can wait on that, as long as the machine is reliable) PII@233: 10 days (Seems as of now it really does not matter anymore) Cel@300: 8 days PIII@450: 6 days PIII@1000: 3 days Athlon@1200: 2 days Some calculations on the ficive exponent 800 (486 left out) PI@60 : 177 days (Doubtfull) PII@233 : 40 days (Seems we can wait on that, as long as the machine is reliable) Cel@300 : 31 days PIII@450 : 23 days PIII@1000 : 12 days Athlon@1200 : 9 days Some calculations on the ficive exponent 1200 (486 left out) PI@60 : 1Y+29 days (Seems to long) PII@233 : 87 days Cel@300 : 68 days PIII@450 : 50 days PIII@1000 : 27 days Athlon@1200 : 17 days When we take into account that the timeout offset is 60 days (so someone starting an assignment and not doing anything at all costs 60 days, nobody works on the exp. so that is a delay of the entire project) We should probably reassign exponents to machines that have already finished at least 2 exponents, and based on that info will return this assignment within 60 days. That would be like doublechecks reassigns for PI / PII / Celeron, Primality reassigns for PIII / Athlon. Exponents in the lower 10% of a range should be reassigned if no progress has been reported for 60 days. A good better solution optimizing for progress would be to re-assign expired exponents to machines that have finished exponents already and will finish them in for instance approximately 20 days (Assigning the smaller exponents to slower machines and larger exponents to faster machines) The actual number of days can be calculated from the "ballpark". So that optimal progress is made. We must try to keep slow machines in as long as possible as they really contribute to the progress. So optimal progress will be made by giving smaller machines small exponents and larger machines large. Kind Regards, Martijn _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: numbering the messages
Steve ( [EMAIL PROTECTED] ) wrote on Saturday, March 10, 2001 at 02:24:00 + X-Mersenne-Count 229 X-headers, good idea. I agree, no need to reset the message count. But having said all of that I don't really think there's much point in doing this. We can't all share the same opinion :-) But I'll ask you this: how many Mersenne list messages have you missed since you joined the list? Respectfully, you probably don't know. Would you want to miss, say, a posting by George Woltman, and not know about it? It's common practice in the printed world to consecutively number the publications. Besides, I don't think it's that difficult to add a message counter. (Could you give me a good reason why the server shouldn't number the messages?) As Joshua Zelinsky put it: automatic numbering would be pretty helpful. Maybe Luke Welsh would give his opinion on this subject? Happy hunting, Robert van der Peijl -- Your mouse has moved. Windows NT must be restarted for the change to take effect. Reboot now? [ OK ] [ YES ] [ APPLY ] -- _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne Digest V1 #825
Mersenne DigestSaturday, March 10 2001Volume 01 : Number 825 -- Date: Fri, 09 Mar 2001 07:34:23 +0100 From: Martijn [EMAIL PROTECTED] Subject: Re: Mersenne: prime95 - v21 progress Henk Stokhorst wrote: L.S., Maybe it would be a good idea to have a special version of prime95 that has an option to request exponents that have expired after having been reserved for a long time without any progress being on the work for that exponent. The server should issue those exponents only to people who have that option. That version should only be available to people who have fast (700 MHz or more) machines running most of the day. That would help prevent exponents expiring multiple times. YotN, Henk Stokhorst Nope bad idea smaller exponent = smaller runtime = lower clock frequency so it would then be better to have them assigned to machines that are slow real pentiums for instance (It does really not matter if such an exponent is finished in 4 or 30 days. The multple expiering problem is an entirely fake one. It does not hinder progress, it only makes (relatively small) exponents unavailable for 90 days, in that time we work on other exponents and life goes on. Martijn Kruithof _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers -- Date: Fri, 9 Mar 2001 08:29:35 +0100 From: "Robert van der Peijl" [EMAIL PROTECTED] Subject: Mersenne: expired exponents We might not need a special version of prime95. How about if the _PrimeNet server_ itself only issue expired exponents to "power"-users? If that is a real possibility, perhaps Scott Kurowski could look into that? Robert. - - Original Message - From: "Henk Stokhorst" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, March 09, 2001 12:45 AM Subject: Re: Mersenne: prime95 - v21 progress L.S., Maybe it would be a good idea to have a special version of prime95 that has an option to request exponents that have expired after having been reserved for a long time without any progress being on the work for that exponent. The server should issue those exponents only to people who have that option. That version should only be available to people who have fast (700 MHz or more) machines running most of the day. That would help prevent exponents expiring multiple times. YotN, Henk Stokhorst _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers -- Date: Fri, 9 Mar 2001 02:24:15 -0800 From: Scott Kurowski [EMAIL PROTECTED] Subject: Mersenne: RE: expired exponents Hi Robert, [Robert van der Peijl:] We might not need a special version of prime95. How about if the _PrimeNet server_ itself only issue expired exponents to "power"-users? If that is a real possibility, perhaps Scott Kurowski could look into that? I would instead recommend a broader strategy that expires exponents based upon the assignment age (days run) and current iteration at null (not started), perhaps at 60 days age. Did someone already suggest that? This will have the system effect of generally causing machines that grab and hold excess exponents to lose smaller exponents to new or more productive machines, while making up for those losses by grabbing fewer, ever larger exponents. This would happen in addition to the current automatic expiration process. The risk that a machine actually started a long-held exponent before contacting the server to learn it had been reassigned is somewhat greater. The result would be slightly more frequent 'opportunistic' double-check passes as the machine forges along to complete the then-redundant test, probably after the reassignment machine finishes. Maybe that's a good thing. George Woltman manages the server's individual exponent and range assignments from time to time. If overriding a 'squatter' is important enough, he could do so manually. However, if server changes are necessary, we defer to him for those requirements. (If there are replies, please cc me directly since I receive only the Mersenne list digests.) regards, scott kurowski Entropia, Inc. San Diego, California P.S. if there are any GIMPS folks on this list nearby, I'll treat lunch or beers... I left Ernst and Luke in Silicon Valley. :-( _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers -- Date: Fri, 9 Mar 2001 11:09:53 - From: "Brian J. Beesley" [EMAIL PROTECTED] Subject: Re: Mersenne: prime95 - v21 progress On 9 Mar 2001, at 0:45,
Re: Mersenne: numbering the messages
On Sat, Mar 10, 2001 at 12:08:09PM +0100, Robert van der Peijl wrote: We can't all share the same opinion :-) But I'll ask you this: how many Mersenne list messages have you missed since you joined the list? Don't know. Respectfully, you probably don't know. Would you want to miss, say, a posting by George Woltman, and not know about it? Missed many before I joined the list and the world kept on turning. It's common practice in the printed world to consecutively number the publications. Besides, I don't think it's that difficult to add a message counter. (Could you give me a good reason why the server shouldn't number the messages?) Well there isn't a good reason why not, and there is already a counter of sorts in the Message ID in the header, but it's not very human readable. Surely the list management software keeps a count of how many posts have been sent out to the group, it's just a case of reading/writing that digit into a header line. -- Cheers Steve email mailto:[EMAIL PROTECTED] %HAV-A-NICEDAY Error not enough coffee 0 pps. web http://www.zeropps.uklinux.net/ or http://start.at/zero-pps 3:10pm up 36 days, 16:51, 2 users, load average: 1.16, 1.14, 1.06 _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: numbering the messages
Well there isn't a good reason why not, and there is already a counter of sorts in the Message ID in the header, but it's not very human readable. Surely the list management software keeps a count of how many posts have been sent out to the group, it's just a case of reading/writing that digit into a header line. digests are generally numbered, while regular postings are passed thru the email list server systems relatively unscathed (other than appending the tag at the bottom). Majordomo at least doesn't keep any sort of counters. I guess it could be modified to do so, but this could get messy on a large busy server (afaik, multiple messages can be in the queue at once getting handled by parallel processes, so updating this counter would have to be done on an 'atomic' basis... preventing deadlock issues etc complicates matters) -jrp _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Security of prime95 + electricity costs.
Brian J. Beesley wrote: 2.What the are actual monetary costs would be of running Prime95. In particular, what are the percentage increases from normal costs. Depends how much extra you're running the system ... if it's on 24 hours a day anyway, the answer is _nothing_. Normally I switch off monitors on systems left running unattended (this is in any case good practise from the fire prevention point of view); power consumption of system units does vary but somewhere around 150W would be typical. So allow 1 KWh per 6 hours extra running. How much that costs obviously depends on how greedy your utility provider is. What about running all the extra floating point operations? Is there no significant affect? Joshua Zelinsky _ Get your FREE download of MSN Explorer at http://explorer.msn.com _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
