mersenneforum.org Is it worth persisting with this machine?
 Register FAQ Search Today's Posts Mark Forums Read

 2017-05-25, 07:10 #1 stebbo   "Chris" Jul 2016 Melbourne 29 Posts Is it worth persisting with this machine? Hi All, I have one machine that keeps giving bad results. This machine is in out-of-the-box configuration - no fiddling with anything. I've run any number of tests on it to try to get it to fail over long periods of time, but nothing shows up. A screenshot of it's recent history is attached. If the occasional bad result is not a drain on resources then I'm happy to keep doing double-checks with it but am just as happy to retire it as well. Thoughts? Cheers, Chris. Attached Thumbnails
 2017-05-25, 07:26 #2 Mark Rose     "/X\(‘-‘)/X\" Jan 2013 C0816 Posts Reseat the RAM. Run memtest86. Try swapping RAM and power supplies. A machine that doesn't perform LL/DC 100% correctly doesn't hurt the project at all, but it does consume more electricity per correct result.
2017-05-25, 11:19   #3
axn

Jun 2003

124748 Posts

Quote:
 Originally Posted by Mark Rose A machine that doesn't perform LL/DC 100% correctly doesn't hurt the project at all, but it does consume more electricity per correct result.
Worst case, it could delay a prime discovery by a decade (until doublecheck finds it). I would not use this machine for first time LL. DC & ECM should be ok.

2017-05-25, 11:42   #4
xilman
Bamboozled!

"𒉺𒌌𒇷𒆷𒀭"
May 2003
Down not across

5×17×137 Posts

Quote:
 Originally Posted by stebbo A screenshot of it's recent history is attached. If the occasional bad result is not a drain on resources then I'm happy to keep doing double-checks with it but am just as happy to retire it as well. Thoughts?
Do you have any guess as to how often an error occurs? Hourly, daily, weekly, monthly? If so it would be wise to use your machine to run tasks which take significantly less elapsed time than that.

Even machines with hourly faults, as long as the faults don't crash the machine, can be used with an ECMNET client. Details and assistance on request, but 109.109.168.71:8194 may be all you need if you want to go that route.

2017-05-25, 19:20   #5
chalsall
If I May

"Chris Halsall"
Sep 2002

1106210 Posts

Quote:
 Originally Posted by stebbo Thoughts?
There's no real downside to the GIMPS project having this machine continue. It probably wouldn't even delay the (*exceedingly* unlikely) missing of a MP by much time because your machine will be given "the evil eye" by Madpoo's "Strategic Double Check" initiative.

However, it is _strongly_ advised you don't use this machine for any mission critical "real" work you might be doing with it.

I've said before and I'll say forever: running GIMPS has saved me more time, money and grief than I can even begin to guess over the years by pointing out machines which are about to die.

2017-05-26, 10:25   #6
henryzz
Just call me Henry

"David"
Sep 2007
Liverpool (GMT/BST)

603110 Posts

Quote:
 Originally Posted by stebbo Hi All, I have one machine that keeps giving bad results. This machine is in out-of-the-box configuration - no fiddling with anything. I've run any number of tests on it to try to get it to fail over long periods of time, but nothing shows up. A screenshot of it's recent history is attached. If the occasional bad result is not a drain on resources then I'm happy to keep doing double-checks with it but am just as happy to retire it as well. Thoughts? Cheers, Chris.
Is this a skylake machine? If so the BIOS may need updating.

2017-05-27, 04:05   #7
Serpentine Vermin Jar

Jul 2014

5×677 Posts

Quote:
 Originally Posted by chalsall There's no real downside to the GIMPS project having this machine continue. It probably wouldn't even delay the (*exceedingly* unlikely) missing of a MP by much time because your machine will be given "the evil eye" by Madpoo's "Strategic Double Check" initiative.
Could be... I was the one who did the triple-check on those two exponents that ended up proving his results wrong.

In those cases at least, it was because they were double-checks, so a mismatch there is definitely going to land the exponent in my crosshairs.

First time checks, well... it all depends on if they've ever done (or had) a doublecheck that matched or not. Someone doing first time checks exclusively isn't likely to get a doublecheck done anytime soon, so bad systems can go undetected for years.

We have looked before at trying to do at least one DC of every computer that's ever turned in a result... there are a lot though. Special attention has been given to those with a lot of results turned in since a mismatch on any of those would be more interesting.

That's also one of the reasons for the change in the assignment code lately to periodically assign a DC as a "sanity check" once a year or whatever, because it really does help the project if we can find bad systems earlier in the process.

EDIT: Oh... for that particular system, here are its stats broken down by year / month. Overall it has more good than bad. That "suspect" result in March 2017 could go either way (78077873):
Code:
YYYY-MM	Bad	Good	Sus	Unk
2016-12	1	4	0	0
2017-1	0	0	0	2
2017-2	0	0	0	2
2017-3	1	0	1	1
2017-4	0	2	0	2
2017-5	1	6	0	0

Last fiddled with by Madpoo on 2017-05-27 at 04:10

 Similar Threads Thread Thread Starter Forum Replies Last Post fivemack GPU Computing 25 2016-03-01 01:02 fivemack Factoring 2 2013-05-19 18:40 NBtarheel_33 PrimeNet 5 2010-06-17 00:17 victor Lounge 30 2009-05-30 21:53 db597 Hardware 8 2009-01-28 09:45

All times are UTC. The time now is 06:31.

Sat Jan 28 06:31:11 UTC 2023 up 163 days, 3:59, 0 users, load averages: 1.67, 1.30, 1.07