You have selected to receive work from other applications if no work is available for the applications you selected
Language
Copyright © 2024 Einstein@Home. All rights reserved.
Copyright © 2024 Einstein@Home. All rights reserved.
The application
)
The application selection/preference controls have now been added to users' account pages at SETI@home and SETI Beta. I assume (but have no knowledge) that the code to make them operational also exists. Existing SETI accounts have been defaulted to accept all current applications, and not to allow alternatives - that seems to be to opposite way round from the (presumed, invisible) default account settings here.
SETI is still having work generation problems, so it'll be extremely difficult to test that everything is working to design specification, but I'll let you know when we have any hard news.
Edit - Code seems a bit counter-intuitive, but the controls appear to work. The default display is "(all applications)". In edit mode, there are two checkboxes, both ticked. If you untick both, it reverts - without explanation - to "(all applications)" and both boxes ticked - so you can't (deliberately or inadvertently) reject all work by this route. But if you then save your preferences again (without making any changes), the display changes to:
No sign at SETI of the BOINC Manager error messages reported here, though I haven't actually got any work since yesterday's maintenance outage (which is when the code was installed, I suspect).
RE: RE: Yes, this is
)
All 4 of my hosts get the same, but then they are all the same machines/setup. I am getting plenty of S5R4's, but haven't seen any S5R3's since the cut-over. I do have S5R3_4.36 exe/pdb's and S5R4_R6.04.exe's in my projects\einstein.phys.uwm.edu folder. I could ignore it and let it crunch S5R4's only, saves a bit on downloads and the S5R3's should run out fairly soon.
BOINC blog
hi geting the same redmesage
)
hi
geting the same redmesage after receveing a new task
the new task to completion is 49:28:04
h1_1188.05_S5R3_255_S5R3b_2
49hrs is a long time is it not
any idear on this one
RE: hi geting the same
)
Even for a S5R4 that's a long time, but for a S5R3....wow, that's almost like one of the AP WU's over at SETI
RE: hi geting the same
)
They have adjusted the est_flops for S5R4 in an attempt to move our DCF's to ~1.0. But they have overshot a little and many are reporting DCF of 1.4.
My DCF before this and using Power app on S5R3 was below 0.3.
So if yours was similar and have completed and reported a S5R4 task, the estimate for a S5R3 could be ~5 * actual processing time.
i have done 9 S5R4 now back
)
i have done 9 S5R4 now back on S5R3
1 RUNNING 1 REDDY TO RUN
29hrs -------- 49hrs
RE: geting the same
)
You can ignore these messages. The bug causing them will be fixed in due course. You do get tasks - the line immediately before the annoying messages tells you how many you got.
The estimate is wrong. Your S5R3 resend task will take what it always used to take and not what the estimate is predicting. BOINC is just having trouble coping with the two different science runs which have widely different DCFs.
If you want a full detailed explanation, try digesting this message.
There are preceding and followup messages as well which may help.
Cheers,
Gary.
thanks Gary read the lot need
)
thanks Gary
read the lot need to go for a lay down got head ake
garry
RE: thanks Gary read the
)
Well, I did warn you that it was full and detailed and I hinted that you might possibly suffer indigestion as a direct consequence :-).
That message sought to explain some quite accurate observations made by archae86. At first glance those observations seemed quite contradictory. However they turned out to be quite explainable.
Here is a hopefully simpler, hypothetical example. Each task that is sent out has an estimate built into it. Lets assume that a task sent to computer X is estimated to be 20 hours. You never see this estimate - it's for BOINCs eyes only. What you see is a revised estimate after BOINC has applied the DCF. If the DCF is around 0.25 (as it was for many hosts running optimised apps at the end of R3) BOINC will show you the estimate of 0.25x20 = 5 hours. If the task actually takes 5 hours, everything will be perfect. We can say that BOINC (through its adjustment to the DCF) has "learned" how to refine the project supplied estimate of 20 hours that we never did see anyway.
So along comes a new R4 task. The project estimate is 8 hours (just an example number I picked). Because BOINC has a DCF of 0.25, BOINC will be forced to tell you that the estimate is 0.25x8 = 2 hours. There is no way that BOINC can avoid giving you this estimate which will be way too low. However R4 tasks are actually taking longer than the project supplied estimate suggests. In this example, let's assume that the actual crunch time was 12 hours. When BOINC sees this, it will have a fit and in one big move it will bump the DCF from 0.25 to 1.5 because the real time divided by the estimated time (12/8) is now = 1.5.
So every other task in your cache will immediately have a big increase in its estimated crunch time. Any remaining R3 tasks will have the estimate go from 5 hours to 30 hours and any further R4 tasks will have their estimates go from 2 hours to 12 hours. So now the R4 tasks are being correctly estimated and the R3 tasks are being way over-estimated. When a further R3 task is crunched, it will still only take 5 hours as the estimate of 30 hours is simply wrong.
Isn't this exactly the sort of behaviour you are seeing?
Cheers,
Gary.
Hi Gary Nice example! I
)
Hi Gary
Nice example! I wonder if you could continue your example and use those figures to show what would happen to the DCF when an R3 is crunched again after an R4. I believe that 10% comes into the adjustment, but I'm not sure how.
Thanks
Rod