![]() |
[quote=petrw1;170612]There was NO Financial Crisis.[/quote]Upon consulting the 22 Apr 08 postings in Ernst's thread "Global Financial Crisis (Was: Subprime Meltdown)" -- but it may have had the original title then -- in Soap Box at [URL]http://mersenneforum.org/showthread.php?t=9526[/URL] we find that Ernst was saying, in post #196:
[quote]Some of the interesting lesser-known places of the world in which the credit crunch is wreaking havoc: [URL="http://www.nytimes.com/2008/04/18/business/worldbusiness/18iceland.html"]Iceland, a Tiny Dynamo, Loses Steam[/URL]: [I]Little could have prepared Iceland for the reversal of fortune it has suffered in the last few months. The country’s long economic boom has ended in a painful bust, with a collapsing currency, rising inflation, double-digit interest rates and predictions of its first recession since 1992 ... To many Icelanders, their country is the victim of foreign speculators, circling like sharks smelling blood. To outside investors, Iceland is the victim of its own excesses.[/I][/quote]and he quoted from an Amazon review of a then-new book titled: [URL="http://www.amazon.com/Bad-Money-Reckless-Politics-Capitalism/dp/0670019070"]Bad Money: Reckless Finance, Failed Politics and the Global Crisis of American Capitalism[/URL]. |
[quote=hockmeng;170556]1. PrimeNet removes exponent with composite [I]n[/I] (where [I]n[/I] is from 2^[I]n[/I]-1).[/quote]PrimeNet never included composite exponents. They've been excluded since the very start of GIMPS. No removal necessary. :smile:
(Perhaps it would be proper to say that when the GIMPS/PrimeNet database was initially being populated with exponents, there was a sieving step performed by the populating program to exclude composites.) [quote]2. Trial factoring done by PrimeNet up to 62 bits?[/quote]TF up to 58, then 59, then 60, then 61, then 62 bits, and still continuing higher on exponents well ahead of what's being LL-tested was done, and still is being done, by a small band of volunteers using the group name Lone Mersenne Hunters (it's a reference to the Lone Gunmen on "X-Files"). Their results reports go into the PrimeNet database. See the Lone Mersenne Hunters subforum under the heading "Factoring Projects" for current news of this group. [quote]4. P-1. < snip > But I gather from the previous posts that now, users can perform P-1 Stage 1 without having to perform Stage 2?[/quote]Stages 1 and 2 are not assigned separately. What we're discussing is: There are [I]two independent[/I] software determinations of whether a user has sufficient memory for stage 2 P-1: 1) PrimeNet [I]currently[/I] (v5) has the ability to look at a user's Available Memory (and CPU speed, I think) and make a decision to assign or not assign P-1 (as a P-1-only assignment) depending on how much there is. 2) The prime95 client program has [I]always[/I] had the ability, when it starts processing a P-1 assignment, to decide what B1/B2 limits to use, and whether to do only stage 1 or to do both stage 1 and stage 2. It makes this decision with an algorithm that is designed to figure out what is best for the sake of GIMPS throughput. (However, if it turns out that stage 1 finds a factor, stage 2 will always be unnecessary.) The B1/B2/stage1/stage2 decision algorithm takes more factors than just Available Memory and CPU speed into account. It's not a user choice (not directly, anyway) -- it's prime95's choice when it starts the P-1 assignment. The only P-1s done without stage 2 are those done when prime95 decides that "Available Memory" is insufficient -- or when stage 1 finds a factor. (BTW, there's no assignment later to perform any skipped stage 2.) [I]Note that prime95's decision may not match PrimeNet's decision, in some cases, because they use different algorithms for their decisions. That is, it is possible for PrimeNet to issue a P-1 assignment because it considers the user to have enough memory & speed to do stage 2, but for prime95, when processing that very same assignment, to decide to do stage 1 only. Unlikely, but possible. [/I] [quote]5. LL. What if the result is returned with an error reported by Prime95? It becomes a suspect LL and has to undergo LL again. But if the next LL has the same result as the first, does DC still need to be done?[/quote]No, because, in that case (matching residue) the second LL, upon completion, becomes the DC even if it was called a reassigned first-time LL when it was assigned the second time. |
An exponent returned with an error code or marked as "suspect" isn't necessarily a bad test. The program uses floating point arithmetic to do integer operations, and there's a roundoff step at the end. There's a gray area between when sufficiently large roundoffs will be flagged for a possible error, and when they will actually cause an error in the computation (I think average roundoffs >.42 get flagged as a possible error, and a roundoffs >.5 will actually cause errors). The reason tests need increasing FFT sizes for larger exponents is because the roundoffs increase with the exponent size until you no longer get reliable results. For exponents that are near the end of an FFT range, the roundoffs will be close to the point where they might get flagged as an error, but if your computer is stable they shouldn't reach the point where they actually cause errors.
|
hockmeng,
If you've been reading my last posting, you might want to reload the page in your browser. I have a habit of editing/revising my postings for up to 60 minutes after they first appear. |
[QUOTE=cheesehead;170669]2) The prime95 client program has [I]always[/I] had the ability, when it starts processing a P-1 assignment, to decide what B1/B2 limits to use, and whether to do only stage 1 or to do both stage 1 and stage 2.[/QUOTE]
Early clients did not have the ability to do P-1 testing at all. |
[QUOTE=hockmeng;170556]3. TF assigned to users.
63 bits? 64 bits? ... Up to 67 bits? Up to 68 bits?? Up to 69 bits??? I remember that last time, I had to perform TF from 63 bits all the way to 67 bits but PrimeNet v5 now assigns TF bit by bit. 4. P-1. I remember that last time, users who wanted to perform LL had to perform P-1 (both Stage 1 and 2) before they started LL. Everything was done by one user. But I gather from the previous posts that now, users can perform P-1 Stage 1 without having to perform Stage 2?[/QUOTE] The total number of bits of TF applied to any given Mersenne number depends upon the exponent. The limits are determined by the relative speed of the TF and LL code, which varies depending upon client and hardware. Consequently they are periodically recalculated. [url=http://mersenne.org/various/math.php]This page[/url] give a probably outdated list. Exponents are assigned for P-1 testing before the last two bits of TF. This is an optimisation of questionable value, given that currently the number of dedicated P-1 testers is insufficient creating a workflow bottleneck. Many exponents will to go forward for LL testing with neither P-1 nor the last two bits of TF done. This is not a disaster as these machines will do this factoring before starting the LL test, but it does shift TF work onto the LL machines, which are the real bottleneck to the project. |
[QUOTE=Mr. P-1;170823]Exponents are assigned for P-1 testing before the last two bits of TF. [/QUOTE]
I believe that is 1 bit TF now...someone correct me if I'm wrong. |
[quote=Mr. P-1;170821]Early clients did not have the ability to do P-1 testing at all.[/quote]... and, thus, never started processing a P-1 assignment, satisfying the when-clause. :smile:
|
Wow!!! BIG Progress.
As of June 8 - a few days late for end of May but since the end of March:
- We completed 71.6% of the remainder in the last 46 days. - We completed first LL for all ranges below 26M. - We have less than 11.5% of what we started with April 22, 2008 (9,576) - We are a few days from having less than 1,000 left. P.S. I am diligently working on my 4% of this range - ETA end of Sept NOTE: There are a lot more Assigned than Unproven suggesting these may be deemed Double Checks (I've had some of these) [CODE] Million LL-ERR No-LL Dec LL-ERR No-LL Total Jan. LL-ERR No-LL Total Feb. LL-ERR No-LL Total Mar. LL-ERR No-LL Total Jn-8 18000000 2 2 1 1 1 1 1 0 0 1 0 0 21000000 1 1 1 1 0 1 1 0 1 1 0 0 1 23000000 8 13 21 6 8 14 7 2 2 12 1 1 1 0 1 24000000 25 4 29 25 3 28 1 4 4 24 0 4 0 0 25000000 10 27 37 3 26 29 8 1 20 21 8 1 1 20 0 1 26000000 24 44 68 16 39 55 13 8 34 42 13 1 14 15 27 3 3 12 27000000 53 79 132 39 72 111 21 32 60 92 19 13 23 36 56 1 5 6 30 28000000 133 337 470 124 326 450 20 79 240 319 131 44 155 199 120 15 62 77 122 29000000 159 259 418 155 236 391 27 136 182 318 73 57 67 124 194 22 20 42 82 30000000 196 546 742 183 538 721 21 172 512 684 37 147 446 593 91 18 143 161 432 31000000 268 1050 1318 255 1027 1282 36 247 993 1240 42 221 870 1091 149 40 218 258 833 32000000 321 1240 1561 310 1210 1520 41 293 1164 1457 63 262 1055 1317 140 66 353 419 898 33000000 92 528 620 91 490 581 39 90 461 551 30 77 415 492 59 17 116 133 359 TOTALS 1292 4127 5419 1209 3975 5184 235 1066 3666 4732 452 824 3046 3870 862 179 920 1099 2771[/CODE] |
Still going strong ... July 1
Only 766 left (just under 8% of the 9576 on April 22,2008).
Almost 15/day since June 8. I have 38 of them (not quite 5%) .... early October ETA. I am running all 4 cores of a Q9550 and 2 cores of a E6550. If necessary I will add more cores. Can we complete this by the anniversary of V5 - Oct 20? How about year end at the latest. |
I have quite a few.. with end dates somewhere around 60-90 days on some.
|
| All times are UTC. The time now is 20:56. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.