|
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 |
[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 |
[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.) |
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: |
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 |
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: |
[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. |
[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: |
[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. |
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? |
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 |
[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 |
[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. |
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 |
[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 |
[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. |
[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 |
[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: |
[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 |
[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. |
[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. |
[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: |
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=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 |
Reserving k=1005-1049 for port 9000. The drive is ready to go!
Gary |
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=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 |
3 cores at the moment, 4 (total) later.
|
i have just put 2 on
|
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: |
[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 |
[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: |
[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 |
[quote=Mini-Geek;157205]Edit: ninja'd[/quote]
??? :confused: |
[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). |
David, the progress report for port 9000 seems to be frozen at two hours ago (8:00 A.M. Arizona time). :huh:
|
I missed a script :cry:
But, it's all better now :grin: |
[quote=IronBits;157263]I missed a script :cry:
But, it's all better now :grin:[/quote] Thanks--looks good now. :smile: |
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. |
[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 |
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. |
We completed [B]56546[/B] in 16 hours :grin:
|
Better add more work.
|
[B]63,398[/B] total for all servers, a new record! :grin:
[url]http://stats.ironbits.net/statsnew/stats_by_date.php[/url] |
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. |
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=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 |
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! |
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 |
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 |
reserving k=1051-1199 for port 9000
|
[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 |
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 |
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 |
[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] |
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 :) |
[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 |
how often are we expecting primes in this drive
i have found five primes and have tested 7200 numbers i expected more primes |
[quote=gd_barnes;157367]reserving k=1051-1199 for port 9000[/quote]
Is the server loaded with that work? IB? |
[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. |
[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 |
[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. |
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: |
[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. |
[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 |
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.
|
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] |
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. |
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. |
We'll be going to
1015 50623[FONT=monospace] [/FONT]1015 53251 as soon as we finish 1013 |
[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. |
Crap!
What should be there, and where in the knpairs.txt do I start adding in the new file? |
[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) |
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 |
[quote=IronBits;157486]It starts with
1005 50006 1005 50034 right?[/quote] Yes. Line 6728. |
[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. |
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. |
Done, the file is HUGE now. My BAD!
I'll get that area cleaned up so that it doesn't happen again. |
I'm still being issued k=1005.
|
[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. |
[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? |
knpairs.txt shows
... 1047 199892 1047 199934 1051 50053 1051 50119 1051 50269 |
Did you stop the server before adding the work?
|
David, check your mail if you're not doing so already...
|
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 |
[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? |
[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: |
[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. |
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??????? |
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. |
[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. |
[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. |
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=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... |
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=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 |
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 12:46. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.