|
Team drive #8 k=1400-2000 n=350K-500K
[COLOR=black][FONT=Verdana]This is team drive #8 for No Prime Left Behind. We will be searching all k=1400-2000 for n=350K-500K.[/FONT][/COLOR]
Karsten (kar_bon) has created a web page that shows details for the drive [URL="http://www.rieselprime.de/NPLB/Drives/NPLB_Drive8.htm"]here[/URL]. He maintaines a site that has almost all known Riesel primes. There is a page for the range of 300<k<2000 [URL="http://www.rieselprime.org/Data/00300.htm"][COLOR=#800080]here[/COLOR][/URL]. The ranges searched and primes found from this project will be shown there. An excellent LLRnet server will be processing a large part 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]. The info. specific to the server that needs to be entered into your llr-clientconfig.txt file is: server = "nplb.ironbits.net" port = 8000 We have divided the manual files up into n=500 pieces. [COLOR=black][FONT=Verdana]There should be an average of around 5700 candidates in each file and should take about 1-2 CPU weeks to test for the current level of n-ranges. Feel free to take as many files as you can complete in around 3-4 weeks.[/FONT][/COLOR] Please report all reservations/statuses/completions for this drive in this thread. Please report all primes found in the 'Report all k=1003-2000 primes here' thread. Please post all results files in this thread or send them to me at: gbarnes017 at gmail dot com. Please report all top-5000 primes with a project ID of 'PrimeSearch'. [FONT=Verdana][COLOR=black]New primes found from drive #8:[/COLOR][/FONT] [code] Prime found by 1887*2^499338-1 Flatlander 1885*2^498607-1 gamer007 1403*2^497854-1 PCZ 1595*2^497756-1 vaughan 1875*2^495775-1 kar_bon 1779*2^495289-1 PCZ 1593*2^494915-1 vaughan 1855*2^493389-1 vaughan 1931*2^492970-1 PCZ 1611*2^492905-1 PCZ 1895*2^492900-1 henryzz 1425*2^492263-1 vaughan 1681*2^492221-1 Flatlander 1771*2^492075-1 PCZ 1623*2^491038-1 Flatlander 1853*2^490210-1 IronBits 1973*2^490134-1 IronBits 1669*2^490105-1 vaughan 1789*2^489891-1 PCZ 1507*2^486901-1 henryzz 1869*2^486293-1 IronBits 1881*2^485590-1 vaughan 1649*2^485120-1 vaughan 1501*2^484947-1 PCZ 1951*2^483481-1 Flatlander 1767*2^483281-1 PCZ 1761*2^483045-1 vaughan 1623*2^481564-1 PCZ 1509*2^480731-1 vaughan 1737*2^480454-1 vaughan 1761*2^480153-1 vaughan 1785*2^479966-1 PCZ 1727*2^479638-1 PCZ 1755*2^479628-1 Flatlander 1653*2^479500-1 henryzz 1531*2^479097-1 vaughan 1789*2^477639-1 PCZ 1757*2*476948-1 vaughan 1487*2^475980-1 vaughan 1881*2^475361-1 PCZ 1663*2^474731-1 MrOzzy 1731*2^473589-1 IronBits 1911*2^473158-1 PCZ 1957*2^473121-1 vaughan 1535*2^472338-1 PCZ 1717*2^472261-1 kar_bon 1883*2^470382-1 PCZ 1887*2^469709-1 PCZ 1707*2^468726-1 vaughan 1997*2^468642-1 PCZ 1607*2^468062-1 PCZ 1591*2^467191-1 IronBits 1437*2^466834-1 PCZ 1893*2^466486-1 PCZ 1765*2^466267-1 gd_barnes 1851*2^465493-1 PCZ 1767*2^465385-1 vaughan 1755*2^464639-1 PCZ 1415*2^464458-1 PCZ 1557*2^462980-1 PCZ 1683*2^462620-1 PCZ 1501*2^462581-1 PCZ 1821*2^460466-1 gd_barnes 1725*2^460152-1 PCZ 1571*2^459950-1 PCZ 1735*2^459265-1 PCZ 1995*2^458684-1 PCZ 1403*2^458616-1 IronBits 1429*2^458533-1 PCZ 1823*2^457696-1 gd_barnes 1669*2^457493-1 gd_barnes 1955*2^457290-1 PCZ 1761*2^457262-1 PCZ 1725*2^455905-1 PCZ 1917*2^454169-1 vaughan 1893*2^453455-1 PCZ 1711*2^453095-1 PCZ 1911*2^452921-1 PCZ 1909*2^452845-1 PCZ 1953*2^450228-1 PCZ 1939*2^450199-1 PCZ 1737*2^448789-1 Flatlander 1729*2^448341-1 vaughan 1847*2^447338-1 PCZ 1531*2^446563-1 gd_barnes 1763*2^445858-1 PCZ 1811*2^445730-1 PCZ 1965*2^445060-1 PCZ 1803*2^445028-1 gd_barnes 1989*2^444247-1 gd_barnes 1641*2^444102-1 PCZ 1445*2^443720-1 Flatlander 1865*2^443434-1 PCZ 1895*2^443266-1 Flatlander 1819*2^443181-1 PCZ 1863*2^442783-1 PCZ 1555*2^442739-1 MrOzzy 1469*2^440588-1 gd_barnes 1639*2^440183-1 PCZ 1647*2^439614-1 vaughan 1839*2^439432-1 PCZ 1551*2^439313-1 PCZ 1889*2^438920-1 PCZ 1629*2^438032-1 PCZ 1691*2^437654-1 PCZ 1997*2^437370-1 gd_barnes 1509*2^436745-1 vaughan 1595*2^436580-1 Flatlander 1725*2^436215-1 PCZ 1797*2^434365-1 vaughan 1971*2^434283-1 gd_barnes 1967*2^433926-1 gd_barnes 1931*2^433494-1 PCZ 1959*2^433467-1 PCZ 1539*2^432959-1 Flatlander 1459*2^432001-1 gd_barnes 1585*2^430625-1 vaughan 1793*2^430592-1 gd_barnes 1945*2^430323-1 gd_barnes 1629*2^426853-1 gd_barnes 1755*2^426546-1 IronBits 1633*2^426379-1 PCZ 1615*2^425081-1 IronBits 1919*2^424768-1 gd_barnes 1909*2^423807-1 vaughan 1663*2^422315-1 gd_barnes 1673*2^422206-1 PCZ 1909*2^419663-1 PCZ 1647*2^419136-1 PCZ 1671*2^418847-1 mdettweiler 1965*2^418747-1 PCZ 1501*2^418681-1 PCZ 1425*2^418169-1 PCZ 1847*2^418054-1 Petey 1891*2^417251-1 PCZ 1671*2^417223-1 PCZ 1671*2^416347-1 gd_barnes 1811*2^413438-1 Ironbits 1563*2^413079-1 vaughan 1487*2^412806-1 PCZ 1915*2^412085-1 IronBits 1897*2^411321-1 IronBits 1625*2^411110-1 PCZ 1879*2^410983-1 PCZ 1883*2^408564-1 Bok 1441*2^407745-1 LaurenU2 1945*2^407283-1 MyDogBuster 1847*2^407094-1 Fozzie 1593*2^406836-1 vaughan 1505*2^404768-1 gd_barnes 1659*2^402920-1 Beyond 1447*2^400365-1 LaurenU2 1489*2^398757-1 MyDogBuster 1479*2^398223-1 Beyond 1863*2^397915-1 Beyond 1625*2^397258-1 Beyond 1629*2^397213-1 MyDogBuster 1817*2^396648-1 Beyond 1875*2^394864-1 Bok 1467*2^393086-1 MyDogBuster 1875*2^392871-1 Ironbits 1487*2^392568-1 Beyond 1629*2^392428-1 gd_barnes 1979*2^392404-1 gd_barnes 1561*2^392253-1 Beyond 1955*2^391522-1 Beyond 1803*2^391127-1 henryzz 1887*2^390993-1 PCZ 1959*2^389797-1 Free-DC Mercenaries 1821*2^389237-1 PCZ 1889*2^389032-1 Petey 1953*2^388967-1 Beyond 1491*2^388903-1 Free-DC Mercenaries 1445*2^388290-1 LaurenU2 1985*2^388208-1 MrOzzy 1647*2^387870-1 Petey 1449*2^386620-1 LaurenU2 1821*2^385633-1 Beyond 1831*2^385475-1 Beyond 1855*2^384059-1 MyDogBuster 1817*2^381708-1 Free-DC Mercenaries 1473*2^381363-1 AMDave 1957*2^380189-1 Free-DC Mercenaries 1887*2^379364-1 MyDogBuster 1887*2^377976-1 LaurenU2 1999*2^376443-1 IronBits 1969*2^375669-1 Beyond 1631*2^375114-1 PCZ 1849*2^374015-1 Beyond 1865*2^372352-1 gd_barnes 1953*2^370639-1 PCZ 1853*2^370128-1 LaurenU2 1505*2^370016-1 Flatlander 1637*2^368470-1 gd_barnes 1683*2^366866-1 Flatlander 1941*2^365467-1 gd_barnes 1667*2^365342-1 gd_barnes 1601*2^365302-1 MyDogBuster 1655*2^365228-1 MyDogBuster 1955*2^364156-1 gd_barnes 1661*2^362878-1 gd_barnes 1689*2^362388-1 gd_barnes 1629*2^362181-1 Flatlander 1697*2^361566-1 Flatlander 1625*2^361306-1 gd_barnes 1609*2^359209-1 gd_barnes 1671*2^357110-1 Flatlander 1623*2^356936-1 gd_barnes 1617*2^356462-1 gd_barnes 1663*2^356015-1 gd_barnes 1669*2^353119-1 gd_barnes 1643*2^352664-1 gd_barnes 1643*2^352606-1 MyDogBuster 1923*2^352462-1 gd_barnes 1673*2^352222-1 Flatlander 1943*2^352182-1 MyDogBuster 1647*2^351262-1 nuggetprime [/code][FONT=Verdana][COLOR=black]Primes confirmed from drive #8:[/COLOR][/FONT] [code] Prime found by 1791*2^492279-1 kar_bon 1559*2^491984-1 PCZ 1529*2^487800-1 MrOzzy 1605*2^485583-1 vaughan 1577*2^485232-1 Flatlander 1455*2^480180-1 PCZ 1575*2^476247-1 Flatlander 1485*2^464029-1 PCZ 1599*2^463571-1 PCZ 1511*2^459846-1 PCZ 1523*2^454040-1 PCZ 1587*2^448493-1 PCZ 1533*2^445512-1 gd_barnes 1423*2^444231-1 PCZ 1587*2^442424-1 gd_barnes 1587*2^442185-1 PCZ 1573*2^439471-1 vaughan 1635*2^433506-1 gd_barnes 1575*2^433354-1 PCZ 1791*2^433299-1 PCZ 1935*2^430904-1 vaughan 1515*2^430504-1 PCZ 1545*2^426823-1 PCZ 1603*2^425391-1 vaughan 1755*2^424305-1 vaughan 1971*2^423714-1 gd_barnes 1711*2^423163-1 IronBits 1665*2^423149-1 gd_barnes 1583*2^422792-1 Petey 1991*2^422322-1 IronBits 1935*2^421982-1 mdettweiler 1995*2^421527-1 vaughan 1665*2^417021-1 vaughan 1521*2^416257-1 PCZ 1755*2^416185-1 JeffGilchrist 1743*2^416002-1 PCZ 1721*2^413634-1 PCZ 1749*2^411647-1 gd_barnes 1577*2^411304-1 PCZ 1427*2^409722-1 LaurenU2 1409*2^408568-1 Bok 1559*2^406648-1 LaurenU2 1431*2^405961-1 IronBits 1461*2^404851-1 PCZ 1989*2^404083-1 gd_barnes 1587*2^402941-1 IronBits 1655*2^400052-1 LaurenU2 1729*2^400007-1 MyDogBuster 1591*2^399861-1 Lennart 1905*2^399686-1 Ironbits 1503*2^397527-1 gd_barnes 1749*2^397157-1 IronBits 1431*2^396111-1 MrOzzy 1797*2^393797-1 gd_barnes 1761*2^393653-1 MyDogBuster 1741*2^392029-1 Beyond 1749*2^391615-1 IronBits 1515*2^391554-1 MyDogBuster 1427*2^391542-1 Beyond 1665*2^391531-1 glennpat 1731*2^390343-1 Beyond 1935*2^390087-1 Beyond 1431*2^389415-1 Beyond 1475*2^388108-1 Beyond 1501*2^386595-1 Bok 1471*2^386575-1 LaurenU2 1547*2^385550-1 Free-DC Mercenaries 1779*2^384925-1 MyDogBuster 1715*2^384264-1 gd_barnes 1545*2^384032-1 PCZ 1757*2^383700-1 LaurenU2 1507*2^380353-1 MyDogBuster 1493*2^377656-1 Beyond 1815*2^376878-1 LaurenU2 1605*2^375489-1 PCZ 1583*2^374660-1 gd_barnes 1569*2^374255-1 Beyond 1595*2^374112-1 Beyond 1459*2^373251-1 Ironbits 1577*2^373062-1 AMDave 1555*2^372227-1 Free-DC Mercenaries 1525*2^372061-1 LaurenU2 1727*2^370942-1 MyDogBuster 1561*2^369477-1 LaurenU2 1463*2^368756-1 LaurenU2 1527*2^366989-1 em99010pepe 1635*2^366428-1 Brucifer 1587*2^365549-1 Flatlander 1483*2^365027-1 gd_barnes 1587*2^364520-1 gd_barnes 1493*2^364348-1 gd_barnes 1603*2^364139-1 Flatlander 1557*2^362769-1 gd_barnes 1783*2^362647-1 gd_barnes 1475*2^362176-1 gd_barnes 1815*2^360187-1 MyDogBuster 1785*2^359725-1 gd_barnes 1403*2^359146-1 gd_barnes 1577*2^356616-1 IronBits 1487*2^356506-1 gd_barnes 1517*2^356384-1 gd_barnes 1737*2^355712-1 gd_barnes 1485*2^355643-1 gd_barnes 1575*2^355060-1 IronBits 1483*2^355039-1 MyDogBuster 1557*2^353309-1 gd_barnes 1699*2^352587-1 gd_barnes 1567*2^352397-1 gd_barnes 1539*2^352111-1 MyDogBuster 1491*2^351886-1 gd_barnes 1457*2^351812-1 IronBits 1127*2^351674-1** henryzz 1195*2^351457-1** em99010pepee 1371*2^351106-1** gd_barnes [/code][COLOR=black][FONT=Verdana]Status:[/FONT][/COLOR] [code] n-range tested by Status # primes 480.0K-500.0K LLRnet (IB8000) complete 31 (plus 6 confirmed) 460.0K-480.0K LLRnet (IB8000) complete 33 (plus 3 confirmed) 451.5K-460.0K LLRnet (IB8000) complete 15 (plus 2 confirmed) 450.0K-451.5K PCZ complete 2 440.0K-450.0K LLRnet (IB8000) complete 18 (plus 5 confirmed) 420.0K-440.0K LLRnet (IB8000) complete 28 (plus 16 confirmed) 400.0K-420.0K LLRnet (IB8000) complete 25 (plus 16 confirmed) 380.0K-400.0K LLRnet (IB8000) complete 31 (plus 24 confirmed) 360.5K-380.0K LLRnet (IB8000) complete 22 (plus 24 confirmed) 360.0K-360.5K MyDogBuster complete 0 (1 confirmed) 350.0K-360.0K LLRnet (IB8000) complete 12 (plus 15 confirmed) 350.0K-352.0K** LLRnet (IB8000) complete 0 (3 confirmed) [/code] **k=1005-1400 searched for one n-range before receiving results from Peter Benson. There should be a ton of top-5000 primes in this area so let's roll! :smile: [B]The drive is now complete![/B] [FONT=Verdana]Gary[/FONT] |
[quote=gd_barnes;155790]With the primes just pouring in at top-5000 as a result of PrimeGrid running an effort on the Proth side similar to what we are currently for k<1200 and at lower n-ranges, it looks like n=350K will be at n=350K by Jan. 5th or earlier.
Since people reserved and divided up their ranges on their cores assuming a Jan. 15th completion date, we'll stick with our plans here but I'll put another quad on it starting later today or on Weds that will boost the reserved ranges to P=~7T. On Jan. 5th, my 1st 2 quads will finish and I'll be able to do another P=1.6T range by Jan. 15th. That would put it at P=8.6T so we'd likely just need a few more smaller reservations to get us where we need to be. The drive will still be n=350K-500K but the first few primes may be non-top-5000. I'm now estimating that the 5000th prime will be at n=351K by the time we start. As if we hadn't done so already, PrimeGrid has demonstrated conclusively that our method of searching for primes is the wave of the future! :smile: Gary[/quote] I think having an efficient sieve is more important than missing out on a few reportable primes. :smile: (I'm more worried about my dozens of top-5000 primes that will be pushed out soon.:cry:) [B]edit:[/B] But why not start a drive for 350-352k now, and get them registered? My reservation will finish late 01/01/09 GMT. (Looks like >20,000 factors.) |
[quote=Flatlander;155800]I think having an efficient sieve is more important than missing out on a few reportable primes. :smile:
(I'm more worried about my dozens of top-5000 primes that will be pushed out soon.:cry:) [B]edit:[/B] But why not start a drive for 350-352k now, and get them registered?[/quote] Well, that's a no-brainer. Why didn't I think of that? Duh. :smile: Ian, how far from completion are you on the P=1.4T-1.8T range? If you're < 3 days from completion, we'll wait on it. If we're gonna be undersieved for part of it, we may as well minimize how much we are undersieved by. lol Max and others, what do you think about getting the drive started on late Tues. or Weds. or Thurs. for n=350K-352K with sieving only at P=1.4T or 1.8T? I don't want to make a big mess out of this by stopping everyone in the middle of sieving to start on LLRing and then having the sieving get put off for a long time so that we're stressing on sieving again. We could get in a nasty circle. We'll have to discuss resource allocation later today to avoid that scenario. I need to go now but I'll need to get an approximate estimated time to complete n=350K-352K so that we can have an informed discussion about it. No worries Chris, you'll get your primes back plus plenty more with this drive. Even though we'll be knocking our own primes off the list quite a bit, there will be many more to replace them than are knocked off. Gary |
Bring the files....if you want I can set up a llrnet server.
|
[quote=gd_barnes;155805]Max and others, what do you think about getting the drive started on late Tues. or Weds. or Thurs. for n=350K-352K with sieving only at P=1.4T or 1.8T?[/quote]
Okay, I like that idea! :grin: BTW @Carlos: Thanks for the offer of running a server, though that probably won't be necessary since we already have had a G8000 server all pre-readied for this effort. However, yes, we'll definitely keep you in mind in case we need any more. :smile: (For these smaller k/n pairs, server load is somewhat higher than it is at the higher k/n pairs, so we may very well need a second server for this range.) Hey, I just thought of an idea: how about, in addition to any LLRnet servers that we have going for this range, I run a PRPnet server for it? I'm beginning to get the hang of how this whole PRPnet thing works now, and I'm planning to write some scripts later today to ensure that PRPnet will fit into our existing stats and status-page setup. Setting up a second server for the 9th Drive would not be hard at all. Not to mention that PRPnet uses LLR 3.7.1c for numbers on power-of-2 bases. :big grin: Max :smile: |
[quote=mdettweiler;155837]Okay, I like that idea! :grin:
BTW @Carlos: Thanks for the offer of running a server, though that probably won't be necessary since we already have had a G8000 server all pre-readied for this effort. However, yes, we'll definitely keep you in mind in case we need any more. :smile: (For these smaller k/n pairs, server load is somewhat higher than it is at the higher k/n pairs, so we may very well need a second server for this range.) Hey, I just thought of an idea: how about, in addition to any LLRnet servers that we have going for this range, I run a PRPnet server for it? I'm beginning to get the hang of how this whole PRPnet thing works now, and I'm planning to write some scripts later today to ensure that PRPnet will fit into our existing stats and status-page setup. Setting up a second server for the 9th Drive would not be hard at all. Not to mention that PRPnet uses LLR 3.7.1c for numbers on power-of-2 bases. :big grin: Max :smile:[/quote] OK, let's just run n=350K-352K sieved to P=1.4T. It'd be too messy and risky to wait for higher factors from Ian and myself. I could actually complete my P=1.8T-3.4T range in 2 days if I put it on all 9 of my working quads but that would take me quite a bit of time to do because I'd have to piecemeal out the P-ranges that haven't been done yet. I also don't want to impose upon Ian to do the same with his range. It's just time-consuming to bring all the factors back together from so many cores. By just using the P=1.4T file, after everyone is done with their sieving, we'll just systematically apply all the factors P>1.4T to the entire file in an orderly fashion. I need order for my disorderly mind. lol Running it to n=352K should work and take the pressure off of the sieving effort a little. It'll be a while before the 5000th prime is at 352K. (>4-5 weeks I think) Max, let's hold off on the PRPnet server since we need to complete the range within a fairly short timeframe. It will take a little time for people to download everything and orient themselves to the new server software. Although that shouldn't take each person too long, I don't want to be derailed by any potential issues that there could be in the new software. Instead, let's plan on using PRPnet for n>352K after the sieving is done. As for running a server for this range, let's just use port 8000 that you've already set up. That was its intent. I'm not going to recommend any kind of resource allocation to anyone. Everyone knows the situation on the 5000th place prime. Likely I'll put 2 quads in on the LLRing effort but may put as many as 5-6 on it depending on how popular the effort is and how quickly the 5000th place prime is moving up. In other words, I'll wait to see what the response is before shifting anything more than 2 quads. This is a good effort for people with lesser resources and I don't want the higher-resource folks to take most of the fun. :smile: Max, have I sent you the n=200K-500K file for k=1005-2000 sieved to P=1.4T? If not, I'll send it to you right away. Just let me know. Let's plan on loading n=350K-351K in the server to get that cracking almost immediately at fairly high speed. We'll leave n=351K-352K for manual reservations in n=100 pieces. Keep in mind that n=100 ranges will actually be ~70%+ larger than n=100 ranges on the 1st drive at the same n-range. That is about ~67% more k's plus likely 3-5% more candidates due to a sieve to P=1.4T vs. 5T. I'll get the drive set up with manual-reservation files posted for n=351K-352K sometime in the morning between 6 and 8 AM GMT (midnight to 2 AM my time). Please plan on completing any manual reservation in < 2 weeks to make sure we stay ahead of the 5000th place prime. If an n=100 file is too big for you, you'll be able to reserve part of a file if you want. So that people have an idea of the size of the files, I'll post a # of candidates by each file. One more thing Max...Please look on Karsten's pages and see who has reservations in the area. We already know about Thomas and I think Adam has a reservation or two in the area. I will PM them about the start of our effort. I doubt we'll impact anyone with n=350K-352K but don't want to give a bad perception if we are. Let's move the goal for completing sieving back to Jan. 20th. I should still complete mine by Jan. 15th-16th because I'll pull quads off of port 5000 to put on LLRing n=350K-352K. The 5000th place prime shouldn't be near n=352K by the 20th but we don't want to push our luck in that regard. PrimeGrid has really been submitting the primes lately. Thanks for being flexible everyone! :smile: Edit: Would it make more sense to use a server by Carlos since he has offered? I'm going to Vegas from Thursday to Wednesday. If we do that, we'd just use his server for this range and plan on using port 8000 for most of the LLRnet ranges for n>352K. Gary |
[quote=gd_barnes;155937]Max, let's hold off on the PRPnet server since we need to complete the range within a fairly short timeframe. It will take a little time for people to download everything and orient themselves to the new server software. Although that shouldn't take each person too long, I don't want to be derailed by any potential issues that there could be in the new software. Instead, let's plan on using PRPnet for n>352K after the sieving is done. As for running a server for this range, let's just use port 8000 that you've already set up. That was its intent.[/quote]
Okay, that sounds good, especially in light of how there have been a few new issues that have cropped up with PRPnet as described in the PRPnet thread over at CRUS. Thus, I'm thinking that we shouldn't even consider setting up a second server until we've gotten things running somewhat more smoothly. :smile: [quote]Max, have I sent you the n=200K-500K file for k=1005-2000 sieved to P=1.4T? If not, I'll send it to you right away. Just let me know. Let's plan on loading n=350K-351K in the server to get that cracking almost immediately at fairly high speed. We'll leave n=351K-352K for manual reservations in n=100 pieces.[/quote] No, you haven't sent me the sieve file. As soon as you can send it to me I'll get 350K-351K loaded into G8000. :smile: [quote]Keep in mind that n=100 ranges will actually be ~70%+ larger than n=100 ranges on the 1st drive at the same n-range. That is about ~67% more k's plus likely 3-5% more candidates due to a sieve to P=1.4T vs. 5T. I'll get the drive set up with manual-reservation files posted for n=351K-352K sometime in the morning between 6 and 8 AM GMT (midnight to 2 AM my time). Please plan on completing any manual reservation in < 2 weeks to make sure we stay ahead of the 5000th place prime. If an n=100 file is too big for you, you'll be able to reserve part of a file if you want. So that people have an idea of the size of the files, I'll post a # of candidates by each file. One more thing Max...Please look on Karsten's pages and see who has reservations in the area. We already know about Thomas and I think Adam has a reservation or two in the area. I will PM them about the start of our effort. I doubt we'll impact anyone with n=350K-352K but don't want to give a bad perception if we are.[/quote] Okay, will do. :smile: [quote]Let's move the goal for completing sieving back to Jan. 20th. I should still complete mine by Jan. 15th-16th because I'll pull quads off of port 5000 to put on LLRing n=350K-352K. The 5000th place prime shouldn't be near n=352K by the 20th but we don't want to push our luck in that regard. PrimeGrid has really been submitting the primes lately. Thanks for being flexible everyone! :smile: Edit: Would it make more sense to use a server by Carlos since he has offered? I'm going to Vegas from Thursday to Wednesday. If we do that, we'd just use his server for this range and plan on using port 8000 for most of the LLRnet ranges for n>352K.[/quote] Hmm...well, we've already got G8000 set up, so that would probably be quicker to get started with. Not to mention that since it has a status page and automatic copy-off for its results files, so it will be easier to manage and quicker to process results. Max :smile: |
OK, port 8000 it is. Hopefully I'll have no internet blips this next week like I had in the last week. They have generally been quite rare.
BTW, what the heck was I thinking? The k=1005-2000 for n=200K-500K file sieved to P=1.4T is in a link in the 1st post of this thread. lol Load 'er up with n=350K-351K using that file. Gary |
[quote=gd_barnes;155959]OK, port 8000 it is. Hopefully I'll have no internet blips this next week like I had in the last week. They have generally been quite rare.
BTW, what the heck was I thinking? The k=1005-2000 for n=200K-500K file sieved to P=1.4T is in a link in the 1st post of this thread. lol Load 'er up with n=350K-351K using that file. Gary[/quote] Okay, I'll get it loaded into G8000 ASAP. :smile: |
Due to problems with my dynamic IP address affecting my servers, we will delay starting the n=350K-352K drive until late Wednesday or early Thursday. n=350K-351K will be run on a new server of David's. Details will be in the drive page.
Gary |
[quote=gd_barnes;155997]Due to problems with my dynamic IP address affecting my servers, we will delay starting the n=350K-352K drive until late Wednesday or early Thursday. n=350K-351K will be run on a new server of David's. Details will be in the drive page.
Gary[/quote] Hi all, As David just recently posted in the LLRnet servers thread, he's started up a new server on nplb.ironbits.net port 8000 (IB8000) loaded with n=350K-351K for k=1005-2000. Everyone can go ahead and shift their machines over there as soon as they're ready. :smile: Max :smile: |
[quote=mdettweiler;156078]Hi all,
As David just recently posted in the LLRnet servers thread, he's started up a new server on nplb.ironbits.net port 8000 (IB8000) loaded with n=350K-351K for k=1005-2000. Everyone can go ahead and shift their machines over there as soon as they're ready. :smile: Max :smile:[/quote] I'll set up an official drive page here within about 2 hours. I'm going to hold off on moving CPU's over...may move 1 quad a little later tonight. Ian and Chris already have the n=350K-351K range at ~10% complete in just 4 hours putting the ETA on the server range at only 40 hours if no more resources were added. Based on this, what do people think about running the entire n=350K-352K range on port 8000? It would save us admins a little time. :smile: At the above rate, we would complete n=350K-352K in 80 hours or < 3.5 days. If I add a quad, then less than that. Max, if there are no objections, feel free to load up n=351K-352K in the server also. David, I haven't read many of the posts yet from the last several hours. If you haven't done it already, due to the high-priority of the effort, please make the JobMaxTime 1 day. After we dry this, then future ranges for port 8000 (if we decide to use it) can go back to the usual 3 days. Thanks everyone for pitching in! :smile: Gary |
Moved 4 cores to IB8000. Going to bed now, Happy New Year to all!!
Carlos |
With Carlos now on there, we're already 13% complete with n=350K-351K.
Here is what I'd like to do: I won't post any manual files in the new drive page. If anyone wants a manual range within the range of n=351K-352K, please tell us within 4 hours of this post or by 7:30 AM GMT on Jan. 1st. With the speed of the server, there is now one stringent requirement: All manual reservations must be completed within 3 days. Please plan accordingly. We're going to shoot for < 4 days for n=350K-352K so everyone can get back to their sieving and running the other drives. If there are no takers, I'll send n=351K-352K to David's port 8000 and we'll run the whole n=350K-352K range on the server. One more thing: An n=350K prime will now come in 4980th place on top-5000 so we started this none too soon! :smile: An n=352K prime will come in at 4859th place so the pressure is off after this small effort is done. Gary |
[quote=gd_barnes;156117]With Carlos now on there, we're already 13% complete with n=350K-351K.
Here is what I'd like to do: I won't post any manual files in the new drive page. If anyone wants a manual range within the range of n=351K-352K, please tell us within 4 hours of this post or by 7:30 AM GMT on Jan. 1st. With the speed of the server, there is now one stringent requirement: All manual reservations must be completed within 3 days. Please plan accordingly. We're going to shoot for < 4 days for n=350K-352K so everyone can get back to their sieving and running the other drives. If there are no takers, I'll send n=351K-352K to David's port 8000 and we'll run the whole n=350K-352K range on the server. One more thing: An n=350K prime will now come in 4980th place on top-5000 so we started this none too soon! :smile: An n=352K prime will come in at 4859th place so the pressure is off after this small effort is done. Gary[/quote] Well, I was originally planning to shift my quad over to IB8000 sometime today, but at the rate we're going, it looks like it won't be necessary after all! :smile: Given that, I'll keep it on C6000 where it's been for the past few days (my plan being to stick with that server until it reaches n=1M on k=341). Maybe I'll toss one core of my dualcore on the server so that I can still rake in one or two of those top-5000 primes that I had been hoping to nab easily with my quad. :smile: As for sending n=351K-352K to IB8000: okay, that sounds like a good plan. :smile: Max :smile: |
It's not here yet :wink:
|
[quote=IronBits;156141]It's not here yet :wink:[/quote]
File coming at you in the next 15 mins. For the record: Reserving n=351K-352K for David's port 8000. Gary |
It's not here yet :wink:
Going to bed now. Happy New Year! |
[quote=IronBits;156159]It's not here yet :wink:
Going to bed now. Happy New Year![/quote] It is now. It's hard working with those huge files. The one I sent you is reasonable though. |
Where are we testing the n-area from 50k to 350k?
thanks, nugget |
[quote=nuggetprime;156172]Where are we testing the n-area from 50k to 350k?
thanks, nugget[/quote] That hasn't started yet. When Ian is finished sieving P=1400G-1800G in the sieving effort, we'll start that drive. I think he said his ETA was Jan. 5th on that. We started this drive early only for the small range of n=350K-352K with undersieved files to put any prime for n>350K on the top-5000 site. When the current range is complete, this drive will be suspended until the sieving effort is done; likely ~Jan. 20th. Gary |
If we all move more cores to IB8000 we can manage to finish n=350k-352k range within 24 hours. Rally time?
|
pairs added,
jobMaxTime = 1 * 24 * 3600 |
[quote=mdettweiler;156139]Given that, I'll keep it on C6000 where it's been for the past few days (my plan being to stick with that server until it reaches n=1M on k=341).
[/quote] I think more 3 days and we are done with k=341. I cached some 1000 pairs to run with llr and that will take me ~3 days to process. Carlos |
:smoking: hot on port 8000 :smile:
|
[QUOTE]
:smoking: hot on port 8000 :smile: [/QUOTE] The only thing missing are the primes. |
[quote=MyDogBuster;156294]The only thing missing are the primes.[/quote]
Yeah, where are they? :smile: I grabbed 200 k/n pairs from the server yesterday and ran them overnight with manual LLR, hoping to snatch an easy prime...but nothing! :cry: |
At this rate, 8000 will be out of work tomorrow :cry:
Gonna send me more pairs to load up? |
[quote=IronBits;156299]At this rate, 8000 will be out of work tomorrow :cry:
Gonna send me more pairs to load up?[/quote] Hmm...well, at this point in the sieving, there *isn't* any more 8th Drive work available after n=352K... :ermm: Gary, how do you think we should proceed on this? I was thinking that we might want to load some work starting at n=200K for k=1005-2000; at n=200K it should be big enough so that LLRnet won't choke on it, and the sieving should definitely be far enough along for that n-range. That way we could get a little head-start on the non-top-5000 portion of this k-range. :smile: |
Let's see what happens to the server...bring it...
|
[quote=mdettweiler;156301]Hmm...well, at this point in the sieving, there *isn't* any more 8th Drive work available after n=352K... :ermm:
Gary, how do you think we should proceed on this? I was thinking that we might want to load some work starting at n=200K for k=1005-2000; at n=200K it should be big enough so that LLRnet won't choke on it, and the sieving should definitely be far enough along for that n-range. That way we could get a little head-start on the non-top-5000 portion of this k-range. :smile:[/quote] is prpnet tested enough yet |
IB8000 server will dry within 12 hours.
BTW, nugget found the first new prime...hehehe |
Can I reserve 200k to 300k?
|
[quote=henryzz;156336]is prpnet tested enough yet[/quote]
For the most part, yes. I'm not sure how much load a PRPnet server can take (never tested it)--maybe we could give it a try with the n=50K candidates for k=1005-2000? It might handle those a lot better than LLRnet because it automatically deals in batches of results, rather than one at a time. |
Waaaaaaaaaaaaaaaaa
/throws self on floor kicking and thrashing about Is port 8000 doomed to be shutdown again? :cry: |
NO NO GUYS GUYS!! Please don't do anything with n=200K-350K yet. I'm off here for only 9 hours and we're going in multiple directions here and way jumping the gun! lol
We want port 8000 to dry and get back to sieving and the 5th-6th-7th drives. The intent all along was for port 8000 to be loaded up with n=350K-352K and then be dried. AFTER the sieving drive is done by ~Jan. 20th, we can decide how port 8000 should be used. Don't worry David, I'm sure we'll use it for some effort on the k=1005-2000 drives. It'll just be about 2-3 weeks yet. Max, it'll be very messy very quickly having too many different sieve depths for the different n-ranges when matching sieve files to results. Let's keep it organized. Here's how you will have to match up the results as per the different sieve depths in the future: n=50K-200K sieved to P=1.8T n=200K-350K sieved to P=~9T or whatever optimal turns out to be for the n=200K-500K range (we won't bother splitting that range off from n=350K-500K since we're sieving so quickly) n=350K-352K sieved to P=1.4T n=352K-500K sieved to P=~9T That's enough different sieve depths already. Carlos, do you have some Free-DC folks that would help substantially with a large non-top-5000 range such as n=200K-300K? The question is, how can a non-top-5000 effort be done the most quickly. Even at a low n-range, that's a huge amount of work for ~500 k's and n=100K. I'd love to have you and your friends knock it out if you think you'll have the resources to do it. You could do that at the same time that we have the team drive set up to do n=50K-200K. Like that range, it'd be best if searched by k-value. As soon as I get the factors from Ian for P=1400G-1800G for k=1005-2000 and n=50K-500K, I'll get the 9th drive set up for that k-range and n=50K-350K. Then we can decide how we want to parse it out. Max, keep in mind that even though this is non-top-5000 work, much of it will be first-time work. We must know that the PRPnet server is working properly. I am pulling the reference out to n=200K-210K in the first post here. It doesn't belong here. I will pull my quad off of port 8000 now and move it over to port 400. (I haven't checked other threads; for all I know port 8000 is dry now.) Port 5000 has moved ahead of port 400 so I'm going to start splitting my cores between the two. Gary |
[quote=gd_barnes;156525]GUYS GUYS!! Please don't do anything with n=200K-350K yet. I'm off here for only 9 hours and we're going in multiple directions here and way jumping the gun! lol
We want port 8000 to dry and get back to sieving and the 5th-6th-7th drives. The intent all along was for port 8000 to be loaded up with n=350K-352K and then be dried. AFTER the sieving drive is done by ~Jan. 20th, we can decide how port 8000 should be used. Don't worry David, I'm sure we'll use it for some effort on the k=1005-2000 drives. It'll just be about 2-3 weeks yet. Max, it'll be very messy very quickly having too many different sieve depths for the different n-ranges when matching sieve files to results. Let's keep it organized. Here's how you will have to match up the results as per the different sieve depths in the future: n=50K-200K sieved to P=1.8T n=200K-350K sieved to P=~9T or whatever optimal turns out to be for the n=200K-500K range (we won't bother splitting that range off from n=350K-500K since we're sieving so quickly) n=350K-352K sieved to P=1.4T n=352K-500K sieved to P=~9T That's enough different sieve depths already. Carlos, do you have some Free-DC folks that would help substantially with a large non-top-5000 range such as n=200K-300K? The question is, how can a non-top-5000 effort be done the most quickly. Even at a low n-range, that's a huge amount of work for ~500 k's and n=100K. I'd love to have you and your friends knock it out if you think you'll have the resources to do it. You could do that at the same time that we have the team drive set up to do n=50K-200K. Like that range, it'd be best if searched by k-value. I will pull my quad off of port 8000 now and move it over to port 400. (I haven't checked other threads; for all I know port 8000 is dry now.) Port 5000 has moved ahead of port 400 so I'm going to start splitting my cores between the two. Gary[/quote] Hmm...I see what you mean. I hadn't considered having to mess with matching up the results with all those different sieve depths. :rolleyes: Should I ask David to remove the n=200K-210K range from the server, or should we just continue on this range until it's done and load no more after that? Max :smile: |
[quote=gd_barnes;156525]
Carlos, do you have some Free-DC folks that would help substantially with a large non-top-5000 range such as n=200K-300K? The question is, how can a non-top-5000 effort be done the most quickly. Even at a low n-range, that's a huge amount of work for ~500 k's and n=100K. I'd love to have you and your friends knock it out if you think you'll have the resources to do it. You could do that at the same time that we have the team drive set up to do n=50K-200K. Like that range, it'd be best if searched by k-value. Gary[/quote] Please keep IB8000 up with the non-top-5000 ranges. Don't worry, the range will be done. |
Indeed, 8 more cores coming shortly. :grin:
Just have to go through the pain of installing an XP Upgrade, so I can do a Vista 64bit upgrade. :( Keep port 8000 busy with whatever you want, the faster the better :big grin: Bah, make this at least 2 minutes! :cry: [LIST=1][*][LIST=1][*]This forum requires that you wait 60 seconds between posts.[/LIST] [/LIST] |
[quote=mdettweiler;156528]Hmm...I see what you mean. I hadn't considered having to mess with matching up the results with all those different sieve depths. :rolleyes:
Should I ask David to remove the n=200K-210K range from the server, or should we just continue on this range until it's done and load no more after that? Max :smile:[/quote] [quote=em99010pepe;156529]Please keep IB8000 up with the non-top-5000 ranges. Don't worry, the range will be done.[/quote] Dang it guys. You knew the intent of this drive was to only do n=350K-352K. Why was n=200K-210K loaded into the server? Please don't jump the gun in the future. Imagine this: How is Karsten supposed to show this on his pages now for 300+ k's: k=xxxx; n=50; n=200K-210K; n=350K-352K All that I ask is that we think ahead a little before impulsively starting on things. It's all a big mess as far as I'm concerned. Max, you'll have to deal with it. My thinking: 1. Stop the server. 2. Remove all n=200K-220K so that it is dry except for any straggling pairs for n=350K-352K. 3. Remove all results related to n=200K-220K. 4. Redo those k/n pairs in the future so that they are done in a proper sequence and there isn't a big hole in the future range. Please please when doing things, try to keep as few of gaps as possible in the ranges. We're talking 100's of k's here and we can't be searching multiple n-ranges right in the middle of them with undersieved files. I'll be able to check the threads here again in about 30 mins. but then will be off for 12 hours. Gary |
[quote=gd_barnes;156559]Dang it guys. You knew the intent of this drive was to only do n=350K-352K. Why was n=200K-210K loaded into the server? Please don't jump the gun in the future. Imagine this: How is Karsten supposed to show this on his pages now for 300+ k's:
k=xxxx; n=50; n=200K-210K; n=350K-352K All that I ask is that we think ahead a little before impulsively starting on things. It's all a big mess as far as I'm concerned. Max, you'll have to deal with it. My thinking: 1. Stop the server. 2. Remove all n=200K-220K so that it is dry except for any straggling pairs for n=350K-352K. 3. Remove all results related to n=200K-220K. 4. Redo those k/n pairs in the future so that they are done in a proper sequence and there isn't a big hole in the future range. Please please when doing things, try to keep as few of gaps as possible in the ranges. We're talking 100's of k's here and we can't be searching multiple n-ranges right in the middle of them with undersieved files. I'll be able to check the threads here again in about 30 mins. but then will be off for 12 hours. Gary[/quote] Okay, I see what you're saying. David, please remove all remaining k/n pairs from the 200K-210K range from the IB8000 server, as Gary said; as for the results files, it should be OK to leave those as they are because I should be able to easily sort out the few extra results when processing them later. Max :smile: |
[quote=IronBits;156537]Indeed, 8 more cores coming shortly. :grin:
Just have to go through the pain of installing an XP Upgrade, so I can do a Vista 64bit upgrade. :( Keep port 8000 busy with whatever you want, the faster the better :big grin: Bah, make this at least 2 minutes! :cry: [LIST=1][*][LIST=1][*]This forum requires that you wait 60 seconds between posts.[/LIST][/LIST][/quote] No more work in port 8000 please. Please move them to port 400. Thanks. Gary |
Grow up Gary. Let that range be on the server.
|
No worries. It'll be there soon enough. Keep in mind that we are removing candidates by sieving much faster than we can LLR them at this point, especially the P=1400G-1800G factors, which have not been removed from the file yet.
Ian can correct me if I'm wrong but I think he said at a previous time that he'll be done with the above sieving range in ~2 days. Then we'll be able to start n=50K-200K. By mid Jan., we'll then have a good n=350K-500K range that we can work on. n=350K-352K was only a small 'emergency' range to work on to avoid missing any top-5000 primes. To start LLRing additional ranges would be a waste of CPU resources. Gary |
I just wanted to apologize to everyone for the confusion regarding the range in the server for this drive.
This preliminary very undersieved n=2K range was an extremely unusual situation that only came about as a result of the rapidly rising 5000th place prime. It is my hope that not too much inconvience nor lost CPU time was had by all involved. If there is one thing that we found out by accident here, it is certainly how robust David's servers are, and in more than one way: 1. It can handle 100's of cached results dumped all at once on it (as long as it is not from a Proxy server). 2. It can handle the fast testing times of a lower n-range. Had we not tried the n=200K-210K range for a while, we would not have known #2 so some good has come out of it. This makes me wonder if his servers couldn't handle candidates as low as n=50K with testing times as low as a few secs. We'll be setting up the 9th drive for n=50K-350K in a couple of days. If David or others think that may be worth a try, perhaps we can set up some sort of testing for that; perhaps with one low-weight k to start with. We'd probably set up a completely different server for it. I'm thinking we'll use port 8000 for n=352K-500K after sieving is complete in < 3 weeks, although that can be discussed. Gary |
[quote=gd_barnes;156648]...
This makes me wonder if his servers couldn't handle candidates as low as n=50K with testing times as low as a few secs. ... Gary[/quote] Maybe have a rule e.g. MaxCoresPerPerson = n/10,000? For me, I'd rather run on servers than do manual ranges. |
[quote=Flatlander;156650]Maybe have a rule e.g. MaxCoresPerPerson = n/10,000?
For me, I'd rather run on servers than do manual ranges.[/quote] Very good idea on the rule. We probably need to add some sort of caching rule too. Although his servers could handle 100's of pairs dumped at once at n=350K, doing so while at n=50K while handing out pairs to everyone every few secs. (vs. 110-150 secs.) might be a different story. For the most part, I also prefer servers but am a bit annoyed by the 5-10% testing time loss of LLRnet. Alas, that will hopefully go away with the new PRPnet software that is currently being tested at CRUS. Very exciting stuff! Gary |
LLRnet IB8000 has completed 350K-352K, lresults emailed to Gary. :smile:
|
Reserving n=352K-360K for port 8000.
As soon as we get the word from David that this file has been loaded, the 8th drive will have officially restarted. This should be an exciting drive with many top-5000 primes coming more quickly than the 5th/6th/7th drives. Don't worry about the already-known primes. A large percentage of this range is unsearched. Some manual files have been posted in n=500 blocks. I'll post known primes after the top-5000 site comes back up. Let's rock! :smile: Gary |
Port 8000 loaded, server running, using auto-notify if primes are found.
|
Reserving 360.0-360.5
|
Reserving n=360.5K-375K for port 8000.
With the current range completing in < 1 day :surprised and the rally coming this weekend, we'll load a big file that should last through the rally. Gary |
Loaded up.
Where are the Rally notifications? I can't find it here or over on Free-DC... When does it start? How long will it last? |
[quote=IronBits;159533]Loaded up.
Where are the Rally notifications? I can't find it here or over on Free-DC... When does it start? How long will it last?[/quote] Huh? I just posted something in the rally thread late yesterday asking if people would post their # of cores on it. See the 1st post of that thread. It's stickied so easy to see. I also sent a PM to Lennart letting him know about it. |
Loading up for the rally:
Reserving n=375K-400K for port 8000. |
LLRnet IB8000 has completed 352K-355K; lresults emailed to Gary. :smile:
|
Reserving n=400K-420K for port 8000. :smile:
|
Reserving n=420K-430K for port 8000.
|
Ian has processed the results for n=355K-360K to me. He will also be checking it against the sieve file and primes in several places. Once it is compared to the sieve file, it will be considered complete.
|
As of 11 PM AZ time on Jan. 26th (6 AM GMT Jan. 27th), here is an updated count of all primes found in the 8th drive. It includes 2 primes not yet posted since they have not been submitted at top-5000 yet:
[code] k primes 1400-1500 32 1500-1600 33 1600-1700 34 Total 99 k primes 1700-1800 18 1800-1900 24 1900-2000 18 Total 60 [/code] Now, if you assume that the 23-3 start was just some random abberation and that it should be random from that point forward, subtracting that off still gives 76-57 in favor of k=1400-1700. With the former k-range continuing to dominate, clearly k=1400-1700 must have a higher avg. weight than k=1700-2000. If anyone has time to look up and compute the avg. from [URL="http://www.rieselprime.org"]www.rieselprime.org[/URL], I'd be very curious to see it. If it's not the weight, than something else is going on. If we are getting a higher percentage of primes from almost the same # of candidates in a sieve file for 2 distinct ranges, than we may have what we've been hoping for if this continues to run at such an alarming advantage for the smaller k-range...that is proof that these things may not be as random as we think they are! :smile: Looking for this type of deviation from the norm is part of the reason the project was started...to have enough searched ranges without holes in them to prove a non-random deviation. A little wishful thinking just yet but certainly worth further investigation. Gary |
[quote=gd_barnes;160632]With the former k-range continuing to dominate, clearly k=1400-1700 must have a higher avg. weight than k=1700-2000. If anyone has time to look up and compute the avg. from [URL="http://www.rieselprime.org"]www.rieselprime.org[/URL], I'd be very curious to see it.
If it's not the weight, than something else is going on. If we are getting a higher percentage of primes from almost the same # of candidates in a sieve file for 2 distinct ranges, than we may have what we've been hoping for if this continues to run at such an alarming advantage for the smaller k-range...that is proof that these things may not be as random as we think they are! :smile: Looking for this type of deviation from the norm is part of the reason the project was started...to have enough searched ranges without holes in them to prove a non-random deviation. A little wishful thinking just yet but certainly worth further investigation. Gary[/quote] The average weight of k=1400-1700 is 1805.600. For k=1700-2000 it is 1746.167. That's a difference of 59.433. I'm not terribly familiar with what weights mean what, but that seems like an insignificant difference to me. (For reference, my two k's I've reserved in the individual k drive are weighted 1463 and 1416, a difference of 47. Over 600K-1M, the difference in the number of candidates is only 137.) I think something else is going on, whether random or not. Edit: By the way, k=1400-1700 has 3885 primes listed on that page, k=1700-2000 has 3789 primes. This correlates closely to the weights, not the recent bunching. |
I have now processed the results for this drive up to n=360K. I have compared primes found vs. the 1st post in this thread, the k=300-2000 page, and Karsten's 8th drive page. Everything looks good.
Karsten, the only inconsistency that I found was that you don't have k=1647 highlighted in blue on the k=300-2000 page. It appears that you are showing all k's where NPLB has found a new prime in blue. We found 1647*2^351262-1 prime. Max or Ian, whenever you can, please process the results for n=360K-400K for this drive to me. The lowest k/n pair in the server is now n>400K. Thanks, Gary |
[QUOTE]Max or Ian, whenever you can, please process the results for n=360K-400K for this drive to me. The lowest k/n pair in the server is now n>400K.[/QUOTE]
Max, I took care of it (I hope) Ian Results emailed (6.5mb zipped) Whew |
[quote=MyDogBuster;160862]Max, I took care of it (I hope) Ian
Results emailed (6.5mb zipped) Whew[/quote] Thanks--I'm glad that now there's at least three people who can process results now (myself, Gary, and you). And since I've been very busy lately and haven't had much time to devote to stuff like processing results, that is greatly appreciated. :smile: |
[QUOTE]Thanks--I'm glad that now there's at least three people who can process results now (myself, Gary, and you).[/QUOTE]
Well, I'm still in training so what I did may be junk. LOL |
[QUOTE=mdettweiler;160916]Thanks--I'm glad that now there's at least three people who can process results now (myself, Gary, and you). And since I've been very busy lately and haven't had much time to devote to stuff like processing results, that is greatly appreciated. :smile:[/QUOTE]
oh, you forgot the fourth one - ME! but results for 7 (in words [b]S E V E N[/b]) servers it's hard to process them and update the pages too! |
Reserving n=430K-450K for port 8000.
|
[quote=kar_bon;160966]oh, you forgot the fourth one - ME!
but results for 7 (in words [B]S E V E N[/B]) servers it's hard to process them and update the pages too![/quote] Ah yes, I forgot about that--thanks for reminding me. As the saying goes, the more the merrier! :grin: |
maybe it would be worth processing less often with larger files
|
[quote=henryzz;160999]maybe it would be worth processing less often with larger files[/quote]
Well, at this point I think we've already crossed the border into "less often with larger files"--the most recent batch of results on port 8000 was for an n=40K range, which came out to 6.5MB, even when zipped. It's just that all you guys are crunching too fast for us to keep up! :missingteeth: |
Reserving 450.0-450.5
|
360.0-360.5 complete 1 confirmed prime already reported
Results emailed |
450-450.5 complete
2 new primes submitted Results emailed reserving 450.5-451 |
450.5 451 completed
No primes found results emailed reserving 451-451.5 |
451 451.5 completed
No primes found results emailed |
Reserving n=451.5K-465K for port 8000.
After we hit n=~450K on this drive (likely sometime Sunday or Monday), I'll move most of my LLRnet machines to port 4000 for the 5th drive. Gary |
[quote=PCZ;161344]450-450.5 complete
2 new primes submitted Results emailed reserving 450.5-451[/quote] I changed the word "confirmed" to "new". Confirmed would mean that they were already in the top-5000 database. Max, you had also shown Brian's 2 primes as confirmed for his manual range in the 1st post of this drive. I also corrected that. Brian, if you'd like to reserve a single larger manual file, just let us know. We can accomodate any size n-range that can be completed within a reasonable amount of time after the server reaches that point. Gary |
Results files have been verified as complete up to n=400K on this drive. Primes were compared to post 1 of this thread, the 8th drive page, Rieselprime.org, and the top-5000 site. No problems were found. :smile:
Ian or Max, when you have a chance, can you coordinate on processing the results for n=400K-440K to me? Thanks. Gary |
[quote=gd_barnes;162457]Results files have been verified as complete up to n=400K on this drive. Primes were compared to post 1 of this thread, the 8th drive page, Rieselprime.org, and the top-5000 site. No problems were found. :smile:
Ian or Max, when you have a chance, can you coordinate on processing the results for n=400K-440K to me? Thanks. Gary[/quote] Okay, sure. Though, originally I was planning to wait until 450K to do it--I generally try to wait until I can do an entire contiguous chunk before I process results, unless that chunk is just waaaay to big to do that with. And considering as how there are only two <450K k/n pairs remaining in the server, that shouldn't be too long to wait. :smile: |
[quote=mdettweiler;162468]Okay, sure. Though, originally I was planning to wait until 450K to do it--I generally try to wait until I can do an entire contiguous chunk before I process results, unless that chunk is just waaaay to big to do that with. And considering as how there are only two <450K k/n pairs remaining in the server, that shouldn't be too long to wait. :smile:[/quote]
Passed 450K quite a while ago. |
[quote=gd_barnes;162869]Passed 450K quite a while ago.[/quote]
Okay, I'll do the results sometime today. :smile: |
[quote=gd_barnes;162869]Passed 450K quite a while ago.[/quote]
[quote=mdettweiler;162884]Okay, I'll do the results sometime today. :smile:[/quote] Uh...actually, I just checked the knpairs.txt on port 8000 just now and this is what the top of the file looks like:[code] 10000000000000:M:1:2:258 1579 448383 1689 448383 1647 458484 1473 458487 1447 458493 1419 458497 1875 458499 1605 458500 1965 458500 1609 458507 1751 458510 1787 458512 1995 458512 1937 458518[/code]As you can see, there are still two results <450K outstanding. No big deal, though; I'll see about cleaning them out on the server in a moment. After that they should disappear after the next time the server prunes knpairs.txt and I can then process the results. :smile: |
LLRnet IB8000 has completed 400K-450K; lresults emailed to Gary. :smile:
Karsten, even though I had to manually fill in two results from this range as described in the post above this one, since I submitted them to the server after finishing them, they should be in the 2/16 results file as normally. Thus, everything should be all in place with no further fixes/fill-ins necessary. :smile: |
[QUOTE=mdettweiler;162961]Karsten, even though I had to manually fill in two results from this range as described in the post above this one, since I submitted them to the server after finishing them, they should be in the 2/16 results file as normally.[/QUOTE]
[b]They are not![/b] |
[quote=mdettweiler;162468]Okay, sure. Though, originally I was planning to wait until 450K to do it--I generally try to wait until I can do an entire contiguous chunk before I process results, unless that chunk is just waaaay to big to do that with. And considering as how there are only two <450K k/n pairs remaining in the server, that shouldn't be too long to wait. :smile:[/quote]
[quote=mdettweiler;162892]Uh...actually, I just checked the knpairs.txt on port 8000 just now and this is what the top of the file looks like:[code] 10000000000000:M:1:2:258 1579 448383 1689 448383 1647 458484 1473 458487 1447 458493 1419 458497 1875 458499 1605 458500 1965 458500 1609 458507 1751 458510 1787 458512 1995 458512 1937 458518[/code]As you can see, there are still two results <450K outstanding. No big deal, though; I'll see about cleaning them out on the server in a moment. After that they should disappear after the next time the server prunes knpairs.txt and I can then process the results. :smile:[/quote] Max, I'm confused. First, you said there are 2 pairs remaining to be processed. I wait 4 calendar days and state that we passed n=450K because I know that the JobMaxtime is 3 days so that those 2 pairs must have been processed. You then state that there are 2 pairs remaining to be processed again. What gives? Did someone cache those and never process them a second time? That seems unlikely. Were they 2 different k/n pairs then the first time? Can you research why the results didn't show up in Feb. 16th like Karsten said? Did you submit them after midnight server time such that they will show up in Feb. 17th? One other thing: Let's not wait until huge contiguous k-ranges like this are complete. Let's do n=20K ranges in the future like we did for the 1st/2nd/3rd drives. Actually, straggling pairs for n>440K is why I requested n=400K-440K to begin with. n=440K-450K could have waited a week or even more if we just did the lower n-range first. Then you wouldn't have had to go through all that hassle on those 2 pairs. One final thing: I had a reason that I had separated the port 8000 n-ranges into n=20K ranges in the 1st post of this thread. Oh well, I'm not going to do it again. I'll just deal with it. Gary |
Reserving n=465K-475K for port 8000.
|
why got we automated LLR-test?
because all will done automatically! if the server will wait 3 days before delivering not submitted pairs again, so wait these 3 days! no need to do them manually!!!! (please read the thread "NPLB Database" too) |
[quote=kar_bon;163118]why got we automated LLR-test?
because all will done automatically! if the server will wait 3 days before delivering not submitted pairs again, so wait these 3 days! no need to do them manually!!!! (please read the thread "NPLB Database" too)[/quote] I must admit I'm confused by this whole situation too Karsten. I asked for the results for n=400K-440K because I knew that there were still straggling pairs for n=440K-450K. Max then suggested that we wait for n=400K-450K because only 2 pairs were left so I wait patiently. 4 days later with no word, I requested n=400K-450K since it should be done by then. Max then says there are still 2 pairs left and that they had to be done manually to complete the n-range. This was not my intent at all. Max, if I may request: Please process the results to me in n=20K ranges after all pairs have been processed automatically. There's no reason to manually process them. Also, did the 2 pairs that you processed to the server show up in our results on the server yet? Gary |
Ooh...my bad again with this latest batch of results. Here's what it looks like has happened: I essentially popped the two straggling k/n pairs into the workfile.txt of an LLRnet client running on IB8000. Then, I let it run until those two stragglers were done. It finished them and submitted them to the server, and I presumed that it put them into that day's results file as it normally would. Yet, when I downloaded all the results to process them later that day, I forgot to download the "copy of current results.txt" file as well--and that's where the results would be (actually, as it turns out, that's where I *thought* they would be)--but, by the time I noticed all this, I was already almost done with processing everything. So, I figured...it's only two results, and I already have the results sitting around from the client that submitted the results earlier. So, I just took the results from the client's lresults.txt file and inserted them into the big results file from there--assuming that the server had accepted them correctly and inserted them into the 2/16 results file.
However, of course, we have now seen that they did not indeed go into the 2/16 results file. They're probably in the 2/17 results file--but, I guess the moral of the story is: never assume that a results is on the server unless you've actually downloaded it back from the server. :smile: Gary, despite all this, the results that I sent you should still be complete and correct; I verified them in full against the original sieve file. All the results should be on the server, too, but possibly in different places than I had assumed. Feel free to verify them with the original sieve file to make sure, of course. Regarding splitting up the ranges in n=20K pieces in the range table: ah, I should have realized there was a method to the madness. :rolleyes: Okay, then--in the future, I'll be sure to ask before making any changes like that. Should have done that in the first place. :smile: Max :smile: P.S.: Just to make sure that everything is indeed as I've projected in this post, later today I'll check all the recent results files to make sure those two results did indeed make it to the server. And yes, I'll write myself a note so I don't forget. :wink: |
the 2 missing pairs are still missing!
the last pairs with n=448k in results_20090211_0000_IB_nplb_8000.txt. so, please, put those 2 pairs in the I8000 server and let them processed there! |
[quote=kar_bon;163304]the 2 missing pairs are still missing!
the last pairs with n=448k in results_20090211_0000_IB_nplb_8000.txt. so, please, put those 2 pairs in the I8000 server and let them processed there![/quote] Hmm...you're right. They do indeed seem to be missing. :unsure: Given this: David, can you please stop the port 8000 server, insert these two lines immediately after the header line, and restart the server? [I]1579 448383 1689 448383[/I] Thanks, Max :smile: |
Done.
|
[quote=IronBits;163321]Done.[/quote]
Thanks! :smile: |
Reserving n=475K-490K for port IB8000.
|
All results for n=400K-460K for this drive have now been processed. All primes were checked against the 1st post in this drive, the top-5000 site, the k=300-2000 page, and the 8th drive page. No missing or incorrect primes were found.
Excellent work everyone. This was a huge range with a lot of primes (127) to have no problems on! Karsten, the only nitpick that I saw on your 8th drive page is that 1551*2^439313-1 is out of order from left to right on that line. You've usually been listing them from lowest to highest n-value from left to right so I just thought I'd point it out. Gary |
Reserving n=490K-500K for port IB8000...the final file for this drive! :smile:
|
Will this server be loaded again soon, or are you waiting for the sieve to complete?
|
| All times are UTC. The time now is 11:53. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2023, Jelsoft Enterprises Ltd.