Expiration time increased

[jjjjL]

...10 days...

I doubled expiration time.

It now takes 10 days w/o a block report before a test is reassigned.

If anyone is curious, this decision is rather arbitrary. I figured people would like it and it would improve thoughput slightly. The only reason I don't make it longer is because if a test is dropped on a prime, it will take a long time before the prime gets reassigned... meaning we will be running a lot of extra tests in the mean time. However, even that's not a huge concern, as the highest weighted k-value will <i>only</i> use 1/10th of the total network power for those 10 days before it gets reassigned. In other words, a theoretical dropped test on a prime, can only waste ~1 day's worth of total work.

Anyway, don't worry about it. The main point is I raised the expiration time and so now it's 10 days instead of 5. :)

-Louie

[vaughan]

Would it be possible for the task expiration date (and time) to be visible in the client?
vaughan

[smh]

For now, you can take a look in the log file to see when the last communication with the serber was

[MikeH]

Louie said
However, even that's not a huge concern, as the highest weighted k-value will only use 1/10th of the total network power for those 10 days before it gets reassigned. In other words, a theoretical dropped test on a prime, can only waste ~1 day's worth of total work.
I would like to question these words.

I have been taking a snapshot of the project stats every now and again. One thing I have noticed is just how slowly the smallest 'n upper bound' moves forward. For k=55459, 'n upper bound' has been 1,716,105 since 13th Jan. Over the same period there have been 1848 prp tests completed for this k. If by some remarkable chance this n came back as prime today, then in actual fact around 2000-3000 prp tests will have been 'wasted'. Which is far more than 1 days work!

I'm guessing this is running on a very slow PC, or one that isn't on 24/7, or it's been recycled, or a combination of factors. Either way this could end up being a significant problem. Some suggestions were briefly discussed here (http://www.free-dc.org/forum/showthread.php?s=&threadid=2321).

Although this probably isn't the most urgent cookie right now, all I'm really saying is we don't want to get stuck in the same position as GIMPS where their equivilent of 'n upper bound' is restrained by PCs that have been doing the same test for the last two years (the same test on a newish P4 would take ~1 week). GIMPS has no end goal, so although it really shouldn't be a big deal, it still is.

With SB there is a goal - to find one prime for each k, ideally the smallest n. Thus PCs which hold back the 'n upper bound' are a problem that will only get worse. I'm not suggesting we discourage slow PCs, far from it, I'm just suggesting they are given apropriate k/n pairs. Also, maybe there should be something on the server that looks for an 'unexpected' stalling of 'n upper bound', maybe recycling the k/n pair to a 'known fast reliable' PC. If they both come back, then that's OK as a double check - so not really wasted.

.... sorry, now I'm just rambling, but I think I've made my point.

[nuutti]

I suspect that Louie is sometimes recycling that kind of numbers by hand. I am not sure but I suspect that based on the observations of the lower bound. Sometimes lower bond of all k values change a lot just during few days.

Nuutti

[Mystwalker]

Just look at k=27653:
The pending tests count increases and decreases from day to day. ATM it's 11. It was 1 or 2 once...

[MikeH]

MystwalkerJust look at k=27653:
The pending tests count increases and decreases from day to day. ATM it's 11. It was 1 or 2 once...
Hmm...k=27653 is a bit of a strange one, 'cause the 'max n tested' has gone all the way out to ~3M. But I'd agree, still strange though.

[eatmadustch]

27653 isn't being tested right now. when sob started testing they first started with this as the only k. Then, when they got to 3 million, they stopped that k and started on others. That explains why 27653 goes that far.

[Mystwalker]

Right, 27653 was the first k, but there seem to be tests handed out to ppl. It's most visible when there are only few tests and the count shouldn't increase as that k is already at 3M...

[jjjjL]

k=27653 isn't at 3 million... that was more or less the upper bound. in other words, we handed out almost all the tests up to 3 million before we got other numbers on the server... however, not all of them came back, so a few tests do exist for 27653 below 3 million... just not many

MikeH - I see what you're saying. Your insights are genuine but at the same time.... it's stuff I've thought about way too much before too. And if you look at the bigger picture, the time "wasted" that could possibly occur is so small compared to what we use to find a prime, it can't be considered. i suggest you click on the # of pending tests for each k and view the k-graphs. they are made to illustrate progress in the "effective lowerbound" since even if a test goes out for awhile, the curve on the k-graph still changes.

also, think about the fact that the waste can only occur 11 times now since there will only be 11 k value removals. something that happens so infrequently isn't going to be a huge issue.

and i disagree that it will be a worse problem going forward. in one sense, it will be worse since the divide between processor speeds will get bigger... but at the same time, fixing the problem will just become more difficult as your proposed solution will lose it's effectiveness continually going forward. assigning lower tests to faster processors will not keep the upper bound moving up much faster, because the faster procs will just finish their range, and you'll be left with the lower processors doing low tests for almost the same time as if you had just given them the lower tests.

in fact, as i sit here thinking about it all again, i think that if i implemented a queing system like you propose, i would actually assign slower procs lower tests since it will take them longer to process. the longer it takes to process, the more chance that the test will never come back... think about how actual users behave. the longer the program takes, the less likely they are to wait around for it to finish.

when you think about it like i have, you'll eventually come around to the insight that the whole reason you are worried is because you have a belief that the lower bound matters. that belief is false. the lower bound is incredibly irrelevant in practical terms. once you come to understand why, you will understand why this whole train of thought, while interesting, it entirely academic and leads to no efficiency gains for the project.

-Louie

[MikeH]

Louie said
when you think about it like i have, you'll eventually come around to the insight that the whole reason you are worried is because you have a belief that the lower bound matters. that belief is false. the lower bound is incredibly irrelevant in practical terms. once you come to understand why, you will understand why this whole train of thought, while interesting, it entirely academic and leads to no efficiency gains for the project.
Louie, of course you are right. I am being far too narrowly focused on one little issue, without think of the problems that would result, and definitely without thinking about the bigger picture.:notworthy

I guess one of the most important sub-goals of the project (to reach the big goal) is to get people to participate, and to continue to participate. Me talking about any potential wasted effort will certainly not help. So that's the last you'll hear from me on this topic.

:|ot|: For my penance I'll think about the key reasons I have joined and (most importantly) left other DC projects. I'll start a new thread or find an appropriate existing one.