Seti is down again

[msattler]

Why not just detach for a month or two? Until the new HP boxes arrive. This is what I will do ... I'm no masochist  

Quoting Papa:
"I have set No New Tasks. ... So the next time you push that Update Button, ask yourself if you are going to be the straw that broke the camels back?"
http://setiathome.berkele{/edu/forum_thread.php?id=61843#1043500

Pappa has been a bit too critical in the last few weeks........

Just let the boxes idle and keep sniffing.
Like the kitties do.  Sniff, sniff, nothing there, sniff again in a few hours.

Sniff, sniff.........and sooner or later, there will be kibble.

Sniff.  The kitties know.

Meoooooooooowww.  Sniff....sniff.......LOL  sniff sniff........

[Frizz]

There will be no harm to servers if there will be no participants.

Yes, I have to admit while scanning over Papas posting this is what I was getting ("without you users we wouldn't have this problems").

I know this will piss many power crunchers off - but why not just giving out the number of work units the project can really[/k] handle?

Anyway ... maybe in the end this all is just a huge experiment in Crowd Psychology - and Self Adaptation

P.S.
Shame that other, very-well funded, projects like for example Einstein@Home, don't allow users/developers to write optimized apps. Maybe setiquest.org well be an alternative ... one day.

[Richard Haselgrove]

Like the kitties do.  Sniff, sniff, nothing there, sniff again in a few hours.

I have no problem with the kitties sniffing every few hours.

But have you seen what a cuda box will do while caching up? It sniffs about every twenty seconds. I suggest that might well be a problem (because a 'sniff' is an incredible amount for work for the database server), and - yes - it would be better in the short term while we are resource-constrained to voluntarily limit those hosts which are in the heavy-hitting phase of their task allocations.

[Richard Haselgrove]

P.S.
Shame that other, very-well funded, projects like for example Einstein@Home, don't allow users/developers to write optimized apps. Maybe setiquest.org well be an alternative ... one day.

Did you see my reply on the Einstein message board? The source is available - linked from the front page, even, and there are instructions for compilation. The only request - and it is that, a request - is that you using a version number of 0.99 or lower when reporting results from a self-compiled application.

The main reason Einstein hasn't spawned an optimisation community is that the apps are already optimised in-house, so everybody gets an optimised app, not just the self-selected few. But I'm sure there's still scope for more optimisation - if you think you can do better, I'm sure you will be welcomed with open arms. You might even get a consultancy out of it, as Akos Fekete did.

[msattler]

Like the kitties do.  Sniff, sniff, nothing there, sniff again in a few hours.

I have no problem with the kitties sniffing every few hours.

But have you seen what a cuda box will do while caching up? It sniffs about every twenty seconds. I suggest that might well be a problem (because a 'sniff' is an incredible amount for work for the database server), and - yes - it would be better in the short term while we are resource-constrained to voluntarily limit those hosts which are in the heavy-hitting phase of their task allocations.

Richard.......I respect your opinions greatly.......
But this is just something that does not work for me.........
If the servers are working correctly, the 'sniffers' get their work or allocations quickly and are silenced accordingly.  most Boinc versions do that.  And then they sniff out more, when allowed.

The small percentage of folks like me that sniff out work all the time is such a small percentage of the user base that I refuse to accept that it has an impact.......
It's the large user base that runs out of work and Boinc sniffs..........because Boinc is TRAINED to sniff.
Even the new 20 hour backoff kitties will have to sniff once in a while, and it will add up.  Eventually, they are ALL sniffing.  Not just MY kitties.

My kitties are just trained to sniff more often.....and the few sniffs they give the servers don't bother them a bit, trust me.  It's the mulit-sniffs from the multitudes that are the problem.  And that cannot be avoided.  Even with your buddy DA's 20 hour frickin' backoffs.

I will never load a Boinc client with such backoffs.........unless I have somebody recompile it for me without.

Verstai?

[Frizz]

The only request - and it is that, a request - is that you using a version number of 0.99 or lower when reporting results from a self-compiled application.

Nice Thanks for the update.

The main reason Einstein hasn't spawned an optimisation community is that the apps are already optimised in-house, ...

AFAIK only FFT is done by the GPU at the moment - so the GPU is utilized only at about 20% (like Raistmers app in the good old days *g*). I am sure there is much space for optimization ...

[msattler]

P.S.
Shame that other, very-well funded, projects like for example Einstein@Home, don't allow users/developers to write optimized apps. Maybe setiquest.org well be an alternative ... one day.

Did you see my reply on the Einstein message board? The source is available - linked from the front page, even, and there are instructions for compilation. The only request - and it is that, a request - is that you using a version number of 0.99 or lower when reporting results from a self-compiled application.

The main reason Einstein hasn't spawned an optimisation community is that the apps are already optimised in-house, so everybody gets an optimised app, not just the self-selected few. But I'm sure there's still scope for more optimisation - if you think you can do better, I'm sure you will be welcomed with open arms. You might even get a consultancy out of it, as Akos Fekete did.

Anybody wanna stop opti's on Seti??

OMFG.......if you think that is an answer to the project's problems.......

I better just stop now.......otherwise the kitties are just going to go berserk.


Grrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr.

[Frizz]

OMFG.......if you think that is an answer to the project's problems.......

I better just stop now.......otherwise the kitties are just going to go berserk.

Grrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr.

Better stop drinking - and start reading. Properly. Nobody want's to stop optimized apps ...

[Jason G]

Now Now people.  Keep it nice please, tensions are high enough with all the bone pointing going on about server load.

[msattler]

I will simply spit if anybody suggests again that limiting the big contributors to the project is the answer to it's problems........
You (expletive deleted for clarity) have muddied the issue for faaaaaaaar to long now.
The few hosts who have the capacity to make a few more work requests to Seti are such a small percentage of the total that they are swamped by the rest.......do you actually think that anything I could do on my end including shutting them all down would make the servers stay up?

Eric knows this.........that's why the limits are put in place each week.........it limits the total amount of work requested.........not by the big users, but by everybody.

And it is more the 'everybody' that overloads the servers than the big users......we are just more visible for you barbs..........

So stop jousting at us........

[msattler]

OMFG.......if you think that is an answer to the project's problems.......

I better just stop now.......otherwise the kitties are just going to go berserk.

Grrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr.

Better stop drinking - and start reading. Properly. Nobody want's to stop optimized apps ...

Who said I was drinking........I'll tell you when I an f$$$$ing drinking.........not nice of you to presume.

[Miep]

... and I already have a migraine...

So Right first up:

Nobody suggested that only big users should be considerate of the current servers reduced capacities.
Nothing we can do about the crowd, that doesn't read forums etc. or doesn't even remember what that blue-yellow symbol in their taskbar is. And that is almost certainly the majority of the user base.
Those with eyes to read however might want to consider what they can collectively do to reduce server load.

Yes, Mark, we don't gain much if just the handfull of big ones take half a step back - it will only have an effect if everybody contributes. And of course NNT on an empty rig is not really an option [well unless you run several other projects and can switch to them to give SETI a breather]

What else? NNT and manually update once in a while. Set small cache until the worst has passed. Don't keep hitting the update button (especially not in the first half hour when everybody is homing in) I'm sure there's more tweaking options (i.e. spreading with backoffs) that can be used to 'take half a step back'.

As Richard has already pointed out, while the limits help to distribute work more evenly they increase serverload because the starved GPUs keep asking for more only to be told they already got some...
It would probably help to implement a 'you've reached a limit'-backoff, so there won't be essentially empty requests. Dripfeeding, while keeping the rigs at the limit, also doesn't help with serverload.
Effectively the 'report one, get one' is the same as if you were set to report after each task - and it makes a vast difference to serverload if you do 10x 1 or 1x 10.

So the best suggestion I can currently come up with is to intermittently set NNT: Wait till you have some work [well when the system is finally up to it] by letting boinc run it's usual backoff routine. Fill up a bit - maybe half a day worth, maybe to the limits - then go to NNT. After a few hours (i.e. while you still have some left, so you won't run dry but so that you will be asking for a reasonable amount) switch back on. fill up some, switch off. redo from start...

I've no idea how well that works, or if it is feasible for larger systems. It does require some babysitting, but it will help to reduce serverload. As to ghost creation I wouldn't think there's a different chance of a single request getting lost than of a bunch - statistically the single requests might result in less ghosts per system, but at the cost of increasing serverload.

So bottomline: If everybody could try to be a little less emotional and egoistic, we might be seeing some work before the new servers are in place instead of one crash after the other.

And as always, talking - sorry writing - to the wrong audience

[Raistmer]

Filling cache then go to disabled network has another good side:
You will accumulate lot of results to scan for elepsed times. Then you will have very nice picture of host true performance (for beta apps, copying whole project directory before switch network ON again will provide good backup for offline checking tasks that can produce invalid results online.
So, switching ON, loading cache, then switching OFF network completely - is the way I run my ATI box many weeks already.

[Raistmer]

BTW, on my good old Athlon 64 I have 3 SETI MB tasks in download state now ... and absolutely idle CPU
Einstein backup refuse to ask for work. BOINC thinks that SETI tasks should be run instead (but they not downloaded and will not be downloaded any time soon).
Obviously it's BOINC bug. Anyone knows is it fixed already and in what BOINC version?

[Jason G]

BTW, on my good old Athlon 64 I have 3 SETI MB tasks in download state now ...

Ahhh, so you're the one blowing up the servers. 

Obviously it's BOINC bug. Anyone knows is it fixed already and in what BOINC version?

Not sure which Boinc version it was introduced in, fairly recent I think.

[Edit:] http://boinc.berkeley.edu/trac/wiki/VersionHistory says 6.10.19-56   , so probably buggy I suppose.  Will see if I can see anything obvious in my modded 6.10.58 this weekend.

[Later:]  Check your debts, and also whether those 3 tasks in the download queue are blocking all requests for work (Shouldn't be    any uploads ?).