Garbage queue still not working correctly?

[Mystwalker]

Current line of http://www.seventeenorbust.com/secret/ :

garbage	840	3975670	6098291	0	+307673

http://www.seventeenorbust.com/stats/oldTests.mhtml shows 4 tests with n < 4M:

3xsk	21181•2^3792740+1	80.185.248.36	Jun 1 2003	Sep 19 10:26	78 %	1045

dgordon	28433•2^3248545+1	64.80.178.148	Mar 22 2003	Oct 8 23:52	58 %	408

jdecker	27653•2^3620301+1	66.92.17.35	May 6 2003	Sep 26 16:37	17 %	193

lynne	10223•2^3667997+1	82.133.101.81	May 13 2003	Oct 8 22:58	95 %	1062

So:
1. The test in the garbage queue is not in the oldTests list.
2. There seem to be 4 oldTests that are not in the garbage queue.

As garbage queue tests have been already assigned in the last weeks, I wonder if there is just some error in the presentation layer or if there really is a wastage of computing power...

[MikeH]

If I understood Dave's comments shortly after this queue was created, I believe that this queue has not been updated/refreshed since the day it was created. So this is now the queue of tests that had not been completed within 90 days of being assigned about 6 months ago.

Should we really be suprised that some of these tests have actually been completed by the users to which they were assigned!

....still I run garbage because it's doing good work on the error fix queue, and might eventually get back to doing good work on the garbage queue.

[vjs]

I've been wondered about that que as well, as long as garbage or secret are not doing tripple checks I think we are doing fine.

The other thing that is a little supprising to me is the error fix, I can't believe that we have that many errors around 3.6m. In order to have an error doesn't a particular k/n need to have two non-matching residues??

If there are really that many errors doesn't it make sence to put more effort into double checks from the ground up so to speak.

From 90 day by increasing n

3792740+1 21181•2 78% 1045 3xsk
4008550+1 55459•2 18% 309 tolsen
4181861+1 10223•2 53% 912 Q
4411257+1 27653•2 48% 1203 pmattson
4489868+1 21181•2 29% 840 Q
4532549+1 10223•2 94% 2858 Q
4609863+1 4847•2 59% 1797 Q
4637503+1 24737•2 92% 2936 Remy
4681105+1 28433•2 50% 1896 Balachmar
4757472+1 33661•2 21% 739 calpan
4886717+1 10223•2 41% 1707 allio
4898065+1 28433•2 53% 2182 craco
4935269+1 10223•2 92% 3843 Kapow
4944788+1 21181•2 40% 1777 allio
4976228+1 21181•2 80% 1649 agpt
4996032+1 33661•2 30% 1363 john33xyz
5011277+1 10223•2 78% 943 Q
5021086+1 55459•2 74% 3409 Dinamitci
5045590+1 5359•2 99% 4524 brainball
5049197+1 10223•2 73% 3342 craco
5060407+1 24737•2 68% 3674 Crava
5101513+1 28433•2 94% 4786 noops

[Keroberts1]

it is possible that the moderators may have palced suspicious tests in the error fix que because theuser who submitted them might have had more than one other bad test. If someone has some faulty memory they will be spittting out bad tests left adn rightand we could have several users like that at this very moment.

Its even very possible that we could have missed a prime but that is what the double check is for.

[MikeH]

The other thing that is a little surprising to me is the error fix, I can't believe that we have that many errors around 3.6m. In order to have an error doesn't a particular k/n need to have two non-matching residues??

I need to check back, but this could well have been around the time when the timeout on tests was really quite low (I certainly remember when it was only 5 days). I think this may well have resulted in a lot of double checks inadvertently being done, i.e. the client that didn't report during the timeout period, but did complete the test. Clearly some of those are non-matching, but I don't think we should be alarmed.

Now what is surprising is that the biggest n in the error fix queue is 6256623. Isn't the test timeout 30 days now? i.e. a client that doesn't report to the server at all for 30 days will cause the test to be re-issued. With this surely we shouldn't be getting many double checks with recent numbers.....and then ones with non-matching residues, now that's not good.

[MikeH]

Whilst we are on this topic, another interesting observation.

I have never seen a small test pop up in the 'error fix' queue. With the number of DC tests being done by secret, it is inconceivable that none of these are resulting in non-matching residues. So where do these go?

[vjs]

Also there are some tests been done in residue-recovery again, It looks as though the creators are trying to keep this que above that of the double checks.

inconceivable that none of these are resulting in non-matching residues.

Mike,

Do you really think we should have that many non-matching residues?

Granted I would have expected that we would have found at least one but I havn't seen one yet. If the error rate were 0.1% we should see one every 1000 results i.e. every two weeks or less...

Perhaps those non-matching resides are going to (not queued) b/c I see one of those tested done every once in a while.

Also the min max etc always report n/a, which is very curious for those nosie indivduals like myself.

Perhaps Kungao could chime in again on non-matching residues, again, simply state

"so far we have tested x double checks and recieved y mismatches, and these k/n pairs were tested a third time by z (us personally etc)",

I also suggest those who are interested futher in this point re-read the previous thread

http://www.free-dc.org/forum/showthr...5&pagenumber=3

first.

[Mystwalker]

Originally posted by MikeH
Now what is surprising is that the biggest n in the error fix queue is 6256623. Isn't the test timeout 30 days now? i.e. a client that doesn't report to the server at all for 30 days will cause the test to be re-issued. With this surely we shouldn't be getting many double checks with recent numbers.....and then ones with non-matching residues, now that's not good.

The bad thing is that we don't know the distribution of n's inside the queue. Could be that the next biggest test is at 5M...

I have never seen a small test pop up in the 'error fix' queue. With the number of DC tests being done by secret, it is inconceivable that none of these are resulting in non-matching residues. So where do these go?

Good question. As they have a very low n thus a high priority, they would be handed out pretty soon if the queue works correctly.
OTOH, this still would take several hours, so there is a certain chance it can be seen.
But IIRC, some time ago it was said that (next to?) no double check returned a non-matching residue. Maybe everything is ok - or there have been that few bad tests that the chance of missing all of them is not low enough to take place.