vjs
12-22-2004, 12:59 PM
There has been several small issues lately regarding client stability and false residues. I'm sure that these are a very small % of test done on a daily basis and we probably won't miss a prime b/c of it. But here is my suggestion...
On a daily basis add 50 or so supersecret or some other low n double check tests to the main que.
These test would be assigned at random as users pull new test from the database, this wouldn't slow the project by any appreciable extent.
Once these tests are completed and residues returned, compare them to the existing residue and look for mis-matches.
Example using 1.2m tests vs 8m tests. If a normal test requires 100 hours to complete a 1.2m test would require about 1 hour, so the slowdown of the project is only 1%. The number of tests and value of n could be manipulated to determine exactly how much computing resources, not to wasted, but used validate the clients validity.
Then when or if a particular IP returns a false/mismatched residue the IP address tests could be flagged. Those test could then be used as validation checks if they were all mismatching again we would know that first IP is returning 100% useless information.
Comments?
Even if we wouldn't track down user IP's etc, it would give us an idea or heads up on potential problems. Also checking supersecret test for error's isn't really valid for determining errors now or whats going on now. Since the people doing the tests then 1.2 as active range do not represent the users of today nor their machines or clients. Also those people doing supersecret testing now are obviously not stats people with highly overclocked machines, nor average SoB users, and also their machines are probably quite relyable.
Present Supersecret testing tests for error of a group then by "relyable" individuals of now. My suggestion would tests for errors of the group now vs the errors of the group we could potential have now.
If we don't find any errors at all reduce the # of tests to 20 per day (<1 test production loss), if we are finding some or alot increase it to 1000-2000 (20 tests production loss) until the problems are solved, etc.
On a daily basis add 50 or so supersecret or some other low n double check tests to the main que.
These test would be assigned at random as users pull new test from the database, this wouldn't slow the project by any appreciable extent.
Once these tests are completed and residues returned, compare them to the existing residue and look for mis-matches.
Example using 1.2m tests vs 8m tests. If a normal test requires 100 hours to complete a 1.2m test would require about 1 hour, so the slowdown of the project is only 1%. The number of tests and value of n could be manipulated to determine exactly how much computing resources, not to wasted, but used validate the clients validity.
Then when or if a particular IP returns a false/mismatched residue the IP address tests could be flagged. Those test could then be used as validation checks if they were all mismatching again we would know that first IP is returning 100% useless information.
Comments?
Even if we wouldn't track down user IP's etc, it would give us an idea or heads up on potential problems. Also checking supersecret test for error's isn't really valid for determining errors now or whats going on now. Since the people doing the tests then 1.2 as active range do not represent the users of today nor their machines or clients. Also those people doing supersecret testing now are obviously not stats people with highly overclocked machines, nor average SoB users, and also their machines are probably quite relyable.
Present Supersecret testing tests for error of a group then by "relyable" individuals of now. My suggestion would tests for errors of the group now vs the errors of the group we could potential have now.
If we don't find any errors at all reduce the # of tests to 20 per day (<1 test production loss), if we are finding some or alot increase it to 1000-2000 (20 tests production loss) until the problems are solved, etc.