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

rogue · 2009-09-02, 01:24

I'm curious as to why PRPNet wouldn't be a good choice for this drive. I can understand base 3 due to the small n, but the n for this drive are much larger. It would be far less likely to cause trigger the same issues that it has with base 3. I could say the same for the Sierpinski base 6 drive.

And yes I am still working on the next release, but have higher priority items at home at this time which keep me away from active development.

Admin edit: Responses to this post and subsequent discussion moved to the "PRPnet server bugs and barfing problem" thread here.

gd_barnes · 2009-09-03, 01:31

Quote:

Originally Posted by mdettweiler

Yes, at that point it should definitely be OK. In fact, come to think of it, as the tests are already getting rather large for this drive, we could probably start using PRPnet right now with no more ill effects than the occasional barfs we get from Lennart's ranges. The manual ranges have been quite popular, but if nobody has any objections to using PRPnet instead, then we could possibly take a whack at it. As I said in my last note, the problems seem to be fixed to the point where they won't contaminate the results any more, so the worst that could happen is a few tests that would need to be re-done.

I'd feel much better if we got it up to n=500K first. There really aren't very many tests because the k's are pretty low weight. I haven't even done any testing myself yet and we're zooming along pretty fast with manual files. If it stalls out for a week or so, I'll reserve an n=6K or 12K range and let a quad hack away at it for a while.

On another note, would it make sense to have PRPnet only cache 1 pair at a time instead of 3 or 5 or 10? In other words: Quick in and quick out.

And on a final note: Lennart, feel free to reserve whatever you can test in about a week or so where you're fairly confident that PRPnet won't leave blank residues on any pairs. If you want all of the remaining files, that's fine. We'll add more fairly quickly. I know firsthand how long it takes to manage multiple machines with many different efforts and I probably have < half of your resources. In other words, don't feel like you need to only reserve 1-3 days worth of work at a time. You can take larger blocks if you want. Way back when, Beyond used to reserve n=10K ranges at NPLB and that would take him well over a week, which was fine with us.

Gary

Batalov · 2009-09-03, 01:45

Taking 323-335K

Lennart · 2009-09-04, 11:27

Here is k=43994 searched range n=350k-500k

NO PRIMES
=================

I will now do the same with k=36772

Lennart

Flatlander · 2009-09-04, 12:19

Quote:

Originally Posted by Lennart

Here is k=43994 searched range n=350k-500k

NO PRIMES
=================

I will now do the same with k=36772

Lennart

Wouldn't it be better to start at 335k?

Lennart · 2009-09-04, 12:41

Quote:

Originally Posted by Flatlander

Wouldn't it be better to start at 335k?

Yes it would !

I did this todo some tests on PRPNet and becuse i did the first from n=350k
i will do that on this one also.

After i have done this k i will help out to get it up to n=350k

Lennart

Flatlander · 2009-09-04, 15:02

320-323 is complete.

Taking 335-338.

gd_barnes · 2009-09-04, 18:46

I just looked at the timings of Chris's file. It appears that each file right now is taking ~3.5 CPU days (assuming the avg. file size of 250 tests) so the file sizes are good to at least n=400K. Estimated time at n=400K would be 3.5 * (400K/320K)^2 = ~5.5 CPU days. This could be plus or minus a day depending on how the fftlen increases fall around 320K and 400K.

Note to all: Lennart contacted Max about doing only k=43994 for n=350K-500K. Of course we're leaving those k's in the files up to n=350K. When we post files for n>350K, we'll remove those k's. With those 2 k's removed, we'll likely just leave the file sizes at 3K up to n=500K. I think he chose the nice even limit to start at to keep the n-ranges of the k's that he searched consistent since there is now only a very small chance that they will contain a prime in the untested ranges up to n=350K.

Gary

Lennart · 2009-09-04, 22:53

Taking 338-341

Lennart.

KEP · 2009-09-04, 23:11

305K-314K is complete. No Primes :(

KEP

Lennart · 2009-09-05, 00:09

Here is k=36772 n=350k-500k

No Primes

2009-09-02, 01:24	#100
rogue "Mark" Apr 2003 Between here and the 2⁴·397 Posts	I'm curious as to why PRPNet wouldn't be a good choice for this drive. I can understand base 3 due to the small n, but the n for this drive are much larger. It would be far less likely to cause trigger the same issues that it has with base 3. I could say the same for the Sierpinski base 6 drive. And yes I am still working on the next release, but have higher priority items at home at this time which keep me away from active development. Admin edit: Responses to this post and subsequent discussion moved to the "PRPnet server bugs and barfing problem" thread here. Last fiddled with by gd_barnes on 2009-09-03 at 08:10 Reason: admin edit

2009-09-04, 18:46	#107
gd_barnes May 2007 Kansas; USA 101·103 Posts	I just looked at the timings of Chris's file. It appears that each file right now is taking ~3.5 CPU days (assuming the avg. file size of 250 tests) so the file sizes are good to at least n=400K. Estimated time at n=400K would be 3.5 * (400K/320K)^2 = ~5.5 CPU days. This could be plus or minus a day depending on how the fftlen increases fall around 320K and 400K. Note to all: Lennart contacted Max about doing only k=43994 for n=350K-500K. Of course we're leaving those k's in the files up to n=350K. When we post files for n>350K, we'll remove those k's. With those 2 k's removed, we'll likely just leave the file sizes at 3K up to n=500K. I think he chose the nice even limit to start at to keep the n-ranges of the k's that he searched consistent since there is now only a very small chance that they will contain a prime in the untested ranges up to n=350K. Gary Last fiddled with by gd_barnes on 2009-09-04 at 18:50

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Riesel base 16 - team drive #2	gd_barnes	Conjectures 'R Us	213	2014-02-26 09:35
Sierp base 63 - team drive #5	rogue	Conjectures 'R Us	146	2011-04-20 05:12
Sieving drive Riesel base 6 n=1M-2M	gd_barnes	Conjectures 'R Us	40	2011-01-22 08:10
Sieving drive Riesel base 6 n=150K-1M	gd_barnes	Conjectures 'R Us	27	2009-10-08 21:49
Riesel base 3 - mini-drive I	gd_barnes	Conjectures 'R Us	199	2009-09-30 18:44

2009-09-03, 01:45	#102
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 2⁴·593 Posts	Taking 323-335K

2009-09-04, 22:53	#108
Lennart "Lennart" Jun 2007 1120₁₀ Posts	Taking 338-341 Lennart.