Faster LL tests, less error checking?

[science_man_88]

Rhyled is making sense, I think it should be part of first test things that will be tested as it will show over time an average number of maximum error free clock cycles that the program can do given the machine.

[Prime95]

Originally Posted by Rhyled

New suggestion - include the SUM check in the Torture Test section, where OC'rs want to know about errors, and don't really care about Prime95 performance other than the ability to stress the cpu/memory.

Rhyled, you needn't worry about the torture test. It is and will remain 100% effective in catching LL errors. This is thanks to the final comparison with the known correct residue.

The SUM(INPUTS) error check during a torture test lets prime95 notice a problem a little sooner -- you don't have to wait until the end of the test for the residue comparison. Alternatively, one could argue that a 3% more efficient LL test pushes the CPU a tiny bit harder making prime95 a tiny bit more likely to detect an unstable machine. The best way to handle this is to run both FFTs during the torture test.

[Rhyled]

Hi. My name is Rhyled, and I'm an overclocker.

Why settle for a 2-3% gain, when 35-50% gains are possible on Core i7's? Sadly, I had to settle for only 40%, as I can't quite get a 4GHz Core i7 920 processor to keep stable 24/7 - which is how I got drawn into this entire GIMPS thing. First I started running the Prime95 torture test, then I got hooked on the Mersenne Prime search.

Now that my concerts about the SUM check risk have been addressed, can I change my vote from "keep checking" to "user optional"?

[Prime95]

Originally Posted by Rhyled

Why settle for a 2-3% gain, when 35-50% gains are possible on Core i7's?

I agree, my i7 850 is overclocked to a modest 3.5GHz. I no longer try pushing an overclock to near the CPU's limit. I've found that over time, a change of seasons, dust buildup, normal wear and tear can turn a once stable overclock into an error generating waste of electricity. Once I found my chip could do 3.8 GHz, I dialed it back to 3.5 GHz for my peace of mind.

If I overclocked more than that I would opt to run the slower LL test with more error checking.

[Primeinator]

Given what has been stated above, I am in favor of this with the following caveats:

1. It should be a user option (as reliable machines will be unaffected by this change)

2. Double-checks will always use the extra error checking

I believe these sentiments are shared above with at least a couple individuals.

[Colt45ws]

Originally Posted by Rhyled

Hi. My name is Rhyled, and I'm an overclocker.

Why settle for a 2-3% gain, when 35-50% gains are possible on Core i7's? Sadly, I had to settle for only 40%, as I can't quite get a 4GHz Core i7 920 processor to keep stable 24/7 - which is how I got drawn into this entire GIMPS thing. First I started running the Prime95 torture test, then I got hooked on the Mersenne Prime search.

Now that my concerts about the SUM check risk have been addressed, can I change my vote from "keep checking" to "user optional"?

Yeah really. My 4.0GHz i7 920 steamrolls these tests. I joined the i7 on the 19 of Jan and have about 1770 GHz-days so far. I have 6 other machines ranging from a 2.4GHz AMD "Barton" to a 3.4GHz AMD "Windsor" joined and all of them put together cannot touch it.
I really should have been easier on the poor 920, but around 3.8GHz I decided I was going to get 4.0 even if I smoked it in the process.

I kinda think this should be something the program can decide. Maybe if it detects a hardware error of some type, or a bad result, a setting gets written to the config and from then on it runs the extra check.

[TimSorbet]

Originally Posted by Primeinator

Given what has been stated above, I am in favor of this with the following caveats:

1. It should be a user option (as reliable machines will be unaffected by this change)

2. Double-checks will always use the extra error checking

I believe these sentiments are shared above with at least a couple individuals.

I am in favor of them too, but there's a potential negative side effect to consider:
People who care about their own credit numbers more than GIMPS's needs (needs like more DCs need to be done) will avoid double checks if they know of this, because it'll take longer to do the same credit worth of work.
Perhaps to compensate, tests with error checking enabled through the whole test (to prevent people enabling it for the last few iterations to earn more credit at a faster speed) should earn slightly more credit. After all, they're slightly more reliable and they take slightly longer, so why not give slightly more credit for it? (the bonus should be set to compensate for the speed penalty as exactly as possible) That would take credit out of the question of error checking.

[Primeinator]

I think the above is a great idea.

[lfm]

Originally Posted by Primeinator

Given what has been stated above, I am in favor of this with the following caveats:

1. It should be a user option (as reliable machines will be unaffected by this change)

2. Double-checks will always use the extra error checking

I believe these sentiments are shared above with at least a couple individuals.

I'd say no credit should be given out to people who disable internal checks till a matching double check has run. Double checks can get full credit right away if the residue matches a previous run. If there are no matches all credit is delayed till a match is found. Of course any bad residues get no credit and get their reliability rating downgraded, perhpas disabling the option to skip future checks.

[lorgix]

Originally Posted by retina

The poll needs another option.

5. Just do whatever makes the project progress faster.

If a 2% speed-up can, on average, adequately compensate for some extra errors not being detected then just do it.

Yes, I don't see how this issue could be any more complex than that equation.

[vsuite]

Originally Posted by lfm

I'd say no credit should be given out to people who disable internal checks till a matching double check has run. Double checks can get full credit right away if the residue matches a previous run. If there are no matches all credit is delayed till a match is found. Of course any bad residues get no credit and get their reliability rating downgraded, perhpas disabling the option to skip future checks.

1. Only machines that are proven to be reliable over a period of time/number of tests (however prime95 calculates reliability) get the option to disable the future check.
2. Those with unreliable results lose the ability to disable the future check.
3. Some results (eg 0.1-5%) from all machines should be double checked ASAP, to get a server estimated reliability check of the machine's results. This way machines do not continue ad infinitum to submit erroneous results without checking.
4. The frequency of early double checks should decrease the longer a machine delivers reliable results. Start off at 5%, and drop to 0.1% over time? Or even start at 100%, ie the first result by a new machine is double checked ASAP, then the 21st, then the 100th, then the 500th, etc.
5. How to determine _if_ to credit wrong results might be the wrong question (unless you plan to ban machines that deliver frequent wrong results...)

[Sorry to reopen this thread]