mersenneforum.org Low weight stats page.
 Register FAQ Search Today's Posts Mark Forums Read

 2006-04-26, 20:20 #89 edorajh     Oct 2003 Croatia 1C816 Posts I am also interested in a distributed low-weight search (something like "3rd drive"). I think it's a great idea.
2006-04-26, 20:34   #90
Thomas11

Feb 2003

1,901 Posts

Quote:
 Originally Posted by edorajh I am also interested in a distributed low-weight search (something like "3rd drive"). I think it's a great idea.
Okay, then let me know your opinion on the following choices:

(1) taking the 23 k ("LowNash1") already tested to n=2.27M and drive them to n<=10M
(2) taking the 36 k ("LowNash2") already tested to n=1.1M and drive them to n=2M
(3) preparation of a complete new selection of k

Personally I would vote for either (1) or (2), since these are just ready to start with.

If we intend to start such an effort in earnest, then one of the moderators should start a separate thread for this sub-project. And I would need an opportunity to upload the presieved files to the 15k.org server.

 2006-04-26, 20:41 #91 edorajh     Oct 2003 Croatia 23×3×19 Posts For start, it seems to me that option 2 might be better. Latter on we might start another drive with option 1. Just a thought... why not take k's from 2nd option up to n=2.27M... then next drive could combine k's from option 1 and option 2, and take them to n=10M. Re option 3... maybe latter on when we reach 10M for options 1 and 2.
2006-04-26, 20:51   #92
Thomas11

Feb 2003

1,901 Posts

Quote:
 Originally Posted by edorajh Just a thought... why not take k's from 2nd option up to n=2.27M... then next drive could combine k's from option 1 and option 2, and take them to n=10M.
k's from the 2nd option ("LowNash2") have only been sieve for nmax=2M. Combining them with "LowNash1" would mean that these k need to be completely resieved for n=2-8M up to around p=14T. This would require again thousands of cpu hours...

Nevertheless, I would agree with you, to start with the smaller candidates (2nd option) and drive them to n=2M. Later on we might switch to "LowNash1" beyond n=2.27M.

P.S.: Just to give you a measure on how long a single test lasts in that region: on a 2.4GHz P4 it will take about 1.5 hours around n=1.1M and more than 6 hours around n=2.27M...

Last fiddled with by Thomas11 on 2006-04-26 at 20:54

 2006-04-26, 21:47 #93 edorajh     Oct 2003 Croatia 23×3×19 Posts You are right Thomas. I didn't take into account sieving time. In that case I think it's the best to start with 2nd option, and once we complete this we can start 1st option. Hope this subproject will become 3rd drive. I'm aware of how long one test lasts in that range of n's. Did some tests for "my own k". Last fiddled with by edorajh on 2006-04-26 at 21:51
 2006-04-27, 06:14 #94 VBCurtis     "Curtis" Feb 2005 Riverside, CA 3×113 Posts I also vote for option 2-- taking a batch from 1.1M to 2M isn't a huge project at this weight, yet has the tantalizing chance of a Big Prime (tm). If there is no moderator with time to administer the RPS-drive-style checkout pages, perhaps the 2-4 of us who are interested in this could commit to a 100k range of n to check, and all just grab Thomas' file, parsing it for our committed range ourselves. Ideally, a mod sets up checkout ranges like the other projects, but I imagine that's a serious time undertaking. If anyone considers setting this up, I'd personally be comfortable with larger file-pieces; 2-3 weeks on a P4 isn't unreasonable, as there will be few people working on this, and frequent progress updates aren't as relevant, with the small chance of finding a prime. Thomas-- thanks again for sharing your sieving work with us. -Curtis
 2006-04-27, 06:39 #95 edorajh     Oct 2003 Croatia 1C816 Posts Curtis, I like your idea... that each of us take a 100k range of n to test, and parsing it ourselves. But, before we go that way maybe we could send PM to admins if they are interested to set up this project as 3rd drive. I'll send PM to Kosmaj and Larry.
 2006-04-27, 06:41 #96 Kosmaj     Nov 2003 2×1,811 Posts Low weight (3rd Drive) sounds good and I also vote for option 2. I'm not sure do you need extra sieving or not. If you do, we have a small "sieving squad" that might be able to help. I'll suggest to Larry to start a new drive thread as I already run two others. As for uploading files to the server I'll talk to SlashDude but he is often slow to respond. In the meanwhile, if you can either mail me the files (zipped), or place them somewhere so that I can access them, I'll put them on the server. Let me know what file size are we talking about. I second Curtis' idea for larger blocks, but ideally it will be nice to have medium-size ones too. I cannot wait to see those low-wieight megabit primes!
 2006-04-27, 06:48 #97 edorajh     Oct 2003 Croatia 1110010002 Posts That's great Kosmaj! So we can have this low weight search as RPS 3rd drive. It would be nice to catch one of those megabit primes!
2006-04-27, 07:58   #98
Thomas11

Feb 2003

1,901 Posts

Quote:
 Originally Posted by Kosmaj Low weight (3rd Drive) sounds good and I also vote for option 2. I'm not sure do you need extra sieving or not. If you do, we have a small "sieving squad" that might be able to help.
The extra sieving effort needed is really low. We could already start with -- let's say 1.1-1.5M -- and I'll finish the sieve for the larger candidates easily by myself (I'm expecting only one or two weeks to be necessary for that purpose). You should note that I'm relying on the good old RieselSieve 1.35 by Paul Jobling. On the low-weight candidates I found it to be up to twice as fast as it's successor ProthSieve...

In total we are talking about less than 12000 candidates. This should keep us busy for a few months - depending on the number of coworkers.

-- Thomas

 2006-04-27, 11:33 #99 Thomas11     Feb 2003 1,901 Posts This is just a compilation of FFT lengths used by LLR for testing k of the size we will look at in the 3rd drive (e.g., k of about 9 decimal digits): Code:  fftlen nmax ----------------------- 114688 1160703 131072 1326659 163840 1650074 196608 1966990 229376 2290405 262144 2618320 327680 3259650 393216 3884481 458752 4522811 524288 5168642 655360 6423302 786432 7652963 917504 8912624 1048576 10182285 ----------------------- ("nmax" is the largest n for the given "fftlen") Note, that we are talking about "Zero Padded IBDWT", which is slightly slower (about 5-10%) than the non-zero padded one of the same FFT length that would be used on the smaller k. P.S.: These FFT lengths are for SSE2 machines (e.g. P4) and are valid for LLR 3.6/3.7. On Athlons the FFT turnover should appear at slightly larger n. Last fiddled with by Thomas11 on 2006-04-27 at 11:42

 Similar Threads Thread Thread Starter Forum Replies Last Post Oddball Twin Prime Search 0 2011-10-29 18:34 ET_ PrimeNet 0 2009-01-10 15:02 mdettweiler Prime Sierpinski Project 3 2008-08-27 18:34 Old man PrimeNet Lounge 15 2003-11-25 02:09 Deamiter Software 1 2002-11-09 06:24

All times are UTC. The time now is 13:57.

Mon Mar 30 13:57:10 UTC 2020 up 5 days, 11:30, 2 users, load averages: 2.07, 2.31, 2.36