Am I glad that I am currently living in this part of the world. Electricity is included in the apartment rent, no matter how much I use. I pray it stays that way for a looooooong time.
______________

Mark.

We all know how much you love and all you done for the success of this project.

Go kitties!

Well, it's all legend now...LOL.
Some do not appreciate it when I make some grandiose statements.
But when I do, I have been there, and done that.

I do not posture much. When I say I have been there and done that, I have done it.

Been there, done that, still saving up for the toaster... :D

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

Still struggling to get work, splitters till not cranking up to match demand.

---

Grant
Darwin NT

It is just a pity that we do not have caches ... it might smooth out some of the unhappiness that's around.

---

All good here 5 machines with max tasks.

---

All good here 5 machines with max tasks.

Down to 362 here of 400.
Every now & then i finally get some work which bumps it up, then dozens of "No tasks available" responses to work requests till the next bump up. But still unable to get the full 400 limit.

---

Grant
Darwin NT

Results Ready to Send ... 0

---

The limits are there to prevent issues from arising in the first place. I fail to see how raising them would help the project at all.

The project scope is clearly stated, to use spare cpu cycles that would otherwise be "wasted" running screensavers or other idle tasks. It was never intended to cope with dedicated computers or specially built crunching farms with multiple GPU's and demands for massive caches to sustain them running 24x7.

By constantly demanding that the limits be raised you are making your need to execute as many SETI tasks as possible more important than the well-being of the project itself you can use with those that stay.

The fix to this problem is larger workunits which will reduce the number of "in progress" entries in the database.

i'm for 10 time larger MB tasks.

IF that "spare cpu cycle" theory was real then get rid of RAC and Credit, and don't keep score. see how many stick around, and then that will be a valid argument.

---

Results Ready to Send ... 0

It's been that way for almost 2 days, the splitters can't keep up with demand so the Ready-to-send buffer has shrunk down to 0.
Hence the multitude of "No tasks sent" messages, with the odd request resulting in work.

There also appears to have been a problem with downloads- traffic dropped off to bugger all for a while there, and i eneded up with all of my downloads in backoff mode. Hit re-rty a couple of times & they finally came through.

---

Grant
Darwin NT

Results Ready to Send ... 0

It's been that way for almost 2 days, the splitters can't keep up with demand so the Ready-to-send buffer has shrunk down to 0.
Hence the multitude of "No tasks sent" messages, with the odd request resulting in work.

There also appears to have been a problem with downloads- traffic dropped off to bugger all for a while there, and i eneded up with all of my downloads in backoff mode. Hit re-rty a couple of times & they finally came through.

I've seen this odd download behavior also.

---

The fix to this problem is larger workunits which will reduce the number of "in progress" entries in the database.

i'm for 10 time larger MB tasks.

The problem is that's a kludge, not a fix.
Several times over the years they're upped the sensitivity of the application, resulting in greatly increased processing times. But the fact is CPU & now GPUs continue to improve their performance at the same increadible rate they've been doing so for years.

The other option is more capable hardware on the server side, but once again that's not fixing the problem, just working around it.


The problem is the databse & the only real fix will probably be to re-design it from scratch.

One database for the in progress work- Waiting to be sent WUs, WUs returned waiting for valiadtion etc & another for the the work that has been completed & validated. The second database will continue to grow over time, the first will only ever be as as large as the amount of work that is in progress. That will allow people to have large caches, and the Scheduler & the databse won't be stuggling with the huge number of entires it needs to manage at present.

---

Grant
Darwin NT

Wow! Now I've seen peak,

"Current result creation rate 67.6120/sec",

but sadly that isn't producing an increase in the ready to send cache though both my rigs are sitting on their limits.

Cheers.

Wow! Now I've seen peak,

"Current result creation rate 67.6120/sec",

but sadly that isn't producing an increase in the ready to send cache though both my rigs are sitting on their limits.

Cheers.

Yeah, the problem is it's only doing brief bursts, then dropping down to even less than when there aren't shorties in the system.
Normally it'll peak at around 50, but hold it there for an hour or 3 till the buffer has built up, then drop down again. Lately it's been struggling to do even 40, where as i reckon 55/s or more would be needed to meet demand and build up the buffer.
Received in the last hour is usually around 70,000, it's been around 120,000 for a couple of days now with peaks up to 140,000. If it were able to meet demand i'd suspect it would have been 140,000 for the last few days with even higher peaks.
There's an amazing number of shorties in the system at the moment.

---

Grant
Darwin NT

Wow! Now I've seen peak,

"Current result creation rate 67.6120/sec",

but sadly that isn't producing an increase in the ready to send cache though both my rigs are sitting on their limits.

Cheers.

Yeah, the problem is it's only doing brief bursts, then dropping down to even less than when there aren't shorties in the system.
Normally it'll peak at around 50, but hold it there for an hour or 3 till the buffer has built up, then drop down again. Lately it's been struggling to do even 40, where as i reckon 55/s or more would be needed to meet demand and build up the buffer.
Received in the last hour is usually around 70,000, it's been around 120,000 for a couple of days now with peaks up to 140,000. If it were able to meet demand i'd suspect it would have been 140,000 for the last few days with even higher peaks.
There's an amazing number of shorties in the system at the moment.

Actually that should have read "167.6120/sec" but for some reason the 1st digit went AWOL.

Cheers.

Actually that should have read "167.6120/sec" but for some reason the 1st digit went AWOL.

Yeah, i knew what you meant.
:-)


I'm wondering if it was an actual value, or just an anomaly? You'd expect a small beuffer to develop with that sort of output. But i guess if it was brief enough, whatever was produced would be gone before the next query & so wouldn't show up in the ready-to-send numbers.

---

Grant
Darwin NT

Strangely enough, despite the apparent lack of work I've been bouncing off the limits on all three of my crunchers. I just don't understand what's going on with the splitters and downloads. Has DA done something and not told anyone??

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

It must be all those 4-5min shorties that we've been chewing through lately (I'm reporting 12 every 5mins across my 2 rigs just off their video cards alone).

Cheers.

Strangely enough, despite the apparent lack of work I've been bouncing off the limits on all three of my crunchers. I just don't understand what's going on with the splitters and downloads. Has DA done something and not told anyone??

The problem is to do with the Seti servers, not the BOINC clients.

---

Grant
Darwin NT

It was the first 0 (zero) I have seen in that field, sort of prophetic at the moment.

---

Strangely enough, despite the apparent lack of work I've been bouncing off the limits on all three of my crunchers. I just don't understand what's going on with the splitters and downloads. Has DA done something and not told anyone??

The problem is to do with the Seti servers, not the BOINC clients.

Which strangely isn't a problem here, all my machines have max WU's and are staying that way.

Odd.

---