I get the following error message fairly frequently:

10/17/2010 3:08:07 AM SETI@home Message from server: This computer has reached a limit on tasks in progress

Is it too much too ask for it to specify the app whose limit is reached? I would like to be able to check the app limits in my machine description so as to find out what is going on. (It would also help if bugs needed to be fixed in this area).

The server certainly knows why it is issuing this; could it be hard to have the message tell me?

---

It's easy to calc by yourself.

If the Limits are active every Rig can have for each CPU/Core 40 Workunits and for every GPU 320 Workunits.

Your Rigs can actually download 1600 Workunits each.

Helli

---

A loooong time ago: First Credits after SETI@home Restart

It's easy to calc by yourself.

If the Limits are active every Rig can have for each CPU/Core 40 Workunits and for every GPU 320 Workunits.

Your Rigs can actually download 1600 Workunits each.

Helli

Sorry - that doesn't seem to apply - I tried it, and something does NOT compute. I don't have quite enough WUs on my rig(s) to hit the limit(s). (I think). ALSO: in Message boards : Technical News : server run, October 08-11 2010 , Jeff said that the limits would be higher for this run, if I read it correctly.

(I'm running < 320 CPU WUs on each of two 8 core machines, and < 1280 WUs for 4 GT 240s on each). Although I am not far from the limits either, right now.

That's why I asked the question, I was hoping to induce a change to the msg so as to have it be more helpful.

---

Well, your right.

It would not be bad to have a Message like: This computer has reached a limit of 1280 tasks in progress


Helli

---

A loooong time ago: First Credits after SETI@home Restart

Well, your right.

It would not be bad to have a Message like: This computer has reached a limit of 1280 tasks in progress


Helli

Would like to know the app, too....

---

Would like to know the app, too....

That's easy, it's just all the project's applications that run tasks on the computer. The message is about number of tasks (work units) not a specific application.

Gruß,
Gundolf

---

Computer sind nicht alles im Leben. (Kleiner Scherz)

SETI@home classic workunits 3,758
SETI@home classic CPU time 66,520 hours

Would like to know the app, too....

That's easy, it's just all the project's applications that run tasks on the computer. The message is about number of tasks (work units) not a specific application.

Gruß,
Gundolf

OK, that makes sense...

Again: I would like to know why this limit is imposed now, when it was stated that it wouldn't be (or, rather, that the limits would be higher) coming out of this week's rest period.

And a further thought: why issue this message so many times - it must bust the servers to do it - how about some changes so if client receives this message, it forbears requesting new WUs until it has another WU to return? This would substantially reduce the msg flow on the network, would it not?

---

Again: I would like to know why this limit is imposed now, when it was stated that it wouldn't be (or, rather, that the limits would be higher) coming out of this week's rest period.

They forgot or changed their minds - wanting a quiet weekend :)

And a further thought: why issue this message so many times - it must bust the servers to do it - how about some changes so if client receives this message, it forbears requesting new WUs until it has another WU to return? This would substantially reduce the msg flow on the network, would it not?

Unless you are manually forcing an update the project backoff should limit these with longer and longer delays or if you have the client set to update a short intervals and it will ask for more work at the same time

or set your "No new tasks" for awhile until you have reduced you cache down a bit

---

Tim

Again: I would like to know why this limit is imposed now, when it was stated that it wouldn't be (or, rather, that the limits would be higher) coming out of this week's rest period.

The limit is in place to keep the few thousand heavy crunchers from using up the entire bandwidth blocking of the 200,000 other systems trying to get work. It is usually raised when bandwith usage drops off peek.

And a further thought: why issue this message so many times - it must bust the servers to do it - how about some changes so if client receives this message, it forbears requesting new WUs until it has another WU to return? This would substantially reduce the msg flow on the network, would it not?

Boinc has a mechanism to exponentially back off request for work when it is unsuccessful. You can see your number the Boinc project properties. There is a number for the max. work fetch back off and another has the count down to the next request. Unfortunately, some people insist on using older clients without this mechanism which continuously pound the servers with requests or they hit the update button.

Perhaps this message could be changed to reflect the fact that it is a GLOBAL limit for WUs, not "a" limit. It would be less confusing, and therefore perhaps somewhat lessen use of the Update button by those of us who (at least occasionally) use it.

---