Why am I testing n's around 2 million?
Printable View
Why am I testing n's around 2 million?
Because we're in the middle of the second-pass portion of the project to ensure we haven't missed a prime below n=5M.
First-pass testing has got to 10M and it has been decided that we should finish second-pass (also known as double-check) up to 5M.
This work has already resulted in one missed prime!
To go on to the next stage we need two matching residues for every outstanding test below 5M.
I noticed by looking for a while at www.seventeenorbust.com/secret that we are now doing error-fix-tests instead of secondpass-tests. Also fetching a test with SBQueue proves that we are doing error-fix-tests right now.
At a guess they've changed the queue allocations and now the tests are coming from error fix, dropped-tests and second-pass.
Since error-fix contains the lowest n tests any new assignments will come from that queue.
When the Min n in error-fix goes above either dropped-tests or second-pass then the next test assigned will come from that queue.
The second-pass queue is still having blocks done since they were handed out up until these recent changes.
To put it simply, the server is now handing out tests with the lowest n value that we need matching residues for.
This is what I'd hoped they would do. :-)
When we have matching residues for all tests below 5M then they'll populate the first-pass queue again and anyone not selecting another queue (by putting QQQsecondpass in their username) will start on the 10M+ tests.
There is a possibility that we do this until we have matching residues for all tests below 10M. If that is their plan, than QQQsecondpass has become obsolete for all time. Secondpass tests from 10M+ will then be populated much earlier after first-pass check, so that this situation of a far behind second-pass check will never happen again.Quote:
Originally posted by Greenbank
When we have matching residues for all tests below 5M then they'll populate the first-pass queue again and anyone not selecting another queue (by putting QQQsecondpass in their username) will start on the 10M+ tests.
In short: There is no problem. This is only temporary and will end probably within a week.
Quote:
Originally posted by Greenbank
At a guess they've changed the queue allocations and now the tests are coming from error fix, dropped-tests and second-pass.
Since error-fix contains the lowest n tests any new assignments will come from that queue.
When the Min n in error-fix goes above either dropped-tests or second-pass then the next test assigned will come from that queue.
The second-pass queue is still having blocks done since they were handed out up until these recent changes.
To put it simply, the server is now handing out tests with the lowest n value that we need matching residues for.
This is what I'd hoped they would do. :-)
When we have matching residues for all tests below 5M then they'll populate the first-pass queue again and anyone not selecting another queue (by putting QQQsecondpass in their username) will start on the 10M+ tests.
You're correct. We actually meant to hand out the error-fix a long time ago but didn't realize it wasn't in the queue list to grab from... we are trying to get matching residues for all tests below 5M.
Well hopefully we don't rush back into firstpass testing. By the time we get all tests n<5M Louie and Dave should have a good grasp of the error rate etc and how far it should be pushed.
Now is probably the best opportunity to bring secondpass testing up to the correct level. I'm thinking it may be as high as n=7M?
The other benifit is the scoring becomes less of an issue if firstpass n is close to secondpass n.
Even if 5M is sufficient we could always push secondpass beyond the optimal point since it tends to lag behind. I'm still an advocate of the pushing one or two k up to 8M before we continue with firstpass.
It's still up in the air. What we'd like to do, idealy is:Quote:
Originally posted by vjs
Well hopefully we don't rush back into firstpass testing. By the time we get all tests n<5M Louie and Dave should have a good grasp of the error rate etc and how far it should be pushed.
Now is probably the best opportunity to bring secondpass testing up to the correct level. I'm thinking it may be as high as n=7M?
The other benifit is the scoring becomes less of an issue if firstpass n is close to secondpass n.
Even if 5M is sufficient we could always push secondpass beyond the optimal point since it tends to lag behind. I'm still an advocate of the pushing one or two k up to 8M before we continue with firstpass.
1 - new units
2 - new client that uses the new units
3 - update on the server side so that second pass tests get handed out and second pass stays a certain amount behind first passed, based on the error rates.
--
Mike
i believe project age should be counted in the new scoring system. Meaning i could like the value earned for work done on the project to increase slowly with time so that if people wanna stay in the stats they need to stay with the project and also so that people who no longer contribute to the project will loose their spots in the stats faster. Its better at encouraging new users and keepuing the ones we have.
No IMHO.
Stats should be the most accurate measure of actual work done -
not a decaying value based on when you did it.
Yes, I know CEMs aren't but that'll be fixed at some point, right?