mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   PrimeNet (https://www.mersenneforum.org/forumdisplay.php?f=11)
-   -   Prime95 defaults - your input requested (round 2) (https://www.mersenneforum.org/showthread.php?t=21147)

Mark Rose 2016-03-26 19:22

[QUOTE=Madpoo;430123][B](note to George: maybe that could be a change to the DC assignments... hand those kinds of things out first, not just based on "lowest exponent first", but "most useful exponent first")[/B][/QUOTE]

For the purpose of the first DC assignment, I would hand out CAT 4 assignments with only a single LL -- I would leave the the more useful exponents to users/machines that have a track recording of completely results quickly.

chalsall 2016-03-27 14:31

[QUOTE=Madpoo;430123]It's a horrible shame those users were unaware of how bad their systems were at the time, it's a waste of resources, and it vastly increased the chances a prime was missed and won't be found until DC gets to it.[/QUOTE]

This raises an idea...

Perhaps add some sort of data exchange between Primenet and the client which could then be presented via the Prime95's GUI as to the apparent health of the machine. Possibly with a link to a page on Primenet or MersenneForum along the lines of "What do I do if my machine is producing bad results".

I suspect there are many people who look at the local GUI much more often than logging into Primenet and drilling down far enough into the data to even realize their machine is producing suspect and/or bad results.

Ethan (EO) 2016-03-27 20:37

[QUOTE=axn;430106]
Maybe have a "I want to ensure reliability of my machine by verifying a known result" checkbox, if we want to give the user the ability to opt-in/out of mandatory DC.
.[/QUOTE]

Maybe reverse the sense of the wording?

Checkbox -> "Skip hardware verification assignment."

or similar.

Prime95 2016-03-27 22:17

To sum up the feedback:

1) My idea of altering the order and/or content of the initial dialog boxes wasn't great.
2) The server should assign a DC to new computers even if they select first-time LL or 100M LL. Madpoo desperately wants the data.
3) Perhaps an option either in the client or on the web pages could allow a user to skip these 2 DC assignments. GIMPS has always put the user in charge of what work their computer does, so this is probably a requirement -- we just don't need to make it particularly easy to evade initial DC assignments.

Prime95 2016-03-28 04:45

How about we generalize the DC rule --- let's call it the madpoo-needs-strategic-souble-checking-data rule:

Each and every computer must complete one verified LL test every year or one every 10 LL tests whichever is *less* frequent. There will be an opt-out (per-computer?, per-user?) accessed via the web pages. Perhaps, we should increase the requirements when a suspect result is reported.

This shouldn't be hard to implement. When a computer gets an assignment, we look for either a verified LL result within the last year or a currently active DC assignment. If none found, we assign a DC instead of a first-time LL test.

Comments?

Uncwilly 2016-03-28 04:59

Would that rule also apply to machines doing only ECM, TF, or P-1?
And if machines are not getting their assignments from PrimeNet, would the be 'force fed' a DC?

Prime95 2016-03-28 05:32

[QUOTE=Uncwilly;430205]Would that rule also apply to machines doing only ECM, TF, or P-1?[/quote]

No.

[quote]
And if machines are not getting their assignments from PrimeNet, would the be 'force fed' a DC?[/QUOTE]

I don't know how we'd do that, so no.

pepi37 2016-03-28 11:47

[QUOTE=Prime95;430204]How about we generalize the DC rule --- let's call it the madpoo-needs-strategic-souble-checking-data rule:

Each and every computer must complete one verified LL test every year or one every 10 LL tests whichever is *less* frequent. There will be an opt-out (per-computer?, per-user?) accessed via the web pages. Perhaps, we should increase the requirements when a suspect result is reported.

This shouldn't be hard to implement. When a computer gets an assignment, we look for either a verified LL result within the last year or a currently active DC assignment. If none found, we assign a DC instead of a first-time LL test.

Comments?[/QUOTE]
Does that rule be executed on all or on only new computers that start Prime95?
Second: in case all computers is affected can we disable that option editing prime.txt/local .txt

Prime95 2016-03-28 15:37

My proposal is all computers. It does not seem unreasonable to do a reliability check once a year....

You'd be able to override from a web page.

TObject 2016-03-28 21:50

I have had memory go bad in computers on many occasions. Just because a PC has completed 17 double-checks it is not guarantee that the next test will be error-free.

Computers with ECC memory can self-report. Bad double-checks is how I get alerted to problems on non-ECC equipped machines (and justify running Prime 95 on company hardware, LOL).

Madpoo 2016-03-29 17:55

[QUOTE=Prime95;430225]My proposal is all computers. It does not seem unreasonable to do a reliability check once a year....

You'd be able to override from a web page.[/QUOTE]

It's definitely the type of thing that should be ongoing. In fact, from what I've uncovered, many systems start out great and then as they head off into their sunset years, they begin to show increased instability.

It's been kind of interesting to take some of those test cases and track their bad/good progress over the years... the life and times of a modern CPU.

On the other hand there are systems that had some problem in the middle of their lifespan and then it was corrected. Maybe a bad mem module was replaced or they blew out the CPU fan.

Even more interesting are what I'd call "summer-itis" on some machines where they see to have more bad results in the warmer months (assuming they're northern hemisphere anyway).

It's easier to spot those trends when the system has a LOT of bad results, so I can't say it holds true in general, but point being, you could say an annual checkup is a good idea for computers and humans alike.


All times are UTC. The time now is 17:16.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.