Re: Mersenne: On v18 factoring
- Original Message - From: Steve Harris [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 24, 2002 8:49 PM Subject: Re: Mersenne: On v18 factoring Daran - you ask why highest and not lowest? The discussion started regarding old machines running v18 which are no longer in the care, custody control of an active GIMPS participant, AND which are asking for factoring assignments which they cannot handle. Whatever assignment is given to them, there is no telling how long until (or even if) they will finish it... That's true of any client, not just runaway v18s. ...We would not want to give them something that would hold up a milestone a year or so down the road... If it got to the point where a milestone was being blocked, then someone else would poach it. I'd rather that happen to a forgotten client than to a slow but active participant. Also any server code-change is going to take the path of least resistance. The server is programmed to hand out the smallest exponent available. To start handing out larger exponents would involve more work than just changing the assignment type, and would probably introduce more bugs. [...] You make a good point about P-1 completed assignments, but on further reflection I don't think that is necessary. There aren't that many available and certainly not at the higher end of the current range. They will more than likely be P-1 tested when double-checked. That's not true. Most *new* DC assignments (currently 850) are not P-1 complete as they were originally LLed by v18 or earlier clients. Many recycled DC assignments (mostly 700-850) were also never P-1ed by the client that let them expire. I specialise in P-1ing these 'neglected children'. However, my above remarks about 'path of least resistance' applies. There are probably more important server changes pending. I've been wondering if it would be possible to compile a list of P-1 incomplete exponents currently assigned to v18 or earlier clients. If so, then I would consider giving these a P-1. This, it could be argued, would be a form of poaching, in so far as if I were successfully to factorise, then the 'owner' would get a 'exponent already complete' error, which might cause some upset. OTOH, the project gains a factor that wouldn't otherwise have been found, and people still using v18 aren't likely to be particularly attentive. I'd like the views of list members concerning the ethics of this. Steve Daran G. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: On v18 factoring
- Original Message - From: Brian J. Beesley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 23, 2002 7:52 AM Subject: Re: Mersenne: On v18 factoring Given that the server can tell the difference between a v18 client and a later one, would it not make most sense to have the server assign a LL test on the _highest_ unallocated exponent which v18 can handle if a v18 client asks for a factoring assignment and none suitable are available. This action would effectively remove the client from the loop for a while (probably a few months, given that most v18 clients will be running on slowish systems), thereby alleviating the load on the server, and buying time to contact the system administrator - when this is still relevant, of course. And some useful work may still be completed, eventually! Why highest? Why not give it the lowest? There's a case for only giving version 18 and below clients DCs regardless of the work requested. (I'm assuming that this is possible.) The only other point I'd add, which isn't particularly relevent to this question, is that these clients should always be given P-1 complete assignments if available. Regards Brian Beesley Daran G. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: On v18 factoring
Daran - you ask why highest and not lowest? The discussion started regarding old machines running v18 which are no longer in the care, custody control of an active GIMPS participant, AND which are asking for factoring assignments which they cannot handle. Whatever assignment is given to them, there is no telling how long until (or even if) they will finish it. We would not want to give them something that would hold up a milestone a year or so down the road. So I agree with Brian, give them the highest available (I don't mean 33M) which will keep them busy for a while, but probably on the order of a year rather than a few months. If it takes them a year and a half to finish, no problem; if it stops running then it goes back to the server, again no problem. As for runaway v18 clients asking for DCs, they would continue getting what they ask for. You make a good point about P-1 completed assignments, but on further reflection I don't think that is necessary. There aren't that many available and certainly not at the higher end of the current range. They will more than likely be P-1 tested when double-checked. Steve -Original Message- From: Daran [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Thursday, October 24, 2002 4:37 AM Subject: Re: Mersenne: On v18 factoring - Original Message - From: Brian J. Beesley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 23, 2002 7:52 AM Subject: Re: Mersenne: On v18 factoring Given that the server can tell the difference between a v18 client and a later one, would it not make most sense to have the server assign a LL test on the _highest_ unallocated exponent which v18 can handle if a v18 client asks for a factoring assignment and none suitable are available. This action would effectively remove the client from the loop for a while (probably a few months, given that most v18 clients will be running on slowish systems), thereby alleviating the load on the server, and buying time to contact the system administrator - when this is still relevant, of course. And some useful work may still be completed, eventually! Why highest? Why not give it the lowest? There's a case for only giving version 18 and below clients DCs regardless of the work requested. (I'm assuming that this is possible.) The only other point I'd add, which isn't particularly relevent to this question, is that these clients should always be given P-1 complete assignments if available. Regards Brian Beesley Daran G. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: On v18 factoring
On Wednesday 23 October 2002 07:26, Nathan Russell wrote: Other people have mentioned the possibility of automatically disengaging or updating the client. I am aware of several linux distributions which do the exact same thing (in fact I am not aware of any widely popular one which doesn't). Eh? I'm not aware of any major OS which even attempts to automatically install upgrades, with the exception of Win 2000 (if you applied SP3 and forgot to disable automatic updating) and Win XP (if you applied SP1 and forgot to disable automatic updating). The problem here is one of _control_. If you allow someone else - whatever their intentions are - to install run software on your system without your explicit permission on a case-by-case basis, you are effectively handing over full control of your system all the data on it to someone else. However, they require the user to initiate the update. Ah, I see what you mean. Would you be more comfortable if that was done, as well as some sort of signature on the update files? Here's the difference: when I'm updating my (Red Hat) linux systems, _I_ wrote the script that downloads the update files (from a local mirror of my choice) checks the certificates. Only then do I trust someone else's software to unpack and apply the updates. I'd far rather run an unpatched, insecure service than depend on something that is in principle uncheckable to download install software automatically. The problem is that, if the connection can be hacked in to, an attacker can supply anything they like Better still if I just download the source code compile it myself. That way I am absolutely sure that what I use is what I think I'm using. Obviously this principle can apply only to programs which are 100% open source. But here's the crunch: this discussion is related to the current problems with seriously obsolete clients. By definition these do not contain auto-update code, so the discussion is (+/-) pointless. To fix the problems, we really need to take a belt and braces approach: (1) the server needs to protect itself from machine gun requests. I reckon the best way to do this is for the server to detect continuous repeat requests automatically command its firewall to block data from that source address for a limited time (say one hour). This would protect the server from excess load, yet is not exploitable by remote attackers - all they can do is temporarily block themselves out! Although not neccessary to the project, I'd reccomend that the blocking action be logged so that it can be followed up (manually or automatically) by contacting the user concerned. Actual contact may sometimes not be possible because the registered user no longer controls the system. (2) future clients should be modified so that, if PrimeNet has no suitable work to allocate, they back off for a few hours before trying again. Even if this means running out of work altogether - though, given the days of work parameter, they should run in need of more work for some time before finishing the current assignment. In addition the server probably would benefit from addition of intelligence so that it does not attempt to assign work which specific versions of the client cannot accept. However, the action I suggest under (1) alone is sufficient; no automatic or forced upgrade is _required_. Regards Brian Beesley _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: On v18 factoring
George Woltman wrote: At 02:03 AM 10/23/2002 +, Russel Brooks wrote: How about a "Black List" of clients that the server will no longer give work to? I would think the problem of pcs no longer under your control would be an increasing problem. We want to give them double-checks so that the client isn't continually asking the server for work. This wastes bandwidth needlessly. Aren't Double Checks going to increase in size until we have the same problem we're having now with first checks? If yes then what do you give them at that time? Can you give Factoring if the client is asking for an LL test? Cheers... Russ DIGITAL FREEDOM! -- http://www.eff.org/ _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: On v18 factoring
Is there any kind of assignment that will force the client to try to calculate a divide by zero and crash? Or would other safe testing still be desired? Subscribe to The Gann Letter if you are interested in:varying levels of humor/jokes/quotes, parody/satire,science/space/technology items, cool news, games,programs, pics, and other interesting stuff. subscribe #1: [EMAIL PROTECTED]subscribe #2: http://groups.yahoo.com/group/TheGannLetter/joinsubscribe #3: gann (at) ganns.comread online : http://ganns.com/TheGannLetter - Original Message - From: Brian J. Beesley To: [EMAIL PROTECTED] Sent: Wednesday, October 23, 2002 1:52 AM Subject: Re: Mersenne: On v18 factoring On Tuesday 22 October 2002 19:09, Gordon Bower wrote: [... snip ...] Does anyone have any suggestions for how to stop a runaway copy of v18? Perhaps in a few weeks the server can be updated to return an "out of exponents" error to v18 instead of offering it an assignment it can't handle?This is not trivial - if you do this then a "broken" client will probably request another assignment immediately - thus trapping the client and the server into a vicious circle. Whilst the client can go hang for all anyone else cares, the effects on the server would probably be much the same as handing out an "unacceptable" assignment.Other people have mentioned the possibility of "automatically" disengaging or updating the client. I have very serious reservations about this; the problem is that it leaves the system hosting the client wide open to use of the mechanism for malicious purposes, e.g. "updating" to a client containing a trojan or switching it to a different project, or attacking a user by disengaging his systems so that you can leapfrog him in the league tables. I'm afraid that I would have to withdraw my systems from the project, and recommend that other people did the same, if any such capability was added to the client.Given that the server can tell the difference between a v18 client and a later one, would it not make most sense to have the server assign a LL test on the _highest_ unallocated exponent which v18 can handle if a v18 client asks for a factoring assignment and none suitable are available. This action would effectively remove the client from the loop for a while (probably a few months, given that most v18 clients will be running on slowish systems), thereby alleviating the load on the server, and buying time to contact the system administrator - when this is still relevant, of course. And some useful work may still be completed, eventually!RegardsBrian Beesley_Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htmMersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: On v18 factoring
On Tuesday 22 October 2002 21:00, you wrote: Suffice to say that the machine I used to use when working at a *totally different* telecom (not US WEST, oddly) had Prime95 running happily on it. When I left, I didn't get a chance to wipe the machine, so every once in a blue moon I see it check in a result. My mistake, for assuming this company wiped and reloaded machines that were reassigned to someone. IMHO (and I do have some clout on this, as I work in the computer security field) this is NOT your fault. If your previous employer reassigns the system you used to someone else, it's either the employer's or the recipient's responsibility to wipe reload the system. (Depending on corporate policy). This is a SERIOUS CONCERN; otherwise a disgruntled employee could get either the company or his replacement into serious trouble by deliberately leaving illegal data (child porn, pirated software or whatever) on the system, waiting a while then informing the authorities. It's a lowly Pentium 180, but I had checked it to do LL tests regardless of server preference. Meaning that nowadays, it's taking nearly a year to complete one. Big deal, it was still contributing useful results! But perhaps you should have changed the work type to whatever makes more sense 0.1 microseconds before you left/were ejected from the building. I haven't actually seen it in a while, maybe 6 months or more, so maybe they finally retired it (a P180 running NT4 with about 128MB of RAM). It was just odd... 2-3 years after I last saw that machine, and then to see it report in every 6 months or so. The odd part was, the machine must not get used all that much because I thought I had it set to check in every week or so, but it was months between check-ins. In that time, the exponent would expire, but then the machine would come up and start working on it again... meaning someone else had probably got the assignment and may have even finished it for all I know. I have a number of old, slow systems which are used intermittently for testing purposes. I can't leave them all on all the time because the room they're in lacks adequate cooling. Perhaps something similar was going on. Unfortunately this activity pattern does tend to break the PrimeNet server checkin protocol, resulting in work getting reassigned. Still, if you're running LL tests, this probably doesn't matter - if the assignment ever completes, you'd get PrimeNet credit for a double check, and save someone else the effort of running the DC assignment. Regards Brian Beesley _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: On v18 factoring
On Tuesday 22 October 2002 19:09, Gordon Bower wrote: [... snip ...] Does anyone have any suggestions for how to stop a runaway copy of v18? Perhaps in a few weeks the server can be updated to return an out of exponents error to v18 instead of offering it an assignment it can't handle? This is not trivial - if you do this then a broken client will probably request another assignment immediately - thus trapping the client and the server into a vicious circle. Whilst the client can go hang for all anyone else cares, the effects on the server would probably be much the same as handing out an unacceptable assignment. Other people have mentioned the possibility of automatically disengaging or updating the client. I have very serious reservations about this; the problem is that it leaves the system hosting the client wide open to use of the mechanism for malicious purposes, e.g. updating to a client containing a trojan or switching it to a different project, or attacking a user by disengaging his systems so that you can leapfrog him in the league tables. I'm afraid that I would have to withdraw my systems from the project, and recommend that other people did the same, if any such capability was added to the client. Given that the server can tell the difference between a v18 client and a later one, would it not make most sense to have the server assign a LL test on the _highest_ unallocated exponent which v18 can handle if a v18 client asks for a factoring assignment and none suitable are available. This action would effectively remove the client from the loop for a while (probably a few months, given that most v18 clients will be running on slowish systems), thereby alleviating the load on the server, and buying time to contact the system administrator - when this is still relevant, of course. And some useful work may still be completed, eventually! Regards Brian Beesley _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: On v18 factoring
On Wed, 23 Oct 2002 06:52:54 +, Brian J. Beesley [EMAIL PROTECTED] wrote: Other people have mentioned the possibility of automatically disengaging or updating the client. I have very serious reservations about this; the problem is that it leaves the system hosting the client wide open to use of the mechanism for malicious purposes, e.g. updating to a client containing a trojan or switching it to a different project, or attacking a user by disengaging his systems so that you can leapfrog him in the league tables. I am aware of several linux distributions which do the exact same thing (in fact I am not aware of any widely popular one which doesn't). However, they require the user to initiate the update. Would you be more comfortable if that was done, as well as some sort of signature on the update files? Nathan _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: On v18 factoring
An odd thing happened to me a little while back. The machine which I used at a previous job, up to April 1999, started doing trail-factoring again a couple months ago! It's nice to see it working, and apparently not bothering its new owner by working -- but the machine is now out of my control, indeed I don't even know where the machine IS now. It is running version 18, which was, of course, the latest version out at the time the machine was last under my control. It's beginning to experience difficult getting assignments below the the 20.x-million limit. Most of the time everything is fine .. but over the weekend it tied up some 100 exponents in the 20.7-20.9 range, then immediately abandoned them. (It is set to report every day, and reported progress on lower exponents, and, mysteriously, on two higher exponents, yesterday, but has not checked in a report on the other 100 or so exponents since checking them out.) I manually released the abandoned exponents today. This time. But I'd rather not have to do this on a daily basis -- and would rather not cause a meltdown when the server finally runs out of assignments within v18's range altogether. Does anyone have any suggestions for how to stop a runaway copy of v18? Perhaps in a few weeks the server can be updated to return an out of exponents error to v18 instead of offering it an assignment it can't handle? GRB _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
RE: Mersenne: On v18 factoring
I'm embarrassed to admit that I have the same situation. Given my past, I'm concerned about this... Suffice to say that the machine I used to use when working at a *totally different* telecom (not US WEST, oddly) had Prime95 running happily on it. When I left, I didn't get a chance to wipe the machine, so every once in a blue moon I see it check in a result. My mistake, for assuming this company wiped and reloaded machines that were reassigned to someone. It's a lowly Pentium 180, but I had checked it to do LL tests regardless of server preference. Meaning that nowadays, it's taking nearly a year to complete one. I haven't actually seen it in a while, maybe 6 months or more, so maybe they finally retired it (a P180 running NT4 with about 128MB of RAM). It was just odd... 2-3 years after I last saw that machine, and then to see it report in every 6 months or so. The odd part was, the machine must not get used all that much because I thought I had it set to check in every week or so, but it was months between check-ins. In that time, the exponent would expire, but then the machine would come up and start working on it again... meaning someone else had probably got the assignment and may have even finished it for all I know. Very peculiar. I guess I should count my blessings that it's been absent for a long while now, lest the FBI accuse me of hacking in and breaking another telecom's network. :) I think I shared the story about how even for the next year, every now and then a US WEST machine was reporting a result. I just hope that US WEST was checking that status page and used the reports to find the machine still running it and wipe it. Fortunately, last activity on that (just re-checked, to make sure... hehe) was Jul. 31, 1999. Aaron -Original Message- From: [EMAIL PROTECTED] [mailto:mersenne-invalid- [EMAIL PROTECTED]] On Behalf Of Gordon Bower Sent: Tuesday, October 22, 2002 12:10 PM To: [EMAIL PROTECTED] Subject: Mersenne: On v18 factoring An odd thing happened to me a little while back. The machine which I used at a previous job, up to April 1999, started doing trail-factoring again a couple months ago! It's nice to see it working, and apparently not bothering its new owner by working -- but the machine is now out of my control, indeed I don't even know where the machine IS now. It is running version 18, which was, of course, the latest version out at the time the machine was last under my control. It's beginning to experience difficult getting assignments below the the 20.x-million limit. Most of the time everything is fine .. but over the weekend it tied up some 100 exponents in the 20.7-20.9 range, then immediately abandoned them. (It is set to report every day, and reported progress on lower exponents, and, mysteriously, on two higher exponents, yesterday, but has not checked in a report on the other 100 or so exponents since checking them out.) I manually released the abandoned exponents today. This time. But I'd rather not have to do this on a daily basis -- and would rather not cause a meltdown when the server finally runs out of assignments within v18's range altogether. Does anyone have any suggestions for how to stop a runaway copy of v18? Perhaps in a few weeks the server can be updated to return an out of exponents error to v18 instead of offering it an assignment it can't handle? GRB _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: On v18 factoring
Hi, At 11:09 AM 10/22/2002 -0800, Gordon Bower wrote: It is running version 18, which was, of course, the latest version out at the time the machine was last under my control. It's beginning to experience difficult getting assignments below the the 20.x-million limit. Does anyone have any suggestions for how to stop a runaway copy of v18? Perhaps in a few weeks the server can be updated to return an out of exponents error to v18 instead of offering it an assignment it can't handle? You cannot stop a runaway v18 factoring client. It will get and discard assignments until it gets one below 20.5 million that is not factored to 2^64. Scott is supposed to be working on a server fix to give these v18 factoring clients a double-check assignment instead. Until Scott implements his fix, I periodically release these discarded exponents so that you don't have to. I've been watching about 5 machines. Email me your userid and machine name and I'll make sure your exponents get released too. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: On v18 factoring
George Woltman wrote: You cannot stop a runaway v18 factoring client. It will get and discard assignments until it gets one below 20.5 million that is not factored to 2^64. How about a "Black List" of clients that the server will no longer give work to? I would think the problem of pcs no longer under your control would be an increasing problem. Cheers... Russ DIGITAL FREEDOM! -- http://www.eff.org/ _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: On v18 factoring
On Tue, 22 Oct 2002 11:09:59 -0800 (AKDT), Gordon Bower [EMAIL PROTECTED] wrote: The machine which I used at a previous job, up to April 1999, started doing trail-factoring again a couple months ago! It's nice to see it working, and apparently not bothering its new owner by working -- but the machine is now out of my control, indeed I don't even know where the machine IS now. Maybe future versions of Prime95 could have the capability of being shutdown from the server when the program does a regular check in. The server could have a list of obsolete userids/machines. Maybe the equivalent of a Test/Stop could be commanded, or even a more elaborate uninstall could be done. Gary Edstrom _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: On v18 factoring
At 07:03 PM 10/22/2002 -0700, Gary Edstrom wrote: Maybe future versions of Prime95 could have the capability of being shutdown from the server when the program does a regular check in. Actually, version 19 has that feature. Too bad its version 18 clients that are broken! _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: On v18 factoring
At 02:03 AM 10/23/2002 +, Russel Brooks wrote: How about a Black List of clients that the server will no longer give work to? I would think the problem of pcs no longer under your control would be an increasing problem. We want to give them double-checks so that the client isn't continually asking the server for work. This wastes bandwidth needlessly. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: On v18 factoring
Quoting Gary Edstrom [EMAIL PROTECTED]: Maybe future versions of Prime95 could have the capability of being shutdown from the server when the program does a regular check in. The server could have a list of obsolete userids/machines. Maybe the equivalent of a Test/Stop could be commanded, or even a more elaborate uninstall could be done. It's my understanding that something like that was already added after the v17 incident. Nathan _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
