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

gd_barnes 2009-01-06 00:24

[quote=IronBits;157077]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?[/quote]


Oh, yes, good thinking Dave. Yes, please turn off auto-notify. I as well as others would have Emails running out of our ears otherwise.


Gary

Flatlander 2009-01-06 00:25

[quote=gd_barnes;157081]Oh, yes, good thinking Dave. Yes, please turn off auto-notify. I as well as others would have Emails running out of our ears otherwise.


Gary[/quote]
Let's all pause while we visualize that.

gd_barnes 2009-01-06 00:32

Well...that was a quick change to #3. lol

Believe it or not, I was not trying to influence people, which is why I didn't officially vote at first. I just wanted to let everyone know the facts of how things would go.

We could potentially do n=200K-350K by k-value also, which is why I wanted to stop the n=200K-210K range but we can have a team discussion about that also when the sieving is done and even if we want to start it at that point. Having n=50K-200K, 200K-350K, and 350K-500K running all at once will be quite an effort and may spread the resources a bit thin so we may want to wait until n=50K-200K is done to start n=200K-350K since both are non-top-5000 ranges.

I'll be on for another hour or so, will be out for 10-12 hours, and then back on for a couple of hours. I'll wait for more opinions if people want to give them. If I see no more votes for the first 2 choices, I'll get the drive set up at that time or effectively early Tuesday morning U.S.


Gary

gd_barnes 2009-01-06 00:41

[quote=Flatlander;157082]Let's all pause while we visualize that.[/quote]


:missingteeth::missingteeth:


Good one.

On another note, Max and David, since we initially started port 8000 with n=350K-352K, should we save that server for the n=350K-500K range? I would think that would be best.

If so, David, can you set up another server for the n=50K-200K range in the next few hours? It's either that or we'll have to set up another server later on for the n=350K-500K range.

Or...if you have some old server set up already that you think would work OK for this, then that is fine too.


Gary

mdettweiler 2009-01-06 00:53

[quote=gd_barnes;157087]:missingteeth::missingteeth:


Good one.

On another note, Max and David, since we initially started port 8000 with n=350K-352K, should we save that server for the n=350K-500K range? I would think that would be best.

If so, David, can you set up another server for the n=50K-200K range in the next few hours? It's either that or we'll have to set up another server later on for the n=350K-500K range.

Or...if you have some old server set up already that you think would work OK for this, then that is fine too.


Gary[/quote]
Yes, it probably would be best to save port 8000 for the 350K-500K range since, after all, it is port [B]8[/B]000, for the [B]8[/B]th drive...probably would make most sense to keep it there.

Maybe port 9000 would work for the 50K-200K range? (Or is that port not available on Linux machines? In that case feel free to pick anything else that's open.)

Also, keep in mind that G8000 is still sitting around awaiting work--we could always use that for one of the ranges. Either that, or we could just keep it around as a secondary server for any of the drives if needed.

gd_barnes 2009-01-06 01:04

[quote=mdettweiler;157089]Yes, it probably would be best to save port 8000 for the 350K-500K range since, after all, it is port [B]8[/B]000, for the [B]8[/B]th drive...probably would make most sense to keep it there.

Maybe port 9000 would work for the 50K-200K range? (Or is that port not available on Linux machines? In that case feel free to pick anything else that's open.)

Also, keep in mind that G8000 is still sitting around awaiting work--we could always use that for one of the ranges. Either that, or we could just keep it around as a secondary server for any of the drives if needed.[/quote]


I'm confused. I'm aware that port 8000 is awaiting work. But should we save port 8000 for n=350K-500K as originally intended or run other ranges through it?...can't do both. lol

mdettweiler 2009-01-06 01:07

[quote=gd_barnes;157092]I'm confused. I'm aware that port 8000 is awaiting work. But should we save port 8000 for n=350K-500K as originally intended or run other ranges through it?...can't do both. lol[/quote]
Maybe you're getting confused about just which port 8000 I'm talking about? I was specifically referring to G8000, not IB8000. Of course the plan is to save IB8000 for n=350K-500K, but G8000 is still uncommitted. That's what I meant to say...sorry for the confusion. :smile:

gd_barnes 2009-01-06 01:16

[quote=mdettweiler;157093]Maybe you're getting confused about just which port 8000 I'm talking about? I was specifically referring to G8000, not IB8000. Of course the plan is to save IB8000 for n=350K-500K, but G8000 is still uncommitted. That's what I meant to say...sorry for the confusion. :smile:[/quote]

lol never mind...and that is why I was confused. My bad; I didn't read close enough. Too many 8000's floating around.

Please refresh my memory, what did we use G8000 for? I don't see any results files for it on the web page that you set up.


Gary

mdettweiler 2009-01-06 01:20

[quote=gd_barnes;157094]lol never mind...and that is why I was confused. My bad; I didn't read close enough. Too many 8000's floating around.

Please refresh my memory, what did we use G8000 for? I don't see any results files for it on the web page that you set up.


Gary[/quote]
G8000 was originally intended to be used for the 8th Drive, though at the time that started we had just gone through all those difficulties regarding the DNS stuff, so we decided not to use it for such a high-priority effort. Thus it was never loaded with any work, though you can still see it on the [url]http://nplb-gb1.no-ip.org/llrnet/[/url] page.

gd_barnes 2009-01-06 01:25

[quote=mdettweiler;157095]G8000 was originally intended to be used for the 8th Drive, though at the time that started we had just gone through all those difficulties regarding the DNS stuff, so we decided not to use it for such a high-priority effort. Thus it was never loaded with any work, though you can still see it on the [URL]http://nplb-gb1.no-ip.org/llrnet/[/URL] page.[/quote]

Oh yes...

Yeah, I saw it listed there. Just no work done on it.

I don't know what to do with it right now. We can decide later.

mdettweiler 2009-01-06 01:41

[quote=gd_barnes;157097]Oh yes...

Yeah, I saw it listed there. Just no work done on it.

I don't know what to do with it right now. We can decide later.[/quote]
Okay. Yeah, it probably would be wisest to stick the n=50K work on one of David's servers--they're much hardier and thus are probably going to take the heat of those little tiny k/n pairs much, much better. :smile:

As for G8000, even if we don't find a use for it right away, that's not a big deal--it won't spoil if it sits around for a while. :smile:

IronBits 2009-01-06 02:02

I'm ready for the knpairs and we will use port 9000.
Once I get it, I need to do a little bit of testing first, then I'll let you guys know when it's ready to come get some.

gd_barnes 2009-01-06 02:34

[quote=IronBits;157102]I'm ready for the knpairs and we will use port 9000.
Once I get it, I need to do a little bit of testing first, then I'll let you guys know when it's ready to come get some.[/quote]


OK, I need to leave in a bit. I'll send you a file when I set up the drive page in ~10-12 hours but I'll have people hold off connecting to the new server until you are done with your testing.


Gary

gd_barnes 2009-01-06 14:04

Reserving k=1005-1049 for port 9000. The drive is ready to go!


Gary

IronBits 2009-01-06 15:22

Port 9000 is active...

[B]Please go slowly when adding lots-o-boxen as I won't be here, so can't kick it if there is a problem.[/B]

gd_barnes 2009-01-06 15:30

[quote=IronBits;157185]Port 9000 is active...

[B]Please go slowly when adding lots-o-boxen as I won't be here, so can't kick it if there is a problem.[/B][/quote]


OK, ready to go folks...

I would suggest no more than 4 cores per person and no more than about 15-20 cores total to start with. When I get back in a couple of days, I'll add a core or two to it for a while.

Please post in this thread how many cores you will put on the server as you add them.


Gary

Flatlander 2009-01-06 15:40

3 cores at the moment, 4 (total) later.

henryzz 2009-01-06 15:51

i have just put 2 on

mdettweiler 2009-01-06 16:15

Added one core for a short while to check this out a bit. :smile: (In other news: I see that we're at ~168K already on k=1005! Wow! :grin: Though I guess that's somewhat to be expected considering how fast I was able to move on just one core back when I did k=1003 from 10K-500K on my own with mostly just one core...)

BTW, I noticed this in the first post of this thread:
[quote]No manual files will be posted. All tests will be done on the server.[/quote]
Eh? I hadn't heard that we were doing this. This is kind of confusing. I mean, I don't see how manual files would cause any problems--in fact, considering as how we're doing this drive by k-range and all, I'd think that manual files would be quite easy to administrate.

Max :smile:

gd_barnes 2009-01-06 16:36

[quote=mdettweiler;157196]Added one core for a short while to check this out a bit. :smile: (In other news: I see that we're at ~168K already on k=1005! Wow! :grin: Though I guess that's somewhat to be expected considering how fast I was able to move on just one core back when I did k=1003 from 10K-500K on my own with mostly just one core...)

BTW, I noticed this in the first post of this thread:

Eh? I hadn't heard that we were doing this. This is kind of confusing. I mean, I don't see how manual files would cause any problems--in fact, considering as how we're doing this drive by k-range and all, I'd think that manual files would be quite easy to administrate.

Max :smile:[/quote]


We're at n=168K on k=1005 because David has 6 very fast cores on it.

Ian suggested that it would be a pain to "allow manual reservations" so I just ran with it. lol See his Jan. 5th post. Technically I'm somewhat indifferent but it would be nice to have a drive without posting files. The testing time loss for the older LLR version is minimal at such low n-ranges.

Can everyone please post their opinions on reserving manual files for this drive?

Gotta go now...back on in ~7 hours for a short bit.


Gary

mdettweiler 2009-01-06 16:48

[quote=gd_barnes;157202]We're at n=168K on k=1005 because David has 6 very fast cores on it.

Ian suggested that it would be a pain to "allow manual reservations" so I just ran with it. lol See his Jan. 5th post. Technically I'm somewhat indifferent but it would be nice to have a drive without posting files. The testing time loss for the older LLR version is minimal at such low n-ranges.

Can everyone please post their opinions on reserving manual files for this drive?

Gotta go now...back on in ~7 hours for a short bit.


Gary[/quote]
Hmm, I see what you're saying. And I can say that it would be nice not to have to continually worry about uploading new manual files for yet another team drive every time we reload the server. :smile:

But, how about this: we allow manual reservations, but not pre-posted; files would instead be available on request--sort of like what we did at the end of the 1st and 3rd Drives. That way, we can have manual reservations, yet essentially without any extra admin hassle than it would normally be to reload a server.

Max :smile:

Mini-Geek 2009-01-06 16:49

[quote=gd_barnes;157202]Ian suggested that it would be a pain to "allow manual reservations" so I just ran with it. lol See his Jan. 5th post. Technically I'm somewhat indifferent but it would be nice to have a drive without posting files. The testing time loss for the older LLR version is minimal at such low n-ranges.

Can everyone please post their opinions on reserving manual files for this drive?[/quote]
I think at the very least, you should allow specific manual reservations, but I don't see a need to post files before they're requested. (i.e. don't bother posting manual files without a reservation, but allow manual reservations and send the file when someone does)
Edit: ninja'd

mdettweiler 2009-01-06 16:55

[quote=Mini-Geek;157205]Edit: ninja'd[/quote]
??? :confused:

Mini-Geek 2009-01-06 17:03

[quote=mdettweiler;157207]??? :confused:[/quote]
It means that someone posted the exact same thing before I did and I didn't know about it, making mine basically a useless double post. I suppose that in a context like this where two people are agreeing on something, it's not quite the same as it usually is (like answering a simple question).

mdettweiler 2009-01-06 17:33

David, the progress report for port 9000 seems to be frozen at two hours ago (8:00 A.M. Arizona time). :huh:

IronBits 2009-01-06 22:43

I missed a script :cry:
But, it's all better now :grin:

mdettweiler 2009-01-06 22:46

[quote=IronBits;157263]I missed a script :cry:
But, it's all better now :grin:[/quote]
Thanks--looks good now. :smile:

IronBits 2009-01-06 23:01

Now that I'm home, folks can crank it up a notch :smile:
For comparison, the 10 cores I have on it now are comprised from
4 cores from a Q9450 and
4 cores from a Q6600
2 cores from a E8500.

gd_barnes 2009-01-06 23:46

[quote=mdettweiler;157204]Hmm, I see what you're saying. And I can say that it would be nice not to have to continually worry about uploading new manual files for yet another team drive every time we reload the server. :smile:

But, how about this: we allow manual reservations, but not pre-posted; files would instead be available on request--sort of like what we did at the end of the 1st and 3rd Drives. That way, we can have manual reservations, yet essentially without any extra admin hassle than it would normally be to reload a server.

Max :smile:[/quote]

[quote=Mini-Geek;157205]I think at the very least, you should allow specific manual reservations, but I don't see a need to post files before they're requested. (i.e. don't bother posting manual files without a reservation, but allow manual reservations and send the file when someone does)
Edit: ninja'd[/quote]


I agree with this. I don't have time to edit the 1st post now but yes, we can allow manual reservations upon request.


Gary

IronBits 2009-01-07 05:37

Port 9000 looks like it can handle [B]double[/B] what it is now.
sockets start at 6, saw it go up to 10 once, then back down to 6 as it handles the connections flawlessly.
I'm very happy with this llrnet server performance under CentOS 64bit. :smile:

We have completed [B]44475[/B] so far, it has about double that left to go, so I wouldn't be surprised if we run out by morning.

IronBits 2009-01-07 07:17

We completed [B]56546[/B] in 16 hours :grin:

em99010pepe 2009-01-07 07:20

Better add more work.

IronBits 2009-01-07 08:29

[B]63,398[/B] total for all servers, a new record! :grin:

[url]http://stats.ironbits.net/statsnew/stats_by_date.php[/url]

IronBits 2009-01-07 08:48

Just added 6 more cores w/20 cache set

Too bad the I7 is stuck on sieving till 11 Jan, or I would have tossed it on there to.

em99010pepe 2009-01-07 09:39

I would like to reserve 4k's to be run on my own llrnet server. Please send the file via PM or email. Thank you.

Carlos

henryzz 2009-01-07 09:54

[quote=IronBits;157346]Just added 6 more cores w/20 cache set

Too bad the I7 is stuck on sieving till 11 Jan, or I would have tossed it on there to.[/quote]
if you put your I7 on this at some point i would suggest using hyperthreading as more cores should overall be faster for so low numbers
i would guess slow computers wont be that much slower on this drive

kar_bon 2009-01-07 10:17

some 2 ct's from me:

- no manual reservations for this drive:
the range is small but to handle it (split files, send/receive results, verify completeness, display primes/done ranges in pages) is to heavy to handle

- i suggest only to put some 'slower' cpu's on this drive because we need the 'runners' for the higher n-ranges (Drives #5-#7)!

- keep the order: ascending k-values and within a k the ascending n-values:
it's quite easier for me to update the PrimeDatabase!

gd_barnes 2009-01-07 11:50

OMG. We have blown away over half the file that I sent already! I think it's already handing out k=1029 or 1031. I only sent up to k=1049.

David, I'm going to sent you a file over 3 times as big. The last file was k=1005-1049. The next one will be k=1051-1199. After that depending on the continued response, I'll send them in k=200 ranges, which will be 4 times as big as first file that I sent you. I'll try to make them last a week.

Karsten is right, this drive is better for slower machines but personally, I don't care as long as David's server can handle it. If people want to slay this range quickly, let's do it!

Yes, we will have a lot of results to match up but that's no big deal. We'll get it taken care of in good time.

Due to the huge response to these low n-ranges, I will keep my cores off of it unless it starts to wane.

Max, let's plan on processing the results on 100 k's at a time for this drive; perhaps even 200 k's. Otherwise we'll be doing them about every 1-2 days. lol


Gary

gd_barnes 2009-01-07 11:54

One thing here: It'd almost be better if people move a core or two back to the 5th-6th-7th drives. Not that we mind but it'd be nice to continue finding top-5000 primes too.


Gary

gd_barnes 2009-01-07 11:54

reserving k=1051-1199 for port 9000

gd_barnes 2009-01-07 13:13

[quote=em99010pepe;157354]I would like to reserve 4k's to be run on my own llrnet server. Please send the file via PM or email. Thank you.

Carlos[/quote]

Carlos,

With the way we are smoking through the ranges, are you sure you want to mess with loading 4 k's into your server? I think it'd be easier if you just stayed connected to port 9000 here. But if you really want them, I'll send you k=1201-1207 within a day.


Gary

IronBits 2009-01-07 14:59

Loaded up what you sent me, without a single hiccup when I restarted the server.

Port [B]9000[/B] has 178657 remaining knpairs!
knpairs.txt - Size: 2222009
Last Updated: 1/7/2009 7:55:39 AM
first k/n pair 1007 189180
last k/n pair 1049 199976
jobMaxTime = 1 * 24 * 3600 -- 1 days
prunePeriod = 1 * 1 * 3600 -- hourly

IronBits 2009-01-07 15:14

Backing off 6 cores that I put on before I went to bed to test the server a little more.
If you guys want to toss on a couple more cores, let er rip.

edit: ok, 6 cores moved back to port 5000

Flatlander 2009-01-07 16:48

[quote=IronBits;157393]Loaded up what you sent me, without a single hiccup when I restarted the server.

Port [B]9000[/B] has 178657 remaining knpairs!
knpairs.txt - Size: 2222009
Last Updated: 1/7/2009 7:55:39 AM
first k/n pair 1007 189180
last k/n pair 1049 199976
jobMaxTime = 1 * 24 * 3600 -- 1 days
prunePeriod = 1 * 1 * 3600 -- hourly[/quote]
I think the daily totals reset when you restarted. :smile:
[URL]http://nplb.ironbits.net/progress_9000.html[/URL]

IronBits 2009-01-07 18:12

I'll take a look and re-run the hourly stats.
I'm home all day if you guys want to see if you can break it :)

em99010pepe 2009-01-07 18:19

[quote=gd_barnes;157379]Carlos,

With the way we are smoking through the ranges, are you sure you want to mess with loading 4 k's into your server? I think it'd be easier if you just stayed connected to port 9000 here. But if you really want them, I'll send you k=1201-1207 within a day.


Gary[/quote]

Yesterday I was having some issues with some clients getting stuck but I suppose it was when everybody started to cache some wu's. For the last 24 hours the clients have been running without a problem. Please hold the files.

Carlos

henryzz 2009-01-07 20:02

how often are we expecting primes in this drive
i have found five primes and have tested 7200 numbers
i expected more primes

em99010pepe 2009-01-07 20:26

[quote=gd_barnes;157367]reserving k=1051-1199 for port 9000[/quote]

Is the server loaded with that work? IB?

Mini-Geek 2009-01-07 20:47

[quote=henryzz;157435]how often are we expecting primes in this drive
i have found five primes and have tested 7200 numbers
i expected more primes[/quote]
Assuming average k/base/n of 1100*2^275000-1 for 3600 candidates and 1100*2^125000-1 for 3600 candidates (to get a slightly more accurate value due to the extremely varying n-range) and sieve depth of 1800000000000 (1800G), you should expect 3.037 (2.088 from the lower range and 0.949 from the higher range) primes, so you're actually well above average.

henryzz 2009-01-07 21:49

[quote=Mini-Geek;157442]Assuming average k/base/n of 1100*2^275000-1 for 3600 candidates and 1100*2^125000-1 for 3600 candidates (to get a slightly more accurate value due to the extremely varying n-range) and sieve depth of 1800000000000 (1800G), you should expect 3.037 (2.088 from the lower range and 0.949 from the higher range) primes, so you're actually well above average.[/quote]
wierd because i am now up to 8 primes for 7900 tests

IronBits 2009-01-07 22:15

[quote=em99010pepe;157438]Is the server loaded with that work? IB?[/quote] If it wasn't, we would have been out of work by now. :wink:
Also, you can always look at the [url]http://nplb.ironbits.net[/url] status pages and see anything you need to know about a server and it's port.

IronBits 2009-01-07 22:16

user=henryzz
[2009-01-07 13:27:41]
1047*2^105974-1 is prime! Time : 60.0 sec.
user=henryzz
[2009-01-07 13:30:13]
1047*2^111341-1 is prime! Time : 69.0 sec.
user=henryzz
[2009-01-07 13:30:37]
1047*2^112293-1 is prime! Time : 64.0 sec.
:smile:

Can we get this fixed please?
[B] This forum requires that you wait 60 seconds between posts. Please try again in 41 seconds. [/B]
Can't hardly get anything done ... :cry:

em99010pepe 2009-01-07 22:26

[quote=IronBits;157464]If it wasn't, we would have been out of work by now. :wink:
Also, you can always look at the [URL]http://nplb.ironbits.net[/URL] status pages and see anything you need to know about a server and it's port.[/quote]

We would still have some work to do, last k from last range added was 1049.

So something is wrong, look at the server info:
first k/n pair 1011 106059
last k/n pair 1049 199976

EDIT: Anyway, my doubt will vanish within 20-30 mins if the server starts sending the next k (1051). The problem will be a script issue for not showing the correct info of the server.

em99010pepe 2009-01-07 22:30

[quote=IronBits;157466]

Can we get this fixed please?
[B] This forum requires that you wait 60 seconds between posts. Please try again in 41 seconds. [/B]
Can't hardly get anything done ... :cry:[/quote]

What's 1 min when you had to wait 9 months for your children to be born...lol

em99010pepe 2009-01-07 22:38

I think more work should be added to the server because we are going to hit ~100k candidates per day. Put something like a week of work in there.

IronBits 2009-01-07 22:49

You can always look at these links to...
[URL="http://nplb.ironbits.net/progress_9000.html"]Progress Report for port 9000[/URL]
[URL="http://nplb.ironbits.net/results_9000.txt"]Copy of current Results.txt[/URL]
[URL="http://nplb.ironbits.net/knpairs_9000.txt"]Copy of current KNpairs.txt[/URL]
[URL="http://nplb.ironbits.net/joblist_9000.txt"]Copy of current joblist.txt[/URL]
[URL="http://nplb.ironbits.net/rejected_9000.txt"]Copy of current rejected.txt[/URL]
[URL="http://nplb.ironbits.net/primes_9000.txt"]All Primes found on Port 9000[/URL]

We'll be hitting 1013 shortly

[code]
1011 106059
1011 156898
1011 166529
1011 168318
1011 168822
1011 169650
1011 170046
1011 170514
1011 170763
1011 171238
1011 171779
1011 172191
1011 172641
1011 172991
1011 173350
1011 173731
1011 174150
1011 174910
1011 175398
1011 175671
1011 176097
1011 176489
1011 176883
1011 177347
1011 177673
1011 177919
1011 178411
1011 178839
1011 179249
1011 179667
1011 180030
1011 180553
1011 181081
1011 181806
1011 182271
1011 182703
1011 183011
1011 183450
1011 183954
1011 184303
1011 184569
1011 184870
1011 185327
1011 185831
1011 186286
1011 186559
1011 187019
1011 187283
1011 188081
1011 188411
1011 188871
1011 189431
1011 189807
1011 190183
1011 190626
1011 191034
1011 191399
1011 191839
1011 192359
1011 192687
1011 193043
1011 193338
1011 193794
1011 194291
1011 194931
1011 195279
1011 195706
1011 196171
1011 196739
1011 197147
1011 197790
1011 198163
1011 198510
1011 198906
1011 199299
1011 199587
1011 199919
1013 52282
1013 57428
[/code]

em99010pepe 2009-01-07 22:51

Did you add the correct file? Why are we redoing k=1005? Someone sent those and you got them as rejected or someone downloaded a bunch of them and did not process them. ??!!!

EDIT: Going to check your files.

em99010pepe 2009-01-07 22:53

STOP THE SERVER, YOU ADDED THE WRONG FILE....

You need to go to the middle of knpairs and take the double work you add. If you look at the file you have twice the work from 1005-1049.

IronBits 2009-01-07 22:54

We'll be going to
1015 50623[FONT=monospace]
[/FONT]1015 53251

as soon as we finish 1013

mdettweiler 2009-01-07 22:54

[quote=em99010pepe;157479]Did you add the correct file? Why are we redoing k=1005? Someone sent those and you got them as rejected or someone downloaded a bunch of them and did not process them. ??!!!

EDIT: Going to check your files.[/quote]
Yes, I'm reading k=1005 right after k=1047 in the knpairs.txt file...it seems that the original file was loaded a second time somewhere along the way. :sick:

David, after the first instance of k=1047 in the knpairs.txt file, remove everything from there to the end of the file, and then re-load the new file that Gary sent you.

IronBits 2009-01-07 22:55

Crap!
What should be there, and where in the knpairs.txt do I start adding in the new file?

em99010pepe 2009-01-07 22:57

[quote=IronBits;157483]Crap!
What should be there, and where in the knpairs.txt do I start adding in the new file?[/quote]

After:

1049 199484
1049 199500
1049 199556
1049 199580
1049 199760
1049 199872
1049 199892
1049 199944
1049 199976

you should add the 1051-1199 work (without the header)

IronBits 2009-01-07 22:59

It starts with
1005 50006
1005 50034

I have another one that starts with
1051 50053
1051 50119
1051 50269

sieve1050-1200-50K-200K.txt

em99010pepe 2009-01-07 22:59

[quote=IronBits;157486]It starts with
1005 50006
1005 50034

right?[/quote]

Yes. Line 6728.

mdettweiler 2009-01-07 23:01

[quote=em99010pepe;157487]Yes. Line 6728.[/quote]
...and the one with:

1051 50053
1051 50119
1051 50269

should be the one you're loading in now.

em99010pepe 2009-01-07 23:03

We are only stopped for 10 mins, it's not important. IB, take your time.
Clients we high cache should check workfile.txt with k=1005 work and delete it.

IronBits 2009-01-07 23:05

Done, the file is HUGE now. My BAD!
I'll get that area cleaned up so that it doesn't happen again.

Flatlander 2009-01-07 23:06

I'm still being issued k=1005.

em99010pepe 2009-01-07 23:07

[quote=IronBits;157492]Done, the file is HUGE now. My BAD!
I'll get that area cleaned up so that it doesn't happen again.[/quote]

Are you sure? I'm still getting some k=1005 work.

mdettweiler 2009-01-07 23:08

[quote=em99010pepe;157495]Are you sure? I'm still getting some k=1005 work.[/quote]
Me too...David, did you remember to delete the second copy of the 1005-1049 stuff before adding the 1051-1099 stuff?

IronBits 2009-01-07 23:10

knpairs.txt shows
...
1047 199892
1047 199934
1051 50053
1051 50119
1051 50269

em99010pepe 2009-01-07 23:10

Did you stop the server before adding the work?

mdettweiler 2009-01-07 23:17

David, check your mail if you're not doing so already...

em99010pepe 2009-01-07 23:17

I think we made a mistake...the work should be added after k=1005. Now the server is confused, maybe it's better to delete joblist.txt, I don't know!!!

EDIT: Forget my statement, the server is up and running. I am already getting k=1051. Good job IB. Now I can sleep in peace...lol

IronBits 2009-01-07 23:19

[URL="file:///S:/nplbserver9000/knpairs.txt"][/URL]Ok, new knpairs.txt is online.
I looked at the first file Gary gave me and found the last pair
sieve1005-1050-50K-200K.txt
1049 199892
1049 199944
1049 199976 <----
found that in knpairs.txt deleted everything past that line

Looked at the next file sieve1050-1200-50K-200K.txt
It starts with
1051 50053
1051 50119
1051 50269

We should be good to go, yes?

mdettweiler 2009-01-07 23:20

[quote=IronBits;157502]Ok, new knpairs.txt is online.
I looked at the first file Gary gave me and found the last pair
sieve1005-1050-50K-200K.txt
1049 199892
1049 199944
1049 199976 <----
found that in knpairs.txt deleted everything past that line

Looked at the next file sieve1050-1200-50K-200K.txt
It starts with
1051 50053
1051 50119
1051 50269

We should be good to go, yes?[/quote]
Perfect! :grin:

em99010pepe 2009-01-07 23:21

[quote=IronBits;157502]Ok, new knpairs.txt is online.
I looked at the first file Gary gave me and found the last pair
sieve1005-1050-50K-200K.txt
1049 199892
1049 199944
1049 199976 <----
found that in knpairs.txt deleted everything past that line

Looked at the next file sieve1050-1200-50K-200K.txt
It starts with
1051 50053
1051 50119
1051 50269

We should be good to go, yes?[/quote]

It's good, thank you.

IronBits 2009-01-07 23:22

Well, we found another problem...
The server is rock solid, however, the operator is apparently missing some cards...

Glad I was here to fix it!
Did we do any duplicate work???????

Flatlander 2009-01-07 23:22

Thanks guys. Your hard work is appreciated. My feet are getting warm again. :smile:

edit:

or
You got a bunch of guys about to turn blue. We're breathing again. Thanks a lot.

mdettweiler 2009-01-07 23:24

[quote=IronBits;157506]Did we do any duplicate work???????[/quote]
A little, but I've got a duplicate-removal script that can remove the extras easily when I process the results.

em99010pepe 2009-01-07 23:24

[quote=IronBits;157506]Well, we found another problem...
The server is rock solid, however, the operator is apparently missing some cards...

Glad I was here to fix it!
Did we do any duplicate work???????[/quote]

It's an age issue...lol
Yes we did, I even found a prime for k=1005.

IronBits 2009-01-07 23:29

The database won't allow dupes, so we are ok there.

Sorry guys! Hope I didn't waste too much of your precious energy :cry:

em99010pepe 2009-01-07 23:34

[quote=IronBits;157510]The database won't allow dupes, so we are ok there.

Sorry guys! Hope I didn't waste too much of your precious energy :cry:[/quote]

I lost some energy...

IronBits 2009-01-07 23:40

One of these days I'll understand what all these numbers mean...
At least I know what column k and n are in now. :wink:

em99010pepe 2009-01-07 23:42

[quote=IronBits;157512]One of these days I'll understand what all these numbers mean...
At least I know what column k and n are in now. :wink:[/quote]

For me all of this means it's a waste of energy. We don't need this for our future. It's a stupid hobbie but I like it...lol

IronBits 2009-01-07 23:49

I don't like Boinc, so my projects to choose from are limited.
Finding a prime doesn't mean much to me yet, however, watching these FAST ones go flying by is fun :smile:


All times are UTC. The time now is 07:36.

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