Reply With QuoteSecret Statistics?
there is an Overall Min n = 1028727 ?
Where do you see this???
Should be holepatch
http://www.free-dc.org/forum/showthr...?threadid=8299
3rd post from the bottom up
BTW: In the Secret Statistics, there is an Overall Min n = 1028727 which is stuck for quite some time. What kind of number is it?
I guess it is an unfinished test from secondpass which did not make it back into the queue. If so, it would be nice if it would be put back into the queue so that we can see the Overall Min n grow as residue-recovery or secondpass makes progress (whichever is lower).
Last edited by chris; 02-03-2005 at 08:03 PM.
Secret Statistics?
there is an Overall Min n = 1028727 ?
Where do you see this???
In the 'Overall' line at the bottom.
I can see it, too.
Hi vjs,
i see it here: http://www.seventeenorbust.com/secret/
Secret Statistics
Server's Assignment Queues 9 minutes old Last 24 Hours
Queue Name # Tests Min n Max n # Done n Increase
dropped-tests 5 7906988 13467677 61 +2433682
error-fix 551 3010186 7807623 0 +435963
first-pass 47792 8195026 9999967 181 +8712
garbage 1375 4207586 7594989 0 n/a
global 0 n/a n/a 0 n/a
largest-prime 14182 13467751 13999982 0 n/a
missing-test 0 n/a n/a 0 n/a
(not queued) n/a n/a n/a 3 n/a
residue-recovery 2480 1415472 2999769 0 n/a
second-pass 90875 1418937 4999946 248 +64194
Overall 163866 1028727 13999982 494 +-326016
Look closer:
Overall 163866 1028727 13999982 494 +-326016
Look even closer: 1028727
Because of the great efforts of everyone that's double checking, we have now moved to a position where DC is running slightly faster than the main PRP effort.
This can be seen here in this line
To be more exact, over the last 14 days, the number of non-factored tests between the main and DC PRP waves has been decreasing at a rate of 5 per day.Code:: < 241( -273)>< 148( -115)> < 222( -5 )>< 67( -43)> < 19 1>
so sometim in the next 100 years the DC should be at an optimal point
MikeH,
I'm sorry, but I just don't see it. Or it is not reflected on this page.
The gap between first-pass min n and second-pass min n has been increasing from 6743834 on January 22, 2005 to 6787178 just now. This is a 4334 increase.
At the current rate of tests done in 24 hours, first-pass will reach 10 million in 226 days. At that time second-pass will have 39240 tests (183 days) left to reach 5 million.
We definitely should have second-pass reach 5 million when first-pass reaches 10 million. This is not happening.
In fact some people think that second pass should be close to 5 million now, and at least at 6 million when first pass reaches 10 million. This definitely is not happening.
We need more effort on second-pass.
Joe O
Sorry.Originally posted by Joe O
MikeH,
I'm sorry, but I just don't see it. Or it is not reflected on this page.
The gap between first-pass min n and second-pass min n has been increasing from 6743834 on January 22, 2005 to 6787178 just now. This is a 4334 increase.
At the current rate of tests done in 24 hours, first-pass will reach 10 million in 226 days. At that time second-pass will have 39240 tests (183 days) left to reach 5 million.
We definitely should have second-pass reach 5 million when first-pass reaches 10 million. This is not happening.
In fact some people think that second pass should be close to 5 million now, and at least at 6 million when first pass reaches 10 million. This definitely is not happening.
We need more effort on second-pass.
Done.
However, at the same time we continue to find factors for candidates in that zone. What I was eluding to was the net effort of moving PRP edges and factor finds. That -5 (it's 0 now) indicates that the number of candidates without a factor between the main and PRP edges is coming down (or at least is now static).The gap between first-pass min n and second-pass min n has been increasing from 6743834 on January 22, 2005 to 6787178 just now. This is a 4334 increase.
I agree that the edges are still moving apart, but that wasn't exactly what I said
In any case Joe, I agree that DC needs more effort. If main and DC resources remain the same, the gap will gap grow ever quicker, since for a given increase of n the tests become proportionately more difficult for smaller n (but then you already know that).
Edit: It's +4 now, so even by my rather dubious measure, numbers are increasing again...
Perhaps it was that big dump of low n factors from double-check sieve was somehow upsetting the average????
what happened when I use username QQQsecondpass?
I don't want to give it a try before admins says something.
and i'm doing my sieving right now... =))
wbr, Me. Dead J. Dona \
Kugano- the starter of this thread is one of the cheif people behind this project. Take his word for anything he says.
And now, thanks to Joe's major sieving efforts it's back out to -41.Edit: It's +4 now, so even by my rather dubious measure, numbers are increasing again...
But I guess in 14 days time that number will be positive again (particularly since DC is affected more by DNS/server issues, since the client is more likely to run out of work more quickly)
want to do this....
my hands itch......Originally posted by Keroberts1
Kugano- the starter of this thread is one of the cheif people behind this project. Take his word for anything he says.
wbr, Me. Dead J. Dona \
Mike,
In 14 days I'll have another massive dump, hopefully there will be more missed factors 1.5M<n<20M...
We will see
please, satisfy my curiosity......
what happened if i try username QQQsecondpass.
or I'll try it at Moday.
wbr, Me. Dead J. Dona \
its a syste mdesigned and implemented by the amdins from server side alterations that results in users being assigned second pass test (tests areound 1.5 million N). However insteae of how it was in the past you will recieve credit for the tests complete and as has been recently stated you'll actually have a bette rchance of finding a prime here for the time being( not a record setting prime or even one of the top ten). This does however benefit the project in several ways, first it eliminates the chance of a missed prime, it helps determine the error rate of the tests that have been done which is used ot determine an opytimal level for the DC phase, it spreeds up the sieve, and if it finds a missed prime will offer he project a rapid boost in speed and it progresses through n values.
its safe aqnd effective. I do it some but am mostly a siever. for slow machines it is ideal because they can finish test ever day inst4ead if hikding a single current level test for months. (remember a test held for months that turns out ot be prime would result in vast amounts of resources being wasted on tests being assigned for that N value whe na faster compurter could have found the prime in days instead of months.)
well, nobody cares...
no single reply.
ok, here I go....
username = QQQsecondpass
wbr, Me. Dead J. Dona \
are you talking about adding qqqsecondpassafter your user name or simply using qqqsecondpass as your user name because i don't know what will happen if you do that. but adding QQQsecondpass to the end of your regular user name (you'll ave ot edit the registry to do this) you'll be assigned and get credit for second pass tests.
Hmmm. I dunno what will happen, but my logic suggests whatever that is going to be will be the secondpass version of what would have happened if you were to use blank username, i.e. username =
Looks like the effect of the previous lot has gone now.In 14 days I'll have another massive dump, hopefully there will be more missed factors 1.5M<n<20M...
Main PRP is pulling away from DC PRP at a rate of 49 tests per day.
I can pretty much answer this question:
adding QQQsecondpass to any user name asks the server to for go the normal que assignment and get secondpass tests in that users name.
IF you used user name secret and added qqqsecondpass...
Nothing would happen you would still only get second pass tests nothing special.
Since secret is an account that is designed to pull from secondpass que by default you would basically be asking.
Hey I don't want what would normally be assigned to my account (for secret this would be secondpass) but instead give me second pass tests.
Basically for secret you don't need to add QQQ secondpass.
2.
Now if you used blank i.e. nothing... as a username followed by QQQsecondpass.
You would get the same result as having no user name. The client or server would ask for a username. If it gave you a test it would probably be assigned to the the anaomous account.
Originally posted by MikeH
Looks like the effect of the previous lot has gone now.
Main PRP is pulling away from DC PRP at a rate of 49 tests per day.
I am not too sure whether this is the good enough reason but doing double check does not "pay off" in terms of points although it might in terms of primes. The cEMs are way too low for anybody with a competitive intent to go for DC PRP.
Also, it seems that lot of people still think that prob of finding a prime by DC is way way low than in the Main PRP. I saw a lot of figures in some posts analyzing the rate of error of PRP but couldn't conclude anything. Can somebody who crunched those numbers post the results in the following manner (if possible, i know it would need to be taken with a pinch of salt but still..)
A= Prob of Main PRP at 8.5m being a prime /Time taken for Main PRP at 8.5m
B=Prob of DC 1.5 m PRP being a prime /Time taken for DC PRP at 1.5m
One can think of A and B as estimates to number of expected primes found in unit time in main and DC prp.
If people see that the estimates of A are more than B(say 5 times) then
they will start shifting to B, if they are nearly same(within a factor of, say, 1.5)
then i dont think there should be worry that DC is lagging behind.
But, i still think that cEM resolution could be quick relief solution till good estimates to error rates and other such things are obtained.
Jaat
Jaat,
This has been done and discussed already so I'll jump straight to the conclusions.
When firstpass prp was n=8M secondpass prp was at roughtly n=1.2M.
At that time it was thought that lowest justifiable double check minimum should be at a n=2.5M so that mean any n<2.5M should have been doublechecked already.
The desired level for secondpass was approximately n=4M and no higher than n=5M.
It's much more complicated than time and probability, you also have to factor in, sieve, extra work from missing a prime, factoring, elimination of k speeding up others, increased errors in high n, newer faster clients possibly using different redisuals.
Read through some of the other posts.
Also the speed points etc will be udpated with the new points scheme which will also include scores from factoring and sieving. When this points ajustment will be made who knows... but it will certainly be before the end of the project.
IMHO, if anything more effort should be put into doublechecks, sieve and factoring. Especially since we just found a prime at n=8M.
I know this has been up before, but it seems there hasn't been anything done about it.
I am a bit anoyed that the secondpass que's expiry time is as low as it is (24 hour) ... I have had quite a few tests expired when my bunch of boxed missed a single day fo crunshing for some day.
I think somthing between a few days to a week would be appropriate ... 24 hours is to little and I think there is a bit (but not a lot) of effort lost by tests that are expired but which then report in later.
Frodo,
There are quite a few questions or suggestions for the project leaders out there currently.
Test expiration is one of them, perhaps now that we are at n=1.8M this 24-hour experation should be extended. I'd also like to get a comment or two on error rates n<1.8M.
i'm trying this too now but why do i test a number lower then "n ubber bound".
Those n numbers should be done completely or not ?
And another question that may fit with that.
why are there still testings on k numbers that have a prime:
28433 18673 tests, in the last week 2 test have been done here.
that looks like waste too me.
GP500,
Couple things....
First,
The n upper bound is the lowest n which has not yet been fully tested. Alot of those are around 6M. Why... b/c people are working on them very slowly and havn't submitted a residue (completed test) yet.lower then "n upper bound"
This is also the reason why some k's (which are already prime) are still being tested. People have just not finished their test on that k yet. Once a k is proved to have a prime no additional tests (n's) are assigned for that k but results are still accepted for outstanding tests.
The "garbage" account actually tests these k/n pairs bringing up the lower bound.
see, http://www.seventeenorbust.com/secret/
as you can see the lower bound is actually n=4968607 currently.
As for why your getting tests around n=1.8M with secondpass is there is a possibility that the first test was done incorrectly and a false residue was reported. This does happen as you can see from the error-fix que on the http://www.seventeenorbust.com/secret/ page.
So basically we are testing each k/n pair twice to get a matching residue. Assume the error rate is 1%, so as long as we can roughly test 100 secondpass tests in the time it take to complete 1 first pass we are better off testing secondpass.
(The above is a tremendous over simplification for secondpass an the error rate is only half of the calculation)
Second,
I don't see where your getting this info:
"still testings on k numbers that have a prime:
28433 18673 tests,"
<edit>
O.K. now is see it... no 18673 tests were done on that k in TOTAL not in the past two weeks. If you watch this number compared to the others it's not increasing.
A good example
5359 26602 prime 1206 n/a 5191846 4128870 4128870
k=5359 still has one test outstanding at n=4128870
but
k=28433
28433 18673 prime 2473 6376584 13467625 4681105 7866697
Has not had any new tests assigned since n=7866697
Last edited by vjs; 04-27-2005 at 03:01 PM.
oke that clears somethings(alot) up thnx.
i failed too say how i noticed test incresd for that k, sorry.
Are we only doing secondpass test below nr's under the n-upper ?
Are we too finishing jobs that have been abanded*? , like finishing from the last intermediate result xx% too 100%.
"as you can see the lower bound is actually n=4968607 currently."
this n is for all k's still running i guess.
So for comparing we shoudl use this nr en the n-upper in the stats too see how we are doing
I was hoping too increase the n-upper, just for the statistical-fun.
And getting the feeling of nearing the last 1.
Ps: soem questions are a bit dubble, because of secondary-twiddeling
Are we only doing secondpass test below n's under the n-upper ?
Yes, it's impossible to do a doublecheck above n-upper since we don't have a first check yet...
Are we too finishing jobs that have been abanded*?
Yes, on the http://www.seventeenorbust.com/secret page you can see the dropped test que these are automatically reassigned. Unfortunately we have to start these tests again from 0% to avoid errors and a few other considerations.
So for comparing we shoudl use this nr en the n-upper in the stats too see how we are doing...
Yes
was hoping too increase the n-upper, just for the statistical-fun ...
Then you should login as garbage, change your username to garbage in the client, this account is intended to increase the upper bound.
And getting the feeling of nearing the last 1
Exactly my feeling as well, but I currently only have 1 P4 3.2G working in this account, come join the fun.
Nice catch Nuri I didn't think of that, looks like there are 13 tests outstanding for k=28433 (from the | in the steps).
Also 90-day old tests
http://www.seventeenorbust.com/stats/oldTests.mhtml
i don't think garbage does tests that are above n-uper bound it does tests from the 90-day old tests que. many of these are tests that were abandoned and then started up again. therefore any work done on garbage is at least a double check and likely going ot be a triple check when the user who got it listed in garbage finishes. he n-upper bound is actually the lowest N-value for which we have no residues.
Keroberts1, are you sure about that?
From the que definitions:
garbage – tests that were assigned a really long time ago but which still aren't done due to a very slow client. We can assign numbers from this queue to tighten the bounds on the current "test window."
I don't think this supports either of our conclusions about the garbage que since "aren't done due to a very slow client" doesn't infer nor deny no residue submitted. I am going on the assumption that it does infer no residue reported.
I know this appeared to be true before the ques were updated a couple months ago at that time we also thought secondpass was at 1M... but secondpass went from ~1M down to 300K for a few tests and garbage did the same. (Do you remember exactly what garbage was at before the refresh?)he n-upper bound is actually the lowest N-value for which we have no residues.
If I'm correct when the late user returns his result it will be a doublecheck if a garbage test was done, and if the user doesn't return his test before secondpass passes by his test will be a tripple when completed.
" he n-upper bound is actually the lowest N-value for which we have no residues."
i agree (but it that n is also a finished1)
http://www.seventeenorbust.com/stats/oldTests.mhtml
Even better do this for the 30 days-time period.
maybe it is wise too state a warning in that persons stats page.
So that he can sort out why;
It could indicate that that pc is without sob or it's broke.
And also if he is on a team paste a warning in the team stats, so if that person doesn't notice it on his statspage, his team members can help him out.
"He why
"fixed,, goodboy
"
Edit/i saw many are still, active but slow.
so maybe slowmachine or somethign is sukking up the cpu.
" Last 24 Hours"
I seethat we are doing less recover/secondpass then there are new one's.!
I tink i will ask some of my subteam-member too join.
There is even a bigger change of getting the primeo n your name
Some of the tests in the 90-days queue are creepy to say the least!
Since I do not intend to point the finger to specific users, I will only show some actual assignment dates, approximate n and progress so far:
Jun 2 2003, 3.7 M, 13%, 123 cEM
Oct 4 2003, 4.7M, 8%, 10 cEM
May 20 2003, 3.7M, 52%, 458 cEM
May 19 2004, 6.1M, 0%, 60cEM
There are more like these, but they should suffice for now...
2003??? Damn, what do these run on? 8086??? I'll be dead before some of those even finish computing!
IMO, there should be another deadline imposed, say 6 or 8 months MAX for the completion of a test, regardless of intermediate blocks report.
These numbers probably show machines that are not only slow but don't get enough uptime/idle processor time too, or even have problems and keep restarting their tests (God forbid!)
I acknowledge that the users meant well when they put these machines on the project, but I feel this kind of "contribution" is harmful, as it holds the project back for long times and may even be fruitless if a factor shows up in the meantime as there's currently no server-side option to remove a running test from a client (or warn that the test is definitely not needed anymore)
And of course, what if a *prime* is hidden in one of these??? Years of wasted CPU time!
Instead of advancing first pass like there's no tomorrow, we should devote more time to cleaning up these "garbage" things and the project generally should be fine tuned to discourage this from happening.
maddog1,
I agree with you. I think we need a little cleaning up of all "sub-projects" going on in SOB and get back to a known baseline again. Knock off some of the way off the mark stats back to "normal range" and go from there.
e
The change would be small for them too have the prime.
And i first of all as in my previouse post like too have a warning on the stats pages these persons are stated on.
they can check that machine if they can find it.
And freshen it up.
prevareble too an quad opteron for example
O.K. I ooked this over last night,
First Keroberts,
I believe you are correct, Mike had asked the question of "what happens now with the old tests they could just get re-qued every 90-days even though they have been tested once already". There was a proposed server fix but I'm not sure if it has been implemented. So I'd have to agree with you the "garbage" account is probably doing double checks at this point until it reaches n-upper bounds.
So I would suggest at this point not to run the garbage account until this is issue is resolved.
The simple fix on the server side would be to change how the n's were qued for garbage. As opposed to queing the lowests n's still being tested, it should que based upon lowest n with no residue.
This would be similar to the way secondpass works, lowest test with only 1 residue.
I say simple (logically simple) but it may be difficult to implement server side.
I'm not sure if this is a pressing issue since there are only 4 tests out standing, so it's not like we are wasting alot of firepower here.
Also garbage is drawing from error-fix as well, those tests are of course useful.
I'll switch my garbage machine to another que next time I get to it.
Regardless the best que to run at this time is probably usernameQQQsecopndpass anyways
Now to Maddog1 and GP500,
The 90-day tests are not really that big on an issue, since the lower bound is probably correct alot of the k/n's being tested on those machine have already been done once. Besides would we want those machines picking up new tests? Second I don't think it's worth the effort of trying to contact the users, those machines are not producing anyways.
Second, I strongly suggest you go back to your hometeams and inform them about the doublecheck effort, sieve, and P-1. Just remember that P4's don't do well at sieve and are best suited in prp testing, firstpass (normal testing) or secondpass, followed by P-1 (which is a little difficult to setup and understand but do able).
BTW; am I mistaken or is DC significantly slowing down? Some weeks ago, we had 200 tests per day, now 70 (while firstpass is stable at about 200 tests per day).
Perhaps it's just that now, DC tests take much longer then some weeks ago; unfortunately, there is no graph for CEM/s as for every user for DC anymore.
Seems to me that the new possibility is not so popular as expected.
But anyway, we need much more DC.....I guess, as the new error rates are still not published (or did I miss them?)
A small: It would be perhaps be possible to make buttons in V3 for FIRSTPASS, DC, and BEST FOR THE PROJECT, where the server chooses what to assign.
Well, all this was not THAT important.... H.
Posting Permissions
