How sure are we that these higher tests done with the beta client are correct?
I'm not sure these should be added until it's stable.
Maybe the memory is not seen as enough for a 768K FFT?
Apart from that, I finished all the last 23 tests of Nuri's list.
Excep 3 tests that gave me the error message shown somewhere above, all factors were found.
Sieving depth was 49, granted memory 512MB.
Thanks everyone for your testing. I'm now writing the zero-padded 640K FFT code, the lack of which is causing the current errors. This will take at least a week.
Nuri, try dropping to 48 bits instead of 49. This will probably eliminate the skipping of tests.
Y'all are welcome to continue using the pre-beta code. I'll post a new version when I can.
I tried it too.
A total of 70 k/n pairs tried, 30 pairs with 48 and 40 pair with 49. All had 0 (two times PRP) setting.
I'll also try 1 times PRP with the skipped tests later when I'm done with the batch I have.
This might be wrong, but what I see is:
All of the pairs where k =< 21181 (i.e. 4847, 10223, 19249, and 21181) are tested without a problem for both 48 and 49.
All of the pairs where k >= 22699 are skipped for both 48 and 49.
PS: If 1 times PRP does not work either, I'm planning to force the client with predefined B1 and B2 values (Pminus1=.....).
BTW, 235703760784331778069847 | 19249*2^6405242+1
Last edited by Nuri; 06-14-2004 at 06:23 PM.
Nuri, using a setting of 1 will half the amount of time the program would want to allocate to P-1. So a setting of 1 would cause more tests to be skipped and not less. But please do go ahead and see what happens. I just wanted to let you know what you should expect.
Thanks garo. Yes, I know it should normally behave like this.
I consider this as a help in beta testing, and I feel there might me something wrong with the FFT size selection script (not necessarily, but probably).
It is not normal that everything where k >= 22699 are skipped for both 48 & 49, and everything where k =< 21181 are tested for both 48 & 49.
In the end, if n is similar, the difference in digits between the highest k and lowest k is not more than 2 (3?). On the other hand, pairs with smaller n are tested with success, whereas larger ones are skipped (or vice versa).
Anyways, trials with 1 setting might result in same (or different) pattern. I feel like both might lead to useful conclusions.
Just out of curiosity.
Is there any progress on the client, or is this the final version?
Is anyone testing/using the current version?
I'm still working on the code. I'm not near a final version. There is plenty more code to write and test. When it is done it can be added to the old P-1 factorer.
Your testing was useful in finding several minor problems. The current client should be stable enough for you to use in further factoring. I'll post improved clients as they become available.
It's getting lonely here
Nuri, hc_grove & dmbrubac - the black sheep of SOB
I guess nobody has the right to complain about P-1 lagging behind.
That doesn't mean they won't though!Originally posted by Nuri
I guess nobody has the right to complain about P-1 lagging behind.
The bad thing is that I only have one P4.
All the computers in the Condor Pool are P3s, which are a lot better for sieving. With a little luck, there will be P4 Celerons in the Pool someday. Then I can devote them to factoring...
Breakdown of ranges between 5,870,000 and 6,440,000
I'm really waiting for George's new client. That should up the P-1 speed a bit. I 'll probably put in a P4 for some time when the new client is released. And I think some others from TPR will also join in to help TPR improve its factoring rankings.
So gimme about a week or so....
Last edited by garo; 06-27-2004 at 02:45 PM.
OK, here's a new beta to try. It is much more thoroughly tested and supports those so-called zero-padded FFTs. Yes, it is still SSE2 only.
ftp://mersenne.org/gimps/sobpm1.zip
If you Windows guys don't find any problems then I'll build a Linux version.
Got a crash right at the start - well, right at the start of the factoring, to be specific. Without a worktodo.ini, the program starts.
The last output is "Chance of finding a factor[...]"
Then, I get "instruction 0x004094f7 tried to write on memory segment 0x0110d000..." (the text might not be exact, bur the values are - maybe they help you).
Using WinXP SP1 (german) on a P4c 2.4 GHz
That doesn't make sense. Without a worktodo.ini the program should just idle. Can you double-check to see what worktodo.ini file it might have found. Also, try deleting old save files - they may not be compatible.
Ok, I did not express myself in a clear way.
Case 1 (worktodo.ini does exist):
Crash as described (basically, it also starts here (naturally))
Case 2 (worktodo.ini does not exist):
program starts, but does nothing / idles --> no crash (so far)
when creating worktodo.ini and selecting "Continue" --> See Case 1
What is the first line in worktodo.ini?
Pfactor=24737,2,6704023,1,49,0
Sorry for forgetting to report that.
Guess I had other things in mind: wrote an exam today - the last of this semester!
edit:
The next don't work, either:
Pfactor=19249,2,6704042,1,49,0
Pfactor=22699,2,6704110,1,49,0
Using the last version (SOBPM1.EXE - HE1), it works...
Last edited by Mystwalker; 07-30-2004 at 10:40 AM.
The previous version (HE-1) has worked for me so far, and I even found a new factor with, but now it has started failing. (I use the Linux version so I can't try the new verson yet)
When I start the program with `./mprime -m` and enter 5 to resume factoring, it runs for a while but then it segfaults:
The first line of my worktodo.ini reads:Code:Your choice: 5 Mersenne number primality test program version HE-1 Starting P-1 factoring with B1=60000, B2=750000 Chance of finding a factor is an estimated 1.68% P-1 on 24737*2^6825703+1 with B1=60000, B2=750000 Using FFT length 768K zsh: segmentation fault ./mprime -m
It's configured to use a maximum of 384 MB of RAM (I have 512).Code:Pfactor=24737,2,6825703,1,48,0
OK I tried the same and I get an error too.
In the exception information section the code was: 0xc00000005
Address: 0x0000004094f7
The same address I had...Originally posted by garo
Address: 0x0000004094f7
The debug version worked great, but the release version crashes. Go figure.
I tracked it down and fixed. Please try downloading again. Thanks.
Looks good - just started processing.
Let's see if everything else works as expected. *testing*
edit: I checked some old tests with known factors - all of them were found.
Meanwhile, I've started the search for factors no man has seen before.
Last edited by Mystwalker; 08-01-2004 at 07:15 AM.
Is there any way to determine what FFT size is going to be used a priori?
This way, one could concentrate on k/n pairs with lower FFT size (e.g. 521K instead of 768K), which saves approx. 30% time.
As each test is done independently, there wouldn't be an effort-increasing side-effect...
It isn't an easy formula for computing the FFT size. But maybe I can get close.
The formula is based on n/FFTLEN + log2(k)/2. So if you start with smallest k and find where it switches from 512K to 768K, then you should be able to figure out the n value that a different k value would switch over.
This is complicated slightly by the zero-padded 640K FFT. Sometimes this will be used before switching to the 768K FFT. IIRC, the zero padded FFT looks at 2*n/FFTLEN - 0.3.
George,
Any chance of a linux version?
Thanks.
I tried running the new version of the P-1 factorer but it kept crashing at i believe exactly 50% of the way through stage 1. anyone else have this problem? Any ideas what i might be doing?
6881007 4847 are the numbers I'm using plus 48 for sieve depth and 256 for mem. I tried running for much smaller numbers and it seems to be going fine.
I've also tried with a few other values above the prp boundary that seems to tbe the only KN pair that has the problem could someone else try it out and see if they get any sort of an error.
Last edited by Keroberts1; 08-12-2004 at 03:35 PM.
4847*2^6881007+1 completed P-1, B1=50000, B2=537500, WZ1: B21DFCCE
Did this problem happen after a long run? If so, maybe there is a memory leak. Use task manager to see if memory used is significantly increasing over time.
Yes. Download ftp://mersenne.org/gimps/sobpm1.tgzOriginally posted by garo
Any chance of a linux version?
It is totally untested - I don't have a linux P4 machine.
i should read the forum more! i just worked on making a new factorer and come here to share the good news and george has been working on it for the past few months.can't complain... it's my own fault i've let my job consume all my time. hopefully that can stop for a bit.
any interest in testing my inferior, old command line style factoring client with these new improvements?
i have a windows build. email me at lhelm@seventeenorbust.com if you'd like it. oh, i've also been covertly testing out the regular SB client with this code for awhile. should be releasing that soon once we test a few more large numbers and get matching residues. everything looks good, i just didn't want to get too much buzz going until the client was validated and closer to release.
Cheers,
Louie
have you tried setting it on secret testing? a significantly faster client could speed up the double check and there would be no risk since its only seeing if the residues match anyways. I'd be willing to put a couple machines towork on the secret account ifi could test the new cient. I only have AMD amchines though and only a couple. I could probably manage a few hours a day on a single P4 also but thats only a few hours a day and isn't likely to make much differance. I don't use it at all now cause i rarely have time to finish many secret tests. I only use it for the occasional factoring.
I think most of the folks here would prefer to use the old command line style client. It has some advantages, like it understands the SOB data files and supports settings other than 1.0 and 2.0 for that-parameter-I-can't-remember-the-name-of.Originally posted by jjjjL
any interest in testing my inferior, old command line style factoring client with these new improvements?
Thanks again to all the P-1 testers here. You found a couple of key bugs that made Louie's integration job much easier. I like testing early versions of changes to the FFT code with P-1 as a mistake (you miss finding a factor) is not a catastrophe (compared to missing a prime find).
Louie any chance of making af Linux version of your new factorer?
I would sure like to use it when I get back home tomorrow and start factoring another range.
sbfactor.exe 7000000 7005000 47 1.5 1 1 + 256
Is this correct?
Please PM me.
Regards
Hi George,
I got a segmentation fault on running the mprime version you posted. The following is the size of the binary :2326620 and the timestamp: Aug 13 16:14 (Timezone +2 GMT).
The worktodo consisted of only one line:
Pfactor=21181,2,6799052,1,48,0
This works on Windows but on linux this is what I get:
Mersenne number primality test program version HE-2
Starting P-1 factoring with B1=50000, B2=575000
Chance of finding a factor is an estimated 1.26%
P-1 on 21181*2^6799052+1 with B1=50000, B2=575000
Using FFT length 768K
Segmentation fault
I know you are probably busy with the cleanup so take your time fixing it.
Louie,
I have about 3 machines working on supersecret right now. I also noticed you stated you had a new client for sob.
If you'd like I could install the new client it on the supersecret boxes I have running. Won't use it on normal prp's or distribute promise.
E-mail me a copy and directions if you wish
mustang (no spaces here all one word) 35157L @ yahoo dot com
Try the new one. The data segment was not properly aligned.Originally posted by garo
I got a segmentation fault on running the mprime version you posted.
It is working for me now. I have not tested it with any known factors yet. Since the range I'm doing will not be done any way, I do not think much will be lost. Will report back after finishing the range to see if any factors were found.
One question for you George. I know you answered something similar on the mersenneforums recently but I'm didn't understand your answer fully.
While testing 28433*2^6799153+1 your program chose the 768K FFT and while testing 4847*2^6799167+1 it chose the 512K FFT. Can you shed some light on why even though the difference in the number of digits in the entire number was minimal (in fact the second number was bigger) a smaller FFT was chosen. I presume it has to do with the "k" value and "k" has a much greater influence on the FFT than the "n" value. Can you briefly explain the math behind it?
Lastly, in the version I'm testing, I tried the tests with factoring depths of 48 and 49. I got B1 and B2 bounds of 40,000/50,000 and 430,000/575,000 respectively. However the amount taken to complete these tests with such different bounds weer almost the same. Does this have to do with zero-padded FFTs? Or is there something wrong with this picture? Here is the relevent log snippet:
Are we getting something for free here? Atleast in stage 1 we are getting an increase of 10,000 in the bounds with a 1% increase in time.Code:Starting P-1 factoring with B1=40000, B2=430000 Chance of finding a factor is an estimated 0.911% P-1 on 33661*2^6799128+1 with B1=40000, B2=430000 Using FFT length 768K [Aug 18 12:47] 33661*2^6799128+1 stage 1 is 13.93% complete. Time: 299.320 sec. [Aug 18 12:52] 33661*2^6799128+1 stage 1 is 27.79% complete. Time: 299.368 sec. ..... Mersenne number primality test program version HE-2 Starting P-1 factoring with B1=50000, B2=575000 Chance of finding a factor is an estimated 1.26% P-1 on 33661*2^6799128+1 with B1=50000, B2=575000 Using FFT length 768K [Aug 18 13:04] 33661*2^6799128+1 stage 1 is 51.35% complete. Time: 302.847 sec. [Aug 18 13:09] 33661*2^6799128+1 stage 1 is 65.21% complete. Time: 302.871 sec. [Aug 18 13:14] 33661*2^6799128+1 stage 1 is 79.07% complete. Time: 303.078 sec.
Posting Permissions
Reply With Quote
