Printable View
What is the expiration time? (if it is a word at all) I've got a couple of clients running, but i didn't sent the intermediate blocks. In "expire tests" they are all gone now. Is it possible for me to send the whole tests after all or was it all for nothing so far? When I choose to send them, will my points be deducted later?
I'm talking about 5 tests so far...:(
the server expires tests 10 days from the last time they heard from you. If you don't have intermediate blocks sent and the test takes more than 10 days it will be reassigned. If the test is almosty done then you should finish it anyways because although it has been reassigned there is no gaurentee that they will be finished (as a matter of fact you could post the tests you're running and how far along you are so that others who might have recieved those could stop working on then and expire them after you have sent in your results. I don't know if you'll still be credited for tests that other people have finished once they are done but having finished them first I'd assume you'l get the credit. Over all the safest thin to do however would be to in the future make sure that all of your machines report back every 8-9 days at least.
you should let them report back. eventually, all tests will be retested a second time to insure the results are correct so you will prevent the need for someone else to retest them later. also, keroberts is correct, the person assigned the test might not finish it so you will prevent a third person from getting the test.
Cheers,
Louie
maybe you should raise limit to two weeks? or more, month or so.Quote:
Originally posted by jjjjL
you should let them report back. eventually, all tests will be retested a second time to insure the results are correct so you will prevent the need for someone else to retest them later. also, keroberts is correct, the person assigned the test might not finish it so you will prevent a third person from getting the test.
Cheers,
Louie
d.NET have two month expiration time with a smaller time needed to complete single block.
setting time to one month can bring to project some users with slower computers that can't complete one block within a 10 days.
many weaker boxs can be efficiently used in sieving.
I left my box over the holidays, so it won't submit any blocks for two weeks or so.
But my test is almost finished, especially with the new client it wouldn't take more than a day to finish it.
Maybe you could raise the limit for just a few days, I'm sure I'm not the only one who left his computer(s) over christmas.
i don't mind experimenting with a different limit.
i've raised the expiration to 1 month (30 days). this applys to all current and future pending tests so if you haven't reported for 9 days, you still have 21 more now to report at least 1 intermediate block report before it will reassign your test. this is probably a good policy over the holidays. if it seems to be good, we'll keep it.
note to double checkers (you know who you are): this new experation does not apply to double checking. any test with n < 3M expires in only 1 day.
also, remember that the server will let you finish an expired test and it will save the residue, so it's not lost work to finish a test even when it does expire. considering that the other person who gets it assigned may not finish as well, you may still be the only one who does a test even if you finish it after you let it expire. also, all tests will eventually be double checked (unless a prime is found before double checking reaches it) so even being #2 to finish a test is not a bad thing at all.
i'll leave the expiration longer and see if it actually results in more tests being finished w/o being reassigned.
Cheers,
Louie
Thanks! :elephant:
ok, thanks. I know what to do now. :)
:|ot|: Little off topic for this thread, but along the same lines. What is the slowest PCs anyone out there is using for regular SoB work? (so that's not secret or supersecret, and not for sieving or factoring)
And following on from that, does anyone have PCs that are switched off for much of the time, but again do regular SoB work? If so what PC spec and what on/off ratio?
Does anyone use the SoB in conjunction with other DC clients, where SoB is the lower priority and only runs when the other DC client has no work?
I'm sure that any shared information will be very useful in determining exactly how the WU timeout should be set, and perhaps how the client should be modified to report WU progress.
I can start off. I have a P3 800MHz laptop that spends most of its life sieving, but because I have an automated process for getting parts of sieve ranges, it also runs SoB for when it doesn't have any sieving work. I'd say on average the SoB client gets 4 hours per day (that's a wild guess), and it's current WU where n=5.02M was started 23-Nov, and is now 81% complete. Just to complicate matters, when SoB is running it's usually becaue it doesn't have a network connection, so it's not able to report progress too often either!:(
I'm running SoB on a PII-400, and occasionally on my very old P133 laptop. Naturally, they don't usually connect while I'm on line. That's why I originally developed my proxy/queue (see below). That way I can control what time I flush my intermediate blocks. :)
Good question, Mike, and point well taken that the expiration system could use some fine-tuning. Louie's brought this up to me recently too, and I think now's a good time to polish it up.
Ideally, the server should try to compute an optimal expiration length at the time the work is assigned. We need an algorithm that can answer the question "after what length of time does re-assigning the test make us more likely to find a prime sooner?"
Many factors affect the answer, including at least:
How long can we expect this particular computer to take to do this particular test, given its past work history?
What's the expected probability that the number being tested is prime? (Of course, we can only guess at this, but there are heuristics to make best-guesses.)
What's the current "error rate," or percentage of tests with incorrect results due to something like a hardware error?
How fast could we expect the same test to be done by another computer if it were re-assigned?
What's the "return curve" like (in other words, the probability Y, from past experience, that an AWOL client will come back and return a test assuming it's already been AWOL for time X)?
We have answers to all of those questions in the database, in the form of almost two years of test logs. So all that remains is to figure out the relationship between them and a final formula to compute the best expiration time.
--
David Norris
danorris@seventeenorbust.com
Oh, and:
HAPPY 2004!
:cheers:
--
David Norris
danorris@seventeenorbust.com
I agree that it would be a good thing to develop an expiration-time-algorithm.
I'm curios as to how you can identify the computers out there. Almost all the computers I have running use dynamic IP-adresses, I have pretty big computers and small computers (down to 400 Mhz running app. 2/3 of the day of which I have 7 running SoB, at present they use something close to 2 months for a test.) using the same range of IP-adresses.
It would also be pretty confusing if diffrent computers be given different expiration-times. For people using dial-up and the like it's pretty simple to remember one expiration time that they have to report blocks within, but to remember a list of expiration-times is pretty anoying.
So therefore I think it's best to stick with a single expiration-time for all computers.
Oh yeah and happy newyear everyone, it's great to be away for a 10 days and find a living forum when you return to the alter :notworthy
Trying to assign a expiration time based on what computer is assigned the test, would cause weird results for me, since I move the tests from computer to computer depending on which are on and running Linux (see the thread on unusual comfigurations for more details).
Likewise, I frequently switch between projects, so I might give you 100 blocks one day, and just one the next.Quote:
Trying to assign a expiration time based on what computer is assigned the test, would cause weird results for me, since I move the tests from computer to computer depending on which are on and running Linux (see the thread on unusual comfigurations for more details).
Yeah, I see your point. I had envisioned implementing some mechanism for the client to generate a unique identifier for each physical machine it runs on, and then send that information to the server. But with work unit queues and setups where it can't (or shouldn't) be determined which physical machine will process a particular test at assignment time, it renders that useless...
So you're probably right. I still think the algorithm needs to take into account the expected time to complete a test, but it probably shouldn't try to adapt itself to specific computers. Good call.
--
David Norris
danorris@seventeenorbust.com
A don't remember exactly how much tests was on a http://www.seventeenorbust.com/stats/ page, when exp daye was changed to 30, but at first glance their quantity raised up a bit.
So can admins tell us some truth. Are we happy?
I don't at all understand the question. Can you clarify what you're asking?Quote:
A don't remember exactly how much tests was on a http://www.seventeenorbust.com/stats/ page, when exp daye was changed to 30, but at first glance their quantity raised up a bit.
So can admins tell us some truth. Are we happy?
what's changed since exp date was set to 30 days?
Something goes better or worse?
Sorry, I still don't know what you're asking. What is the "something" you're referring to?Quote:
what's changed since exp date was set to 30 days?
Something goes better or worse?
When I get Death right, he's asking whether a difference in testing performance (on a project-level basis) can be seen due to the raised expiration limit.
Gotcha. Well, it's a tricky question. First of all it's worth noting that changes of the expiration time do not affect the "performance" of the network. If we were to set the expiration time to 0, making tests expire the instant they're assigned, we'd still have the exact same performance -- the exact same number of tests being reported. The only difference is that all the reported tests would be duplicates, and the productivity of the network drops to zero.
So from this we can prove that raising the expiration time cannot possibly decrease productivity, either. But it can raise it by reducing the number of duplicated tests. It's an interesting question, and I'm really not sure whether there has been a big reduction in duplications or not. I'll run some SQL queries when I get home and see if I can give you a little more practical answer ;-) I would imagine that duplicates have been reduced (improving productivity), but not much.
Depending on the definition of productivity, a high expiration time might decrease it - in case the higher expiration leads to a longer average test processing time and a prime has been found.Quote:
Originally posted by kugano
So from this we can prove that raising the expiration time cannot possibly decrease productivity, either.
(Otherwise, no time limit has to be best) ;)
Hehe, I guess that's true. I was using something along the lines of "total distinct work done [in a computation-theoretic sense]" as my definition for productivity; but you're right, that's not necessarily consistent with a goal like "maximize the probability function for finding a new prime." Which is of course the definition we should be going by. Hmmm.
Now to run those SQL queries. ;-) Or better yet, generate a plot of the drop rate vs. time with a marker showing where the expiration time was raised...
so as times goes by, some statistic was gathered, again the same question.Quote:
Originally posted by jjjjL
i don't mind experimenting with a different limit.
i've raised the expiration to 1 month (30 days).
Cheers,
Louie
whats changed?
as Louie says " if it seems to be good, we'll keep it. "
So is IT seems to be good??