I re-enabled work requests on my old PII-233 for this project after reading the News:
October 22, 2008
We've switched workunit generation to single redundancy mode for testing purposes.
I was a bit surprised to get a Task which was created using the old replication and quorum rules.
My PII was almost always the third to report it's results, and therefore doing mostly unnecessary work.
My faster Athlon XP currently has a LTD for this project of -1.1 million.
On furher investigation, I noticed that my most recent task http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=4555349 was created on 10 Oct 2008 i.e before the change in policy, so I assume the there are still a lot of tasks in the pipeline like this before we get the new ones.
____________
A lot, yes. 148,151 in the "Ready to send" queue, which should last until next year. There were around 40000 MB after the old AP work was cancelled, then the mb_splitter ran again Oct 20 and added the rest.
Just came back to beta with one machine - after 1.5y of absence.
Hope that helps to go through that quicker... :)
____________
mic.
Given the current state of Astropulse testing (Linux and Windows apps seem to have no chance of validating against each other), I've decided to implement Plan B again.
Got an allocation from the residual replication=3 backlog, so let's see if we can shift them pronto.
WinterKnight, if you're watching: this should demonstrate your TDCF/workfetch point perfectly. My Xeon is showing a TDCF of 0.9163 following the super-slow-mo AP stock test: that should come down to approaching 0.15 or below with an opti app on an exclusive diet of shorties. Watch for a repeating pattern of finish one/request three/report one.
Edit - well, a whole batch of noisy (30 spike) tasks slightly distorts the picture - TDCF down to 0.7648 already - but I don't think it invalidates the principle. And just for a moment I was afraid it was a bug in the Lunatics Beta app I'm testing, but they're validating against stock, so I think it's OK.
There are now 32512 non-redundant WUs at the end of the "Ready to send" queue, 1417147 through 1449658. Maybe plan B could get us there by the end of November, but it looks like AstroPulse is coming back to life.
I'm doing my part- I have mine set to do Enhanced only (through the webpage settings).
____________
Only just got here, been at son's place, and he is only occasional cruncher, so not attached Beta, so couldn't post from his computer.
I'll keep watching. My LTD here is -404k (from 600+k), and am reluctant to manually adjust, considering my views on the scheduler, so nowhere near downloading yet.
Looks like all the IR=3 tasks have been cancelled. Got a whole new batch about an hour ago, starting with WU 1417796, showing IR=1.
The experiment is finally in progress, all the work with initial replication 3 has been cancelled. Last night they also added 15872 new WUs to the 32512 I noted Friday. Those (WUs 1417147 to 1465530) show the tabular data indicating which host has been given the task. The splitter seems to be running again and WUs above 1465530 do not show the table, as is supposed to happen with true Adaptive Replication.
[edit] Last WU as of a minute ago was 1482169.
I am getting tasks cancelled by the server when computation had already started, or even completed. Why can't the nicer kind of server-side cancellation be used, where they are cancelled only if no computation has started?
____________
I am getting tasks cancelled by the server when computation had already started, or even completed. Why can't the nicer kind of server-side cancellation be used, where they are cancelled only if no computation has started?
I got some of those too, but I got full credit for the work I'd already done. WU 1384574.
I am getting tasks cancelled by the server when computation had already started, or even completed. Why can't the nicer kind of server-side cancellation be used, where they are cancelled only if no computation has started?
I got some of those too, but I got full credit for the work I'd already done. WU 1384574.
Ah! When I originally posted, I was awarded 0. But they have since been changed to actual credits. Must have been a delay for some reason. Thanks!
____________
After returning the first results that had
initial replication 1
So, single redundancy mode works ?
____________
_\|/_
Urs
When I originally posted, I was awarded 0. But they have since been changed to actual credits.
Going to see how this applies to WU 1369534 Task 4562572; it also was server-aborted in the middle of crunching when I was doing an upload of another result.
[edit]Forgot the quotey...[/edit]
____________
Likewise. All 8 of the single-redundancy tasks I've returned so far have been sent back out for checking (well, put at the back of the queue for sending out...). That seems like a very high sample rate.
Looks like we're going to have to re-earn our "reliable" spurs the hard way.
Just checked mine all awaiting resends I think i'll NNT and finish what I have at the moment.
I see the server page states last look 136,663 awaiting to be sent.
Michael
Now, i can see both hosts (P3, T7200) receive credit with single-redundancy tasks, while all wus before the outage are still pending.
The P3 usually fails on a wu every few days, so, maybe the reaction of the server can be seen on that host then.
____________
_\|/_
Urs
Agreed - all single-redundancy results reported before Tuesday's maintenance outage were sent for re-validation, but all results after the outage have been accepted for credit without validation. Methinks they flipped a switch somewhere....
Having upload problems, All WU's returned after outage valid, WU's from Before outage still pending.
Michael.
By definition I would suspect all hosts on here to be 'honest'. So the question is do we need:
faulty hosts,
old clients,
third party clients,
third party clients with inflated benchmarks,
to test out this one replication/quorum.