Re: Mersenne: SUMOUT errors
A interesting note, and I forgot to include this in my original post, but the computer that I encountered the illegal sumouts on was a 500MHz K6 PC. Perhaps this is a problem when running those software modems on a K6 based machine?? - Jeramy Original Message - From: "Steve" <[EMAIL PROTECTED]> For what it's worth, I have had the exact same problem getting illegal sumouts when using the modem on this 475Mhz K6 PC. _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Spacing between mersenne primes
At 10:56 AM 5/16/2001 -, "Brian J. Beesley" <[EMAIL PROTECTED]> wrote: >Another point - we're coming up to the second anniversary of the >discovery of M38(?) - I think we're overdue to find another one! It would be nice to find another soon. But I don't think we're overdue. Long ago in Internet time I wrote: Date: Thu, 29 Jan 1998 22:57:31 -0600 "In mersenne primality testing, exponents double in magnitude are much more than double the work. For prime95 or the related versions, each iteration takes about 2.1 times as long as an iteration for half the FFT length, and there are twice as many iterations to perform, per exponent. The odds of a number being prime diminishes as the magnitude increases. Twice the FFT length is usable up to not quite twice the exponent. An interval of n to 2n contains nearly twice as many exponents as the interval 1/2 n to n. In either of these intervals we expect based on experience, to find about the same number of mersenne primes on the average. (The actual rate of occurrence seems to be a little bit in our favor for finding more primes in higher intervals, but it's slight.) That makes about 3 factors of 2. I think to maintain a constant rate of discovery of new primes, we would need to maintain about an 8 or 9-fold increase of computing resources per period of exponent doubling. Since exponent doubling has occurred in about the past year, most of this must come in rapid growth in the cpu pool, both by upgrades and by new membership. Otherwise we can expect to droop back to a lower discovery rate. On average there are less than 2 mersenne primes per exponent doubling: 36 / [ln(2976221)/ln(2)] = 1.67 mersenne primes per doubling of exponent, or about 37 / [ln(~300)/ln(2)] = 1.72 Mp's per doubling of p (though we may have yet to find one in p < 2976221, or slightly above!) In the long run the present discovery rate is unsustainable. Even if we do drop back to a discovery rate of one per two years, from the recent ~2 per year, we will have moved this area ahead by years from its old curve. (The discovery rate was about 1 per 2 years over the past 20 year interval and for the past 40 year interval.)" Our experience described on http://www.mersenne.org/history.htm bears this out. And there is no particular reason to expect the time interval, or the spacing between mersenne primes on a log or linear scale to be uniform. It should vary about the expected curve. Ken Kriesel _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne Digest V1 #853
Mersenne DigestWednesday, May 16 2001Volume 01 : Number 853 -- Date: Tue, 15 May 2001 20:56:20 -0400 (EDT) From: Jason Stratos Papadopoulos <[EMAIL PROTECTED]> Subject: Re: Mersenne: GIMPS accelerator? On Tue, 15 May 2001, Gareth Randall wrote: > Also, any code would be very hardware specific, and may only work if the display was not displaying, say, a desktop. > > However, if someone could implement it, it could provide the *ultimate* in Mersenne related screen savers! What you'd see on the screen would be the actual calculations themselves taking place before your eyes, and with no overheads for displaying it either! This question pops up every once in a while. A few years ago I looked through a postscript manual wondering how difficult it would be to build a postscript file that crunched RC5 keys when a printer tried to render it. The latest bleeding edge graphics cards are programmable to a limited degree (am I thinking of the ATI Radeon here?) but not nearly programmable enough, I'm sure. Heck, at least these ideas have a better chance than the guys who want to crack the programming on kids' toys to make them crunch RC5 keys :) jasonp _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers -- Date: Wed, 16 May 2001 01:32:15 + (GMT) From: Russel Brooks <[EMAIL PROTECTED]> Subject: Re: Mersenne: GIMPS accelerator? John R Pierce wrote: > Virtually all GPU's in use today are fixed function hard wired graphics > accelerators. There's no way to use them for general purpose computational > use. Also, there's no APIs, and each chip vendor has a radically different > architecture. Too bad, the idea might also have given us an interesting screen saver as a side effect! :-) Cheers... Russ _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers -- Date: Tue, 15 May 2001 20:58:34 -0500 From: "Jeramy Ross" <[EMAIL PROTECTED]> Subject: Re: Mersenne: SUMOUT errors I don't really know how much help this will be since I don't know your exact situation and am not a expert by any means, but here goes! First, the software modem may be a culprit. I have had problems with ones of the HSP variety. Most show up as 'HSP Micromodem56' or something very similar on your system. Most of these modems also use a chipset manufactured by PCTel. Fairly stable, but use a nice chunk of CPU time when online, and I have received errors when I am checking email and/or surfing the web while using this type of modem. I have no hard evidence to tie this modem to the errors, but all errors happened when I was using that modem or soon after (I hooked up a external modem just to see if the same would happen with it and I did not receive errors when using it). I have no idea if you have a modem similar to that one or not, but it may be the problem. Also, the electrical environment may be vastly different. I am assuming that where you had your computer was at school, and it is now at home. At my home, I have problems with various utility problems, and have been told by others that utility problems could cause such errors. I invested in a UPS with line conditioning to hopefully control some of those problems. Maybe one of these two things could be your problem.. I wish you the best of luck in finding and fixing the problem! - - Jeramy _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers -- Date: Tue, 15 May 2001 19:21:08 -0700 From: "John R Pierce" <[EMAIL PROTECTED]> Subject: Re: Mersenne: GIMPS accelerator? > This question pops up every once in a while. A few years ago I looked > through a postscript manual wondering how difficult it would be to build a > postscript file that crunched RC5 keys when a printer tried to render it. postscript is essentially forth, after all. Trouble is, most postscript interpreters are pretty damn slow. > The latest bleeding edge graphics cards are programmable to a limited > degree (am I thinking of the ATI Radeon here?) but not nearly programmable > enough, I'm sure. NVIDIA's chips are semi programmable too, but a big hurdle is lack of documentation on the 3D rendering engine. That stuff is trade secret. I *do* suspect you could use the geometry engine (aka "Transformation Lighting and Projection") to do large numbers of fixed point 3x3 vector-matrix dot products with limited precision rather quickly. The question is, how useful would this be? The pip
Re: QA (was re: Mersenne: Purpose of the self-test; also, aren't P4s fast!)
At 10:56 AM 5/16/2001 -, Brian Beesley wrote: >On 16 May 2001, at 0:24, Ken Kriesel wrote: > >> For the time being I would like to continue focussing our QA efforts on the >> general case, rather than P4's specific limits, since > >Agreed. I was talking about the "short" test suite, where the runs >stop after 400 iterations. We can generate the required data for a >large number of exponents without diverting significant effort. In >fact it's much easier to do this than it was a couple of years ago, >as we have at least two reasonably efficient programs other than >Prime95 which can be used to generate & cross-check the data. >> >> If I recall correctly, this does not require "ridiculously" small exponents, >> since the convolution error falls off quickly away from our usual upper >> limit on exponent for a runlength. > >Quite correct. IMO it is "ridiculous" to run a whole LL test using a >FFT run length of 2R when a run length of R would suffice; but >running at least some 400-iteration short tests with a "half size" >exponent during a self-test does make sense in two ways: it saves >having to generate quite as much short run data (since we can recycle >some of the smaller exponents into larger self-test run lengths), and >- providing there is a temporary reduction in the rounding error >limit whilst these short runs are in progress - we would be making >the self-test more stringent. Yes. Even the next-longer runlength provides a very large drop in the expected convolution error for those exponents near the limit of a runlength.(orders of magnitude.) Two to one on runlength is not needed. The ratio 5:4 gives substantial reductions. >There is no point in optimizing the self-test for speed, since we are >going to run the self-test for a fixed period of time. There is some point in having the self-test resemble closely, actual running conditions, to be as valid a test as possible, with respect to everything from bit patterns to power loadings. Ken _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Re: 26 exponents
I believe that is set at the server. Ken At 08:25 AM 5/16/2001 +0100, "Daran" <[EMAIL PROTECTED]> wrote: >Does the client 'know' the threshold performance level for double-checks and >factorisations? If so, is it hard-coded, or does it get this information from >the server? If hard-coded, then you have a problem with people continuing to >use older clients which tell them that it still makes 'most sense' to do >first-time checks, long after it has become more sensible to do double-checks >or factorisations. > > >Daran G. _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Newsgruop formation?
> I'm sure many of us on this mailing list are familiar with Slashdot, and > that the code behind it is open-source (known as Slashcode). we've had 600 messages TOTAL since the beginning of the year. Thats like 3-4 a DAY average. SlashDuh type web forums thrive on communities of 1000s of messages a month. And look at the quality of the average postings on slashduh... mostly cheap and easy microsoft bashing. quite frankly, I detest web forums for this sort of thing. If we had 10X the traffic we have, I'd consider the newsgroup thing, otherwise, a mail list is just FINE. _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Newsgruop formation?
I'm sure many of us on this mailing list are familiar with Slashdot, and that the code behind it is open-source (known as Slashcode). For those of us who aren't, Slashdot (http://www.slashdot.org) is a news website which covers news mainly in the interest of the Open Source community. About 10 of the latest news items are posted on the front page, and each has a related discussion board automatically set up. I propose that someone could implement and host our mailing list on this website... This could allow for people to browse through threads easily, and allow people to catch up easily when joining for the first time, or coming back from vacation. The obvious problem to me is that the creation of new threads is normally done manually, with only the most interesting/serious topics being posted. We won't be having hundreds of posts every day, but somebody (or some group of us) will have to make sure that whenever anybody requests a post, that it gets posted after meeting some criteria... In my opinion, the quality of some of the discussions on this mailing list should be available to the public without having to subscribe to the mailing list. And this type of system will allow anonymous people to post, maybe with valid points... Just my two cents... Ryan McGarry _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Newsgroup formation?
> On Tue, May 15, 2001 at 10:23:33PM -, Brian J. Beesley wrote: > >If you understand _nothing_ discussed on a mailing list, there's no > >point in subscribing. Similarly if you understand _everything_. You > >can always delete the messages which you consider beyond your > >intellect, or beneath contempt. Personally I like the range we have > >at present. > > Yes -- that is my opinion too. I skim quite a lot, though ;-) Personally, I really hate all mailing lists. I was on one once where somebody misused the system, and everybody (at once) complained by emailing a complaint about the post to the base address. Pretty soon people started complaining about the complaints, saying the "huge traffic could be avoided if you had never complaind." Before long, someone thought it would be funny to send a 3MB attachment to everyone, and soon others followed. Now, I know the intellegence level here is __much__ higher, but I didn't join for almost 2 years, because of my hatred of such groups. I'm sure this format is keeping many people away (especially the more experienced netizens). It seems a newsgroup is such a better medium for discussions like this. Then, if I go on vacation for a month, I won't have to unsubscribe to keep my INBOX from overflowing. Also, a newsgroup will allow newbies to read through old posts and see what types of question are asked. This is really the only way to keep the same questions from being asked over and over. But, most of all, I want threading. If I have a K7 processor (I do), I might not want to read about every bugfix in v.21, because it isn't going to affect me. The ability to skip threads is extremely powerful. Oh, and did I mention that keeping my own archive of messages is really eating my disk space? Instead of 50 people saving the same message to read later, it should just be kept on a newsgroup server, so that if I need to refer to it later, I just download it again. -aron _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: SUMOUT errors
For what it's worth, I have had the exact same problem getting illegal sumouts when using the modem on this 475Mhz K6 PC. Hasn't happened since january but had been happening about once a fortnight for months, and _only_ when the modem was heavily in use (Rockwell HCF 56K Data Fax PCI Modem). I had forgotten all about it until I read Jeramy's message. It has never happened on any of my other PCs. Oddly enough, I have noticed on Athlons that the iterations run about 2% faster when the modem is connected! Steve Harris -Original Message- From: Jeramy Ross Date: Tuesday, May 15, 2001 9:24 PM Subject: Re: Mersenne: SUMOUT errors >I don't really know how much help this will be since I don't know your exact >situation and am not a expert by any means, but here goes! > >First, the software modem may be a culprit. I have had problems with ones >of the HSP variety. Most show up as 'HSP Micromodem56' or something very >similar on your system. Most of these modems also use a chipset >manufactured by PCTel. Fairly stable, but use a nice chunk of CPU time when >online, and I have received errors when I am checking email and/or surfing >the web while using this type of modem. I have no hard evidence to tie this >modem to the errors, but all errors happened when I was using that modem or >soon after (I hooked up a external modem just to see if the same would >happen with it and I did not receive errors when using it). I have no idea >if you have a modem similar to that one or not, but it may be the problem. > >Also, the electrical environment may be vastly different. I am assuming >that where you had your computer was at school, and it is now at home. At >my home, I have problems with various utility problems, and have been told >by others that utility problems could cause such errors. I invested in a >UPS with line conditioning to hopefully control some of those problems. >Maybe one of these two things could be your problem.. I wish you the best of >luck in finding and fixing the problem! > >- Jeramy > _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: GIMPS accelerator?
John R Pierce wrote: > The newest Geforce3 chip also has both Pixel Shaders and Vertex Shaders > which are each a SIMD programmable vector processors. The Pixel Shaders > operate on every pixel and generate the actual RGB pixels while the Vertex > Processors operate on the geometry and texture mapping coordinates of the 3D > mesh... I don't know much about these, but pixels are only 8 bits per > component so the pixel processors can't be very wide. Could this help NFS sieving? Ciao, Alex. _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: ECM Question...
Eric Hahn wrote: > > If a person runs an ECM test using a B1 of 250,000 with 700 > curves (for up to 30 digits), will they also find any factors > that they would have found if they had used a B1 of 50,000 with > 300 curves (for up to 25 digits) ?!? > > Eric If the sigma is the same, then a curve with B1=25 will find any factor that a curve with B1=5 finds. When you run 700 random curves at B1=25, you might theoretically miss a factor that someone else finds with B1=5, if he gets a lucky sigma so that the group order is very smooth. But in general, using the same number of curves, the higher bound should find all the factors that the lower bound can find. But dont be tempted into running only a few curves at very high bounds. The strength of ECM is that you can try curves with different group orders until a sufficiently smooth one comes along. So "skipping" bound levels is usually not a good idea unless you have reason to believe the the number unter attack has only large factors which call for a higher bound. Ciao, Alex. _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: GIMPS accelerator?
On 15 May 2001, at 22:46, Ken Kriesel wrote: > Among others, I raised the question with George Woltman some time ago. > I trust his judgment that his time is better spent elsewhere. Agreed! > > However, I wonder if there might be some possibilities in trial factoring > there. > That would present the possibility of a factoring screensaver, and an FPU > LLtest, running together on what is nominally a uniprocessor. > > Just speculation, Nice idea (using the fact that trial factoring & screensaver would be almost pure integer work, whereas LL testing is almost pure FP) but with practical difficulties. (1) To get any benefit, you're going to have to bind all that functionality into one thread - because if you are running more than one thread, the OS will schedule the threads independently, throwing away any benefit which might be gained by parallelism. (2) I think there would be serious difficulties in coordinating code between LL testing (time per iteration almost constant, of the order of tens of millions of CPU cycles) & trial factoring (time per candidate very variable, and of the order of hundreds of CPU cycles). I've no idea at all as to how you would usefully squeeze in a screensaver too, but I do think that the code coordination neccessary to parallelize tasks in a single process thread would be very hard to achieve. (3) Though trial factoring places almost no load on the system memory bus or the floating-point execution units, there are other potential bottlenecks within the CPU - in particular, the L1 instruction cache, instruction decoders, instruction pipelines, jump prediction tables & "spare" registers (required for out-of-order execution) - which may well limit severely the amount of factoring work which could be done in parallel with LL testing, without inflicting a significant performance penalty on LL testing. Given that trial factoring is well advanced, implementing a scheme which increases the trial factoring throughput of the project as a whole at the expense of LL testing throughput does not seem to be a good idea. However, if anyone can provide the functionality that Ken suggests without impacting LL testing performance noticeably, I'll be just as grateful as everyone else! 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: GIMPS accelerator?
-Original Message- From: Gareth Randall <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: 15 May 2001 23:36 Subject: Re: Mersenne: GIMPS accelerator? >Daran, > >This is an interesting piece of lateral thinking that deserves to go further >than I think it actually does. Thank you for taking me seriously. >Essentially, I'm not sure how the operations that a graphics card can >provide, such as line drawing, texture overlaying, raytraced light effects >etc, could be made to implement a LL test or FFT etc which would require >things like bit tests, conditioning branches and loops etc. What you've listed are the functions of a graphics card, each of which will have been implemented through the application of one or more primitive operations. For example, the function of mapping a set of co-ordinates in 3-space onto screen pixels will be implemented by a linear transformation, which will itself be implemented through a number of scalar multiplications. I'm wondering if it might be possible to access any of the available primitive operations without having to invoke a specific card function. AFAICS the problem requires affirmative answers to all of the following questions. 1.Can the hardware theoretically do work useful to GIMPS? 2.Could this be done efficiently enough to be worthwhile? 3.Is it possible to program the hardware to do this work? 4.Would it be possible to read the results back from the card? 5.Is the available technical documentation sufficient for a programmer to be able to implement this? 6.Would the implementation be acceptable to the user? 7.Are the prospective gains to the project worth the programming effort? I suspect the answer to 1 is yes, given how simple the requirements are for a set of primitive operations to be able to universally compute - the Turing machine and Conway's life spring to mind. But we wouldn't waste time programming a hardware Turing machine to do LL tests, even if we had one. An example of a user issue would be if the only way to program the card is to 'flash upgrade' the GPU's on-card firmware. I wouldn't be willing to do that, although I might consider installing a special GIMPS driver, so long as I could uninstall again. >Conceivably additions could be done by superimposing textures and reading >back the resulting frame buffer, but these wouldn't be 64-bit precision >additions! That's all you get with CPU integer arithmetic, but you can build longer ones out of the shorter. >Maybe some form of matrix multiplication could be done by rotating textures >before superimposing? However, I think the resulting calculation efficiency >would be very poor, and may never achieve useful precision. Could you not build an FFT out of Discrete Cosine Transforms? Or build a multiplication from DCTs in some other way? Some cards have hardware support for this. >Also, any code would be very hardware specific, and may only work if the >display was not displaying, say, a desktop. Which would hit 'prospective gains' question hard, since it would not then be useful on Windows machines. >However, if someone could implement it, it could provide the *ultimate* in >Mersenne related screen savers! What you'd see on the screen would be the >actual calculations themselves taking place before your eyes, and with no >overheads for displaying it either! That I did not think of. >Yours, >=== Gareth Randall === Daran G. _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Re: 26 exponents
On 15 May 2001, at 22:36, Steinar H. Gunderson wrote: > On Tue, May 15, 2001 at 04:48:19PM +0100, Daran wrote: > >BTW what happens now when a first-time check, (or for that matter, if a > >double-check) discovers a new prime. Surely this is checked immediately on > >the fastest machine available to the project, and not left to the vagaries of > >random allocation? > > It is run on a different architecture, with different software. The > three first were (as far as I know) tested on Crays, Through the good offices of David Slowinski. > while the 4th (M38 > (we think)) was tested on an Alpha machine with mlucas, as far as I > remember. Yes. DS couldn't help, for some reason, probably due to Cray having been bought out by Silicon Graphics. > > The idea is to completely eliminate any possibility of a persistent > program or hardware bug :-) Plus, Prime95 didn't have the random shift code which allows it to check its own results until after M37 was discovered; and the random shift code was rather new when M38(?) was discovered. Another point - we're coming up to the second anniversary of the discovery of M38(?) - I think we're overdue to find another one! 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: GIMPS accelerator?
On 15 May 2001, at 18:22, Daran wrote: > GIMPS clients use the spare capacity of the primary processing resource within > any computer:- the CPU(s). But most modern PCs have another component capable > of performing rapid and sophisticated calculations:- the GPU on the graphics > accelerator. Is there any way that the GPU can be programmed to perform GIMPS > processing when otherwise not in use? There are several practical difficulties: (a) GPUs are usually 32-bit, single-precision hardware. Nothing more is needed for graphics displays. Running multiple precision arithmetic using floating-point FFT in single-precision hardware is not very effective; you need about 20 guard bits; with a single- precision manitssa being 24 bits long, you don't have very much left to work with. (b) GPUs run code from ROM. The system as a whole transfers data but not instructions from the main CPU to the GPU through the video card bus connectors. There is no easy way to change the code which runs the processor(s) on the graphics card. (c) Even if the GPU was programmable from the system, there are so many different graphics card controller architectures that writing code that would work nearly universally would involve something close to an impossible amount of effort. And graphics cards keep changing, fast! (d) Don't forget that running a LL test on a 10M exponent involves about 8 MBytes of data storage. This is not a serious problem given the amount of system memory available to most systems capable of completing a LL test on a 10M exponent in a reasonable time, but "robbing" 8 MBytes from the more limited memory available on most graphics cards might well be critical. 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: Re: 26 exponents
-Original Message- From: Brian J. Beesley <[EMAIL PROTECTED]> To: Nathan Russell <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: 15 May 2001 23:57 Subject: Re: Mersenne: Re: 26 exponents >Actually I think that there may be a perceptual problem with many new >users in that they may give up as soon as they realize that a "most >sense" assignment is going to take several weeks to complete. >Unfortunately there seems to be no easy way to fix this! I think this could be a significant problem. I'm currently 46% of the way through double-checking M6193307, and I'm expecting to complete it on 26 July. Last time I dropped bellow 90 days queued work, I requested a factorisation, just to see what the range was. I got M16065053, which I expect to complete on 6 September - nearly six weeks to do the fastest possible assignment. This doesn't bother me now - I wouldn't be bothered if it took a year or more - but when I started, I was keen to return a result. OK, you might think a slow machine like mine would be no great loss to the project, but I'm not going to have this abacus for ever. One improvement would be to credit people with work done each time they check in, instead of only when they return a result. That way they can see themselves on the producer charts more or less immediately. Another possibility would be to extend the project to search for something else - there must be many other interesting number-theoretic questions involving primes which are not currently being researched in depth, and which could benefit from a distributed approach. We already do this with factorisations which do not contribute to the search for a Mersenne prime. There must be many people who started off doing factorisations before moving on to double-checks and first-time LLs. [...] >> Perhaps clicking the 'give me the work that makes the most sense' box >> should immediately set the appearance of the others to the work that >> will be chosen, rather than simply graying them out. > >Agreed. Does the client 'know' the threshold performance level for double-checks and factorisations? If so, is it hard-coded, or does it get this information from the server? If hard-coded, then you have a problem with people continuing to use older clients which tell them that it still makes 'most sense' to do first-time checks, long after it has become more sensible to do double-checks or factorisations. Regards Brian Beesley Daran G. _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
