Panic Mode On (78) Server Problems? |
![]() |
| log in |
Message boards : Number crunching : Panic Mode On (78) Server Problems?
Previous · 1 . . . 11 · 12 · 13 · 14 · 15 · 16 · 17 . . . 22 · Next
| Author | Message |
|---|---|
However since I have two GPUs that should have close to 200 WUs and it is getting down to 100 shortly. There hasn't been any hard info on the limits, just going with what others are reporting. I got down to 100 cpu yesterday at about this time, and run on NNT most of the time i request work when I get down 15 or 20, and when I'm lucky and get a successful work request, the server has replenished me to exactly 100. Not down there on GPU yet, and there haven't been many posts to confirm that limit. Still assuming it is per gpu and your limit s/b 200 a. Not sure if ghosts are causing your problem. With so many of our loyal SETI community upset and frustrated over the current situation, perhaps it would be a good time for one of the SETI staff to take a few minutes to let us know what their ideas are about the problem, why they have limited us so severely, and if they have been able to determine a way to fix things and release the restrictions. +1. I'm sure they are working on it, but... ____________ Another Fred Support SETI@home when you search the Web or shop online with GoodSearch and GoodShop | |
| ID: 1304017 · | |
Not quite true. The status page typically updates every 10 minutes... But, for reasons unknown to me, it will sometimes only update every 20 minutes. EDIT... Ooops. Sorry, I see somebody already mentioned that. ____________ ****** "Ask not, what your kitty can do for you. Ask what you can do for your kitty." As it is kitten, so shall it be done. | |
| ID: 1304031 · | |
|
Missed the edit window, but the more I think about it, the gpu limit may be total gpu rather than per gpu. Was a quick and dirty implementation. Can anyone confirm? | |
| ID: 1304039 · | |
|
While I cannot confirm it, I will say that, based on the way most SETI logic has been written, the limits are most likely 100 CPU units per host and 100 GPU units per host. I know this is not what any of us want to hear, but I suspect it is the case. :( | |
| ID: 1304044 · | |
Missed the edit window, but the more I think about it, the gpu limit may be total gpu rather than per gpu. Was a quick and dirty implementation. Can anyone confirm? I can't... The kitties are still burning off cache. And I don't use any 3rd party software to monitor the 9 rigs, so it's hard for me to know exactly how what I actually have on hand compares to what the servers think I have on hand. ____________ ****** "Ask not, what your kitty can do for you. Ask what you can do for your kitty." As it is kitten, so shall it be done. | |
| ID: 1304045 · | |
Tried that route as well. It works ( SOMETIMES) Me too, maybe an Acme anvil dropped on it would flatten the problem. ;) Just kidding of course. ____________ BSG Anthem My Facebook page | |
| ID: 1304048 · | |
|
Me thinks an anvil might not be adequate : | |
| ID: 1304113 · | |
|
APs are NOT the whole problem. One problem is the crazy long back-off that BOINC throws up. Any reasonable model of a try/re-try/back-off delivery system shows that the very worst thing you can do is back-off for a long time - all it does it makes things worse, far worse. The best solution is actually to set the re-try/back-off time to around 50-75% of the server swap time (remember the download servers swap over every five minutes or so). This time must be properly random, and not the "high end biased" random that is currently in use. | |
| ID: 1304145 · | |
Missed the edit window, but the more I think about it, the gpu limit may be total gpu rather than per gpu. Was a quick and dirty implementation. Can anyone confirm? Looks like that is what it is. ____________ | |
| ID: 1304161 · | |
|
Appologies if I have missed something, been busy this week, but is there not a major logic problem here? I have just run Boinc Rescheduler on my No2 cruncher and it tells me I have 324 tasks in progress whilst my SETI account page for this PC shows 426 in progress, so presumably 102 ghosts. Cruncher No2 cannot currently get any more tasks off SETI as it is over the newly imposed limit, so it cannot download these ghosts and get them off the system. For this cruncher the situation will presumably eventually resolve itself as it has a GPU and so should be allowed a total of 200 WUs. So when the SETI total in progress drops below 200 I assume the ghosts will be resent. | |
| ID: 1304172 · | |
Missed the edit window, but the more I think about it, the gpu limit may be total gpu rather than per gpu. Was a quick and dirty implementation. Can anyone confirm? Can't talk about GPU, but CPU limit is 100. Running new* installation of BOINC in AMD 6-core processor and 100 tasks. *As new install of BOINC 7.0.31 on which used 7.0.28 client. And now... out of 100, 99 tasks are ghosts. ____________ | |
| ID: 1304176 · | |
With so many of our loyal SETI community upset and frustrated over the current situation, perhaps it would be a good time for one of the SETI staff to take a few minutes to let us know what their ideas are about the problem, why they have limited us so severely, and if they have been able to determine a way to fix things and release the restrictions. Too late for me I have given up waiting for any meaningful communication from the project. I can no longer justify running 4 crunchers without really having any idea what is going on. Whatever the reasons it is not good enough. ____________ | |
| ID: 1304192 · | |
|
Because the inability to cure the disease, they are choosing to kill the patient. | |
| ID: 1304195 · | |
|
I figure, in about 4 hours, our little yellow | |
| ID: 1304199 · | |
Questions: In theory that would be possible if the download server logs are detailed enough. The general idea would be that for a task marked sent at a particular time, there ought to be a corresponding download of the WU. The download server would only know the IP address of the system which asked for the file, hopefully that would most times match the address in the host record. If not, perhaps simply checking that there were as many completed downloads as tasks assigned for a WU would be an adequate fallback. Whether it's practical is another matter. I guess it would take at least a day of programming effort trying to foresee all the possible problems, and another day testing with copies of the download server logs and data extracted from the BOINC database to see if the list of probable ghosts produced makes sense. I have too foggy a view of what the problem really is to try to guess whether the effort would help. Eric and Jeff of course have much better knowledge of what's going on with the servers. ------------------------ The most puzzling aspect I see is that if the lost work checking is performed for every work request, it ought to be impossible for one host to have more than ~200 ghosts. That is, as soon as there are any ghosts no new tasks should be assigned until those ghosts are turned into real live tasks the host can report as other_results in its scheduler requests. Richard Haselgrove's post to boinc_dev last Sunday made it clear enough, but perhaps Dr. Anderson failed to look into it once Eric had implemented damage containment changes. Joe | |
| ID: 1304201 · | |
Missed the edit window, but the more I think about it, the gpu limit may be total gpu rather than per gpu. Was a quick and dirty implementation. Can anyone confirm? A shame if it is the case. Would be better if they could have just overridden people's cache settings. Set it to 2 days for now, that will get us through most outages. Although given the difference in work fetch between v6.x & v7.x clients that probably wouldn't work to well either. The present settings will mean i'll run out of GPU work during the weekly outages. Probably CPU work as well on my i7 if they're mostly shorties. ____________ Grant Darwin NT. | |
| ID: 1304203 · | |
The most puzzling aspect I see is that if the lost work checking is performed for every work request, it ought to be impossible for one host to have more than ~200 ghosts. That is, as soon as there are any ghosts no new tasks should be assigned until those ghosts are turned into real live tasks the host can report as other_results in its scheduler requests. Richard Haselgrove's post to boinc_dev last Sunday made it clear enough, but perhaps Dr. Anderson failed to look into it once Eric had implemented damage containment changes. Joe, you have some extra background by email. | |
| ID: 1304236 · | |
|
What SETI Really Needs And Our Current Data Problems $350 Gift On The Way | |
| ID: 1304254 · | |
Missed the edit window, but the more I think about it, the gpu limit may be total gpu rather than per gpu. Was a quick and dirty implementation. Can anyone confirm? I am certain that is how it is, in fact it counts WUs in progress as well as WUs wating to run. Between my cache and running jobs, the downloads bring the total up to 200. Down to 3100 ghosts which are slowly downloading. I would normally never have that many WUs on my computer....it is a shame that the programing kept trying to send me WUs even when there were ghosts waiting to download. ____________ | |
| ID: 1304261 · | |
|
Your Karma is good. | |
| ID: 1304264 · | |
Message boards : Number crunching : Panic Mode On (78) Server Problems?
| Copyright © 2013 University of California |