20080326, 21:22  #23  
May 2007
Kansas; USA
2×5×1,039 Posts 
Quote:
This is good news because the base used for the calculations (12000candidate file) now has more candidates meaning that the divisor for othersized files increases, which reduces the testing time for those files. Here are corrections based on your exact # of candidates: No change to the smaller range because I used nrange calculations, not # of candidates. It should still take 8.027126 days to do n=100K260K for a file with 12969 candidates. For your larger range, it would actually take LESS time even if the filesize was still 25000 candidates because the base used for calculating it contained a smaller # of candidates. But it'll be even MORE LESS (lol) since it contains < 25000 candidates. So...it should take you 22674/12969*8.027126 = 14.03401 days for a file with 22674 candidates. For an average sized file, it would take 19563/12969*8.027126 = 12.10846 days for an averagesized file of 19563 candidates. 12 vs. 13 days is more in the ball park and is about what I'd expect for a drive 3 file at n=~380K so not far from what we had originally hoped for. The slight problem here is the variability in file size. I personally think we're OK at this point. Anon is posting the # of candidates by each file so people with slower machines can take smaller files and with faster/more machines can take larger files. Gary Last fiddled with by gd_barnes on 20080326 at 21:28 

20080326, 21:27  #24  
May 2007
Kansas; USA
10390_{10} Posts 
Quote:
But we do prefer not to have overclocked machines for this effort. But if Carlos has run an appropriate torture test and Anon is good with the test, then I'm OK with it. He knows more about how those specific torture tests work for various machines. Edit: I could attempt to get down to the n=10 or n=1 level of the incremental analysis but the additional accuracy would not be worth it. Technically calculus needs to be used here. Unfortunately my basic calculus is not good enough so I generally resort to algebra and incremental analysis using formulas similar to compound interest calculations. Perhaps Axn1, Geoff, Robert, or even MiniGeek here could chime in with some calculus that would give as exact of estimate as possible. Exact CPU timings don't help for specific n's here with the way I did it because it would require an analysis of when FFTlen changes. Total CPU time spent for an nrange is what helps the most. But doing that analysis would give the most exact estimates. Gary Last fiddled with by gd_barnes on 20080326 at 21:39 

20080326, 21:57  #25 
A Sunny Moo
Aug 2007
USA (GMT5)
3×2,083 Posts 
Given all the calculations that have just transpired as to how long it will take to do a file, is everyone satisfied with the sizes of the files? As Gary said, since the number of candidates is listed by each file, people can tailor the size of their reservation to the speed of their computer, so I'm thinking that the existing file sizes should be fine.
However, there is another option available to us: Split up the files so that the 3=<k<400 range is available in 3k chunks, but the 400<k=<1001 range is available in 2k chunks. Does anyone think this would be a better way to go? 
20080326, 22:32  #26 
I quite division it
"Chris"
Feb 2005
England
2077_{10} Posts 
The file sizes are fine for me so far. How much slower will it get as the ks get higher?

20080326, 22:40  #27 
Mar 2006
Germany
2901_{10} Posts 
llrtools
look here:
http://www.mersenneforum.org/showpos...3&postcount=36 download the llrtools. insert in 'times.txt' the timings of your CPU for a given FFTlen for my Quad 2.4GHz i do this for the range 2125: Code:
6144 0.096 7168 0.116 8192 0.120 10240 0.168 12288 0.207 14336 0.250 and the output is like mine: Code:
 Quad Q6600 2.4GHz  number of (k,n) pairs in file: 19448 estimated total time for LLR testing the whole file: 656024.274 sec average time per LLR test: 33.732 sec the other 2 progs in there:  fft_len gives you all the FFTlen for a given k and nrange  av_time gives you the average time per LLRtest for a given k and nrange try it! it's easy to use with many information you get. karsten Last fiddled with by kar_bon on 20080326 at 22:41 
20080328, 16:10  #28 
May 2007
Kansas; USA
2·5·1,039 Posts 
Anon,
Would you mind posting the # of candidates by the reservations also? It'll give us an idea of how much everyone has reserved. BTW, k=300400 should be just as errorprone as k=4001001. After finishing, say, k=400450 or k=400500, you might consider starting on k=300400 to get it 'filled in'. k=1300 will be the most accurate because in looking at RPS's threads, it appears they've probably doublechecked perhaps 2535% of everything but the efforts were very sporadic and spread out and it's difficult to tell exactly what was truly doublechecked. Gary Last fiddled with by gd_barnes on 20080328 at 16:11 
20080328, 17:53  #29  
A Sunny Moo
Aug 2007
USA (GMT5)
1869_{16} Posts 
Quote:
Quote:


20080402, 06:51  #30 
May 2007
Kansas; USA
2·5·1,039 Posts 
reserving k=407417 (2 files)

20080403, 14:26  #31 
I quite division it
"Chris"
Feb 2005
England
4035_{8} Posts 
15 to 19 completed.
No surprises. Total running time on one core of C2D @ 2925 MHz was c. 7 days 10 hrs. I've emailed the zipped results because they exceed the 244.1kb limit. 
20080403, 14:43  #32 
Account Deleted
"Tim Sorbera"
Aug 2006
San Antonio, TX USA
10253_{8} Posts 
How many candidates were in your range? How much was the CPU used? Reason is to compare speed with my A64X2 @ 2500 MHz. It will finish 913 within 35 minutes. I had a power outage and fell ~7.5 hours behind. Estimated CPU time is 204 hours (8.5 days), note this is a rather rough estimate as I couldn't grab the CPU time just before the power outage. Real time is about about 8.75 days (234 hours).

20080403, 15:19  #33 
Account Deleted
"Tim Sorbera"
Aug 2006
San Antonio, TX USA
17×251 Posts 
913 Done. Results and primes attached. It had trouble writing to the lresults.txt file for a little bit there and put it in the other file in the archive.
Edit: Oh yeah, and, no surprises here. All and only all primes known. Last fiddled with by MiniGeek on 20080403 at 15:27 
Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Team drive #14: k=6001001 n=1M2M  mdettweiler  No Prime Left Behind  10  20210313 22:32 
GPU sieving drive for k<=1001 n=1M2M  mdettweiler  No Prime Left Behind  11  20101004 22:45 
Doublecheck drive #2: k=300400 n=260K600K  mdettweiler  No Prime Left Behind  0  20100521 00:22 
Team drive #3: k=300400 n=260K600K  gd_barnes  No Prime Left Behind  255  20081112 10:43 
Team drive #2: k=4001001 n=260K333.2K  gd_barnes  No Prime Left Behind  154  20080331 02:59 