Re: Mersenne: Where is M23494381?
On Thursday 25 December 2003 23:22, Ignacio Larrosa Cañestro wrote: Where went M23494381? I has assigned that exponent to factor. But today it dissappears from my Individual Account Report. And I don't found it in the Assigned Exponents Report nor in the Cleared Exponents Report ... Yes - one of my system lost an assignment a couple of days ago - or at least it did an automatic checkin the elapsed time dropped to zero. I'd just let it carry on running. 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: Re: Large memory pages in Linux
On Tuesday 23 December 2003 20:15, Matthias Waldhauer wrote: Last friday I read some messages about recent kernel modifications and patches for version 2.6.0. There is an imcplicit_large_page patch, allowing applications to use large pages without modifications. I don't have the time to dig into it :( Sure. This is a much better approach than mucking about with application-specific modifications which would likely involve serious security hazards (leaking kernel priveleges to the application) and/or clash with other applications private large-page code and/or large page enabled kernels in the future. The bad news with kernel 2.6 is that the (default) jiffy timer resolution is changed from 10ms to 1ms, resulting in the task scheduler stealing 10 times as many cycles. This will likely cause a small but noticeable drop in the performance of mprime. Probably ~1% on fast systems. In other words the cycles gained by large page efficiency could easily be swallowed up by the task scheduler being tuned to improve interactive responsiveness (and cope with more processors in a SMP setup). I suppose you could retrofit a 10ms jiffy timer to the 2.6 kernel, but then you could just as easily patch large page support into a 2.4 kernel (hopefully) keep the stability of a tried, tested trusted kernel. Finally, the good news. Crandall Pomerance p441 describes the ping pong variant of the Stockham FFT, in which an extra copy of the data is used but the innermost loop runs essentially consecutively through data memory. CP note that contiguous memory access is important on vector processors but similar memory access techniques are surely the key to avoiding problems with TLB architectures _and small processor caches_ - and the largest caches present on commercial x86 architecture are indeed small compared with the size of the work vectors we use for LL testing. Perhaps implementation along these lines could reduce the cache size dependency which seems to affect Prime95/mprime - though paying a very large premium for the extreme version of the Intel Pentium 4 is most certainly not cost effective in view of the small performance benefit the extra cache generates, most probably because the Prime95/mprime code appears not to be tuned for the P4 Extreme Edition. Seasonal felicitations Brian Beesley _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Another thought on the L-L Test
Hi, Another thought struck me - this could have useful applications in L-L testing programs. If M is the Mersenne number being tested R(i) is the L-L residue after i iterations, then R(i+1) = R(i) * R(i) - 2 (modulo M) (by the statement of the L-L algorithm) But note that (M - R(i))^2 - 2 = M^2 - 2MR(i) + R(i)^2 - 2 so (M-R(i))^2 - 2 (modulo M) is clearly equal to R(i+1). How can this be of any use? Well, when we have a dubious iteration (say an excessive roundoff or sum error) we can check the output by redoing the last iteration but starting from (M-R(i)) instead of R(i) - the output should be the same. Furthermore the action of calculating M-R(i) is very easy - just invert all the bits. Also, if we have suspicions about the accuracy of code when there is a high density of 1 bits, we can try just one iteration but starting at M-4 instead of 4. The output residual should be 14 irrespective of M (providing M7 - as will often be the case!). The point here is that, just as the value 4 is represented by a string of p bits only one of which is set, M-4 is represented by a string of p bits only one of which is unset. 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: Speeding Up The Speediest Yet
On Saturday 12 July 2003 13:08, Scott Gibbs wrote: Dear Base: By a twist of extraordinary luck I procured a 3GHz. P IV with 1 GByte of RAM which translates to 12 possible 1 million candidate tests per year. But I found a way to accelerate this behemoth even more! By installing the www.memokit.com memory optimizer and setting the priority of PRIME95 to REALTIME, I brought the .081 spec down to .063 at the very top of the Benchmark list. 1) Assuming your system is otherwise idle, changing the priority should have zero effect. 2) Again assuming your system doesn't run loads of other stuff, 128 MBytes is more than sufficient for running LL tests in Prime95. More is useful for P-1 stage 2 and ECM, depending on the exponent. 3) I've no idea what the memory optimizer does, but any bigger change than a few percent is most unlikely - unless you do something like overrrunning the memory clock? BTW I'm getting 0.084 benchmark for 1792K FFT run length on a 2.66 GHz P4 using dual-channel PC2100 DDR memory, e7205 chipset. 0.063 sounds about right for a 3GHz system using dual-channel PC3200 DDR. 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: Squaring huge numbers
On Sunday 29 June 2003 05:42, Pierre Abbat wrote: I am investigating 64-100 sequences, which are chains of bases such that the number written 100 in each is written 64 in the next (e.g. 8,10,16,42). I quickly wrote a Python program to compute them. It is now computing the square of a 1555000 digit number and has been doing so since the 17th. What squaring algorithm is Python using? I don't know offhand, but: (a) Python is interpreted; (b) the Python interpreter is open source, so it shouldn't be hard to find out how it does big integer arithmetic; (c) you might also look for a dependence on the GNU multi-precision library (GMP) since that is an obvious candidate; (d) whatever method it's using doesn't seem to be very efficient - you have been running for 10 days to execute something which mprime/Prime95 would accomplish in a small fraction of a second. Is there a faster way of squaring numbers where the number of digits doubles at each iteration? There is x^2 code in the published mprime/Prime95 source. To do what you require would obviously require you to hack together something to load the initial work vectors read the result back out when you've finished. Also you would need to start with twice the FFT run length you would require for the multiplication modulo 2^p-1 (so there is room for the double-length result) double the run length again for each squaring. But it looks more like lots of work than being difficult. An alternative approach, cobble something together using GMP, which is reasonably efficient for general work, though not blindingly so. 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: Double Checking
On Saturday 28 June 2003 18:47, you wrote: Will the 64-bit residue be the SAME when a given exponent was originally Lucas-Lehmer tested with a 384K FFT, but the double-check is performed using a 448K FFT ? Hopefully - in fact the whole 2^p-1 bit residue R(p) should be the same! R(2)=4 R(n+1) = R(n)^2 -2 modulo 2^p-1 I don't see how the FFT run length should affect this ... in fact the FFT is only used at all because it's the most efficient method known of doing the multiplication of very large numbers. If the residues calculated with 384K FFT 448K FFT are different, then: - most likely, at least one of the runs has been affected by a glitch of some sort; - or, the 384K FFT run length is too small some data value was rounded to the wrong integer during the run - I do not think that this is very likely unless serious abuse has been made of the SoftCrossoverAdjust parameter; - or, there is a systematic error in the program code for at least one of the run lengths. Since short runs (400 or 1000 iterations) have been crosschecked with various FFT run lengths, again I do not think this is very likely. 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: M#40 - what went wrong?
On Monday 16 June 2003 20:16, George Woltman wrote: I'm also adding code to 23.5 to check EVERY iteration for an impossible result such as -2, -1, 0, 1, 2. This test will be very, very quick. Sounds sensible to me ... but, does it not make sense to run this test during those iterations when testing for excess roundoff error occurs, i.e. normally only 1 in 128 iterations? The point here is that, once the residual gets into a loop like this, it won't get out again. FYI, six times a result of 0002 has been reported to the server. So, somehow or another it is possible for a hardware error to zero the FFT data without triggering an ILLEGAL SUMOUT. Any instances of FFFE? Should be about as common, if this is a hardware related problem. There are lots of reasons why memory corruption may occur but, in most cases, it is hard to see how a whole block of data should be filled with zero (or one) bits without corrupting the program code in such a way that the program would crash or have the operating system crash from under it. I think the most likely scenario would be that a pointer to the FFT work space could be corrupted point to virtual memory which has zero on demand attribute. This might be detectable by memory leak even on systems without proper memory protection (Win 9x) but could be fixed easily enough by keeping _two_ pointers to critical work space (the values don't change that often...) comparing them occasionally. As to why the pointer might get corrupted, most likely we're looking at stack overflow or some other program behaving badly rather than a bug internal to Prime95. It would be interesting (though probably impossible) to check which OS the residue 2 runs were run on. If my logic is right then I would suspect that they were all run on Win 9x/ME rather than NT, W2K, XP or any of the varieties of linux, where proper memory protection should give much better protection against this sort of problem. 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: Re: M#40 verification run
On Thursday 12 June 2003 10:07, Nathan Russell wrote: That is a collosal understatement. Every modulo operation destroys information, and I'm not sure whether one COULD construct such a file. Indeed. In general there will be more than one x such that x^2-2 = R modulo 2^p-1 so, working backwards through a number of steps, you would have only a very small probability of deriving the same starting condition. Even if the equation was easy to solve in reverse... 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: mersenne prime +2
On Saturday 05 April 2003 20:33, Alexander Kruppa wrote: Bjoern Hoffmann wrote: Hi, I wondered if someone already have checked if the last mersenne numbers +2 are double primes? like 3+5, 5+7, 9+11, 11+13 or 824 633 702 441 and 824 633 702 443 regards Bjoern Mp + 2 is divisible by 3 for odd p and thus cannot be prime. Mp - 2 however can, in theory, be prime and form a twin prime with a Mersenne prime. A list of the status of Mp - 2 for known Mersenne primes can be found on Will Edgington's page, http://www.garlic.com/~wedgingt/mersenne.html Try the M3status.txt link right at the top. As you see most Mp - 2 have known factors, some others have failed probable primality tests. However you will notice that for the present record prime, M13466917, no status is listed for M13466917 - 2. This is because no factors are known, nor has a primality test been done yet. I have searched for factors in vain up to almost 10^13 and am planning to do a primality test, but I'm still not determined which program to use for optimal speed. I would think that running Miller's Test (for strong pseudoprimes) would be worthwhile... this _should_ take about the same time as a Lucas-Lehmer test on the associated Mersenne number, but there may be a problem with fast calculation modulo (2^p-3). It might be possible to modify PRP (Woltman) and/or Proth (Gallot) to perform this test without an enormous amount of effort. Even without a shortcut for modulo (2^p-3) working, the run time should be reasonable on a fast PC system. Proth may also give some clues about constructing a Lucas sequence to perform a proper primality test, though the run time is likely to be a lot longer than a Fermat/Miller pseudoprime test isn't worth the effort of starting unless the number is found to be a probable prime. 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: mersenne prime +2
Hi, The _only_ incidence of 2^p-1 2^p+1 both being prime is p=2 yielding the prime pair (3, 5). Here's a proof by induction: Consider the difference between the second successor of two consecutive Mersenne numbers with odd exponents: (2^(n+2)+1) - (2^n+1) = 2^(n+2) - 2^n = 2^n * (2^2 - 1) = 2^n * (4 - 1) which is clearly divisible by 3. Now 2^1 + 1 = 3 is divisible by 3, therefore 2^p+1 is divisible by 3 for _every_ odd p (irrespective of whether or not 2^p-1 is a Mersenne prime). However I believe there is at least one known Mersenne prime 2^p-1 for which it is not known whether (2^p+1)/3 is prime or composite. Regards Brian Beesley On Saturday 05 April 2003 18:47, Bjoern Hoffmann wrote: Hi, I wondered if someone already have checked if the last mersenne numbers +2 are double primes? like 3+5, 5+7, 9+11, 11+13 or 9 = 3^2 (well, usually) 824 633 702 441 and 824 633 702 443 regards Bjoern _ 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: mprime and primenet
On Tuesday 01 April 2003 07:11, John R Pierce wrote: I just started running a recent build of mprime on a couple of linux systems, and noted an anomaly vis a vis primenet... When mprime connects to primenet, its not updating date on the rest of the worktodo, only on the exponent actually in progress. case in point... 18665107 67 13.6 7.4 67.4 26-Mar-03 12:48 18-Mar-03 17:20 xeon1b 2790 v19/v20 18665149 66 13.6 17.4 74.4 18-Mar-03 17:20 xeon1b 2790 v19/v20 I guess what's happenning is that mprime checks in a single assignment after completing the P-1 factoring. The default config these days leaves factoring until the assignment reaches the top of the heap. mprime -c only forces connection to server if prime.spl exists (there are unreported results!) or if there is now less work remaining than your specified value. If you want to force updating completion dates, run mprime -m use the manual communication menu (item 12 I think). 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: servers down completely?
Hi, There still seems to be a problem of some sort. This morning (between 0800 0900 GMT) I was able to get some results checked in but since then I'm getting server unavailable from the client. traceroute shows a nice loop: This is typical of a problem at a network leaf node. The site router has a default route which points down the link to the network as a whole; when the leaf (target host) is online it generates a local route which overrides the default for the address(es) used. Meanwhile the network node to which the site router connects has a route for the entire site. So a packet with the leaf's address bounces between site the adjacent network node routers until it times out. The _correct_ configuration at the site is to specify a static default route for the whole site's address which points to a null interface so that undeliverable packets are instantly dropped. 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: p4 xeons...
On Saturday 15 March 2003 01:07, John R Pierce wrote: another minor question... Is there any way to force CPU affinity, or does mprime do that automatically? Unlike Windows, linux has a smart CPU/task allocation algorithm that tries hard (but not too hard) to run a thread on the same CPU it used last. So there's no need to force CPU affinity, in fact this might well damage throughput. As for hyperthreading - I believe the development kernel (2.5.x) has support for hyperthreading. You will almost certainly need to build your own custom kernel to obtain this support. The best sources of information on task allocation on a multiprocessor linux system are, not surprisingly, the kernel documentation and the source code itself. 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: Optimal choice of E in P-1 computations
On Sunday 09 March 2003 12:24, Daran wrote: In the hope of more quickly collecting data, I have also redone, to 'first time test' limits, every entry in pminus1.txt which had previously done to B1=B2=1000, 2000, and 3000. For these exponents, all in the 1M-3M ranges, the client was able to choose a plan with E=12. Unfortunately, I found far fewer factors in either stage 1 or stage 2 than I would expect, which suggests to me that exponents in this range have had additional factoring work (possibly ECM) not recorded in the file. 1) What about factors which would be found with your P-1 limits but happened to fall out in trial factoring? (In fact a lot of the smaller exponents - completed before P-1 was incorporated in the client - seem to have been trial factored beyond the ecomonic depth.) In any case, if you're using very small values of B1 B2, I would _expect_ that a very high percentage of the accessible factors will be found during normal trial factoring. 2) It would not surprise me at all to find that there is a substantial amount of P-1 work being done which is not recorded in the database file. I've also had very bad luck when extending P-1 beyond limits recorded in the database file for exponents under 1 million. Eventually I gave up. 3) ECM stage 2 for exponents over 1 million takes a serious amount of memory (many times what P-1 can usefully employ), whilst running ECM stage 1 only is not very efficient at finding factors - lots of the power of ECM comes from the fact that stage 2 is very efficient (assuming you can find memory!) Of particular concern is the possibility that in addition to reducing the number of factors available for me to find, it may have upset the balance between 'normal' and 'extended' P-1 factors - the very ratio I am trying to measure. One way to deal with this would be to deliberately forget previously reported work, i.e. take _all_ the prime exponents in the range you're interested in, trial factor to taste then run P-1. This way you can be sure that, though the vast majority of the factors you will find are rediscoveries, the distribution of the factors you find is not distorted by unreported negative results. 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: please recommend a machine
On Saturday 08 March 2003 03:35, spike66 wrote: Some of you hardware jockeys please give me a clue. I have two machines at home running GIMPS 24-7. One is a P4-2Ghz. The other is a 5 yr old 350 Mhz PII, which is in need of a tech refresh. Clearly there is more to computer performance than clock speed, but for GIMPS I suppose clock speed is everything. Is it? My other machine already has a DVD writer, networked etc, so I need not rebuy that. What should I buy? I have no hard spending limit, but I am looking for value and suppose that a thousand dollar machine would be more than adequate. Does AMD vs Intel matter? Does bus speed matter? 1) In this position you are _far_ better off building your own system. It's interesting in itself, offers a cash saving when you can delete unwanted parts or recycle old peripherals and is the only way you can guarantee to get optimised performance. Medium or large systems builders catering for the retail or direct sales market will almost always not be able tell you the specification of important parts of the system - in fact just about all they will be able to tell you is processor type, speed HDD size. This is like choosing an automobile on the basis of number of cylinders, top speed number of seats - usually there are other factors you might want to consider. 2) If you want to use the system for general purpose tasks then there is something to be said for AMD systems. But, because of the efficiency of SSE2 code in Prime95/mprime, a P4 system is _much_ better value for money if that's what you're intending to use the system for. 3) Whether you go for AMD or Athlon, avoid the top two or three CPU speeds. You pay increasingly large amounts of money for relatively small increases in speed. In any case, if you're building a system which is otherwise state of the art, you will be able to upgrade the processor in one year to a processor chip faster than today's top of the range, keep the old one and still have money in your pocket. (The old processor chip can of course be sold on eBay). 4) The chipset for P4 systems is in a state of flux at the moment. There are several available but only two worth considering: i850e and e7205. The differences here are substantial e.g. i850e supports 533 MHz RDRAM (PC1066) whereare the e7205 supports dual-channel DDRAM. Actually the theoretical memory bandwidth are the same - but DDR is much cheaper easier to obtain. Also the e7205 chipset, and only the e7205 chipset, supports hyperthreading. Systems using single-channel DDRAM memory will be considerably slower with the same clock speed - probably 10-15%. The way I look at it, the ~$200 required to buy a 10% faster processor is better spent on a more efficient memory subsystem. Same applies with RDRAM - using cheap PC800 RDRAM in a system which supports PC1066 is a very bad compromise. The last two systems I've built have been as follows: P4-2533 / Asus P4T533-C / 4 x 128MB PC1066 RDRAM P4-2666 / Asus P4G8X / 2 x 256MB PC2100 DDRAM Neither of these mobos are cheap, but bear in mind that the P4G8X has just about everything you might need on board, except the graphics adapter. (6 USBv2, 2 Firewire, 6 channel audio, gigabit LAN as well as the still-standard PS/2, serial parallel ports). It also supports RAID but only on the two serial ATA ports it boasts in addition to the two standard IDE ports. The combination I used for the P4-266 system should come in _well_ under $1000. You could probably recycle the old peripherials (monitor, kb, mouse, floppy, CD, hard disk) from your old P2-350 unless you really feel like shelling out. You _might_ be able to recycle the old case as well - however you will probably need to replace the PSU with a new one in order to supply the power requirements of a P4 system. Look for PSUs rated over 300W with dual fans - I particularly reccomend the Enermax PSU with rheostat fan speed control because it's quiet effective, though certainly not cheap. In any event it would be worthwhile considering replacing the case with a new, top-end version in order to get decent cooling without having to have noisy fans. The Coolermaster ATC-200/201 cases are very well built, elegant and have 4 quiet fans - cooler and much quieter than one standard one. Thermaltake Xaser cases are cool and also feature multiple fans with a speed controller; they're significantly cheaper and undoubtedly adequate but much tinnier in build quality. You should also consider the Zalman CPU cooler instead of the retail Intel unit. It's very effective and very quiet (except when turned up to maximum, which shouldn't be neccessary!) Adding a Coolermaster case Zalman fan to the suggested P4-266/P4G8X system will get you close to the $1000 mark. The last wrinkle here is that you will probably _not_ be able to recycle the graphics card from your old system. All decent P4 mobos _require_ an AGP graphics card capable of
Re: Mersenne: P-1 on PIII or P4?
On Thursday 06 March 2003 13:03, Daran wrote: Based upon what I know of the algorithms involved, it *ought* to be the case that you should do any P-1 work on the machine which can give it the most memory, irrespective of processor type. ... assuming the OS allows a single process to grab the amount of memory configured in mprime/Prime95 (this may not always be the case, at any rate under linux, even if adequate physical memory is installed.) However, some time ago, I was given some information on the actual P-1 bounds chosen for exponents of various sizes, running on systems of various processor/memory configurations. It turns out that P4s choose *much deeper* P-1 bounds than do other processors. For example: 8233409,63,0,Robreid,done,,4,45,,Athlon,1.0/1.3,90 8234243,63,0,Robreid,done,,4,45,,Celeron,540,80 8234257,63,0,Robreid,done,,45000,742500,,P4,1.4,100 The last figure is the amount of available memory. The differences between 80MB and 100MB, and between 8233409 and 8234257 are too small to account for the near doubling in the B2 bound in the case of a P4. Yes, that does seem odd. I take it the software version is the same? The only thing that I can think of is that the stage 2 storage space for temporaries is critical for exponents around this size such that having 90 MBytes instead of 100 MBytes results in a reduced number of temporaries, therefore a slower stage 2 iteration time, therefore a significantly lower B2 limit. I note also that the limits being used are typical of DC assignments. For exponents a bit smaller than this, using a P3 with memory configured at 320 MBytes (also no OS restriction plenty of physical memory to support it) but requesting first test limits (Pfactor=exponent,tfbits,0) I'm getting B2 ~ 20 B1 e.g. [Thu Mar 06 12:07:46 2003] UID: beejaybee/Simon1, M7479491 completed P-1, B1=9, B2=1732500, E=4, WY1: C198EE63 The balance between stage 1 and stage 2 should not really depend on the limits chosen since the number of temporaries required is going to be independent of the limit, at any rate above an unrealistically small value. Why am I bothering about this exponent? Well, both LL DC are attributed to the same user... not really a problem, but somehow it feels better to either find a factor or have an independent triple-check when this happens! 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: Why is trial factoring of small exponents slower than large ones?
On Friday 07 February 2003 04:00, 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. Can someone tell me why the time difference is so great? Factors (if any) of 2^p-1 are all of the form 2kp+1, so there are less candidate factors to check in any particular range as the exponent increases. FYI the exponents under 1 million have already had a lot of extra-curricular factoring work done on them - _all_ have had P-1 run to limits much higher than the economic values suggested by mprime/Prime95, many have already had extra trial factoring done, and some of the smaller ones have had substantial amounts of ECM work. I'd expect you to find _some_ factors by extending trial factoring even further, but not very many. If you have a reasonable amount of memory on your system I'd reccomend running P-1 on selected exponents just above 1 million - use the pminus1 database file to direct your work. Otherwise ECM on small exponents, or trial factoring on those exponents which have not been done deep enough - there are a considerable number of these in the 6M - 8M exponent range. 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: ECM
On Saturday 01 February 2003 07:53, Eric Hahn wrote: Let's say you've done 700 curves with B1=25,000 to find a factor up to 30-digits... and you've been unsuccessful... :-( Now you've decided to try 1800 curves with B1=1,000,000 to try and find a factor up to 35-digits. Do you have to start from scratch... or can you somehow use the information from attempting to find a factor up to 30-digits... to save some time and energy... and speed up the search process at the same time??? Effectively every curve is starting from scratch. The only way I can think of using information from previous unsuccessful curves is that it's probably a Bad Idea to use the same s-value (well, it's a complete waste of time if the limits are not increased). The point here is that the chance of picking a previously-used s-value is infinitesimal, providing the random number generator on the system is reasonably behaved. 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: Re: poaching
On Wednesday 29 January 2003 01:07, Paul Missman wrote: You bring up an interesting point about the software, I suppose. I never thought that George or Scott considered the software proprietary. This whole area is a legal minefield ... Even open source software can be proprietized, e.g. the mess Microsoft have made of TCP/IP starting from the published BSD source. I'd think that a basic Lucas-Lehmer type software could be written without too much headache, though I've never tried my hand at it. If you try, let us know how you get on. Making the thing _work_ is easy enough. Making it tolerably efficient, say better than 50% the speed of Prime95/mprime (or Glucas or Mlucas on other hardware) is a different matter altogether. Assuming you're starting from scratch, not just filching other people's DWT code. I do wonder at your assertion that, were I to discover a large prime by a self written program, I would have to publish the program along with the discovered prime. I'd imagine that, as long as the number could be verified by independent means, it would be an publishable fact. Not being authorized to speak for EFF, my guess is that you may be right. However, what independent means are you going to use for the demonstration, if not established LL testing software? The numbers we're talking about are so large that other methods e.g. ECPP are _at least_ several orders of magnitude too slow to be viable, even if you had a large grid of supercomputers at your disposal. In any case, $100K is a lot more than you'd expect to be able to sell a LL testing program for - so disclosure of the source (at least the key working parts of it) would seem to be sensible. I'll admit that I didn't follow this poaching thread from the beginning. I just noticed much more than the normal volume of Mersenne email, and decided to see what was up. The Idea that someone can poach a number still strikes me as humorous. It is a bit like me trying to copyright the number1234567890. I doubt that the claim would hold much water if tested in a court of law. This is a very interesting issue. The software, music and film industries are trying very hard to do just this sort of thing - and having considerable success in the courts. (Patenting software, and extending the life of copyright for absurd times). Don't forget that a digital recording, like anything else stored in a computer, is nothing more than a string of 0 and 1 bits, i.e. it can be thought of as simply a very large number. Don't forget also the hoo-ha over the publication of a prime number specially crafted to contain the source code of the DeCSS algorithm. Is the negative impact here that large groups of numbers are being tied up for unreasonable lengths of time? Or is it that some lucky person might just happen to stumble on a large prime, and publish it, while someone in GIMPS/Primenet had it checked out for testing? I thought the negative impact was that a user assigned a job of work may be discouraged by finding that job of work made irrelevant by someone else doing the same job _and reporting the result to the same authority_. Especially when the poacher is using the statistics tables published by the project to select the jobs (s)he is going to poach. The fact that the lowest outstanding exponent in some (arbitary) class may remain fixed for a long time doesn't bother me, but I can understand how it might irritate some people. As for the chance of a poacher poaching a prime discovery - well, at best these are much the same as anyone else's; in practise they're probably a lot worse, as many of the exponents being poached will have been recycled due to possible errors in a previous run, possibly more than once by the time the exponent is close enough to the trailing edge to be a tempting target. If the latter, I'd have to say, in my mind, finding a large prime is pretty much a crap shoot. However, I'd support some sort of reasonable timeout on the ownership of numbers checked out from the database. Yes. And there is at present a sort of timeout, it's just that it's possible to work around this by checking in every few months without actually doing any work. Also, if I had some magic insight into the probability of a particular number turning up prime, I'd probably want to test it, even if I didn't own it. Good luck to you. My guess is that, if your magic insight was based on mathematics rather than gambler's intuition, the insight would be worth considerably more than the actual discovery of the prime. 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: GIMPS Forum
On Sunday 26 January 2003 06:11, Rick Pali wrote: [... snip ...] that *everything* on the site is copyright by the owner. No exception is made for the forums. They even go so far as do reject liability for what people write, but seem to claim ownership non-the-less. IANAL but I don't think the combination of ownership disclaimer would convince a court. If you claim you own the content then you become liable for legal action in the event that someone posts defamatory or illegal content, or breaches someone else's copyright by posting copyrighted material without proper consent. IASNAL but I think the correct thing to do on a forum - unless the contents are _strictly_ moderated _before_ being posted in public - is to have each individual author retain copyright of his/her contributions. It's then up to each contributor to take action for any breach of copyright if and when they see fit. Obviously the act of posting to a forum gives the forum operator the right to make the content available to the public. 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: Poaching -- Discouragement thereof
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. If you calculate (P90 cpu years/week factoring)/(P90 cpu years/week LL testing) then I'll think you'll find PII/66 MHz FSB PPGA Celeron systems are the best trial factoring systems. 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: Communication between GIMPS Forum and Mersenne mailing list
On Saturday 25 January 2003 05:38, Michael Vang wrote: Well, to be honest, not much more can be done... As it is now, we have several mechanisms in place to enable people with dialup access the ability to log on and get done right quick... What about posting (a digest of) forum messages on the list, a la SourceForge? 1) There are no heavy graphics usage... (If I were paying for access I'd have graphics turned off anyways!) 2) Everything is GZIP compressed... 3) You can have email notifications of new posts... I was stuck on dialup for a week recently and was able to keep up with the forum with just 5 minutes of reading a day... And I don't read all that fast... And it was a 33.6 connection... I find the major problem is the awkwardness of going on offline when composing contributions, especially replies. Having been an Internet user for 20 years, I think store forward rather than instant messaging. That's my problem, not yours. 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: Poaching -- Discouragement thereof
On Saturday 25 January 2003 02:07, John R Pierce wrote: But, no, you won't be able to complete a 10M on a P100 ;-) my slowest machine still on primenet is a p150 that has 60 days to finish 14581247, its been working on it for about 300 days now, 24/7, with nearly zero downtime. 2.22 seconds per iteration, yikes. I probably should retire this box after it completes this one, its still running v16 :D Obviously if such a change were made one would expect a period of grace to accomodate assignments already started to complete. On Saturday 25 January 2003 00:42, Nathan Russell wrote: Does this apply to 10M assignments? I don't see why not. The machine I used until earlier this month, a P3-600, couldn't do those in much under 6 months, and some machines which were sold new around 2000 are unable to do them in a year. Yes. But given that there is plenty of work left which can usefully be run on systems a lot slower than P3-600, and that the fastest PC systems currently available can run a 10M digit range LL test in about 4 weeks, I'm not sure it is sensible to be running 10M digit assignments on P3-600s any more. On Saturday 25 January 2003 00:39, Mikus Grinbergs wrote: [... snip ...] What I am saying is that having an assignment expire after a year does not get at the root of the problem. Even if an assignee could perform the work in 15 days start-to-finish, a poacher with a Cray might decide to intervene anyway. But in my experience the majority of poaching is connected with running tests on the lowest outstanding exponents irrespective of the fact they're assigned to someone else. My suggestion is that in order to receive credit for their work, everybody MUST register what they are doing. Sure. But does this address the problem? And the registration process must refuse to give out duplicate assignments. I wasn't aware that it did. But what is the objection to having both LL test and double check for a particular exponent assigned simultaneously? If we're done looking for factors, we need the results of both runs eventually. BTW what about another problem I have come across on several occasions, namely reverse poaching? This is when I have properly got an assignment which someone else has let expire, but the original assignee reports a result whilst I'm working on it? 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: Poaching -- Discouragement thereof
On Friday 24 January 2003 02:27, Richard Woods wrote: Let's put it this way: Maybe you don't give a fig for fame, but some of the rest of us do. A chance at real, honest-to-gosh mathematical fame has a value not measurable in CPU years, but poaching steals that. So what we want is a declaration that in the event of a prime being found, kudos etc. goes to the official owner of the assignment, even if a poacher finishes first. The only problem here is that I could make it almost certain that I would get the kudos for a prime discovery by grabbing a _very_ large batch of assignments, checking them in regularly but not actually doing any work on any of them, until a poacher finds the prime for me ... but that's cheating, too. I think perhaps what may be needed is a new rule that users who don't complete assignments in a reasonable period of time (say 1 year?) should lose the right to the assignment, even if they do check in regularly. This should discourage poaching by removing the motive, and also improve the quality of the work submitted - random glitches do occur; with run times much over one year, I would think it fairly likely that a glitch would lose you the chance of a prime discovery even if you had the right assignment. (What a sickener that would be!) I might also point out that there is sufficient information in the other reports (particularly the hrf3 lucas_v database files) to enable the poachers to be identified, Better read my proposal again. Its intent was to _PREVENT_ (not perfectly, but to some extent) poaching, not identify it after-the-fact. Police forces can't _PREVENT_ crime, but they can discourage it. If you can identify the poachers, then you could ask them (politely or otherwise) to desist, or name shame them. BTW, exactly which data fields in either the HRF3.TXT or LUCAS_V.TXT file provide information about currently-assigned, in-progress, incomplete assignments (which are the poachable ones)? The hrf3 lucas_v database files identify those who have submitted results for each exponent (except when a factor has been found). So if you have had an assignment poached ... As you correctly point out, they don't contain direct pointers to poachable assignments - though, with a list of primes, a list of exponents in the factors database, a list of exponents in hrf3 a list of exponents in lucas_v, you can fairly easily derive a list of the lowest exponents which are short of a LL test or double-check - these are in all probability assigned therefore poachable. I asked this in the GIMPS forum, but haven't seen any answer there yet. So will you please point out what I overlooked? Sorry, I don't read the forum. It's inconvenient expensive for those of us that have pay-as-you-go dialup access; whilst I'm at work I simply don't have the time to mess with such things. There is no cable service within 40 miles of me, the nearest ADSL-enabled exchange is about the same distance away, satellite broadband is ferociously expensive still depends on a dial-up line for outbound data; the density of population round here is such that there's almost no chance of a wireless mesh working, either. 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: Top 1000 connection to server
On Wednesday 22 January 2003 07:57, Denis Cazor wrote: Hello, for my part, I looked for my place in the top 1000 list - on www.mersenne.org /top.html my place is 388 this week with 100 LL tests. - on mersenne.org/ips/topproduccers.shtml (updated hourly) I found to be at the 26444 place, credited with only one LL test. (difficult to find my place :-). What are the different strategies ? top.html is George's list, which includes manual submissions but does not include any results for exponents where factors have been found. topproducers.shtml is based on PrimeNet automatic notification for results relating to assignments issued by PrimeNet. Another problem is when I connect to the server. My computer is sending (at each connection) all the results I found in more than one year, instead of the last one. How can I reset the list after a connection ? This _sounds_ like you keep turning on Use PrimeNet in the Test/PrimeNet menu, then turn it off again. What I would suggest is: (1) rename results.txt to something else (results.old seems reasonable) (2) turn on Use PrimeNet (if it is off at the moment) leave it turned on (3) if you have a dial-up connection don't want automatic dial-out whenever the client wants to talk to the server, set Do not contact PrimeNet server automatically in Advanced/Manual Communication. Set Contact now to manually connect, send whatever results are available collect more assignments if neccessary. 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: Poaching -- Discouragement thereof
On Wednesday 22 January 2003 22:50, Richard Woods wrote: Here's what I've just posted in the GIMPS Forum. - - - _IF_ PrimeNet has automatic time limits on assignments, ordinarily requiring no manual intervention to expire assignments or re-assign them, then why would any GIMPS participant, other than a system administrator or a would-be poacher, need to know someone else's: (a) current iteration, (b) days-to-go, (c) days-to-expire, or (d) last date-updated? If there's no non-poaching non-administrating user's need-to-know for those items, then just stop including them in public reports. Include them only in administrative reports and private password-requiring individual reports. That would deny target-selecting information to would-be poachers, right? Sure. So would eliminating the report altogether. I detect righteous indignation here. Might I respectfully point out that, if you stick to LL test assignments, it makes practically no difference whether you get poached, since there will eventually have to be a double-check anyway. I might also point out that there is sufficient information in the other reports (particularly the hrf3 lucas_v database files) to enable the poachers to be identified, 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: Has something gone wrong with the mersenne.org server? (yes, again)
On Saturday 07 December 2002 23:45, Barry Stokes wrote: Tried to get to my individual account report again, and this time was greeted with this: Insufficient system resources exist to complete the requested service. Anyone else getting the same? Yes. Around 0700 GMT yesterday (7th) I found I couldn't check in results, then when I tried to check my personal account I was getting a Couldn't load DLL problem. Later in the day this changed into Insufficent resources. The general status reports still work but seem to be frozen at 0500 GMT yesterday. My guess would be that some clown has successfully executed a DoS attack but an underlying problem, like a memory leak or disk space exhaustion, could possibly lead to similar problems. Guess we have to live with it until Brad gets in to work tomorrow. Regards Brian Beesley Jacquin's Postulate on Democratic Government: No man's life, liberty, or property are safe while the legislature is in session. Or afterwards, if they legislate a mechanism for enforcement. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: P-1 and non k-smooth factors
On Wednesday 04 December 2002 21:46, Daran wrote: [... snip ...] ...though I think there needs to be a careful analysis as to what the extra computation time for actual E values might be... I agree. My tests have been limited to exponents in the 8.1M range, for no particular reason than those are the ones I am doing. Well, you seem to have more experimental evidence than anyone else. As for the theory - whilst there is adequate theoretical modelling of the expected distributions of the largest and second-largest factors of arbitary numbers, I couldn't find much in the literature which would help predict how many extra factors you would expect to find with different values of E. There is obviously a tradeoff here between increasing B2 and simplifying E and increasing E compensating for increased run time by lowering B2. However it does seem to be obvious that increasing E always has to be paid for in increased memory requirements. For exponents around 8M, this is not a particular issue. However there is a real, practical constraint so far as Prime95/mprime is concerned - the entire _virtual_ address space is limited to 4 GBytes by the 32 bit address bus, and the OS kernel claims some (usually half) of this, so that the total memory usable by a single process is limited to 2 GBytes. (There is a big memory variant of the linux kernel which expands this to 3 GBytes, but the point still stands). Since, on my practical experience, a 17M exponent will quite happily use ~ 800 MBytes in P-1 stage 2, the 32 bit address bus may well be a limiting factor within the exponent range covered by current versions of Prime95/mprime. George - is there a sanity check on the memory constraints? If we _don't_ have to worry about memory, at some point it becomes cost-effective to run ECM with small limits instead of P-1 with much larger limits. And ECM can easily dig out some factors which are more or less inaccessible with P-1. I was under the impression the ECM was only practical for small exponents well below the current DC range. ECM stage 2 quickly becomes impractical with larger exponents because of the memory requirement. ECM stage 1 is not particularly heavy on memory. Running stage 1 only with small limits on DC sized exponents is feasible ... it's just a question of whether the extra computation costs would be justified by the discovery of factors which were inaccessible to trial factoring or P-1. [... snip ... I don't disagree but the basic argument is the same as above] In 2 out of the 29 stage 2 factors I have found so far using E=4, k has not been smooth to B2. This suggests that increasing E from 4 to 12 could yield about 20% more factors. I've done a few tests with a modified and recompiled client, which suggests that it would worth it even if E=12 yielded as few as 10% more factors, though I need to investigate this further. That's a very small sample. It's the only sample I have. I'm trying to increase it by doing some P-1s on exponents in the 1.2M range which have only been tested to B1=B2=1000. How many of these were found during stage 2? (If half your factors were found during P-1 stage 2, and half of those used E=4 or greater, then your single 'surprising' factor would not be out of line with my two.) Well, actually I was doing the test in several steps, with gradually increasing B1 then gradually increasing B2 - the cost of the GCDs with small exponents is very small so it's worth checking fairly frequently to see if a factor is available. I don't have the full data to hand but I do have some of it. The distribution of 22 factors found at various limits was as follows: stage 1 B1 = 50 1 stage 1 B1 = 100 1 stage 2 B1 = 100 B2 = 4004 stage 2 B1 = 100 B2 = 1000 5 stage 2 B1 = 100 B2 = 2500 11 Some easier factors were in all probability missed because someone had found them by running P-1 with smaller limits before I started. I have a total of 57 factors, including one found earlier today. A few were by TFs, 30 in P-1 stage 2 (including today's) and the rest in stage 1. OK. Actually for about the last three weeks I've been running P-1 with standard limits on some exponents in the range 2M-6M (those exponents where all the entries in lucas_v have the same user ID, with the exception of a very few where P-1 was already completed to reasonable limits). The system I'm using is configured with mem=224 MBytes (about as much as I dare on a 512 MBytes dual-processor system). I'm getting E=4 logged fairly consistently. The results so far are: No factor found, 130 Factor found in stage 1, 2 Factor found in stage 2, 6 - all smooth to B limits used. One of the factors found in stage 1 is _very_ interesting: 6807510023694431 is a factor of M(5993719) (smooth to B1=353) The factoring depth database had this trial factored
Re: Mersenne: P-1 and non k-smooth factors
On Tuesday 03 December 2002 22:31, Daran wrote: [... snip ...] For clarity, let's write mD as x, so that for a Suyama power E, the exponent (x^E - d^E) is thrown into the mix when either x-d or x+d is prime in [B1...B2], (and only once if both are prime). This works because (provide E is even) x^E - d^E = (x-d)*(x+d)*C where C is a sum of higher order terms. The benefit of prime-pairing arises when E=2. The cost of higher E is AFAICS linear in multiplications. The benefit of higher E comes from any additional factors thrown into the mix by C. This benefit is greatest if C has factors slightly B2 For E=4, C = (x^2 + d^2) For E=6, C = (x^4 + x^2d^2 + d^4) = (x^2 + xd + d^2)*(x^2 - xd + d^2) For E=8, C = (x^2 + d^2)*(x^4 + d^4) I can't think of any reason why either of the two algebraic factors of C when E is 6 should be any better or worse than the single irreducible factor when E=4. And there are two of them. This suggests to me that E=6 should be about twice as effective as E=4 in providing additional factors, at about twice the cost (over and above the 'cost' of E=2). If this is correct, then it will always be worth going to E=6, whenever it is worth going to E=4, (provided there is sufficient memory to do so). Let's see if I get this right. Overwhelmingly, the factors produced by P-1 factoring come out because they are smooth to the limits selected. The fraction that comes out because of the extension is 10%. To double that fraction (i.e. to increase the total number of factors found by 10%) we have to double the stage 2 run time? Doesn't sound that great to me, even without worrying about memory considerations. If we're talking about the _extra_ computation time in stage 2 then obviously the suggestion makes a lot more sense - though I think there needs to be a careful analysis as to what the extra computation time for actual E values might be (as opposed to a rather simplistic linear model, which fails to take into account that some of the temporaries needed for small E probably drop out pretty well for free). If we _don't_ have to worry about memory, at some point it becomes cost-effective to run ECM with small limits instead of P-1 with much larger limits. And ECM can easily dig out some factors which are more or less inaccessible with P-1. [... snip ... I don't disagree but the basic argument is the same as above] In 2 out of the 29 stage 2 factors I have found so far using E=4, k has not been smooth to B2. This suggests that increasing E from 4 to 12 could yield about 20% more factors. I've done a few tests with a modified and recompiled client, which suggests that it would worth it even if E=12 yielded as few as 10% more factors, though I need to investigate this further. That's a very small sample. Some time ago I found a considerable number of first factors for exponents in the range 100,000-150,000 using P-1 with limits up to B1=10^6, B2=25x10^6. The results.txt file doesn't record the E value used; though I did have tons of memory available (in relation to the exponent size) and seem to remember something about wondering what E=12 meant in the console output. Or maybe I'm confusing this with recollections about running ECM? My records show 67 factors found; I mailed George on one occasion because P-1 found a factor which surprised me, but I don't think it happened twice. Incidentally I found a factor only yesterday using P-1 on a production system: [Tue Dec 3 07:54:38 2002] P-1 found a factor in stage #2, B1=22, B2=5665000. UID: beejaybee/Procyon, M17359099 has a factor: 312980494172935109497751 Again no mention of E. If it helps, this system was set up to use 384 MBytes memory. In any case this should have come out without extensions; B1=65267 B2=3077953 is sufficient to find the factor with the standard stage 2 algorithm. Would there be any means of retrieving actual factors found using P-1 and the E values used from the server logs? The problem otherwise is that, so far as the database is concerned, once a factor is found, nobody cares much how! 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: Re: christmas computer system?
On Monday 25 November 2002 12:36, you wrote: One should basically not use a CD-R/CD-RW as a general CD reader, since it usually has way lower MTBF than a normal CD/DVD reader, and is more expensive. Ie. it breaks a lot earlier if you use it a lot, and it's more expensive to replace :-) Did you check out the manufacturer's claimed MTBF? A sample I checked out showed no significant difference between CD, CD-R CD-RW drives. I've _never_ had any problems with CD-RW drives on linux systems, except for an old model which refuses to write some high-speed CD-R media above 2x, though it appears to write medium-speed media at its limit of 4x quite happily. On Windows systems, woe despondency. Basically I gave up Roxio as a total disaster. Nero is better, but every so often after writing a CD it refuses to read anything in the same drive until system reboot. Never had any genuine hardware problems, though. Playing a lens cleaning CD occasionally does no harm. Most PCs tend to suck air and dust in through gaps in the front panel, this can cause a buildup of crud on the RW head. 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: christmas computer system?
On Sunday 24 November 2002 15:55, you wrote: (B I'm giving my brother's family a new computer for christmas. (B He'll buy it from a local (to him) 'white box' pc store and I'll (B pay for it. I am a little concerned about performance because (B the pc will probably be running GIMPS and I'd like to get my (B money's worth. It's easy to request a P4 in the 2.0-2.5 range (B and 256M-512M of memory but I've read of the bottleneck caused (B by slow memory and the bus between memory and cpu and I don't (B know what to specify or how to evaluate components in this area (B or measure performance after the pc is built. (B (B Any comments or suggestions? (B (BWell - one of the key things with P4 systems is that the processor needs to (Bbe properly cooled. If it isn't, the reliability will probably be OK, but the (Bperformance will suffer as the processor goes into thermal throttle mode. (B (BUnfortunately many "fashion" systems come in unreasonably small cases with (Bgrossly inadequate ventilation, and an underspecified heat sink. Most users (Bnever notice that the system is throttled, because even at quarter speed, a 2 (BGHz P4 is more than powerful enough for everyday tasks like word processing, (Beven using M$'s mega-bloated packages. Also, shifting sufficient air to cool (Ba P4 (or a high-end Athlon) properly means either a large, heavy and (Bexpensive heat sink, or a noisy fan. (B (BBasically my advice would be to go for build quality rather than raw (Bperformance. If the thing is properly built, you will at least be able to do (Bsomething about any deficiencies. (B (BI would reject out of hand any package containing peripherals which are (Bdesigned to work only with Windows, or which has Windows pre-installed with (Bonly a "system recovery" CD rather than proper installation media. I'd far (Bprefer to take a system without Windows bundled at all, but M$ tries to make (Blife miserable for system builders who try to avoid the "Microsoft tax". (B (B I want them to have a fast machine but not on the bleeding (B (expensive) edge. (B (BThe problem here is that most "big name" systems builders keep changing the (Bimportant components (motherboard, graphics card etc) to suit their profit (Bmargins and stock availability. You will find apparently identical systems, (Bwith the same "top line" specification, are quite different inside and may (Bhave very different performance. (B (BSo ... look for something that at least tells you what the mainboard chipset (Bis. This will give you a good indication of the performance _potential_ and (Bupgradeability of the system. (B (BPersonally - although this is distinctly unfashionable - I far prefer Rambus (Bmemory - so far as GIMPS is concerned, a 2.53 GHz P4 using PC1066 Rambus (Bmemory (implying the i850E chipset) will outperform _any_ system up to 2.8 (BGHz using DDR memory. The point here is that the total memory bandwidth of (Bthe Rambus system is 4200 Mbytes/sec, whereas even using 400 MHz DDR memory (B(just as rare expensive as PC1066 Rambus memory) you are only going to get (B3200 MBytes/sec. (B (BIf you're forced to a DDR based system, then look for the Intel 845PE (Bchipset. (This also supports the new P4 processors up to at least 3.06 GHz (Bwith hyperthreading support enabled). With chipsets using DDR, there is (Bpotential for inefficiency by using slow memory - e.g. KT400 chipset should (Balways be used with 400 MHz memory (PC3200), KT333 with 333 MHz memory (B(PC2700) etc. This is because the "gearchange" caused by using slower memory (Bthan the chipset supports kills performance. Installing faster memory than (Bthe chipset supports is OK (except that Rambus systems supporting only PC800 (BRDRAM do _not_ work with PC1066 memory) but not often done for reasons of (Bcost. (B (BThe problem here is that few "big name" manufacturers will tell you the (Bspecification of the components have gone into a system, and even fewer sales (Bassistants in the retail stores where they're sold will understand (Bintelligent questioning. (They _may_ understand raw MHz, disk capacity, (Bmonitor size etc., but that's about the limit of what you should expect.) (B (BIf you really want performance, and are prepared to cut back on things you (Bdon't need (superfluous peripherals, bundled software etc), then it is (Bpractically essential to "roll your own", or (at a premium) go to a small, (Bspecialist systems builder armed with a specification. Building the thing (Byourself is satisfying, too. (B (B Other than GIMPS I'm sure my nephew will be the heaviest load (B when he plays games on the new machine. (B (BSo you want a darned good graphics card ... a weak graphics card will kill (Bgames performance much more than a poor mainboard/processor/memory (Bcombination. Many games players also insist on a good sound system. (B (B I think I should also request the
Re: Mersenne: christmas computer system?
On Sunday 24 November 2002 18:47, John R Pierce wrote: my shopping list for a reasonably priced high quality P4 right now is, with prices from my local cloneshop (not the cheapest place, but good service)... $213 Intel Retail P4-2.4B (these have the 533MHz bus) 2.53B should be very little more expensive. Last time I checked the first big price step was still between 2.5A/2.53B and 2.6A/2.66B. The other point here is that P4s don't seem to benefit much (if at all) from 533MHz FSB except with 533 MHz RDRAM. Even at 400 MHz, DDR throttles the CPU/memory bus to the point where the CPU/chipset clock rate is unimportant. Consider spending a bit more on a Zalman Flower Cu/Al S478 heatsink variable speed fan. Even with the fan turned down to minimum, at which speed it is truly inaudible, it's at least as effective as the retail box HSF. $133 Asus P4PE/L (i845pe chip, integrated ethernet and audio) $158 Samsung 512MB PC2700 DDR SDRAM $163 Asus V8420 GF4 Ti 4200, 128MB Personally I _love_ the Matrox G400/G450/G550 video card. Cheaper, unsurpassed 2D display, drivers superbly stable. But then I'm not a games freak. $113 Seagate Baracuda ATA IV 80GB disk (super quiet, very fast) $48 Toshiba 16X DVD-ROM I could easily do without the DVD drive. $83 Teac CDW540E 40/12/48 cd-rw burner Seems a bit expensive. There's little point in going for superfast write/rewrite performance; either you can't get media much faster than 24xW / 8xRW, or you can't justify the price premium. $8 Mitsumi floppy If I can boot from a CD, I don't need a floppy drive any more. Spend the money on a couple of round IDE cables instead. (Neater, less air flow obstruction) $78 Enlight mid-tower IMHO money spent on the case is money well spent. On my previous experience with Enlight cases, if you buy one you should also buy a box of sticking plasters. I always seemed to end up with shredded fingers whenever I worked inside them. There are cheaper, nastier cases with even sharper edges, but I don't reccomend them, either. These days I use Coolermaster ATC200 (comes fitted with 4 quiet 8 cm fans) and Enermax 350W PSU (dual fan; thermally controlled inlet, manual variable speed exhaust). I don't know the current US price but the case PSU come to around £180 retail here (so probably $180ish?). For that you get an all-metal case with superb build quality, excellent cooling with barely audible fan roar and really smart styling. It's a normal-size mini-tower case but will accomodate _at least_ 6 3.5 drives without touching the 3 5.25 bays. A good case will survive a few PC generations. $23 Microsoft Intellimouse Optical OEM $9 Mitsumi generic 104 keyboard I _hate_ membrane keyboards would not pay even 9 cents for any of them... If you can, get a genuine late -1980s IBM PS/2 keyboard from a scrapyard / car boot sale rather than buy a new one. It will be more reliable as well as much more comfortable to use. I think Cherry still make a proper mechanical switch keyboard with a decent action, but it's _very_ expensive (well over £50). Regards Brian Beesley _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: SV: SV: Mersenne: Drifting UP(!) in Top Producers ranking?
On Saturday 23 November 2002 02:41, Torben Schlüntz wrote: [... snip ...] Sorry Nathan. It is my fault you read the IMHO paragraph in a wrong way. I meant I had that point of view UNTIL I discussed it.. As George argue: Nobody would do LL if a succesful TF was rewarded the same - he is truly right. From the point of view of the project, the objective is to find Mersenne primes. Finding factors, like completing LL tests returning a non-zero residual, only eliminates candidates. However, from the point of view of league tables, it seems to make sense to award effort expended (in good faith); otherwise there would be only two raks in the table: those who have found a prime, and those who haven't! My goal is to get the succesful TF rewarded a bit higher. As it is now someone might skip the 57-65 range and only do the 66-bit part, thus missing factors and get fully rewarded for only doing half the work. This is not a particularly effective cheat; you still end up having to do significantly more than half of the computational work. Is there any evidence that this may be happening? Does it make sense to impose a penalty clause i.e. if someone subsequently finds a factor in a range you claim to have sieved, you lose 10 times the credit you got for the assignment? N.B. There will be _occasional_ instances where an honest user misses a factor, possibly due to a program bug, possibly due to a hardware glitch. [... snip ...] Composite exponents was removed long before the project. Lucas must have known the exponent needed to be prime. I believe a Mersenne number has to have an exponent which is a positive integer?! The exponents above 79.300.000 are still candidates, though George has chosen to limit his program to this size and I think with very good reason. Hmm. As it happens, one of my systems has just completed a double-check on exponent 67108763. This took just over a year on an Athlon XP1700 (well, actually it was started on a T'bird 1200). The fastest P4 system available today could have completed the run in ~3 months. The point is that running LL tests on exponents up to ~80 million is easily within the range of current hardware. Personally I feel it is not sensible to expend much effort on extremely large exponents whilst there is so much work remaining to do on smaller ones. I justify running the DC on 67108763 as part of the QA effort. BTW, the list of found factors contains 2.500.000+ but the top producers list only contains 30.000- of these. GIMPS must be responsible for far more than only 30.000 factors. Any explanation for that? Well, there are a lot of factors which can be found by algebraic methods rather than by direct computation: e.g. if p+1 is evenly divisible by 4, and p and 2p+1 are both prime, then 2^p-1 is divisible by 2p+1. Also, there are more efficient methods of finding _small_ factors (up to ~2^48) than individually sieving for each exponent. 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: Poach?
On Tuesday 19 November 2002 16:21, George Woltman wrote: At 01:30 PM 11/19/2002 +0100, [EMAIL PROTECTED] wrote: 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 The berra test had errors and the exponent was re-released for first-time testing. I did this by manually setting the exponent's state. My guess is the database sync caused the server to once again notice it has a result for the exponent and now flags it as a double-check. Surely this really doesn't matter. If the first test had errors, there is still a reasonable chance of discovering a prime - at any rate, as good as running a LL test on a 17M range exponent. Also, PrimeNet will still credit you; there is no distinction between credit for a first LL test and credit for a double-check. 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: CPU type wrong on account report
On Friday 15 November 2002 00:23, Ryan Malayter wrote: Does anyone else have their P4 and newer Xeon machines show up as Unspecified Type on the Individual Account Report page? Is this a common issue, or do I have something flaky in my local.ini? Yes, there's something odd - I have two P4s contributing to PrimeNet. One shows up as a PIII, the other as unspecified. Another unspecified system I have is actually a Sun Sparc running Glucas, using PrimeNet's manual testing pages. I've no idea at all as to where the speed 1401 which shows up in my personal account report against this system came from. 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: Request for help (especially ECM)
One more, this one is a much larger exponent. The factor 17304916353938823097 of M111409 is found with sigma=8866098559252914, in stage 2 with B1 = 4861 B2 = 343351. I didn't bother finding the critical limit for finding the factor in stage 1 as it would have taken a considerable amount of computation time. 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: Update on my stability issues
On Monday 11 November 2002 22:28, Gareth Randall [EMAIL PROTECTED] wrote: The front air intake vents on almost every PC case I have ever seen have been virtually *useless*. For some reason manufacturers continue to drill a few pathetically small holes in the steel sheet and call that an air duct. People then put case fans against these and try to suck against what is 90% metal sheet and wonder why not much happens. Hmm. I know exactly what you mean, but they're not _all_ like that. Look at e.g. the Coolermaster range. What you should do is to take a saw or a drill and cut the whole circular section out! You may end up with sharp edges, and you need to take precautions against metal shavings. You may also need to drill some neat holes (e.g. 10mm diameter) in the plastic front bezel in order to provide an unimpeded air path. Do the job _before_ you install components (or remove everything before commencing surgery). File down the inevitable sharp edges, finishing with fine emery cloth, or wet-and-dry paper. Thoroughly remove swarf right down to metal powder - personally I think it's best to wash out with a high-pressure hose, then allow to dry. At least think about installing a grille to protect fingers the inevitable stray bits of cable from rotating fan blades. It also helps - long term - to place a piece of open-cell foam, or a layer of filter material intended for use in a vacuum cleaner, in the inlet(s). The idea is that much of the dust drawn in will stick in this - where it can be got at easily - rather than end up getting stuck in heat sink fins etc. where it will have a serious effect. Suitable material can be cut with scissors held in place by a grille. Nevertheless, when the procedure is done you should be able to hold a match in front of a machine with nothing other than the PSU fan and see the flame visibly sucked into the case. If your airflow can't do that, then any internal fans you deploy are going to be pulling on a vacuum (or rather, reduced pressure). If it can do that, then you are in a *much* better position to keep your number cruncher cool and reliable! Some other points here: (1) fans working in a badly restricted air flow are probably going to be noisier than they should be, as they will be running with stalled airflow over the blades, causing excessive turbulence. When the airflow is reasonably free, the air flow over the blades will be much less turbulent. (2) It seems to make sense that the fans in the case (including those in the PSU) should be arranged so that roughly equal volumes are blown in and sucked out. Otherwise one or other of the fans will very likely be running with stalled fan blades. Also, obviously, it helps if the path between inlet and outlet passes things you want to cool down - there's not much point in having inlet air blown straight back out before it has a chance to warm up. (3) Other things being equal, large fans are quieter than small ones with the same air flow, since the rotation speed is lower and there tends to be less turbulence. Two low-output fans are preferable to one high-output fan for the same reason. 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: Request for help (especially ECM)
On Saturday 09 November 2002 04:45, you wrote: A harder problem is finding some smooth ECM curves to test. I do not have tools to compute group orders. Nor do I. If someone can help by finding a couple of dozen smooth ECM test cases for exponents between 1000 and 50, I would be most grateful. If you take some examples of known factors around 2^64 in size (say 19 or 20 digits), you would _expect_ to be able to find some of these factors by running a few score random ECM curves with B1=100,000 automatic B2. With luck some might even drop out in stage 1. These should yield your test cases - obviously what you need is a specific sigma which should yield a factor with given limits, and a specific sigma which shouldn't - and the second is all to easy to find! Once we have some examples, a bit of experimenting with limits should furnish the critical limits for these particular examples. I believe that calculating the group order is rather time-consuming, even with the appropriate tools, so with reasonably small factors this experimental approach might not be too wasteful. I wouldn't worry too much about covering the whole range of exponent sizes, or B limits - though those of us who have been running ECM can furnish working sigma values for specific factors we have found with large limits. The point with exponent sizes is that the code for the various FFT run lengths should already be tested through the short LL residual data set. The problems that we want to test out are those specific to the ECM stage 1 stage 2 algorithms (and the GCD, though that should be covered with P-1). We should also be finding working examples for ECM on 2^n+1. Does this sound reasonable? If so I could pick a few suitable factors start trying to find sigma B limits for test curves using ECM in v22.12. 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: Request for help (especially ECM)
On Sunday 10 November 2002 20:03, [EMAIL PROTECTED] wrote: Brian J. Beesley [EMAIL PROTECTED] wrote - Here's one example: - - With sigma=1459848859275459, Prime95 v22.12 finds the factor - 777288435261989969 of M1123: - - in stage 1 with B1 = 535489 - in stage 2 with B1 = 38917 B2 = 534241 And here are some more With sigma=7324432520873427, the factor 649412561933038085071 of M1621 is found - in stage 1 with B1 = 2546119 - in stage 2 with B1 = 94727, B2 = 2543311 With sigma=5643809308022499, the factor 838124596866091911697 of M1787 is found - in stage 1 with B1 = 378041 - in stage 2 with B1 = 35543, B2 = 378001 With sigma=6305161669623833, the factor 597702354293770769 of M1867 is found - in stage 1 with B1 = 258983 - in stage 2 with B1 = 3061, B2 = 258301 With sigma=5956836392428930, the factor 8142767081771726171 of P721 is found - in stage 1 with B1 = 54779 - in stage 2 with B1 = 33487, B2 = 54390 How does one map sigma to a curve (and initial point)? What is the range of sigma (it seems to go beyond 2^32)? At worst, RTFS. My reason for finding the critical B values was in the hope that someone with a better understanding of the algorithms and/or an independent ECM factoring program would be able to confirm that these values make sense. The ECM tests should include a case where two primes are found at the same time during step 2, because the largest primes dividing the two group orders are equal. [That is, the GCD will be composite.] This test may be hard to construct, however. Actually, it's very easy. The way I constructed the results submitted so far was to remove the known target factor from the low[mp].txt file run a few curves with B1=10^5, B2 automatic to find a sigma that works. Not neccessarily the sigma that gives the lowest limits. After receiving this message, I removed _all_ the known factors for P721. This was interesting, and indicates a bug, though it appears to be not very important: with same sigma minimum B1 B2 noted above, the composite factor 129 (= 3 * 43) was found. I would have expected (at least) 3*43*8142767081771726171 Placing the known factors 3 43 back into lowp.txt and repeating the same curve yielded the expected factor 8142767081771726171. Either the ECM tests or the p-1 tests should include a case where the group order (or p-1) is divisible by a power of a moderate prime, such as 61^3 or 757^2 . There are lots of known examples for P-1. 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: Bug in version 22.10
On Tuesday 05 November 2002 21:40, George Woltman wrote:
I'd actually recommend not doing the P-1 again. If you are using enough
memory to run both P-1 stages, then the bug did not affect stage 1 but did
affect stage 2.
If you run only stage 1 of P-1, then the bug would cause no factors to be
found.
In this case, you might consider re-running P-1 again as Brian suggests
(but only if you used 22.10 dated after Sept 28).
I did this on my own system have been rewarded with _two_ factors
found -
This is way above expectations! Nevertheless, I'm always happy to get the
factors.
Sure, I was surprised too. Anyway this is what I got:
{system 1}
[Wed Oct 30 21:00:54 2002]
UID: beejaybee/slug1, M8589491 completed P-1, B1=4, B2=42, WY2:
DE3C48D7
...
[Tue Nov 5 10:15:49 2002]
P-1 found a factor in stage #1, B1=4.
UID: beejaybee/slug1, M8589491 has a factor: 42333443925749970809
{system 2}
[Thu Oct 31 23:12:50 2002]
UID: beejaybee/caterpillar, M8564431 completed P-1, B1=45000, B2=618750, WY2:
DDB16BFB
[...]
[Tue Nov 5 12:44:02 2002]
P-1 found a factor in stage #2, B1=45000, B2=618750.
UID: beejaybee/caterpillar, M8564431 has a factor: 9592239270614293063
There's no particular reason to suspect that a glitch on either system caused
a factor to be missed on the first run. I did have a couple of problems with
cabbage in the summer which turned out to be due to a UPS overload, but
that's fixed now.
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: Bug in version 22.10
Hi, One thing you might consider - when you change to v22.11, check out your results file. If you have a P-1 run logged on an exponent you haven't yet started LL/DC testing, make it run the P-1 again (change the ,1 at the end of the assignment line in worktodo.ini to ,0). If you are already running the LL or DC test, things are not quite as straightforward; I'd reccomend: For DC tests, if less than half done, force P-1 to rerun (as above) else just let it run on. For LL tests, if less than 1/3 done, force P-1 to rerun (as above). If between 1/3 and 2/3 done, change the test type from Test to DoubleCheck then force P-1 to rerun. (This makes the P-1 limits smaller - with a lower chance of finding a factor, but using less time). If more than 2/3 done, just let it run on. I did this on my own system have been rewarded with _two_ factors found - one on an unstarted DC assignment, one on a DC assignment which was about 40% of the way through - there are still a few repeat P-1s running, too. Regards Brian Beesley ... On Tuesday 05 November 2002 05:19, George Woltman wrote: Hi all, Sigh If you downloaded a version 22.10 dated September 28 or later, then please upgrade to version 22.11 at http://www.mersenne.org/freesoft.htm The bug causes factors to be missed in the final stage of P-1 and ECM factoring. While this isn't the end of the world, it will cause you to run an unnecessary LL test. Sorry for the trouble, George _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Modularising Prime95/mprime - a path to broader development.
On Wednesday 30 October 2002 23:08, Gareth Randall wrote: Could you please expand upon how this secure certificate concept would work, for the benefit of myself and the list? Unless there is more to it than I currently comprehend, this only authenticates results as coming from specific users, rather than authenticating that the result is correct and genuine. Your analysis is correct. For instance, how can a new user who has had no previous contact with GIMPS prove that they have completed a Lucas-Lehmer test correctly? If we were able to do this with 100% certainty, then we would not need to run double-checks! Don't forget that a small fraction of the results submitted in perfect good faith by people who are making no attempt whatsoever to cheat will be incorrect by reason of a hardware or software glitch. In the final analysis, the best deterrent to anyone who is deliberately submitting concocted results is the knowledge that they will (eventually) be caught out through the double-checking mechanism. One way of tightening the procedure would be for interim residues to be logged as well as the final residue. As I've stated in the past, this would also enable a saving in effort by allowing investigation when a double-check run disagrees rather than having to continue the run through to the end. 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: Torture test allocating hundreds of MB?
On Wednesday 30 October 2002 02:34, Nathan Russell wrote: Thanks to everyone who responded. In this case, it's a bug in my thinking. I had the memory usage set to the max allowable, because I wanted P-1 to succeed whenever possible, even if it inconvenienced me - I do most of my academic work via VNC into timeshares, so it isn't a big deal if the system thrashes. Is that the Wrong Thing (tm) to do in terms of improving Prime95's efficiency? No, in principle its the Right Thing (tm). In practise you want to set the memory parameters big enough that that all available memory is in use, but just small enough that swap thrashing doesn't occur. Because swap thrashing is _so_ limiting to memory access speed, it's best to be on the cautious side - especially since you may occasionally want to do some real work on the system. My current practise is as follows: On systems with 128 MB memory, or less, set max memory to half the memory size. (Obviously this is not sane on systems with very small memory ...) On systems with more than 128 MB memory, set max memory to memory size less 80 MB. Except for one system with 512 MB which regularly processes very large files, so I limit mprime to 128 MB to avoid any possibility of the system having to sort files hundreds of megabytes in size in only ~ 40 MBytes real memory. Remember the OS kernel consumes memory too! From the point of view of torture testing a system, again the sane thing is to test as much memory as possible. Causing swap thrashing by setting the memory allocation set a bit too high may be a good way of testing the disk I/O subsystem; however the fact that the processor will be idle waiting for data for a lot of the time may (depending on the CPU, power economy settings in the BIOS etc) allow the CPU to run cooler than it normally would. So, if you're testing out CPU cooling rather than memory problems, setting memory allocation very small (i.e. 8 MB) for the duration of the torture test is probably wise. If you really suspect you have a memory subsystem problem, ideally it's best to use a specialist program like memtest86 which runs without an operating system. You simply can't guarantee to test all memory properly with any program running on a multitasking operating system (unless the basic capability is built into the kernel itself!) 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: Modularising Prime95/mprime - a path to broader development.
On Tuesday 29 October 2002 17:28, Gareth Randall wrote: I'd like to suggest that prime95/mprime be modularised, and that only the core calculation component be kept closed source. Umm - actually the core calculation component is open source (but subject to restrictive licence). See source.zip. I realise that the code for generating verification codes must remain restricted, No - there is an alternative, which is for results submitted to be accompanied by a secure certificate generated by the server. because that is the only authentication that work has really been done and done correctly. There are a couple of points here: (1) the verification code may be crackable; (2) there may be ways of persuading the program to submit results without actually executing all the iterations required. If every user had a (free) secure certificate, all results submitted would be traceable to the individual user. This scheme would also make it possible for other clients to use the automatic server interface, instead of having to rely on the manual forms ( not getting PrimeNet credit for work completed). However, I do not see any reason why any of the building blocks other than the core calculation component actually need to be restricted. I also see many benefits of them being made open to contribution. Sure... and this will become increasingly important if (when!) the mass PC market starts to diversify from the current universal IA32 architecture. [non-contentious material snipped] The computation module would be simplified, I doubt it! The key benefits are: 1. Removal of many bottlenecks caused by the understandibly limited time of core developers. 2. Substantially easier bug-fixing. (What's error 2250 again? Quick search of the source for the server comms module. Oh yes, that means...) 3. Vastly increased potential for user participation and development. 4. (Important) Ease of implementation on other platforms. Only the core computation stuff really needs to be optimized to all hell. The server comms general control stuff would probably be more than efficient enough if it was implemented in perl, java or something else inefficient but portable. 5. (Important, for those who like eye candy) Ability to add customized skins. Prime95/mprime could be regenerated as a collection of programs, such as: On Windows: One executable and multiple DLLs or: Multiple executables, and one calculation component in Win32 command-line mode. The benefit here is a (small) saving in memory by not having to load unused code. Multiple DLLs are probably the best way to achieve this saving. The downside of this approach, from the developer's point of view, is that you get shafted if/when M$ change an API without telling you. On UNIX: Separate binaries and scripts. One script to start the collection running. Better still: build a version with what you want compiled in / loaded as modules at run time / omitted (like the linux kernel - though obviously much simpler!), monolithic or as a suite of smaller simple programs, depending on your personal taste. Wouldn't it be great if from some point in the near future, feature request posts to this newsgroup became more like I've written a fancy improved frontend to GIMPS with some cool graphics, see this link for more info, Actually that happened Sunday! Further, the ability for users to run their own personalised frontends might give GIMPS the tangible advantage over other distributed projects that many readers would so like to find. Agreed. 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 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: Dissed again
On Tuesday 22 October 2002 16:31, you wrote: Yeah, well, we don't have a super cool Trojan horse program that can update itself (and crash machines) like these other ones, and we're not out there looking for ET or saving cancer boy or anything... just a bunch of geeks looking for big numbers. :) (tongue planted firmly in cheek here). And we tend to run in the background, all the time, instead of wasting cycles waiting for a screen saver to kick in, then wasting even more cycles drawing pretty graphics :-P Probably we would get more participants if we had a screen saver version. This has been mentioned many times before. And, _are_ we just looking for big numbers? There are software applications for improved algorithms implementations of algorithms developed for this project; there are engineering spinoffs - a couple of years ago, the problem was how to keep GHz+ CPUs cool enough to be reliable, now the problem is how to make systems quiet enough to live with as well; there are cryptological spinoffs, not withstanding the obvious point that knowledge of a few very large primes is not in itself useful ... for instance, has anyone considered using the sequence of residuals from a L-L test as a practical one-time pad? The problem with one-time pads is distributing the data - but you can effectively transmit a long sequence of residuals by specifying only the exponent and the start iteration, which can be transmitted securely using only a tiny fraction of your old one-time pad data ... OK, this is pretty geekish stuff, but so what? 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 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: Composite factors.
On Tuesday 24 September 2002 06:05, Daran wrote: P-1, like any other GCD-based factorisation method, will yield a composite result in the event that there are two (or more) prime factors within its search space. It seems unlikely that this would happen in practice because unless both were ~ 64 bits, one of them would most likely have been found earlier during TF. However given that some factors found have been 130 bits, TTBOMK only using ECM - and those events are rare enough to be newsworthy. I don't think P-1 has found a proper factor exceeding 110 bits, yet. then the possibility is there. I was wondering if returned factors are checked for primality. I've found a few composite factors whilst running P-1 on small exponents. They've all factorised _very_ easily (well within one minute) using standard tools. Basically I'm interested enough to do this myself whenever what appears to be an abnormally large factor is found, but it wouldn't be hard to automate. Also very large factors are found at a low enough rate that there's simply no need to distribute the checking. 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: TF - an easy way to cheat
On Friday 20 September 2002 22:42, Torben Schlüntz wrote: Anyone receiving a TF task could edit the worktodo.ini from Factor=20.abc.def,59 to Factor=20.abc.def,65 He would receive approx. twice the credit the effort is worth. Not quite - even allowing for the 1/2^6 effort involved in TF through 59 bits ... through 64 bits the algorithm runs much faster than it does for 65 bits and above. The factor is around 1.6 rather than 2. Ofcourse nobody would do this, as we are all volunteers! Or could somebody some day be tempted to raise his rank using this method? Never underestimate what some people may do to rig league tables! Does GIMPS hold some log for TF's done by which account? If so could this log please be open? I think the log exists but, since intermediate checkpoints are not logged, it might not show anything. Would this cheat be trapped later by P-1 or does P-1 trust earlier work so factors below say 67-bits are not considered? P-1 doesn't care what (if any) TF has been done previously. _Some_ but by no means all missed factors would be picked up bt P-1. Note also that some factors may be missed due to genuine glitches as opposed to deliberate skipping. The above questions are _not_ asked because I intend to use the method. :-/ I think it would miscredit GIMPS as we trust the results of GIMPS. And I would be disappointed if I learned that an LL I did could have been solved far earlier - and using less effort. Yes - but as TF is primarily designed to reduce LL testing effort, missed factors are an inefficiency rather than a serious problem. Suggestion: TF should report completion of each bit to PrimeNet, not just the on completion to the target depth. I don't see how this would require changes to the server, though there would be a (relatively small) increase in load. Suggestion: the TF savefile should be modified to contain an internal consistency check (say the MD5 checksum of the decimal expansion of the current factoring position) so that cheating by editing the savefile, causing jumping past a large range of possible factors, would be made a great deal more difficult. 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: TF - an easy way to cheat
On Saturday 21 September 2002 16:15, Daran wrote: ... through 64 bits the algorithm runs much faster than it does for 65 bits and above. The factor is around 1.6 rather than 2. Good point, and one which I didn't consider in my reply. But the ratio must be different for the P4, which uses SSE2 code for factorisation over 64 bits. Pass, I haven't let my one only P4 system do any TF! According to undoc.txt:- You can limit how far the program tries to factor a number. This feature should not be used with the Primenet server., which implies that something bad will happen if you do. Umm. I guess there is a possibility that PrimeNet might get confused about whether an assignment is completed (as far as the system running it is going to go). Suggestion: the TF savefile should be modified to contain an internal consistency check (say the MD5 checksum of the decimal expansion of the current factoring position) so that cheating by editing the savefile, causing jumping past a large range of possible factors, would be made a great deal more difficult. Easily cracked. Why not just encrypt it? True. But the problem with encryption is that it has to be decrypted - if the client knows how to do that ( it has to, if the save file is to be any use at all) then a cheat can dig out the code somehow. One thing that could be done is to write an extra hidden save file (or store a registry key) containing some value computed from the save file contents, so that if the save file was manually changed there would be a clash the client would know something odd had happened. Another trick (which I actually used in a now-obsolete anti-tamper system) is to take the time the file is opened for writing (in unix seconds) xor that into part of the file data. When checking the file, read the file creation date from the directory, xor into the data, if the file checksum fails increment the creation date try again - at most 10 times, since the file creation date (stored in the directory) shouldn't disagree with the system clock read by your program just before it called the file open routine by very much. This works pretty well because few people will twig what you're doing (even if you document it!) even fewer will manage to frig the checksum properly. The idea here is to make successful cheating not worth the effort. There's no way it's going to be possible to stamp it out altogether. Personally I'm more concerned about the possibility of cheating your way up the PrimeNet LL testing league table. The obvious way to do this is to start a test, stop manually after a minute or two, edit the iteration number to a few less than the exponent restart ... lo behold, you _could_ complete LL tests on _any_ exponent in about five minutes, even on a P90 system. The fact that the residuals would all be wrong is irrelevant since PrimeNet doesn't penalise bad results; in any case, you'd probably get away with it until DC started to catch up with you. An internal consistency check would make this a lot harder to do. MD5 is pretty good (though not perfect) as there is no simple way to fudge it; the compute effort involved in frigging a file to achieve a specified MD5 sum is several orders of magnitude greater than that required to LL test a 10 million digit exponent, so it's simply not worth trying. 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: Hyper-threading
On Saturday 21 September 2002 21:20, Daran wrote: Could this feature of forthcoming Intel processors be used to do trial factorisation without adversely impacting upon a simultaneous LL? Could this be easily implemented? 1) _Existing_ Pentium 4 Xeons have hyperthreading capability. 2) Implementation is easy; just run two processes - one LL one TF - assigning one to each virtual processor. In fact there's no other way to implement: you can't have one process running in multiple virtual processors simultaneously with hyperthreading technology alone. 3) I reckon there would be a very significant performance hit. Temporary registers, instruction decoders etc. are shared so any pressure whatsoever on the critical path would cause a performance drop - even if the code in the two processes could be guaranteed to stay phase locked so that there was no simultaneous call on a particular execution unit. (In practise I think unregulated phase drifts would result in a phase locked clash, since this appears to be the most stable state). You would probably get 20-30% more _total_ throughput this way than you would be running LL DC assignments in series, i.e. the LL test speed would be at best 2/3 of what it would be without TF running in parallel on the same CPU. One benefit of hyperthreading technology for compute-bound processes in an interactive environment - provided you're running only one compute-bound process per _physical_ processor - is that the extra capacity helps the system to react more quickly to interactive loads, so it's a lot less likely that foreground users will notice the background CPU load. 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: New First Time Tests!
On Monday 16 September 2002 22:18, George Woltman wrote: I'm releasing about 3000 exponents from 10,000,000 to 15,000,000 for first-time testing! These have been tested once already, but the first run had one or more error. As we saw in another thread, this means the first test has less than a 50% chance of being correct. Retesting these exponents now rather than waiting for double-checking to get this high makes sense to me. Yes ... in fact it makes sense for LLtests with errors to be automatically recycled (but only the first time), since the worst that will happen is that there will be an early verification. If there are two results with the same residual this is very, very probably correct, even if both runs had errors - this may well happen, at least with some versions of Prime95/mprime, when the exponent is very close to a FFT run length crossover. 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: Order of TF and P-1
On Wednesday 11 September 2002 13:43, Steve Harris wrote: I don't think the TF limits were ever lowered; I haven't checked the source from the latest version but the TF limits should surely be linked in some way to the LL/DC FFT run length crossovers. Many of these _have_ been lowered. Slightly, and especially for P4 systems. it seems they may have been raised, as I have gotten several 8.3M DC exponents which first had to be factored from 63 to 64 and THEN the P-1. Yeah, I've had a number of these, too. I would have thought that, since (ignoring runs with errors - which is a reasonable first approximation) factoring before DC saves only one LL test, whereas factoring before first LL test saves two. So trial factoring (TF) depth for DC assignments should be one bit less than for LL assignments - ignoring efficiency changes due to hardware (word length) constraints, the last bit takes half the total TF time. It occurred to me that it might be more efficient to do it the other way around, but factoring from 63 to 64 goes relative quickly. If it were a question of factoring from 65 to 66 versus P-1 first, then I think the P-1 wins easily. Again I haven't checked against the new code - TF on P4s is supposed to have been speeded up considerably - but it used to be the case that, assuming trial factoring runs at the same speed irrespective of depth (which is again a reasonable assumption since most TF through 2^64 is completed) it was most effective on a PIII or Athlon to run TF through to N-1, then P-1, then the last bit of TF. On P4s the best policy was to run P-1 after TF to N-2 bits. I guess the new P4 TF code will have brought it all into line. 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: WinXP SP1 slows prime95
On Tuesday 10 September 2002 19:09, Jud McCranie wrote: Yesterday I went from Windows XP home to service pack 1. The speed of prime95 went down by over 2%. Has anyone else seen this? Any ideas on what caused it or how it can be fixed? No, I haven't seen this. I don't even have a copy of Win XP. 2% is the sort of change which can occur when a program is stopped restarted without changing anything else. Probably the cause is a change in the page table mapping (of physical to virtual memory addresses). It's also common to find Prime95/mprime speeding up a little when an assignment finishes and the next one starts compared with the speed measured when the program is freshly started. This seems to happen on (at least) Win 95, Win 98, Win NT4, Win 2000 and linux with both 2.2 and 2.4 kernels, with multiple versions of Prime95 mprime. From what I've heard read about XP SP1, I don't think there's anything in it which should affect Prime95 running speed to any significant degree. Personally I would not agree to the modified EULA which comes with SP1, as it appears to allow M$ to take complete administrative control of your system. However, that's irrelevant to the speed problem; in any case, not applying the critical patches contained in SP1 is in itself a security risk. 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: Still unable to communicate with server.
On Friday 30 August 2002 20:59, I wrote: Are we losing users? Well, if users can't connect to the server, they're going to be discouraged. Ditto anyone still using Windows 95 - Prime95 v22.3+ has problems since George apparently upgraded his development kit. I'm please to report that Prime95 v22.8 runs without problems on my reference Win 95 system (original version + SP1 + assorted patches). Regards Brian Beesley _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Database - truncated lucas_v file available
Hi, Since George added offset error information to the lucas_v database file, it's grown ... now around 7 megabytes, making it painful to download on an analogue modem link. I've therefore created a truncated version of the file. This is the same file but with the information omitted for all exponents smaller than the double check completed through value on the status page. The new file is only about 40% of the size of the full version, but contains all the information of interest to people working in active PrimeNet ranges. The file is available as follows: http://lettuce.edsc.ulst.ac.uk/gimps/lucas_va.zip or by anonymous ftp from the same host, look in directory /mirrors/www.mersenne.org/gimps It's generated by a cron job run at 0630 GMT daily, if the lucas_v.zip file on the master database has been updated during the previous day. BTW this file has been generated by an open-source compression program which is supposed to produce files 100% compatible with Windows Zip format. Please let me know if there are any problems with decompressing it. The orginal file remains available; omit the last a in the URL given above. 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: More error info
On Sunday 01 September 2002 03:35, George Woltman wrote: Our intrepid researcher broke down the non-clean run stats below. So if you get a single error, you've got a 2/3 chance of being OK. Two or more errors and your chances are not good. There will be a major change in this area - since new versions run per-iteration roundoff error checking when close to FFT run length crossovers, there will be a fair number of _reliable_ results with multiple (automatically checked) roundoff errors. Perhaps the analysis should distinguish between runs where all roundoff errors were found to be false alarms, and runs where a roundoff error seems to have been a glitch. Analysis of the seven results in the bad database submitted on my account: 3 due to a failed CPU fan (on an old P100 system, running in an air-conditioned computer lab. One with detected roundoff errors, two without) 2 due to software bug in a recent alpha release 1 due to hard disk problem - almost certainly bad swap file I/O caused memory corruption on a busy system (without detected error) 1 (also without detected error) cause unknown. 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: Still unable to communicate with server.
On Friday 30 August 2002 21:29, you wrote: Well, Win95 is getting increasingly uncommon (and for good reasons, stability and support for USB come to mind). Well - there are still a lot of older systems around which run Win 95 quite happily (some of them are even reasonably stable!) but which it isn't worth paying M$ upgrade tax on. Some simply don't have the resources to run Win XP, and some of the owners can't be persuaded to switch to linux (perhaps because they're corporately owned). Suggesting to people that their contribution isn't welcome because they're operating somewhere close to the trailing edge is another good way of discouraging participants. As for USB - I'm responsible for twenty-odd systems with hardware USB ports; only two of them have ever had USB peripherals connected. I may be unusual in this respect, but I don't think USB support is absolutely essential. In any case, later OEM versions of Win 95 contain the same USB support as Win 98. Yes, it is neat to be able to connect a printer to two systems simultaneously using both the parallel and USB ports! 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: Still unable to communicate with server.
On Friday 30 August 2002 04:22, Sisyphus wrote: Hi, Recently started getting error 29 with Windows, PrimeNet version 21, so I've upgraded to version 22.8. Now I get error 2250 - so we're definitely making progress 2250 is a problem with the server being offline for some reason. :-) 'prime.ini' contains 'UseHTTP=1'. And I've tried the stuff relating to proxies/firewalls mentioned in the faq (though this was not an issue with version 21). Still can't get a connection. Where to, now ? Hmm. Surely UseHTTP is now obsolete since there hasn't been RPC support for some time? Are we losing users? Well, if users can't connect to the server, they're going to be discouraged. Ditto anyone still using Windows 95 - Prime95 v22.3+ has problems since George apparently upgraded his development kit. Another good reason for changing to linux? Anyone with this problem could also try Prime95 v22.1, which _does_ appear to work on Win 95 _and_ hasn't had the connection problems others have been reporting (though there have been occasions this week - at least 12 hours on one occasion - when the server was broken). I find all this a bit hard to understand (and harder to wrestle with when I'm hopelessly overloaded with work - as usual at this time of year) since web comms on TCP port 80 is pretty standard these days; even firewall tunnelling is pretty much a given. When it stopped working, which end was broken so far as standards compliance is concerned? 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: 22.8.1 has increased iteration time
On Thursday 29 August 2002 13:30, Gary Edstrom wrote: I have noticed a small but definite increase in the iteration time of version 22.8.1 as opposed to 21.4. During the night, when my 2.2GHz Pentium IV system was free of all other processing activities, the iteration times were as follows: 21.4 47 msec 22.8.150 msec Is the exponent very close to the run length threshold? If so you're now running with per-iteration roundoff checking. On my P4 1.8A (with PC800 RDRAM) I found this made very little difference, but systems with more limited memory bandwidth may be more affected by this. I am continuing processing on the very same exponent using the new version. Is this allowed? It works, reliably, though sometimes the FFT run length may change at the time of the upgrade. 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: 266 vs 333 ddr on Athlon
On Tuesday 27 August 2002 02:08, Marc Honey wrote: Anyone else notice that a kt333 Athlon board using an Athlon XP gets better performance at 266 than at 333? I was amazed at the difference, and yes I tweaked out the bios under both memory speeds. AMD really needs a fsb speed update! Weird. Possibly your 266 MHz DDRAM is CL2 but your 333 MHz DDRAM is CL3. Also, I have two near-identical systems using 1.2GHz T'bird Athlons in Abit KT7A mobos, with CL2 PC133 memory. The only difference is that one of the CPUs is 200 MHz FSB the other is 266 MHz. Both are running the memory at 133 MHz (the BIOS on the KT7A lets you do this). The system speeds are within 1% of each other. 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: Benchmarks / Reference Machine / Calculations
On Tuesday 20 August 2002 22:39, you wrote: Michael Vang highlights the fact that there are two different things that we can measure: 1) work accomplished, e.g. Mnumbers evaluated, iterations run, etc. 2) work effort expended, which requires evaluation of processor/system power. The P4 versions (more efficient) accomplish more with less effort. This can make evaluation of effort expended complex, even when work accomplished is trivial to calculate. Also, PIII and Athlon are more efficient than PII because of the impact of the prefetch instruction... The only thing I have concluded so far is that any re-indexing or re-calculation should be concerned strictly with LL computation. No consideration should be given to factoring or P-1 effort in determining machine efficiency. After all, any factors found are a nice side effect. The _real_ objective is to find numbers _without_ factors. Umm. I think the point here is that factoring LL testing are _different_. You can't add apples oranges directly; you really need seperate tables. The rankings should ideally be based on work effort expended, in my opinion. I have no idea how this can be done fairly. If accomplishments are to be the basis of rankings, the individuals who have found MPrimes should always be at the top of the list for LL testing. This is all old stuff fairly uncontroversial. To recap: at present we have two sets of tables: the PrimeNet tables are effort expended and seperated into LL testing trial factoring components (P-1 is ignored) George's tables count LL testing effort only; results subsequently found to be incorrect are discredited; so are results for exponents when a factor is subsequently found. 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: The first 1000+ digit prime
On Tuesday 20 August 2002 16:32, Tony Forbes wrote: We all know that A. Hurwitz discovered the Mersenne primes 2^4253 - 1 and 2^4423 - 1 in 1961. (i) Were these the first two 1000+ digit primes discovered? Yes. See http://www.utm.edu/research/primes/notes/by_year.html#table2 (ii) If that is true, then is it generally accepted that the larger one (4423) was discovered first? (The story I heard was that left the computer running overnight and when he came to look at the results he read the printer output backwards, thus seeing 4423 before 4253.) Interesting. Is the discovery the point at which the computer finishes with zero residual (in which case 4423 was discovered first) or the point at which a human being becomes aware of the result of the computer run (in which case 4423 was discovered first). (Unless the operator (remember those?) was reading the printout as it was being output?) 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: Benchmarks / Reference Machine / Calculations
On Tuesday 20 August 2002 08:57, Paul Leyland wrote: Anyone else here old enough to remember Meaningless Indicators of Processor Speeds? Oh yes. My first boss used to rate CPUs in Atlas power All gigaflops are not created equal, unfortunately. Wordlength alone can make a big difference. Really we need only consider IEEE single (24+8) double (53+11) precision types... the x87 80-bit format is not much different to double precision the way we use it, and I'm not aware of any common hardware implementations of other floating-point formats. Or use bogomips... :) It's no worse than many suggestions, and better than some we've seen. Surely bogomips is measured only in the integer arithmetic unit? Personally I vote for the status quo. It's a well understood arbitrary unit and there are enough P90's around to be able to re-calibrate new algorithms as they come along. If need be, I can un-overclock my P120 to convert it back into a P90 for benchmarking purposes. I doubt very much that there aren't other P90 owners who could also provide a similar service. There's a great deal to be said for that proposal. But don't forget that the official P90 benchmark refers to a specific system, no longer in existence, operated by George Woltman; it seems to have been a rather good P90 system. Apart from the CPU, factors such as the L2 cache size, memory timings, chipset type, BIOS parameters etc. etc. can make a significant difference to the speed of a system. 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: Benchmarks / Reference Machine / Calculations
On Sunday 18 August 2002 17:59, Jeff Woods wrote: 21000 of the 31000 participating machines are P-III or better. Less than 2,000 true Pentium-class machines remain in the mix. George et. al.: Could it be time to change the baseline reference machine away from the Pentium-90, and wipe the P-90 off of all pages, from rankings to status to years of computing time left to complete the task? A couple years back, George changed the Status page reference to be a P-II/400, equivalent to 5.5 P90's. Now even that PII/400 is far less than the 'average participating machine, which given the above numbers, I'd guess is now about one gigahertz, perhaps slightly better. I believe that a one-time re-indexing of ranks, stats, and time left to compute that re-indexes on either a P-III/1000 or an Athlon-1000, would make the CPU years left numbers on the status page a bit more realistic, as well as the number of CPU years I complete each day. If we're going to re-index at all then we should be jumping to the top of the range since this will be relevant for longer. How's about referencing to Pentium 4 2.67B which is about the top of the range at the moment (if it's even available yet). I think we should also publish conversion factors for common processors including obsolete ones at least as far back as 386. There _is_ historical interest in this, even if working examples of these processors are now only to be found in space hardware. (Incidentally the first successful microprocessor-controlled space probes - the Voyagers, controlled by Intel 8008 CPUs - are just coming up to the 25th anniversary of their launch!) Side note: Also of interest in both the benchmarks table and on the individual / top producers tables, would be a RECENT CPU hours/day comparison, as well as a machine reference back to the baseline machine, whatever it may be. i.e. I've been with this thing from the beginning, in 1996. Obviously, my average machine has gotten better and better. My top listing says I'm doing about 1090 CPU hours a day but that's averaged over ALL of my submissions, dating back to when I was using 486's in 1996! I did some arithmetic to try to figure out what I'm cranking out NOW (anyone want to check my logic here)? i.e. how many CPU-hours a day is, say, an Athlon 1600+ worth? According to the benchmarks page, the P-II/400 does a 15-17MM exponent iteration in 0.536 seconds.And we know that this machine is 5.5 P-90's. Thus, a P-90 would be expected to take 5.5 x 0.536, or 2.948 seconds. My Athlon 1600+ takes .130 seconds per iteration. 2.948 / 0.130 = 22.677 times as fast at the P-90, so 22.677 x 24 hours means that this machine ought to be doing ABOUT 544.24 P-90 CPU hours per day. If I add up what all my machines are doing NOW, I get 3503 P-90 CPU Hours a day, not the 1090 shown on my account and report. -- What I'd like to see is: 1) On the individual account report, the above calculation (i.e. the 544.24) shown next to the exponent/machine. This should not be ESTIMATED, but reverse engineered from actual reported iterations per second for the exponent, compared to 2.948 seconds for the P90 (or whatever a new baseline might be). 2) A SUM of all of the above, to let one know how much they TRULY are cranking out, as opposed to that slow creeping average that, after so many years means nothing. 3) A rolling average for the last 6 months, for the Top XXX pages, so that I can compare RECENT work to other recent work. i.e. I see that I am surrounded by many others in the 1100 CPU Hours/day rangebut if my historical data is skewed so much by those old slow machines from six years ago, how much are others skewed? Who do I have a chance to pass? Who's gaining on me? I can't tell! A rolling average, or perhaps the calculations from #2 above in a column instead of a rolling average, would make comparisons in the Top XXX listings easier, and much more meaningful. This suggestion makes a lot of sense. The hours per day figure is pretty meaningless, for the reasons stated. 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: Two bugs in Prime95 v21.4.1
On Tuesday 23 July 2002 10:25, Paul Leyland wrote:
George,
I think I've found two bugs in Prime95 or, at least, serious
misfeatures. I don't know whether they've been fixed in more recent
releases but as I'm using the program in a rather creative manner I
suspect not. The Mersenne list is Cc:ed so that if anyone else wishes
to use your program in this way they will be aware of the problems and
take appropriate countermeasures.
Bug 1: A factor specified in lowm.txt or lowp.txt which is more than a
hundred or so decimal digits is not read correctly and is incorrectly
reported as not dividing the M or P number being factored. The exact
length at which it fails wasn't determined directly but it's around that
size.
Umm.
My guess would be that whatever buffer space is set aside for known factors
(or the product of known factors) is insufficiently large, so something gets
trampled on.
Bug 2: If worktodo.ini contains two lines specifying ECM work to be
done, and a factor is found of the first number, the worktodo.ini file
is truncated to zero size and Prime95 halts. In my opinion it's a
misfeature that the program doesn't append the new factor to
low{m,p}.txt and continue with the remaining curves on that integer but
I accept that may not be what everyone wants. Wiping out all remaining
lines *is* a bug in my opinion.
Sure. But it hasn't happened to me when I've found factors (up to 44 digits).
I thought the continue after finding factor feature was set by default -
doesn't one have to set ContinueECM=0 in prime.ini if one wants to abort
after finding a factor? The exception being if the cofactor is determined to
be a probable prime, in which case there is no point in continuing...?
Maybe fixing any short buffer problem would fix this problem too.
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: Roundoff errors
On Monday 22 July 2002 16:55, you wrote: Thank you and everyone else, both on- and off-list, for your helpful suggestions. I took the cover off and had a look. The HSF looked like the inside of an old vacuum cleaner, so I used a new one on it. :-) The fan speed is now back up to 4600, and the processor temperature has dropped by 10 degrees. While this is probably what tipped the system into instability, I'm not convinced it is the sole cause of the problem, if, as you say, 50 degrees is not excessive. This does depend on whether the sensor is correctly installed in the mobo - socketed AMD Athlon/Duron processors have the sensor located in the well in the middle of the socket, rather than in the processor package. It should sort of stick up a bit so that the springiness of the mounting wires holds it in contact with the installed processor package base. If it is pushed down to the bottom of the well, out of contact with the processor package, it will underread badly - even if the reporting software maps the current/voltage/resistance measured by the sensor to temperature correctly. The temperatures voltages reported in the BIOS Setup health status display should be correctly mapped but are, of course, impossibly inconvenient to use on a running system! A small amount of dust buildup on the leading edges of fan blades is inevitable. The problems with buildup of excessive dust/fluff are (a) it gets stuck between the heatsink fins, reducing the effective area of the heatsink and restricting airflow - possibly to the point where fan rpm reduces, though this usually involves fan blade stalling with a marked increase in aerodynamic noise; (b) lumps of compacted fluff can be thrown from the fan blade, whereupon they stick to the inside of the duct and are clouted by each passing fan blade; this makes a terrible noise, and failure of the bearing due to repeated shock loading often follows shortly thereafter. I prefer to mount cooling fans onto heatsinks so that they suck hot air from the heatsink rather than blow cool air onto it. This does result in a small decrease in efficiency of the HSF combination when clean, but helps prevent the heatsink from getting clogged with debris. The reversed airflow trick is particularly effective when combined with an adapter allowing a 80 mm fan to be fitted to a heatsink designed for a 60mm fan; the advantage here is that the larger fan can be much quieter, due to being able to shift air at the same rate whilst rotating at a much lower speed. to test your processor, i recommend www.memtest86.com it is a memtest in first place, of course, but it also tests the processor You can test your system with madonions 3DMark 2001 SE. This program will heat up your ram, cpu and grafik card. If you are running Windows, you could also check out Sisoft Sandra. The free limited edition will do enough. http://www.sisoftware.co.uk/sandra One final point - I heard of a system built by a well-known overclocking expert who had a problem with the system blue screening at intervals for no apparent reason. (Sounds typical of Windows systems to me; however...) The problem persisted even when everything was returned to rated speed. Eventually it was traced to the chipset fan; occasionally this would seize (probably due to blade fluff shedding) for a few minutes, but then restart itself, so that a quick check of the operation of the fan showed no obvious fault. Operating the system with the cover off, it was noticed next time that the system crashed, the chipset fan was not running. If you _do_ have to deal with a suspect/failed chipset fan, it is now possible to obtain large area passive heatsinks which can be used to replace the chipset HSF; these are ovbiously going to be more reliable less noisy than a replacement fan, though they may not be suitable for (or indeed compatible with) all motherboards. 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: Extrange assignament
On Thursday 11 July 2002 00:00, you wrote: Yesterday, Primenete did assigned to one of the computers that I manage, a exponent in the 8 million rank, for first test, not for doublecheck. But in the Status page, this rank is complete for first test ... How is it possible? The factorization level is 1, if it help ... I've had a few of these (as DC assignments). Factorization level 1 is WRONG. The correct value can be obtained from the database files - you need nofactor.zip (and the unpacking tool decomp). If you get one a sobviously wrong as this, the best thing to do is to manually change the factoring depth in worktodo.ini. 64 is about right for 8 million range exponents. Regards Brian Beesley Saludos, Ignacio Larrosa Cañestro A Coruña (España) ¡¡NUEVA DIRECCIÓN!!: [EMAIL PROTECTED] _ 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: Prime95 21.4.1 miscomputation of completion date--my setup or bug?
On Wednesday 10 July 2002 22:38, Gerry Snyder wrote: I am puzzled. I am running two copies of prime95 (one with no options, one with -A1) on a dual 1 GHz P3 computer under Windows 2K. One is factoring, and the other is doing an LL test of an exponent in the 15,xxx,xxx range. The torture test was run for several hours with no problems. W2K recognizes the two CPU's and the task manager shows each mprime getting 50% of the total CPU time and almost no idle time. The only problem is a galloping completion date. After about 11 days of execution (split among several reboot sessions), with some time spent in trial factoring and P-1 factoring, the LL is over 26% complete. The per-iteration of .191 seconds indicates a total LL time of around 33 days. Right after I start it running, the completion date is reasonable. But every few hours it contacts the PrimeNet Server to extend the completion date by weeks. The Status now menu shows completion in April 2003 (this execution has been for about 5 days). Any idea what could be the problem? Did you change the CPU type/speed - perhaps after importing local.ini from a different system? Keep a track of the changing value of RollingAverage in local.ini; if it's a long way different from 1000 (say outside the range 500-1500) try stopping Prime95, editing RollingAverage to 1000 restarting. There have been problems with some versions of Prime95/mprime where the CPU type would be detected wrongly. Suggest changing to v22.1 (or v22.5) as v22 has much better CPU type/speed detection code - automatic, too, so you can't mis-set it :-) BTW my dual 1 GHz PIII system, with a similar work loading to yours, has RollingAverage=1128 on the CPU running LL tests. 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: Damage done by overclocked machines
On Thursday 11 July 2002 03:43, George Pantazopoulos wrote: Hey all, If an overclocked machine is producing erroneous results, how much harm does it to the project as a whole? Can it miss the next Mersenne prime? Will the rest of the group assume that there is officially no Mersenne prime at the missed location and not double-check? (Apart from the fact that there are lots of reasons other than overclocking why a result might be in error!) That's the whole point of double-checking There IS a VERY SMALL chance that a double-checked result would be wrong. This will happen if BOTH runs go wrong and the final residual is the same. The chance of this happenning with independent random errors is obviously less than 1 in 2^64; this is about the same chance that the same balls will be drawn four weeks running in a 6/49 lottery game, so we don't worry too much about it. The chance of missing a prime is much smaller than that, because the wrong result would have to belong to a number which really is prime. However, there are a number of exponents where one or other of the runs was made with an old client which reported 16 (sometimes even less) biys of the residual. Clearly there is a much higher chance that one of these might be wrong. For some time, some of us have been systematically working our way through these running a triple-check, but there are still a few thousand left. This is an ideal project for systems too slow to be useful otherwise, as the remaining exponents are all less than 2 million (in fact about 40% of them are less than 800,000). Anyone interested in contributing, please e-mail me directly. Regards Brian Beesley _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Re: Mersenne: Slow Pentium 4 question - status report
On Thursday 13 June 2002 23:56, Bockhorst, Roland P HQISEC wrote: Gentlemen; Thank you for your help. My P4 is successfully working on its second 15,000,000 range number. The first number was found to be not prime in about three months full time. It should have taken a month, hence this discussion. Umm. I find my P4 1.8A takes just one week to process a LL test on an exponent just under 15 million. Running 24x7 of course! WCPUID recognizes my P4 and its having SSE and SSE2 instructions. Prime95V22.3 doesn't. This is very odd Could the CPU be overheating? This is a good idea to pursue. The P4 thermal slowdown is easy to diagnose - the speed shown by the diagnostic output from Prime95 will vary depending on the ambient temperature. Also, if you stop Prime95, wait a few minutes and continue again (using the Test menu), the CPU will cool down the diagnostic output will show it starts very fast then slows down over a minute or two as the system warms up again. If you do have this problem, there are now available some very good P4 CPU coolers, and they aren't neccessarily noisier than the standard Intel part. A good tip with Intel retail pack CPUs is to carefully remove the thermal goo which is stuck to the bottom of the supplied heatsink - carefully scrape the bulk off with a soft edge e.g. a plastic credit card, NOT a knife which will scratch the heatsink mating surface; then remove the residue with white spirit, then methylated spirit. Allow to dry then apply a good thermal compound like Arctic Silver II in accordance with the instructions on the web site. This will, on its own, reduce the CPU die temperature by around 5C. Win95 unless another SSE/SSE2 ... timesharing Good point Surely the problem is that a system with extra registers will use more stack when the save all registers opcode is executed. If so, the OS need not support SSE/SSE2 directly - but there might be a problem with crashing through the stack base. hum the error was illegal instruction A stack overflow will usually cause system hang or spontaneous reboot. . I recently bought a new license for Win98. That's fine then. But where from? My understanding is that Win 9x licences are no longer available ... the official MS line seems to be that you can buy a licence for ME or XP Home Edition but install Win 9x provided that the copy of ME or XP HE is not installed on another system simultaneously and on the understanding that MS will do nothing to support you technically. (I believe Windows Update still works with Win 98 but I don't know when the last update to any '98-specific component was posted.) 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: Slow Pentium 4 question - status report
Hi, Check out http://www.theregister.co.uk/content/archive/25085.html Microsoft do seem to chop change as to some of the more ridiculous extensions of what their EULA actually says. Some of us are just happier to sidestep the issue altogether. My employer's policy is to permanently remove all software or physically remove destroy the hard disk drive before a system is passed to any third party, even if it's being removed directly to a landfill. Regards Brian Beesley On Friday 14 June 2002 05:09, Brian Dessent wrote: John R Pierce wrote: I'd like to know the source of this story Sounds like urban folklore to me... The OEM Windows license is bundled with and tied to the hardware and automatically transfers with it. Now, if these recycling projects were taking bulk OEM CD's purchased off the grey market, and bundling them with recycled hardware without having a redistribution agreement, thats another story entirely. Ditto, if the EULA for the original system was lost and not kept with it when the system was recycled... I think the problem stems from the fact that most donated PCs with MS OSes do not arrive with the full documentation of the original OS license. Organizations who accept and use these PCs without all the proper paperwork could technically be found in violation by MS or its BSA goons. Hence they are hesitant to accept any donations without all the paperwork. Since the OS is tied to the machine, the donating company cannot reuse the OS license if they donate the machine. This further complicates things since the donating company must prove that they have transferred all the licensing paperwork, unless they wipe the drives of every machine. If the donating party does not buy new licenses for the machines that replace the donated ones, or they fail to transfer/destroy all of the bits relating to the donated machines, then they are in violation as well. By making it hard on both the donating and receiving parties, MS ends up selling new licenses to everyone, which is probably a contributing factor to why they're stinky filthy rich. Brian From http://www.microsoft.com/education/?ID=DonatedComputers Q. What does the donor need to do to donate a PC with the operating system? A. PC owners have to transfer their license rights to the operating system to your school along with the PC. They may do so as specified in their End-User License Agreement (received at the time of purchase) as part of a permanent sale or transfer of the PC. Q. What if the donor can't find the backup CDs, End-Use License Agreement, End-User manual and the Certificate of Authenticity? Can they still donate the PC and operating system? A. Microsoft recommends that educational institutions only accept computer donations that are accompanied by proper operating system documentation. If the donor cannot provide this documentation, it is recommended that you decline the donated PC(s). _ 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: P-1 Puzzle
On Sunday 09 June 2002 08:22, Daran wrote: I'm currently concentrating exclusively on P-1 work. The primenet server doesn't support this as a dedicated work type, so my procedure is to reserve some DC exponants, imediately unreserve any which have the P-1 bit already set, P-1 test the rest, then unreserve them without doing any LL testing. One problem I have discovered is that the server doesn't always 'recognise' that a P-1 result has been returned. It can take several days before my individual account report removes the * indicating that factoring work is necessary. In these cases I hold on to the exponant until the result is recognised in order to stop the subsequent 'owner' from doing a redundant P-1 check. In other cases, the P-1 result is recognised imediately. Though I'm not looking for P-1 specifically, I have seen something similar on a large number of occasions. My current assignment report - the DC part of which follows - contains a number of examples. 6493831 D 64 3.3 33.8 93.8 07-Jun-02 07:25 06-Jun-02 06:02 cabbage 0 v18 6530189 D 64 2.3 27.8 64.8 08-Jun-02 06:02 07-Jun-02 06:02 nessus-b 266 v19/v20 6672569 D 64 31.3 13.8 73.8 14-May-02 07:43 09-May-02 06:05 cabbage 0 v18 6881321 D 64 6.3 23.8 63.8 06-Jun-02 06:06 03-Jun-02 06:06 nessus-j 332 v19/v20 6972001 D* 64 0.3 14.7 60.7 09-Jun-02 04:02 caterpillar 654 v19/v20 7009609 D 63 394908824.3 9.8 64.8 07-Jun-02 06:04 16-May-02 06:06 nessus-m 266 v19/v20 7068857 D 63 588757825.3 0.8 60.8 06-Jun-02 06:06 15-May-02 06:05 nessus-j 332 v19/v20 7076669 D* 64 561798830.3 3.8 63.8 07-Jun-02 06:02 10-May-02 06:04 nessus-b 266 v19/v20 7099163 D 63 269335914.3 11.8 65.8 09-Jun-02 06:26 26-May-02 06:43 T4070 366 v19/v20 7908091 D 64 308019117.7 15.4 60.4 08-Jun-02 21:12 22-May-02 19:17 broccoli 400 v19/v20 7937717 D 64 235929510.5 7.6 60.6 09-Jun-02 02:04 30-May-02 00:30 caterpillar 654 v19/v20 7938407 D 64 131072010.3 12.3 60.3 08-Jun-02 20:29 30-May-02 04:16 vision.artb 495 v19/v20 7940447 D 64 9.8 16.8 65.8 09-Jun-02 06:24 30-May-02 17:39 Simon1 1002 v19/v20 7951049 D 64 65536 7.5 10.7 60.7 09-Jun-02 04:31 02-Jun-02 00:40 rhubarb 697 v19/v20 6972001 and 7076669 are starred although the fact bits column seems to indicate that both trial factoring to 2^63 and P-1 have been run. This is _definitely_ true for P-1 on 7076669, the fact is recorded on my system in both results.txt prime.log. So far as 6972001 is concerned, the database (dated 2nd June) indicates P-1 has been run to a reasonable depth but trial factoring has only been done through 2^62. My system definitely won't have done any more trial factoring yet, let alone reported anything, since that system is set up with v22 defaults i.e. defer factoring on new assignments until they reach the head of the queue. 7009609, 7068857 7099163 are not starred although the fact bits column is one short. The nofactor Pminus1 databases (dated 2nd July) give these all trial factored through 2^62 Pminus1 checked to B1=35000, B2=297500 (or higher). The P-1 limits seem sensible for DC assignments, but shouldn't these have been trial factored through 2^63 like most of the other exponents in this range? Currently, I have nine exponants 'warehoused' whose P-1 results have been returned but not recognised, the oldest was done on May 14, which is rather longer than I would expect. There's no question that the server has correctly recieved the result, because it is contained in a recent version of the pminus1.zip file downloaded this morning along with another four exponants 'warehoused' from May 20. Three more, whose results were returned on June 3 have not yet been recorded in this file. There is an entry in the file for the last of the nine, returned on June 5, but the limits are much smaller than the test I did. The most likely explanation is this is a previous owner's P-1 result which wasn't recognised before the exponant was given to me. I wonder what happens if you're working like Daran and someone returns a P-1 result independently (either working outside PrimeNet assignments, or perhaps letting an assigned exponent expire but then reporting results); if PrimeNet gets two P-1 results for the same exponent, which does it keep? This is not trivial; e.g. if you get no factors, B1=10, B2=100 and no factors, B1=20, B2=20 there might still be a factor which would be found if you ran with B1=20, B2=100. Also, if the database says that P-1 stage 1 only has been run (probably due to memory constraints on the system it ran on), at what point is it worthwhile running P-1 for the possible
Re: Mersenne: Quicker Multiplying ?
On Tuesday 28 May 2002 02:43, you wrote: 6 is -2 mod 8 6*6 = 36 36 = -4 mod 8 2^2 = 4 if the mod of the represented as a negative is much less than the positive, could we square the negative and save some time ? Sure we could. However on average we would save 1 bit 25% of the time, 2 bits 12.5% of the time, 3 bits 6.25% of the time on average the saving is 0.5 bits. Out of several million. In fact the _practical_ saving is zero, as we aren't ever going to save enough bits to justify using a shorter FFT run length, even just for one iteration. 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: Roundoff Checking
On Saturday 25 May 2002 22:19, you wrote: I noticed that v22.2 and v22.3 automatically do roundoff checking every iteration for any exponent close enough to the FFT limit. Is there any reason to be concerned about the possibility of roundoff error for CPUs that aren't P4s? I don't think so. We are looking at the x87 (non-SSE2) code and may make some minor adjustments to the FFT run length crossover points, but there is a lot of experimental evidence relating to non-SSE2 code; the adjustments are probably as likely to be up as down. Please remember that the crossover points are a compromise between wasting time by using an excessive FFT run length and wasting time due to runs failing (or needing extra checking) due to using a FFT run length which is really too short. There is no completely safe figure. What about if the non-P4s are only doing double checks? This doesn't really matter. Double checks are independent of the first test. Don't assume that the first test was correct... if you make that assumption, what's the point in running a double-check at all? Since numbers of double checking size have been checked by non-P4s for years without any problems that I've heard about. The point is, if you do get an excess roundoff error that makes the run go bad, the double-check (when it is eventually done) will fail, and the exponent will have to be tested again. There is essentially no possibility of the project missing a prime as a consequence of this. However, if you can detect the likelihood of there being excess roundoff errors at the time they're occurring, you can save time which would be wasted if you continue a run which has already gone wrong. This also virtually eliminates the possibility of you, personally, missing a prime due to a crossover being too aggressive and therefore falling victim to an undetected excess roundoff error. We simply don't know if there are extra problems occurring very close to the existing non-SSE2 crossover points as any genuine errors caused by the crossover points being too aggressive are overwhelmed by errors caused by random hardware/software glitches. However it has become apparent that the SSE2 crossover points were initially set too aggressively. We do have one documented instance of where a roundoff error of 0.59375 occurred (aliased to 0.40625, therefore causing a run to go bad) without there being any other instances of roundoff errors between 0.40625 0.5. This is probably a very, very rare event, but the fact that it has happened at all has made us more wary. v22.3 has a new error checking method which will _correct_ any run which is going wrong by running the iteration where the excess roundoff error occurs in a slow but safe mode. This of course depends on the excess roundoff error being detected. If you have roundoff error checking disabled then you miss the chance 127 times out of 128. The roundoff error rises very rapidly with the exponent size - somewhere round about the 25th power. This is why it's only worthwhile having roundoff error checking every iteration in the top 0.5% or so of the exponent range for any particular run length - that 0.5% makes a lot more than 10% difference to the expected maximum roundoff error. Why not just set the crossovers lower? Well, this would work, but running with roundoff checking enabled is faster than running with the next bigger FFT run length but without roundoff checking. Another consequence of having roundoff error checking enabled is that random hardware glitches (or software glitches due to misbehaviour by device drivers etc. unrelated to Prime95) will be detected much more consistently. Very specifically, I'm wondering if I should be ok if I use the undocumented setting in prime.ini to turn off roundoff checking every iteration for when my Pentium 200 MHz double checks 6502049 ( the next FFT size is at 652 ). Thanks. Up to you. My feeling is that the new default behaviour is right. However per-iteration roundoff checking probably causes more of a performance hit on Pentium architecture than on PPro or P4 due to the relative shortage of registers. Another point here, if people using v22.3+ leave the default behaviour, we will get a lot better evidence as to the actual behaviour in the critical region just below the run length crossovers; we will be able to feed this back in the form of revised crossovers and/or auto roundoff error check range limit. QA work should prevent gross errors, but the amount of data which QA volunteers can process is small compared to the total throughput of the project. We should have avoided the problems with the aggressive SSE2 crossovers, but QA volunteers didn't have P4 systems at the time the code was introduced. Regards Brian Beesley _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ
Re: Mersenne: This supercomputer is cool
On Tuesday 21 May 2002 16:21, [EMAIL PROTECTED] wrote: http://www.cnn.com/2002/TECH/industry/05/21/supercomputing.future.idg/index .htm l The theme of reducing transistor count without sacrificing much performance is an interesting one. This is indeed interesting. The problem seems to be that the sustained floating-point performance of Transmeta chips seems to be at best only similar to that of PIII or Athlon chips when scaled by the power consumption of the chip itself. For our purposes, the transistor-heavy SSE2 unit on the P4 gives a much larger performance improvement than the resulting increase in power consumption. Add on the power consumed by support devices (chipset, memory etc) and the Transmeta design doesn't look too effective. In a situation where _on average_ only around 10% of the actual peak performance is required, the Transmeta design has considerable advantage, due to its capability to idle on very low current. From the ecological point of view, one could easily make gains by using the waste heat from processors - ability to pipe it into building heating systems (at least the hot side of a heat pump) would be more useful than dispersing it locally as hot air. Some obvious possibilities I can think of, related to the way typical CPUs do hardware arithmetic: 1) For floating-point add, have a dedicated unit to do exponent extraction and mantissa shift count generation, then do the actual add in the integer adder (there are often multiple integer adders on the chip, so this need not stall genuine integer adds that are occurring at the same time). 2) Similarly, use the intger multiplier to multiply the 2 floating mantissas in an FMUL together. For IEEE doubles this would need to generate the upper 53 bits of a 106-bit product, but many CPUs already can generate a full 128-bit integer product (this is useful for cryptographic applications, among other things), so one could use the same hardware for both. Most of the transistors in a typical modern CPU die are associated with cache multiple parallel execution units. Cutting out one execution unit - one of the simpler ones at that - probably wouldn't save much power. 3) Have the compiler look for operations that can be streamlined at the hardware level. For example, a very common operation sequence in doing Fourier (and other) transforms is the pair a = x + y b = x - y . If these are floating-point operands, one would need to do the exponent extract and mantissa shift of x and y just once, and then do an integer add and subtract on the aligned mantissa pair. It might even be possible to do a pairwise integer add/sub cheaper than 2 independent operations at the hardware level (for instance, the 2 operators need only be loaded once, if the hardware permits multiple operations without intervening loads and stores (and yes, this does run counter to the typical load/store RISC paradigm). This is a Good Idea and would cost very little extra silicon. There is however a synchronization problem resulting from always doing add subtract in parallel ( discarding the extra result when only one is needed). This is because (when operands have the same sign) renormalizing after addition requires at most one bit shift in the mantissa, whereas after subtraction one may require a large number of bit shifts; indeed we may even end up with a zero result. Fixing this sychronization problem requires either extra silicon in the execution unit, or a more complex pipeline. 4) Emulate complex functions, rather than adding hardware to support them. For instance, square root and divide can both be done using just multiply and add by way of a Newtonian-style iterative procedure. The downside is that this generally requires one to sacrifice full compliance with the IEEE standard, but hardware manufacturers have long played this kind of game, anyway - offer full compliance in some form (possibly even via software emulation), but relax it for various fast arithmetic operations, as needed. Yes. That's why FP divide is so slow on Intel chips. 5) Use a smallish register set (perhaps even use a single general-purpose register set for both integer and floating data) and memory caches, but support a variety of memory prefetch operations to hide the resulting main memory latency insofar as possible. I get suspicious here. Extra working registers enable the compiler to generate efficient code easily, and (given that memory busses are so much slower than internal pipelines) bigger caches always repay handsomely in terms of system performance. (Incidentally there may be an impact on Prime95/mprime here. The new Intel P4-based Celerons have 128KB L2 cache; I believe the SSE2 code is optimized for 256KB L2 cache, so running SSE2 on P4 Celerons may be considerably less efficient than it might be.) Others can surely add to this list, and extend it to non-arithmetic functionality. A few weeks ago
Re: Mersenne: electrical energy needed to run a LL-Test?
On Saturday 27 April 2002 22:11, you wrote: Better still, switch the monitor off when you're not using it :-) Sure. At least get it to switch to standby mode when not required. The problem with switching the monitor off with its own power switch is that you may be asking for problems, as some CRT monitors appear not to be designed with this in mind. I've had a (Sony G200) monitor fail twice at 14-15 months from new/repair with a PSU failure. Fortunately it's a three year warranty, but I don't want it to fail _again_. [... snip ...] you might save a few watts, maybe another 10W if you can manage without any disk spinning permanently. As it happens I have on my desk at the moment a spare 13GB 5400 rpm Maxtor HDD, which I guess is not untypical of hard disks installed in new systems in the last year. The power requirements are stated as 360mA 5V + 780mA 12V. These are steady state currents; the 12V startup current must be higher. Again you have to balance the wear caused by start-stop operation of a HDD against the power consumption. Typically current desktop HDDs are designed for 500,000 hours MTBF based on continuous operation but only 30,000 stop-start operations. Factor in the cost of lost service restoring data when a drive fails and the extra power consumption caused by continuous operation starts to look very cheap. The power consumption of the CPU is supposedly around 30W under load - modest compared to recent Athlons or 0.18 micron P4s. Yes. You pump up the speed, you ramp up the power requirements - cutting the fab size does help... the Northwood P4s (0.13 micron) use just over half the power of the corresponding 0.18 micron P4, despite having twice as much L2 cache built onto the processor die. A 15 LCD monitor will use 150W-200W less power than a 17 CRT which has a similar visible screen size. There's a worthwhile saving in desk space as well. I did the calculations a few months ago and it's actually a saving of around 100W (my 17 Iiyama claims to take 130W, 15 LCDs seem to take around 30W). I used this to show that replacing CRTs with LCDs purely to lower power bills wasn't yet economic. (And 1024x768 resolution isn't enough for me anyway :-) My estimate of the power saving was based on the Sony 17 CRT monitor. It actually uses more current on standby than a fully-active 15 LCD monitor I also posess. The other factor here is that the CRT monitor has such a high power on current surge that it will overload a 1000VA UPS to a dangerous degree (it will actually trip out a 650vA UPS supplying no other load - though the continuous in operation power draw is a lot less than this). For practical purposes, a LCD monitor has no startup surge at all. The CRT power on current surge appears to be associated with degaussing the screen; many people claim (possibly with some justification) that they've had floppy disks rendered unusable by this action even at some distance from the CRT itself. OK, it's not as important these days, but LCD monitors are going to be more floppy friendly as well. CRT monitors are undoubtedly better for some specific types of work - you can get more accurate colour rendition as well as higher resolution - that's why I still have the Sony monitor (and miss it when it breaks). On the other hand LCD monitors are completely free of the geometrical imperfections (wavy lines etc) which afflict even the best CRT displays. I do like the LCD because I can have it in front of a keyboard on a standard office desk (pushed against a wall) and still have about 15 of space to play with. With a 17 CRT the keyboard has to be placed quite close to the edge of the desk; ergonomically dangerously close if, like me, you like a decent wrist support, and want your face two or three feet from the screen rather than rubbing your nose against it. LCD prices have crept up in the last couple of months but you can still get a decent 15 LCD for about the price of a high-quality 17 CRT (though I agree you can get a budget 17 monitor for less than half that amount - with luck, even one that you might be able to bear looking at). Even 17 (1280x1024) LCDs are starting to look reasonably affordable. 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: electrical energy needed to run a LL-Test?
On Saturday 27 April 2002 21:26, Paul Leyland wrote: [... snip ...] They are still doing sterling service as fan heaters to keep my study warm (it's not easy living at a latitude of 52 degrees north ;-) and happen to factor integers by ECM while doing so.My 21-inch Hitachi monitor cost me the grand sum of 4 GBP (approximately 6 USD) and also keeps my study warm when it's switched on. Oh sure. (Actually I'm living on a windy coast at 55N, furthermore my house has electric storage heating so waste heat from computers during the winter months has a very low cost). My moral is: don't over look the benefits of the waste heat if you live in a climate where you have to spend energy to keep warm. If you live somewhere which requires the expenditure of energy to keep cool, the balance may lie elsewhere. Indeed. I have to switch off some (less productive) systems during the summer just to keep my indoor environment reasonably comfortable. I don't have air conditioning - the climate hereabouts doesn't often warrant it - but running AC to dump waste heat from computers would approximately double the effective cost of the energy consumed. 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: electrical energy needed to run a LL-Test?
On Friday 26 April 2002 09:52, Lars Fricke wrote: Hello! I was just curious, how much electrical energy my system here needs to run a LL-Test. Even if you don't let the system run if it is not used otherwise, it seems to be quite a lot. On my P-III 933 (WIN XP), Prime95 needs about 15W power (measured with an energy-monitor). That adds up to about 9 kWh for an exponent in the 13M range for this system here. If you have your system set up drop into standby mode when idle, there will definitely be a measurable increase in power consumption when Prime95 is active. Otherwise the increase in power consumption could be due to the FPU being active. Based on my experience with CPU core temperature monitors on PIII systems, I rather doubt that a PIII-933 FPU consumes as much as 15W above the normal load. I would think 15W extra for an Athlon FPU or P4 SSE2 would be reasonable. That does not even include the raised power-reqs for the power-supply fan due to increased thermal load because i did not run the test a long time... Hmm. PSU fans normally run continuously. In any case the consumption would be low - computer case/PSU/CPU fans rarely consume more than 0.2A 12V (2.4W), often significantly less than this. Perhaps it would be interesting to find the system thats optimal for LL-tests energywise ;) In terms of P90 CPU hours per kWh, we've got to be looking at P4 Northwood based systems - equipped with minimum peripherals. The main power saving that most people can make is to use an LCD monitor instead of a CRT. A 15 LCD monitor will use 150W-200W less power than a 17 CRT which has a similar visible screen size. There's a worthwhile saving in desk space as well. To get a real feel for this value for money question, surely you have to factor in the system depreciation cost i.e. the difference between the purchase and residual values plus the total cost of the power consumed over the working lifespan of the system. Since new systems depreciate very fast, whereas systems more than a couple of years old have virtually no resale value, keeping an old system running is often going to prove to be cheaper per work unit than buying a new system which might process work several times faster for roughly the same energy cost. In terms of sheer energy efficiency, there _may_ be an argument for P4M based notebook systems, but I think the total cost of ownership may be very high - not withstanding the difficulties that high-powered notebook systems often have in keeping cool when used for processor-intensive tasks. 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: Generalizations of Mersenne primes.
Ouch, HTML formatting:( On Thursday 25 April 2002 01:46, you wrote: htmldiv style='background-color:'DIVHi,/DIV DIVnbsp;/DIV DIVnbsp;nbsp;nbsp;nbsp;nbsp; Mersenne primes are of the form 2^p-1. The usual generalization is primes of the form ((k^p)-1)/(k-1), that is repprimes in base k. It is a well known result that when /DIV DIV2^p-1 is composite every prime factor has to be of the form 2np+1 for some n. Only when p is prime. Neither of the prime factors of 2^4-1 are divisible by 8n+1. In fact 2^n-1 is _always_ divisible by 3 when n is even, yet 3 = 2kp+1 only when k p = 1. Does there exist anbsp;similar restriction fornbsp;divisors ofnbsp;nbsp;repdigits?nbsp; Most results for Mersenne numbers generalize easily but this one doesn't seem to. Any thoughts?/DIV DIVnbsp;/DIV Oh, doesn't it? 3 is a special case, so ignore repunits with length 3. 1 (base 3) = 121 = 11 x 11 = (2.1.5+1)(2.1.5+1) [This case is VERY interesting. It is widely believed that the factorization of Mersenne numbers is square free, although AFAIK there is neither proof nor counterexample - if so then generalized repunits are obviously different in at least this respect!] 111 (base 3) = 1093 is prime 111 (base 3) = 88573 = 23 x 3851 = (2.1.11+1)(2.175.11+1) 1 (base 3) = 797161 is prime 1 (base 5) = 781 = 11 x 71 = (2.1.5+1)(2.7.5+1) 111 (base 5) = 19531 is prime 111 (base 5) = 12207031 is prime 1 (base 7) = 2801 is prime 111 (base 7) = 137257 = 29 x 4733 = (2.2.7+1)(2.338.7+1) 1 (decimal) = 41 x 271 = (2.4.5+1)(2.27.5+1) 111 (decimal) = 239 x 4649 = (2.17.7+1)(2.332.7+1) ... 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: Major slowdown need help!!
On Monday 22 April 2002 14:19, Jeff Woods wrote: [... snip ...] 2 pcs. My new system has an AMD Athalon 1400mhz processor and has been crunching the numbers in about 3 weeks or so and my per iteration time has always been around 0.098 to 0.099, Since I got my newest number (33238643), My per iteration time has gone up to 0.250 to 0.259 and my status tells me it wont finish until August 12th. Thats almost 4 months, any suggestions? That's about right for that processor on a number that size. You seem to have set the choice for which work to money-awarded winners if a prime is found, i.e. 10 million digits or more. Well - the server seems to have been fouled up most of yesterday (Sun 21st) - perhaps it issued a 10M assignment because it hadn't anything else left at the time? Should I or can I go to advanced menu and Unreserve the exponent and get another one? Up to you. Personally I think you need a lot of patience and/or a P4 processor to run 10M assignments. (Yes, I've done a few...) 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: Client configuration for a Duron?
On Tuesday 26 March 2002 15:32, Markus Landgren [EMAIL PROTECTED] wrote: Hi, What settings should I use in Prime95 on a 1 GHz Duron? Since there is no Duron in the options menu I tried Athlon, it seemed like the closest choice, but the performance I get is not quite as good as I expected compared to other people's benchmarks (about 25% slower). Should I switch to another CPU type in the options menu? Or should I use CpuSupportsPrefetch or something similar in local.ini? Try CPUSupportsPrefetch=1 in local.ini Also try Prime95 v22 which has much better CPU detection code. By the way, my other machine shows up as Unspecified type in my individual account report, even though it is correctly set as an Intel P4. Did I configure the client wrong in any way? Probably not. My P4 system appears to be shown in my individual account report as an Athlon. I think there may be a problem with the server report code. 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: Re: Mersenne Digest V1 #950
On Monday 25 March 2002 00:31, Bruce Leenstra wrote: Gordon writes: Now where on Earth does the figure of 210,000 computers come from?? This is the same mistake made on a previous news item: Both of them are misquoting an earlier study that determined a *Total* of 210,000 computers worldwide were participating in a distributed computing project of some kind. If you look back through the messages, the figure of 210,000 is quoted in the press release from Entropia.com - it relates to the number of client systems attatched to _all_ projects serviced by Entropia, not just GIMPS/PrimeNet. The other item was worse: it used the 210k to calculate ratios and percentages to compare the different projects. So of course all the numbers were useless, and the conclusions were idiotic. GIGO! (Garbage in garbage out for those who've forgotten 1970s acronyms) Regards Brian Beesley _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Test Message - please ignore
Hi, Sorry for wasting your time. I need to send this message to find out why some of the messages I've been sending to this list are being duplicated. Apologies... Brian Beesley _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Factors aren't just factors
Hi,
I seem to remember about 3.5 years ago someone (I think it was Chris Nash)
had done something similar eliminated a lot of Mersenne numbers.
Is it worthwhile mounting a formal attack on the Mersenne numbers between 20
million say 40 million using this technique? We're getting quite close to
this I think Chris would not have bothered with these, since they were so
far ahead of LL testing at that point (first tests around 6 million).
Regards
Brian Beesley
On Thursday 21 March 2002 00:21, Alexander Kruppa wrote:
Bruce Leenstra wrote:
As luck would have it, this is nearly what I am doing right now:
tempvalue = (q+1)/2
count = 1
while tempvalue != 1 {
if tempvalue is odd tempvalue += q
shiftright tempvalue
count++
}
v = count
I'm not sure I understand that code yet, but
I've crunched through all q 2^23; [...] The program is really starting
to slow down.
There may be a faster method.
Let f be a prime factor of the prime exponent Mersenne number M(p).
f | M(p) =
2^p == 1 (mod f) =
ord(2) (mod f) | p = (since ord(n) = 1 = n = 1)
ord(2) (mod f) = p.
Thus, f is a factor of M(p) if and only if the group order of 2 (mod f)
is equal to p.
On the other hand, ord(2) (mod f) divides f-1, since f is prime.
We can thus test whether f is a factor of some prime exponent Mersenne
M(p) by testing all prime divisors p of f-1 and checking if 2^p == 1
(mod f).
I add a quick hack to exemplify. Please don't take this code too
seriously. I made no effort to make it efficient, for example all odd
and not only prime f are tested and the trial division is pathetic, too.
An order of magnitude speedup would be possible.
But the basic algorithm is reasonably fast:
time ./ismersfac /dev/null
real1m7.907s
user1m7.710s
sys
0m0.040s
for f 1000 =~ 2^23.25 , on a K6-II 500Mhz.
#include stdio.h
unsigned int powmod(unsigned int a, unsigned int b, unsigned int m) {
unsigned int t = 0, mask = 131;
if (b == 0) return 1;
while ((b mask) == 0) mask = 1;
mask = 1;
t=a;
while (mask) {
t = (unsigned long long) t * t % m;
if (b mask) {
t = (unsigned long long) t * a % m;
}
mask = 1;
}
return t;
}
unsigned int ismersfac(unsigned int f) {
unsigned int fm1 = f-1;
unsigned p;
while ((fm1 1) == 0) fm1 = 1;
for (p = 3; p*p = fm1; p+=2) {
if (fm1 % p == 0) {
if (powmod(2, p, f) == 1) {
return p;
} else {
while (fm1 % p == 0)
fm1 /= p;
}
}
}
if (fm1 1) {
if (powmod(2, fm1, f) == 1)
return fm1;
}
return 0;
}
int main() {
unsigned int i, p;
for (i=3; i 1000; i+=2) {
if ((p = ismersfac(i)))
printf(M( %d )C: %d\n, p, i);
}
return 0;
}
_
Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: mprime, linux and 2 MB pages
On Tuesday 19 March 2002 10:09, Nick Craig-Wood wrote: On Mon, Mar 18, 2002 at 02:12:48PM +, Brian J. Beesley wrote: If the active data is already memory resident, TLB thrashing is not going to be an issue. The TLB (translation lookaside buffer) has very little to do with the Virtual Memory system. The TLB is used by the processor to cache the address translations from logical memory to physical memory. These have to be read from the page table RAM which is expensive - hence the cache. Ah, but ... frequently accessing pages (virtual _or_ physical) will keep the TLB pages from getting too far away from the processor; probably at worst they will stay in the L1 cache. The overhead of accessing from L1 cache is small compared with the overhead of accessing data from main memory, and _tiny_ compared with the overhead of accessing data from the page/swap file. When I was working on a DWT implementation for StrongARM I found that thrashing the TLB caused a factor of two slow down. The StrongARM system I was using had no virtual memory. If mprime is using 10 MB of memory say, then each page needs 1 TLB entry to be used at all by the processor - ie 2560 TLB entries which is way bigger than the size of the TLB in the processor (I don't remember what it is in x86 but on StrongARM it has 32 entries). To access each physical page the TLB has to be reloaded from the page tables which is an extra memory access or two. If you use 2 MB pages then there are only 5 pages needed and hence the TLB will never need to be refilled and hence some speed gain. Don't you _need_ to have at least enough TLB entries to map the whole of the processor cache? (Since without it you can't map the cache table entries...) The K7 (Athlon) architecture is designed to support at least 8MBytes cache, even though AFAIK no Athlons with more than 512KB cache have been supplied. Intel have supplied Xeons with 2MBytes cache; I can't remember offhand what the design limit is... Anyway, here's the point. I'm running mprime on an Athlon (XP1700) with a very large exponent (~67 million); the virtual memory used by the mprime process is 42912 Kbytes = 10,000+ pages. The speed it's running at suggests that any performance loss due to TLB thrashing is small, since the extra drop beyond linearity is only about what one would expect from the LL test algorithm being O(n log n). Whatever effect TLB thrashing may or may not be having, it doesn't look as though it's having a dominant effect on mprime. I think this would make a real difference to mprime - what percentage I don't know - at the cost of on average 1 MB of RAM extra. I wouldn't mind _doubling_ the memory footprint, if we got a _significant _ performance boost as a consequence. BTW why does this argument apply only to mprime? Surely Windows has the same underlying architecture - though obviously it's harder to get the Windows kernel changed than linux. 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: mprime, linux and 2 MB pages
On Monday 18 March 2002 10:21, Nick Craig-Wood wrote: There has been some discussion on the linux kernel mailing list about providing 2 MB pages (instead of 4kB ones) to user space for the use of database or scientific calculations. It seems to me that prime95/mprime would benefit from this enormously - it should reduce the TLB thrashing to practically zero and hence speed up mprime by some unknown amount. Is this true? Should we put in our plea to the developers? Other people may and probably will disagree, but I think it will make very little if any difference for most applications. The point is that mprime should normally be running on a system in a way which means that all its active data pages are in memory. Having active data paged out will cause a hideous performance hit. If the active data is already memory resident, TLB thrashing is not going to be an issue. Applications written in such a way that rarely-accessed data is stored in virtual memory with the intention that the OS allows it to be paged out are a different matter - larger page sizes would undoubtedly help those, at least to some extent. If the page size is going to be changed at all, there is a lot to be said for using the same size pages as AGP hardware - 4MB I think - there have already been some issues on some Athlon (K7) architecture linux systems caused by incorrect mapping between linux virtual pages and AGP address space; obviously using the same page size removes this source of confusion. One factor with shifting to a much larger page size is a corresponding decrease in the number of pages available to the system - a 32 MByte system will have only 8 4MB pages resident in real memory at any one time. Since page access rules are often used to protect data from accidental modification by rogue pointers etc., a big reduction in system physical page count is a distinctly mixed blessing. As a project I don't think we need to make reccomendations one way or the other. As an individual I would say either go with AGP or stick with the status quo; and I think the status quo is better suited to systems with small to moderate amounts of physical memory (certainly those with less than 256 MBytes). 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: Mersenne primes
On Wednesday 13 March 2002 00:52, danny fleming wrote: I saw recently a method of locating a Mersenne Prime. Please tell us more! We'd all like to know of any better (less computationally expensive) method than computing the Lucas-Lehmer sequence for those Mersenne numbers which cannot be easily shown to be composite by finding a factor. Does anyone know if it includes the expected number of Mersenne Primes to a given integer? The usual number of primes to any positive integer n is n/ln(n)-1. There are more accurate estimates than this of the number of primes up to any given limit, or between any two specific limits, than this. See for example Riesel, Prime Numbers and Computer Methods for Factorization (2nd edition), p.50ff. I'm not aware that there is any specific formula for the number of Mersenne primes up to a given limit. In fact the much weaker assertion that there are an infinite number of Mersenne primes still remains to be proved. However the (rather limited) experimental evidence to hand does not disagree with the unproved theoretic assertion (apparently based on heuristics rather than solid logic) that there should be _on average_ exactly one Mersenne prime in the interval (2^x,2^(x+y)) where y is Euler's constant gamma = 0.5772... 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: LL test efficiency
On Wednesday 27 February 2002 06:26, Steve Harris wrote: For those of you interested in optimizing efficiency of LL testing: We are approaching first time tests of 15.30M exponents, at which point the Prime95 program will start using an 896K FFT. However, the P4-SSE2 section of the program will start using that larger FFT size at 15.16M exponents, making it (relatively) inefficient to test exponents between 15.16M and 15.30M on a P4. Since the Primenet server doesn't take this into consideration when assigning exponents, I would suggest you all have enough exponents queued up on your P4s before the server reaches 15.16M to keep them busy until it reaches 15.30M. I know there are other ways around it, but that is the simplest. And I replied: Whilst I appreciate Steve's motives in making this suggestion, I have a philosophical problem with it. If a few people hog these exponents, other people with an equal need to economise will be unable to get them. Overall I don't see that there is much gain, whilst there is scope for resentment against the hoggers in a similar (but possibly less extreme) way to the resentment felt against poachers of first-time LL test assignments. On reflection I can see that there is merit in Steve's idea (provided that restraint is used i.e. not grabbing more work than is neccessary to bridge the rather small exponent gap). I wish to publicly apologise to Steve for any implication that he might be encouraging users to hog exponents. 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: error: Another mprime is already running!
On Friday 01 March 2002 00:40, Mary K. Conner wrote: 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'll have a look at the code see what I can come up with. 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. That would be a crude and surely unusual way of economising. un*x gurus normal Good Practise to keep executable binaries and scripts seperate from the data, as opposed to the Windows practise of keeping them all mixed up (which makes it much more awkward to set a proper security policy). I think practically every user setup script on unix-like systems (including linux) adds $HOME/bin to $PATH so the obvious place to store mprime is to create a bin directory in your home directory (if it doesn't already exist) put the binary executable in there. On a multi-cpu system you can then set up a directory for each CPU. None of these working directories need to, or should, contain a copy of mprime. So long as each instance has its own copy of local.ini, there will be no problem with Another copy is already running. Of course it is counterproductive to run more instances of mprime than there are processors in the system. (Real processors or virtual processors when running on the new Xeons with hyperthreading? I don't know ... but apparently Windows thinks a dual-processor system has four CPUs ... obviously there is scope for confusion here, especially if you have to rely on what the OS tells you, rather than being able to take off the cover and eyeball the hardware!) 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: Two L-L tests at once?
On Thursday 28 February 2002 22:03, Guillermo Ballester Valor wrote: Hi, On Thu 28 Feb 2002 22:19, Brian J Beesley wrote: [ snip ] The difference here is that your method generates memory bus traffic at twice the rate George's method takes advantage of the fact that (with properly aligned operands) fetching the odd element data automatically fetches the adjacent even element data The streams would be alternated : stream0_data(n) , stream1_data(n), stream0_data(n+1), stream1_data(n+1) When fetching data(n) for a stream we also get the other Yes, this scheme does seem to work The memory bottleneck was the first thing I thought, and I was near to discard the idea when I realized that the trig bata would be the same, and the required memory access would be less than double the single stream scheme If a double stream version cost less than double the single one the we can speed up the project a bit On Friday 01 March 2002 00:37, George Woltman wrote: Well, that would be true if SSE2 had a multiply vector by scalar instruction That is, to multiply two values by the same trig value, you must either load two copies the trig value or add instructions to copy the value into both halves of the SSE2 register I can't see that being a major problem Surely there's only one main memory fetch to load the two halves of the SSE2 register with the same value, and surely the loads can be done in parallel since there's no interaction ( M - X; then X - R1 X - R2 in parallel, where X is one of the temporary registers available to the pipeline) On Thursday 28 February 2002 21:20, Steinar H Gunderson wrote: Testing a number in parallel with itself is obviously a bad idea if there occurs an undetected error :-) Sure But the only way there would be a problem here (given that the data values are independent because of the different random offsets) is if there was a major error like miscounting the number of iterations This is relatively easy to test out I'm sort of marginally uneasy, rather than terrified, about running a double-check in parallel with the first test on the same system at the same time Also, I think most people would rather complete one assignment in time T rather than two assignments in time 2T with both results unknown till they both complete Against this is that Guillermo's suggestion does something to counter the relatively low rate at which DCs are completed Regards Brian Beesley _ Unsubscribe list info -- http://wwwndatechcom/mersenne/signuphtm Mersenne Prime FAQ -- http://wwwtasamcom/~lrwiman/FAQ-mers
Re: Mersenne: /. article
On Wednesday 27 February 2002 05:07, you wrote: Well anything that can increase the speed of TF by even a wee amount is welcome by me. Unfortunately there is no impact on trial factoring. The technique suggested is an improvement requiring specialized hardware of a technique which is only effective on numbers which are exceptionally hard to factor. Trial factoring would still be employed to dig out any small factors, as it's a great deal more efficient to remove these before resorting to more advanced techniques. The specialized hardware can, of course, be emulated in a general-purpose computer. The paper is not particularly clear on whether an implementation of the new algorithm would be any more efficient than the existing NFS method (which is also defined in terms of specialised hardware) when a general-purpose computer emulation is employed. I guess that depends a great deal on the quality of the emulation. In terms of the work on Mersenne numbers, assuming the theoretical gains predicted in the paper can be realized, then the main effects would be: 1. an increase in the rate at which the NFS people are factoring awkward Mersenne numbers; 2. a possible corresponding decrease in the depth to which it's worth proceeding using ECM before handing awkward numbers over to the NFS squad. 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: LL test efficiency
On Wednesday 27 February 2002 06:26, you wrote: For those of you interested in optimizing efficiency of LL testing: We are approaching first time tests of 15.30M exponents, at which point the Prime95 program will start using an 896K FFT. However, the P4-SSE2 section of the program will start using that larger FFT size at 15.16M exponents, making it (relatively) inefficient to test exponents between 15.16M and 15.30M on a P4. This is undoubtedly true. However a P4 should still run tests in this range faster than anything else (even adjusted for clock speed). Since the Primenet server doesn't take this into consideration when assigning exponents, I would suggest you all have enough exponents queued up on your P4s before the server reaches 15.16M to keep them busy until it reaches 15.30M. I know there are other ways around it, but that is the simplest. Whilst I appreciate Steve's motives in making this suggestion, I have a philosophical problem with it. If a few people hog these exponents, other people with an equal need to economise will be unable to get them. Overall I don't see that there is much gain, whilst there is scope for resentment against the hoggers in a similar (but possibly less extreme) way to the resentment felt against poachers of first-time LL test assignments. I would suggest instead: (a) if you have both a P4 and a something else running LL tests and you get an exponent in an inefficient range on the P4 system, swap assignments between the P4 and the something else. (b) pick up exponents at a time designed to avoid exponents in a range you don't want to test. My guess is that if you pick up assignments between 07:00 and 10:00 GMT then, for the next month or so at least, you're very unlikely to get exponents 15,160,000. By then you will probably be able to switch to picking up around 05:30 GMT and be very unlikely to get an exponent less than 15,300,000. Unless lots of people start following Steve's advice... I've suggested before that the client/server communication should include a preferred exponent range so that, when the server is allocating a new assignment, it tries to pick one within the range requested by the client rather than just assigning the lowest available exponent. I think this would remove the problem identified by Steve, and also any possible friction caused by adoption of Steve's suggestion. I'm well aware that there are practical problems in implementing my suggestion. 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: /. article
On Wednesday 27 February 2002 19:28, Justin Valcourt wrote: Which brings up something that I just wondered about. As far as FFT operations go for LL and DC, if some crazy person who had millions to spend (ie we are talking pure theory here) to hire a chip maker, could a coprocessor be made that specializes in FFT operations? Or do the optimazations in the code that use SSE2 on P4s pretty much equate to the same thing? Or maybe someone has already made such a chip? SSE2 is essentially a limited form of vector processing. Vector systems that can process a very large number of operands in parallel already exist (in very expensive supercomputers). Alternate hardware approaches to the problem of computing x^2-2 (mod 2^p-1) involving very long word length are possible. With a long enough word it's possible in principle to compute x^2-2 (mod 2^p-1) in a _very_ few clocks (possibly as few as two), without even having to resort to FFT. The problem is that practical hardware would have to contain an enormous number of gates - of the order of hundreds of thousands or even millions of times more gates than there are in a Pentium 4 - and this specialised hardware would have somewhat limited applications, thus making it commercially unviable to develop or produce. Unless No Such Agency (or someone else with equally deep pockets) would like to buy a few million of them to help them crack commercial cyphers? Part of the fun of this project is doing something which is so leading edge with relatively cheap, mass-produced consumer hardware! 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: P-1
On 23 Jul 2001, at 19:13, CARLETON GARRISON wrote: The name of the game is validate - by duplication. You cannot make a case without duplicating the result. This is to safeguard against the many gremlins that can occur - faulty overclocked CPUs, etc. But the only thing that goes wrong if a factor is missed is that a LL test gets run unneccessarily. It simply isn't worth rerunning all the factoring on the offchance that a small number of runs will glitch miss a factor. If the error rate of LL tests is about 1% then P-1, being much shorter, should be less than 0.1%. Trial factoring doesn't use the FPU much, so the processor will probably run much cooler errors may be even less likely than that. The point is that _even if factoring is omitted altogether_ LL DC will still eliminate a composite number. The purpose of doing factoring is to _save time_ by eliminating LL testing for those numbers where finding a factor is cheap enough to be cost effective. If someone finds a factor, someone ofer a PrimeNet can do a single division case and confirm the result. The server already does that automatically! The time required to _check_ a factor is miniscule. 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: 33mio exponents
On 30 Jun 2001, at 20:16, Guido Lorenzini wrote: 1st observation: the beerman's computer named SKA4 seems to work simultaneously on 4 33mio exponents, since each exponent is getting iterations: how it come? If any Cpu is best working on just one copy of prime95, even a dual cpu PC should have 2 computer ID...You may see the same situation with DEJEFLATERIC of netconx, but, once again, these are just examples. This looks odd, but in fact I can set up as many systems as I like with the same computer id, making many systems appear to be one. I can also confuse the issue by changing the computer id on a single system, making one system appear to be many. 2nd: Sometimes it happens that an exp. is assigned to an unspecified computer ID (for example, the account kpgcfd, has some). Is it possible? Yes. When I joined the project more than three years ago, blank computer IDs were very common. The server software has been changed to automatically assign computer IDs to new systems being set up when the user has not set the computer ID himself, but there are still a number of systems running with blank IDs which have been active since before this change was made. 3rd: Net_Force seems to have some wonderful machines, called (properly!)10MIL-X: they are able to test (or factoring) dozen of 33mio exponents in 2 months time or more! Any information about the processor of these machines? Or is it relevant the fact bits? (60 or I don't know what's going on here. The fact bits just means that when the assignment was given out, that's the factoring depth that was done. For exponents of this size, you're supposed to complete factoring to 68 bits before starting the LL test. 4th: netconx reserved 2,325 33mio exps on its computer ID DEJECHRISTIA, most of them with 60 fact bits or less. It started getting 'em on June 20th at 4:59 AM, one each two minutes, till June 23th at 12:07 PM. Now it may be too long to explain but this mass of 33mio exps. seems to be bounced like a ball from an account to another (e.g. from kpgcfd, ID mac_233, on May to netconcx by now); then these exponents, assigned in June to netconx to computer ID DEJECHRISTIA, were assigned to the same account netconx, but to a machine called BART, in April 7th. I really do not understand what's going on... Is there anybody who may give me do not understand what's going on... Me neither. I reckon that big block of exponents expired got picked up again. The only thing that seems to make any sense is that someone is running in a Beowulf cluster that happens to have no net connection (maybe because it's running in a highly secure environment), so they're using one system to collect work then farm it out locally. Anyway it's doing no harm, so long as they leave a few assignments for other people to pick up! It will be interesting to see what happens in a few months, when (if my guess is true) there may be a big block of results coming in more or less at the same 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: Factoring on a P4 - CORRECTION
--- Forwarded message follows --- From: Brian J. Beesley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date sent: Fri, 22 Jun 2001 18:46:43 - Subject:Re: Mersenne: Factoring on a P4 Copies to: [EMAIL PROTECTED] On 22 Jun 2001, at 13:12, [EMAIL PROTECTED] wrote: For some reason, I am at a loss to explain, a v21 P4 1.4 GHz factors significantely slower that a P3 v20 700MHz. Is there a reason, and solution, for this? Good question. AFAIK George has done nothing to the factoring code. You will see a big speed loss if you compare factoring under 2^64 with factoring over 2^64 on _any_ system - that's simply explained by triple- precision integer arithmetic being much slower than double-precision integer arithmetic. Intel's development for the P4 was very much geared towards making SSE2 work well. Unfortunately this left less room in the silicon for some of the ordinary integer stuff on which the factoring code (but not the LL testing code) in Prime95 depends. If memory serves me right, the 32 bit by 32 bit integer multiply instruction was badly hit by this. Consequently the factoring throughput of a P4 would be expected to be considerably less than that of a PIII running at the same clock speed. I would expect that a PIII-700 and a P4-1400 would probably run factoring at about the same speed. Earlier I wrote: For now, those who are lucky enough to have P4 systems are probably best advised to stick to LL testing (and trial factoring - which will not be affected by any inefficiency in the P4 integer instructions), leaving trial factoring to those with slower systems. Slip of the brain, I'm afraid. I meant LL testing (and P-1 factoring... Incidentally ECM ought to run pretty well on the P4, though there may be some more optimization to come for the very small run lengths typically used by ECM. 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: Proth observations
On 22 Jun 2001, at 13:42, Gordon Bower wrote: After seeing a post on this list a few weeks ago I decided to branch out and try a few ranges from Michael Hartley's page looking for k*2^n-1 primes. I must say there is a bit of a thrill in actually discovering a new prime every day I run the program instead of proving two numbers a month composite. :) Yes, it does make a change. Anyway, a few curious observations I made, which surprised me: I have 2 computers, a P2-350 and P3-500. The program executes nearly 2 1/2 times as fast on the latter as on the former with nothing else running. Apparently the Proth code takes advantage of a lot of P3 features? Yes, Proth 6.6 has prefetch code for PIII and Athlon CPUs. With the same version of prime95 and the same version of proth on each computer, if you run them both at the same time, under Win2000 proth gets a higher priority and all the processing power, while under NT4, it's the other way round, and prime95 has to be stopped or have its priority reduced in the ini file to not smother proth. Curious. (Why run them both at once, you ask? If the computer is going to be on all night anyway, it'd be idle when proth finished a range unless prime95 was ready to take over as soon as proth was done.) There is a marked difference in the process timeslot allocation algorithm between NT4 W2K. (IMHO neither is as effective as the equivalent function in linux 2.2, further improved in linux 2.4, but that's a different story!) Also between Win95 and Win98. '95 behaves like NT4, and '98 behaves like W2K. Well, only on uniprocessor systems, since '9x/ME don't support SMP at all, but I think you get the drift? My strategy is: (1) run Proth at medium priority in factoring only mode to eliminate candidates with small factors; (2) on the same system, run PRP at low priority to check the survivors from stage 1 for probable primes; (3) on a different system (normally running Prime95), run Proth at medium priority to verify the probable primes. (If you don't have a spare system it would be best to do this in a seperate directory so as to save keep changing the Proth setup!) (1) takes a lot less time than (2) so even if (2) stops temporarily that's not a problem. Not much survives (2) so run (3) takes little time, even though it's much slower per candidate than the others! BTW so far _every_ probable prime I've found using PRP has been accepted as a genuine prime by Proth, though this is certainly not guaranteed. I assumed that one value of k was pretty much the same as any other as far as execution time and the chance of finding primes. To my surprise this turned out not to be so: On the P3-500, for most 650k750, it takes about 5 hours for 16000n32000 and 12 hours for 32000n48000 -- but for k=701 it took less than 2 and just over 6 hours, respectively. The phenomenon is reproducible, doesn't seem to be an artifact of other programs or reboots or suchlike. Any number theorists care to explain what is special about k=701 that makes it easy to check for primality? If you break the run down as above you will see that some values of k yield a much smaller proportion of candidates for psuedo-prime testing than others. Or, to put it another way, some values of k give a much higher percentage of k.2^p-1 with small factors than others. Conversely the slower values of k tend to yield a lot more primes than the faster ones. In fact, if your trial factoring strategy is reasonable, your average rate of discovery of primes will not depend much on the value of k - though it certainly will depend on the average value of n! k.2^p+1 behaves similarly. In fact there are some values of k for which it is _proved_ (mathematically) that there are _no_ k.2^p+1 primes, even though the lowest value of k for which this is true is still uncertain. (Or at least there was still work in progress last time I checked.) You may care to look up the Sierpinski Problem if you're interested in this. A fun project. Now if Michael would just put a stop to that pesky server error I could submit a half dozen more primes to him... :) Yeah, I finished up my raft of blocks a couple of days ago, can't get any more can't report results. No response to mail messages either. He may have gone on vacation. 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: Factoring on a P4
On 22 Jun 2001, at 13:12, [EMAIL PROTECTED] wrote: For some reason, I am at a loss to explain, a v21 P4 1.4 GHz factors significantely slower that a P3 v20 700MHz. Is there a reason, and solution, for this? Good question. AFAIK George has done nothing to the factoring code. You will see a big speed loss if you compare factoring under 2^64 with factoring over 2^64 on _any_ system - that's simply explained by triple- precision integer arithmetic being much slower than double-precision integer arithmetic. Intel's development for the P4 was very much geared towards making SSE2 work well. Unfortunately this left less room in the silicon for some of the ordinary integer stuff on which the factoring code (but not the LL testing code) in Prime95 depends. If memory serves me right, the 32 bit by 32 bit integer multiply instruction was badly hit by this. Consequently the factoring throughput of a P4 would be expected to be considerably less than that of a PIII running at the same clock speed. I would expect that a PIII-700 and a P4-1400 would probably run factoring at about the same speed. For now, those who are lucky enough to have P4 systems are probably best advised to stick to LL testing (and trial factoring - which will not be affected by any inefficiency in the P4 integer instructions), leaving trial factoring to those with slower systems. Conversely, if you need a system with optimal integer performance, you'd be much better advised to buy a system based on a fast Athlon processor than a system based on a Pentium 4. Athlons running integer code even run much cooler; the FPU turns itself off when it isn't needed, leading to a big drop in current consumption. BTW there was an unreasonable acceleration of trial factoring between the P5 architecture (Pentium Classic/MMX) and the P6 architecture (Pentium Pro / PII / PIII / Celeron / Xeon), so you can't simply assume that Intel doesn't care about integer performance! Regards Brian Beesley _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
