Riesel base 6 - team drive #4 - EIGHT OR BUST!

[mdettweiler]

Originally Posted by Mini-Geek

Thought I should give an update on 170k-175k:
I bit off a bit more than I could chew between NPLB, CRUS, and factoring, so I paused this work (after crunching ~45 of the ~280 candidates) until I could finish the NPLB work (specifically, mini-drive 454K-456K; that work is currently getting all of my CPU). That should finish early tomorrow morning, then within another two days or so I'll finish 170k-175k.
Sorry for the delay. Hopefully it's not causing too much trouble. (would be quite a mixed bag if a prime is in 170-175, huh! on the plus side, we'd be down to 7 k's, on the down side, that means I made other people waste work from doing needless tests on higher n's for the k) I'll be more careful in the future.

No problem--take your time. A few more days is no big deal.

[gd_barnes]

For sieving extremely huge efforts like at NPLB, I do optimal sieve depth calculations as though we were only sieving a smaller n-range (even though we're actually including the higher n-range); that is the range that plan to break off and that we might finishing LLRing within one year. I do that to take into account future hardware and software improvements.

Here is an example of what I would mean using the sieving of an n=300K-1M range: Let's say we want to break off n=300K-500K, which is only 2/7ths of the range. "Act" as though we are only sieving n=300K-500K by taking your sieving removal rate and dividing it by 2/7ths. So if you're getting a removal rate of 1 every 200 secs., up that to 200 / (2/7) = 700 secs. If your PFGW test at 70% of the breakoff n-range (440K) is the same as that, then you have sieved enough and can break it off.

It's also good to lower the "true" optimal sieve depth on conjectures because k's with primes won't need to be tested for the entire range (if we can ever fine one, lol).

This is a tough decision this go around. Will we be able to test this thing to n=1M in a resonable time frame? I'll define reasonable as < 1 year. At a glance, it seems so but if you analyze it, likely not. It's a HUGE amount of work, even for only 8 k's. If a test at n=260K takes ~1000 secs., then a test at n=260K*4=1.04M will take ~1000*16=16000 secs. or over 4 hours! If Lennart or anyone else like Ian or myself stayed on with many cores for an extended period, probably yes, else probably not.

Let's hold off on a decision on far to sieve for now. BUT...let's NOT hold up files. IMHO, unless a drive is terribly undersieved (say well < 1/2 of what it should be), then never should you force interested testers to wait and work on other efforts that may be less interesting to them.

I don't really have the time but Lennart and Max, if you can coordinate on getting files posted up to a limit that you deem appropriate for the demand here, that would be great. P=32T is a tremendous depth to have sieved to already and we're testing in the upper n=200K's at only P=6T. In other words, even if you do the optimum depth of the entire n=290K-1M range (without my fancy adjustment), we're likely not much undersieved at P=32T for breaking off the n=290K-500K range (i.e. using a PFGW test at 70% or n=437K vs. the removal rate of the entire n=290K-1M file).

Don't overdo the posting of files until we come to a better conclusion on how far to sieve. I'd suggest posting up to n=330K at the most. You could consider posting in n=3K files also. If you do that, you might even just go to n=320K, which would be exactly 10 files. Lennart, with your resources, you could just reserve multiple files. We don't want to force the smaller resourced folks to rush and n=3K files would be good at this point. But at the same time, if there is a gap for too long, we risk wasting a lot of resources searching k's that aren't needed at these lower n-depths. Smaller files would help avoid that. At the higher n-depths, it's far less problematic as the chances are far lower of prime and the testing rate much slower so the gaps are perhaps only 10-20% below the current testing range vs. 30-50%.

And finally: One main reason I'm suggesting holding off on a decision on the optimum sieve depth is that we want to get more of the lower n-range holes filled in to see if there is a prime. If it's one of the heavier weight k's, it could have a large impact on the optimum sieve depth.


Gary

[mdettweiler]

@Gary: Okay, that sounds good. As soon as Lennart's ready with that 32T file, I'll post 3K files up to 320K. If demand carries us past that, I'll post more, though as you said I'll hold off on initially posting more than that until we can get a better determination of how far to sieve.

Meanwhile, I've got to come up with a script to handle splitting of sieve files into team drive-size chunks automatically. I'm getting really tired of having to do those manually.

[Lennart]

p=31999526896457, 19392312 p/sec, 69 factors, 100.0% done, 746 sec/factor
sr2sieve 1.8.9 stopped: at p=32000000000000 because range is complete.
Found factors for 69 terms in 51794.008 sec. (expected about 69.22)
q9550@q9550-desktop:~/Desktop/min/crus_6$

This is on a Intel Q6600 sieved with 4 core (-t4)

Thats ~3000 sec/factor

All will be done in about 4 hr.

Lennart

[MyDogBuster]

190K-195K complete - No primes

Results attached

[gd_barnes]

Originally Posted by mdettweiler

@Gary: Okay, that sounds good. As soon as Lennart's ready with that 32T file, I'll post 3K files up to 320K. If demand carries us past that, I'll post more, though as you said I'll hold off on initially posting more than that until we can get a better determination of how far to sieve.

Meanwhile, I've got to come up with a script to handle splitting of sieve files into team drive-size chunks automatically. I'm getting really tired of having to do those manually.

Aw, you wimp! I've been splitting 10's of files manually for a long time now.

Lennart, could you run a PFGW test of a candidate at n=~437K (70% of n=290K-500K range)? Since we know we're getting ~3000 secs. per factor, that will give us a good idea of how close we are to optimum depth for breaking off n=290K-500K -if- we include the entire n-range in the calculation (i.e. assumes we'll finish n=290K-1M within ~1 year).

Since Max tested n=260K at 990 secs. n=437K should take ~2.8 times that long or ~2800 secs., i.e. (437K/260K)^2, so I think we're even a little past optimum for including the entire range in a calculation for breaking off n=290K-500K.

I think the only way we'd be not past optimum for breaking it off is if Lennart's machine is much slower than Max's machine on a PFGW test. (That seems unlikely!) Therefore I think we can post as many files as we want at this point, although I'd suggest holding off until Tim and Dougal are done with their lower n-ranges. If a prime is found, it would be one thing to have to repost 10 files with a removed k, quite another to do 20-30 of them.

I think we need Karsten to come in here and show us how to find a Riesel base 6 prime! lol


Gary

[Lennart]

Here it is.

Will soon be back with the time on pfgw

Lennart


EDIT: 59095*6^435235-1 is composite: RES64: [9A8DA7CAF565D7ED] (2961.6498s+0.0260s)

on a q6600@2.4Ghz

[Batalov]

Taking 285K-290K

[mdettweiler]

Originally Posted by Batalov

Taking 285K-290K

Welcome to Conjectures 'R Us!

[mdettweiler]

To all: I've posted new n=3K files for 290K-299K. That makes for a total of only three files; this is intentional, since as Gary said earlier, until all the lower ranges come in and we're sure there aren't any primes hiding there, we'll be posting files in smaller batches to minimize admin effort in case of a prime being found.

[gd_barnes]

Originally Posted by mdettweiler

To all: I've posted new n=3K files for 290K-299K. That makes for a total of only three files; this is intentional, since as Gary said earlier, until all the lower ranges come in and we're sure there aren't any primes hiding there, we'll be posting files in smaller batches to minimize admin effort in case of a prime being found.

Once Tim and Dougal are done with their ranges, we'll be at n=250K. I'd definitely suggest posting more files at that point. After all, although unlikely, we could end up finding more than one prime for the same k, which would give us an extra top-5000 prime, which I won't complain about. :-) This happend on Sierp base 16 where you and I both found primes close together for the same k with 2 different reserved n-ranges. As I recall, it was k=63405 or something like that. Yours was lower so it got reflected as the prime for that k but both primes were reported at top-5000.