mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   No Prime Left Behind (https://www.mersenneforum.org/forumdisplay.php?f=82)
-   -   Team drive #9 k=1005-2000 n=50K-350K (https://www.mersenneforum.org/showthread.php?t=11285)

gd_barnes 2009-01-05 02:18

Team drive #9 k=1005-2000 n=50K-350K
 
[COLOR=black][FONT=Verdana]This is team drive #9 for NPLB. We will be searching all k=1005-2000 for n=50K-200K and k=1400-2000 for n=200K-350K. [/FONT][/COLOR]Karsten has created a web page that shows details for the drive [URL="http://www.rieselprime.de/NPLB/Drives/NPLB_Drive9.htm"]here[/URL].

An LLRnet server will be processing most of the range. For general info. on setting up and running the server see [URL="http://www.mersenneforum.org/showthread.php?t=9959"][COLOR=#22229c]this thread[/COLOR][/URL]. Server info. is:
server = "nplb.ironbits.net"
port = 9000

For this drive, there will be no top-5000 primes. For ranges run on the server, the admins will take care of showing all primes in this post.

Please post requests for manual files and we will send them to you. For manual ranges, please wait until you have completed your range and then post primes in THIS THREAD along with your completion status.

The drive will be searched by k-value to make it easier for posting the many small primes that will be found.

[FONT=Verdana][COLOR=black]All primes found from drive #9 for k=1005-2000 and n=50K-200K by k and n-value:[/COLOR][/FONT]
[URL="http://www.noprimeleftbehind.net/crus/prime1005-2000-50K-200K.txt"][COLOR=#800080]primes k=1005-2000 n=50K-200K[/COLOR][/URL]

[FONT=Verdana][COLOR=black]All primes found from drive #9 for k=1400-2000 and n=200K-350K by k and n-value:[/COLOR][/FONT]
[code]
Prime found by new (n) or confirmed (c)?
[URL="http://www.noprimeleftbehind.net/crus/prime1400-1500-200K-350K.txt"]primes k=1400-1500 n=200K-350K[/URL]
[URL="http://www.noprimeleftbehind.net/crus/prime1500-1600-200K-350K.txt"][COLOR=#800080]primes k=1500-1600 n=200K-350K[/COLOR][/URL]
[URL="http://www.noprimeleftbehind.net/crus/prime1600-1700-200K-350K.txt"][COLOR=#800080]primes k=1600-1700 n=200K-350K[/COLOR][/URL]
[URL="http://www.noprimeleftbehind.net/crus/prime1700-1800-200K-350K.txt"][COLOR=#800080]primes k=1700-1800 n=200K-350K[/COLOR][/URL]
1805*2^306658-1 Bruce n
1809*2^238623-1 Bruce n
1809*2^336785-1 Bruce n
1813*2^319647-1 Flatlander n
1815*2^228294-1 Flatlander n
1815*2^311016-1 Flatlander n
1817*2^235952-1 Bruce n
1821*2^246419-1 Bruce n
1821*2^290518-1 Bruce n
1821*2^297574-1 Bruce n
1821*2^303365-1 Bruce n
1823*2^246004-1 Bruce n
1823*2^281714-1 Bruce n
1823*2^322490-1 Bruce n
1825*2^252167-1 Angus n
1825*2^295279-1 Bruce n
1827*2^248202-1 Bruce c
1831*2^222585-1 Flatlander n
1831*2^247437-1 Bruce n
1833*2^252332-1 Bruce n
1837*2^229849-1 Bruce n
1837*2^299529-1 Bruce n
1839*2^215465-1 Flatlander n
1839*2^250292-1 Bruce n
1839*2^278308-1 Bruce n
1839*2^302901-1 Bruce n
1841*2^225402-1 Bruce n
1843*2^288315-1 Bruce n
1843*2^294115-1 Bruce n
1845*2^294744-1 Bruce n
1847*2^274472-1 Bruce n
1849*2^239095-1 Bruce n
1849*2^332807-1 Bruce n
1851*2^248743-1 Bruce n
1853*2^272544-1 Bruce n
1855*2^231477-1 Bruce n
1855*2^243451-1 Bruce n
1857*2^312129-1 Flatlander n
1857*2^312738-1 Flatlander n
1857*2*328389-1 Bruce n
1861*2^204171-1 Bruce n
1863*2^293660-1 Bruce n
1865*2^298048-1 Bruce n
1865*2^338206-1 Bruce n
1867*2^332485-1 Bruce n
1869*2^214951-1 Flatlander n
1869*2^325843-1 cipher n
1873*2^340103-1 Bruce n
1875*2^228870-1 Flatlander n
1875*2^238542-1 Bruce n
1875*2^244593-1 Bruce n
1875*2^270537-1 vaughan n
1875*2^280485-1 Bruce n
1875*2^336774-1 Bruce c
1875*2^349189-1 gd_barnes c
1877*2^223784-1 Bruce n
1877*2^275870-1 Bruce n
1879*2^230575-1 Bruce n
1881*2^213434-1 Flatlander n
1881*2^237046-1 Bruce n
1883*2^222536-1 DeeDee n
1883*2^227872-1 Bruce n
1883*2^239804-1 Bruce n
1883*2^256734-1 Bruce n
1887*2^217365-1 Bruce n
1887*2^258488-1 Bruce n
1887*2^266094-1 Bruce n
1887*2^341424-1 Bruce n
1891*2^276077-1 Bruce n
1893*2^260271-1 Bruce n
1893*2^263876-1 Bruce n
1895*2^269400-1 Bruce n
1895*2^343020-1 Bruce n
1897*2^309825-1 Bruce n
1897*2^318281-1 Bruce n
1899*2^201939-1 Bruce n
1899*2^248209-1 Bruce n
1901*2^239030-1 Bruce n
1901*2^335018-1 Bruce n
1905*2^233771-1 Bruce n
1905*2^298367-1 Bruce c
1905*2^327452-1 Bruce c
1907*2^321792-1 Bruce n
1909*2^234299-1 Bruce n
1909*2^263299-1 Bruce n
1911*2^220995-1 Bruce n
1911*2^222953-1 Bruce n
1911*2^234801-1 Bruce n
1911*2^249483-1 Bruce n
1911*2^314979-1 Bruce n
1915*2^234347-1 Bruce n
1915*2^281135-1 Bruce n
1915*2^297009-1 Bruce c
1915*2^302463-1 Bruce n
1919*2^267604-1 Bruce n
1921*2^229735-1 Bruce n
1923*2^271876-1 Bruce c
1925*2^201836-1 Bruce n
1929*2^230120-1 Bruce n
1931*2^279422-1 Bruce n
1933*2^233999-1 Bruce n
1935*2^218387-1 Bruce c
1935*2^223263-1 Bruce c
1937*2^237368-1 Bruce n
1939*2^228401-1 Bruce n
1939*2^246303-1 Bruce n
1939*2^275505-1 Bruce n
1939*2^317107-1 Bruce n
1939*2^318723-1 Bruce n
1941*2^267025-1 Bruce c
1943*2^219932-1 Chuck n
1945*2^269747-1 Bruce n
1947*2^250556-1 Bruce n
1947*2^271084-1 Bruce n
1947*2^337306-1 Bruce n
1949*2^233400-1 Bruce n
1951*2^219801-1 Bruce n
1951*2^229379-1 Bruce n
1951*2^266411-1 Bruce n
1951*2^341191-1 Bruce n
1953*2^210682-1 Bruce n
1953*2^212614-1 Bruce n
1953*2^245310-1 Bruce n
1953*2^332010-1 Bruce n
1957*2^340269-1 Bruce n
1959*2^249845-1 Bruce n
1961*2^220270-1 Bruce n
1963*2^226315-1 Bruce n
1963*2^320619-1 Bruce n
1965*2^226308-1 Bruce c
1965*2^304237-1 Bruce c
1965*2^327384-1 Bruce c
1971*2^212490-1 Bruce n
1971*2^231206-1 vaughan n
1971*2^243534-1 Bruce n
1971*2^336566-1 Bruce c
1973*2^316374-1 AMDave n
1975*2^259849-1 vaughan n
1977*2^275732-1 Bruce c
1977*2^303712-1 Bruce c
1977*2^307490-1 Bruce c
1983*2^202120-1 Bruce n
1987*2^231621-1 Bruce n
1991*2^307402-1 Bruce c
1993*2^226451-1 Bruce n
1993*2^267003-1 Bruce n
1993*2^286223-1 Bruce n
1995*2^225074-1 Bruce c
1995*2^239412-1 Bruce c
1995*2^240279-1 Bruce c
1999*2^236699-1 Bruce n
1999*2^238361-1 Bruce n
[/code][COLOR=black][FONT=Verdana]Status:[/FONT][/COLOR]
[code]
k-range n-range tested by Status # primes
1800-2000 200K-350K LLRnet (IB9000) in progress 131 (plus 21 confirmed)
1609-1800 200K-350K LLRnet (IB9000) complete 152 (plus 15 confirmed)
1601-1607 200K-350K Mini-Geek complete 3
1400-1600 200K-350K LLRnet (IB9000) complete 144 (plus 15 confirmed)
1800-2000 50K-200K LLRnet (IB9000) complete 396 (plus 32 confirmed)
1600-1800 50K-200K LLRnet (IB9000) complete 418 (plus 3 confirmed)
1400-1600 50K-200K LLRnet (IB9000) complete 358 (plus 33 confirmed)
1200-1400 50K-200K LLRnet (IB9000) complete 343 (plus 18 confirmed)
1005-1200 50K-200K LLRnet (IB9000) complete 314 (plus 65 confirmed)
[/code]

The drive is now complete.


Gary

gd_barnes 2009-01-05 22:18

[quote=MyDogBuster;157043]1400G - 1800G complete

results emailed[/quote]


Excellent. OK, everyone. I just need to apply the P=1.4T-1.8T factors to the file, which I will do shortly. How would we like to proceed with the n=50K-200K effort?

I had previously recommended that we search by k-value. If we do that, we'd post files, 1-3 k's at a time in sequencial order similar to our double-check drive, and people can take as many as they see fit.

Alternatively, we can try loading a very small n-range for the entire set of k's in n-value sequence, say, n=50K-52K, and see how it handles such fast tests. A second alternative might be to load 2-3 k's into the server and observe how the server performs in k-value sequence over the entire n=50K-200K range. In a synopsis:

1. Test manually by k-value.

2. Use server on a small file sorted by n-value. This would be the most stringent test on a server because all tests would be very fast.

3. Use server on a small file sorted by k-value then n-value. This is not as stringent of a test since all n-values within the range will be tested.


Gary

mdettweiler 2009-01-05 22:30

[quote=gd_barnes;157052]Excellent. OK, everyone. I just need to apply the P=1.4T-1.8T factors to the file, which I will do shortly. How would we like to proceed with the n=50K-200K effort?

I had previously recommended that we search by k-value. If we do that, we'd post files, 1-3 k's at a time in sequencial order similar to our double-check drive, and people can take as many as they see fit.

Alternatively, we can try loading a very small n-range for the entire set of k's in n-value sequence, say, n=50K-52K, and see how it handles such fast tests. A second alternative might be to load 2-3 k's into the server and observe how the server performs in k-value sequence over the entire n=50K-200K range. In a synopsis:

1. Test manually by k-value.

2. Use server on a small file sorted by n-value. This would be the most stringent test on a server because all tests would be very fast.

3. Use server on a small file sorted by k-value then n-value. This is not as stringent of a test since all n-values within the range will be tested.


Gary[/quote]
I'll vote for #2--to load 50K-52K into IB8000, and see if it breaks. :smile:

Of course, if we're giving the server ranges in terms of n, we'll probably want to do the same for manual ranges to avoid confusion. That shouldn't be too bad, though--sorting by n worked pretty well for the 8th Drive on this same k-range, so this should essentially be the same thing except that we'll be giving out larger files to compensate for the smaller tests.

BTW, Gary: if you're having a hard time dealing with the huge sieve files for this effort in a text editor, try popping it onto one of your Linux machines, and then use the terminal to run the command "split -l 500000 [i][name of sieve file][/i]". It will then split the file into nice easy chunks of 500,000 lines each--quite manageable. :smile: (It will originally call the files generic names such as "xaa", "xab", "xac", etc., but you can of course rename them however you like.)

IronBits 2009-01-05 22:52

vi has no such limitation :wink:
[url]http://www.vim.org/download.php[/url]

I like #2, however, send IB8000 that entire range and let's just eat it up. :grin:

gd_barnes 2009-01-05 23:36

I know this is long but I'd appreciate it if people could read it all the way through because it goes "one way" and then the "other". :smile:

We need to think this through. You remember the discussion we had before? Karsten is not going to like us because he'll constantly have to be entering primes all over the place on his pages. That is why I had suggested sorting by k-value to begin with on the low n-range, i.e. n=50K-200K. People had initially agreed searching manually by k-value was the way to go so we now have 2 schools of thought.

Let's look at what we have here:

1. There will be 10's of primes coming in very rapidly and David, it will stretch your primes listing to a very long length on your web page as they come in.
2. If people post them all in our primes thread as they come in, it will quickly innundate our primes thread.
3. It will be extremely easy to miss a prime or two because we won't be associating primes with specific k-values, only n-ranges, and there will be so many of them.

I know it sounds like I'm trying to talk everyone out of it but not really. I just want to make sure everyone knows the facts of doing it that way. If people think it would be more fun to search by n-value, here is what I would suggest:

1. Load n=5K or (10K or whatever we think is best) ranges into the server sorted by n-value. The range can be decreased as we move higher.
2. No one report any primes anywhere until the entire n=5K range is done.
3. When we have determined that the n-range is complete, Max or I check the results files, [B]sort the primes in them by k-value[/B], and post them in our primes thread, showing who found them, all in one post for each n-range. In addition, as usual, they will be put in the 1st post of the drive thread in decesending n-value order, also showing who found them.

This creates a little more admin work for us but I personally don't mind if Max doesn't. IMHO, it's the only way we'll avoid missing primes. It's just too easy for otherwise "passive" searchers to accidently miss reporting non-top-5000 primes. It will also make it relatively easy for Karsten to post the primes on his k=300-2000 page.

Karsten, if you're around, you can give your opinion here too.


Gary

IronBits 2009-01-05 23:47

Whatever, however, you want to do it is fine by me.
I was just trying to help everyone out by avoiding the tedious manual reservations thang.
Just load up the server with what ever you like, if folks want to come in and cache 100s at a time, that's fine by me, the server seems to handle that with out a hiccup.

We'll never know what the limits of the server are, if we don't push it a little harder...
I have no preference to loading it up by K or N, what ever suits you suits me :smile:

MyDogBuster 2009-01-05 23:50

[quote]1. Test manually by k-value.

2. Use server on a small file sorted by n-value. This would be the most stringent test on a server because all tests would be very fast.

3. Use server on a small file sorted by k-value then n-value. This is not as stringent of a test since all n-values within the range will be tested.
[/quote]

Actually I vote for #3. Loads easier to keep track of everything for all concerned (except stragglers). Gives Karsten at least a fighting chance.
Everything eventually gets tested either way so why create loads of unnecessary work.

Oops I almost forget, NO MANUAL RESERVATIONS. To hard to handle.

Oops #2. I would love to reserve a k from n=50K to n=1M.

mdettweiler 2009-01-06 00:10

[quote=gd_barnes;157067]I know this is long but I'd appreciate it if people could read it all the way through because it goes "one way" and then the "other". :smile:

We need to think this through. You remember the discussion we had before? Karsten is not going to like us because he'll constantly have to be entering primes all over the place on his pages. That is why I had suggested sorting by k-value to begin with on the low n-range, i.e. n=50K-200K. People had initially agreed searching manually by k-value was the way to go so we now have 2 schools of thought.

Let's look at what we have here:

1. There will be 10's of primes coming in very rapidly and David, it will stretch your primes listing to a very long length on your web page as they come in.
2. If people post them all in our primes thread as they come in, it will quickly innundate our primes thread.
3. It will be extremely easy to miss a prime or two because we won't be associating primes with specific k-values, only n-ranges, and there will be so many of them.

I know it sounds like I'm trying to talk everyone out of it but not really. I just want to make sure everyone knows the facts of doing it that way. If people think it would be more fun to search by n-value, here is what I would suggest:

1. Load n=5K or (10K or whatever we think is best) ranges into the server sorted by n-value. The range can be decreased as we move higher.
2. No one report any primes anywhere until the entire n=5K range is done.
3. When we have determined that the n-range is complete, Max or I check the results files, [B]sort the primes in them by k-value[/B], and post them in our primes thread, showing who found them, all in one post for each n-range. In addition, as usual, they will be put in the 1st post of the drive thread in decesending n-value order, also showing who found them.

This creates a little more admin work for us but I personally don't mind if Max doesn't. IMHO, it's the only way we'll avoid missing primes. It's just too easy for otherwise "passive" searchers to accidently miss reporting non-top-5000 primes. It will also make it relatively easy for Karsten to post the primes on his k=300-2000 page.

Karsten, if you're around, you can give your opinion here too.


Gary[/quote]
Okay, you're right, that does sound like a better idea. I officially change my vote to #3 (that is, to sort by k and, by extension, load files into the server by k). :smile:

Oh, and by the way: sorting by k should still be just as much of a stress test for the server. Maybe not quite as prolonged of a stress test, but that shouldn't make a difference--it will still tell us unequivocally whether the server can handle n=50K tests. :smile:

Flatlander 2009-01-06 00:15

[quote=mdettweiler;157075]Okay, you're right, that does sound like a better idea. I officially change my vote to #3 (that is, to sort by k and, by extension, load files into the server by k). :smile:

Oh, and by the way: sorting by k should still be just as much of a stress test for the server. Maybe not quite as prolonged of a stress test, but that shouldn't make a difference--it will still tell us unequivocally whether the server can handle n=50K tests. :smile:[/quote]
I agree.

IronBits 2009-01-06 00:19

Heck, I'll offer to save you all the trouble and reserve that whole k/n range and let you know when I finish it. :missingteeth:

Did you want me to turn off auto-notify, and not display found primes on the web page, for this range on port 8000?

gd_barnes 2009-01-06 00:23

I will also vote for #3 mainly because it would save us a little admin time and Karsten a lot of admin time. It would also spread out the average prime rate found instead of having tons of them at first followed by less of them later.

David, if we went that route, you would still get the entire range loaded into your server; just processed in a different order.

If we did #3, I would still suggest doing what I suggested above with Max or me posting the primes found sorted by k-value in the primes thread. Instead of every n=5K or 10K range, we just do it after about every 2-5 k's searched. The admin time it would save for Max and me is us having to sort it by k-value before posting so not a lot. But...the admin time saved by Karsten would be large. He would only have to update the n-range searched on each k one time each.

We have 2 votes each on #2 and #3. More opinions still welcome.


Gary


All times are UTC. The time now is 02:10.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.