2004-11-16 16:30:14 [SETI@home] Message from server: No work available (there was work but you don't have enough disk space allocated)

This is a common error (I think its the one), if I leave the BOINC interface on the default "Run based on preference", which is set to "always run" btw, it will tell me I dont have enough space alocated (I am sorry if all those GB I allocated arent enough, oh wait, they are! its an erronous error)

Then when I change it to "work always" and try to connect again I get THIS message:

2004-11-16 16:38:50 [SETI@home] Requesting 7685 seconds of work
2004-11-16 16:38:50 [SETI@home] Sending request to scheduler: http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
2004-11-16 16:38:54 [SETI@home] Scheduler RPC to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi succeeded
2004-11-16 16:38:54 [SETI@home] Message from server: Not sending work - last RPC too recent: 519 sec
.
.
2004-11-16 16:39:30 [SETI@home] Message from server: Not sending work - last RPC too recent: 37 sec
.
.
2004-11-16 16:44:52 [SETI@home] Message from server: Not sending work - last RPC too recent: 321 sec

What the hell? I avoid net speak but the only way to describe the "Not sending work, last communication too recent" message is with "Seriously, WTF!". And it measures from my last connection, not from my last success at retriving work, so every time I try (if I havent waited enough) it resets the counter. Thats bullshit! and insulting to boot! I am reconnecting because I changed settings/solved a problem, not because I am some impatient prick, and even if I was, so what. Whats really stupid is that it actually CONNECTS and THEN disconnects me with that message, instead of simply refusing the connection with that message.

---

I do not have a superman complex; for I am God, not superman!

> What the hell? I avoid net speak but the only way to describe the "Not sending
> work, last communication too recent" message is with "Seriously, WTF!".

Actually, I suspect that it was implemented strictly for survival.

When SETI has run out of work in the past, people get anxious for more work, and keep hitting "update" until they get more work -- and the server is so busy trying to handle the update requests that it can't actually do anything.

So, think of it as behaviour modification -- people who hammer the server will be penalized, so hopefully people will stop doing that.

It'd be better if the timer was in the BOINC client, so that "UPDATE" simply doesn't work more than every ten minutes or so.

The server lets you connect because it doesn't know the host ID until you're connected -- only then can it tell if you've connected too often.

The timer is ten minutes, if I remember correctly.

---

It was implimented back when BOINC was still in Beta. There was a bug that would cause a client to constantly connect. I don't remember exactly what the situation was, but in essance, the servers were being spammed by client requests. Yes, i know it is frustrating, but like Ned Ludd stated, it was implimented for survival purposes.


> Actually, I suspect that it was implemented strictly for survival.
>
> When SETI has run out of work in the past, people get anxious for more work,
> and keep hitting "update" until they get more work -- and the server is so
> busy trying to handle the update requests that it can't actually do anything.
>

---

Actually it is working as it is suppose to. When set to run based on preferences, most likely you have the preference do work while computer is in use set to no, and the do work during these hours only set. This plus the factor of percentage of time the client is on {found on your host id page} and the estimated time a unit should take and what your benchmarks results yield go into an equation to figure out how many seconds of work to request from the scheduler. This apparently happened on your machine and boinc got work from the server. Then you changed your mind and switched the client to run always. This is in effect setting the preference do work while the computer is in use to yes with no hours restrictions. This changes the amount of work needed, so boinc contacted the scheduler to get more work, but it was within the ten minute anti-spamming limit, so the scheduler did not give you any more work. It is known that the exponential backoff on failed or denied rpcs still needs some more work, and usually it doesn't kick in until after the third try. As for the not enough disk space, please check your host's id page to see what your operating system is returning as to the size of your hard drive and the amount of free space and check to make sure that the limits of disk use settings in your preferences will work with those returned figures.

"most likely you have the preference do work while computer is in use set to no"

Actually its set to yes. This was an old bug, which apperantly was solved already.

I thought it was rearing its head again, but it turns out it was the "leave at least X GB free" setting. It said not enough space, which was odd considering I allowed it to have 20GB... I then realised I only have 5GB free space left on that drive, and I set it to leave at least 10GB. I changed that to leave 0 GB now...

And as for the 10 minutes thing... it should be scaling. After one recconect within 10 minutes set it to refuse it for the next minute, after second one set it to refuse any more for the next five minutes... etc.

Also, it keeps resetting the timer, and it doesn't tell you how much time you still need to wait. It would have been better if the client, when receiving such a message from the server, automatically set it to reattempt in 10 minutes. and if you click update again within those 10 minutes it will tell you exactly how many more minutes you have to wait. With a nice explanation.

---

I do not have a superman complex; for I am God, not superman!

> Also, it keeps resetting the timer, and it doesn't tell you how much time you
> still need to wait. It would have been better if the client, when receiving
> such a message from the server, automatically set it to reattempt in 10
> minutes. and if you click update again within those 10 minutes it will tell
> you exactly how many more minutes you have to wait. With a nice explanation.

Actually, it will wait the ten minutes by itself.

Remember, this is behaviour modification -- you're supposed to stop hitting the server, that's why it sets the 10 minute penalty, and resets it when you continue to hammer the server.

You get what you want when you stop molesting the machine(s).

---

But it doesnt tell you gow LONG you have to wait. Which causes people to "experiment", and is plain annoying. Also, someone ehre said this was done due to a bug that caused the software to autoreconnect over and over, not due to some behavious modification theory.

---

I do not have a superman complex; for I am God, not superman!

> Also, it keeps resetting the timer, and it doesn't tell you how much time you
> still need to wait. It would have been better if the client, when receiving
> such a message from the server, automatically set it to reattempt in 10
> minutes. and if you click update again within those 10 minutes it will tell
> you exactly how many more minutes you have to wait. With a nice explanation.
>

In the same "RPC too recent"-message, the BOINC-server tells the client "wait 10 minutes", so the client doesn't try connecting again before in 10 minutes if you're not manually trying to override this by hitting "update".

> But it doesnt tell you gow LONG you have to wait. Which causes people to
> "experiment", and is plain annoying. Also, someone ehre said this was done due
> to a bug that caused the software to autoreconnect over and over, not due to
> some behavious modification theory.

If you have a reasonable "connect every x days" setting, and you don't hit "update" all the time, everything will be just fine.

The fact that you know what it does so well suggests you are using the manual "update" command alot.

---

What kind of bullshit attitude is this?

I needed to update because I changed my settings so that it will download new work (lower HDD filling limitations). It was COMPLETELY valid.

I dont need that bullshit of "if you get that message you are at fault" attitude, so shove it! I had perfectly justified reasoning for it... and even if I DIDN'T, then you should EDUCATE. It should be designed to explain to a newb what they are doing wrong. Not arbitrarily punish them without them knowing why... BECAUSE THEN THEY WOULNDN'T CHANGE THEIR BEHAVIOUR. And top it off with a "well its your fault for not knowing any better"; way to go PRICK!

Luckily I see that you are just a user. Projects and companies whose developers and staff hold attitutes like that invite people to do things out of spite... Like make viruses agains them (take microsoft as an example). Don't be a jerk, be constructive!

---

I do not have a superman complex; for I am God, not superman!

Another good point... If I understand correctly, you are saying have it check if you have enough work to actually do anything, and that if you connect too early but dont have enough work to run it will "forgive" it and send you something to munch on...

And yea... whatever happened to getting multiple units? I am only getting 2 work units from seti at the same time.. regardless of my setting... A workunit now takes 3 hours...

I usually connect manually simply because there is no work left, and I need to get some new work. (it should really connect whenever it finishes a work unit.. NOT every X days.. or rather, in addition to. If you dont connect for X days to get work, connect anyways to check for updates or changed settings; this will be best)

---

I do not have a superman complex; for I am God, not superman!

It's annoying to me because I have to use dial-up with three PC's and one phone line. When I enable network access, I do so with the hope of uploading, reporting, and sometimes downloading work.

Lately, I've seen some "rpc too soon" messages on my first try. If it says "backing off for 1 minute", fine. I let it timeout. But the 10 or more minutes ties up my voice phone line.

I don't have the finances to network or obtain a hi-speed Internet connection, so I have to live with what I've got. But it is annoying...

An old auto racing saying, "money buys speed! How fast do you want to go?"

---

<img src='http://www.boincsynergy.com/images/stats/comb-912.jpg'>

its an example of not catering to the needs of the users. We are donating something here, but there is only so far we will go.

I for example, detached certain computers from climate prediction, since it has no error correction (after running one of their giant things for two monthes, it has an error, and completely aborts the unit... they claim its because certain CPUs, especially when overclocked, might cause an error.. well no shit, thats when you backtrack to a stopping point a few minutes before and recalcualte that segment)

---

I do not have a superman complex; for I am God, not superman!

> I dont need that bullshit of "if you get that message you are at fault"
> attitude, so shove it!

Your posts are a great example of what I find so fascinating about SETI and BOINC.

You claim that this feature is not catering to the needs of the users, when in fact I think it is quite the opposite -- as a user I'd like to see my machines get through to schedulers without someone constantly tying things up by repeatedly hitting "update."

The folks behind SETI asked for donations of computing power that would otherwise be wasted: to use your regular workstation when you aren't using it -- yet we see people who are building machines, and running 24 hours, and frankly, are upset because the mechanism to let you grab work units and let my machines starve does not work.

Technically, the project runs very well during an outage, but the "donors" all freak when the project is down for a while.

I set my preferences to connect every 1.5 days, and simply let BOINC do what BOINC does. Even when I get the occasional "last RPC too soon" it reconnects ten minutes later and I've still got work.

I was hoping I could help you see __why__ it works the way it works. I'm sorry you decided that an honest attempt to explain something was somehow personal.

---

> It's annoying to me because I have to use dial-up with three PC's and one
> phone line. When I enable network access, I do so with the hope of uploading,
> reporting, and sometimes downloading work.

There are a number of Cable/DSL routers that have "backup" dial-up capability. You could also probably use something like the Linux Router Project software to do the same thing.

Network the computers together, one "router" set to dial on demand, and you'd pretty much be set.

There is probably even a way to restrict calls to late night so it doesn't randomly dial in.

---

> It Should ensure that if work is not available from one project that it will
> request more to compensate for it from another project , but still check to
> see if work is available again from the projects that have run out first
>
> Dave

Have you tried raising the "connect every X days" setting?

If you set for 2 days, it should start trying to reconnect when you have "2 days" of unprocessed work. If you're really going twice as fast, then 2 days is really only one day, and it should have at least a half-day when the request goes in.

I'd probably try 4 days to see if that changes things....

---

> I have to disconnect from lhc to and wait for the next request to seti for it
> to use the full cpu allocation
>
> It Should ensure that if work is not available from one project that it will
> request more to compensate for it from another project , but still check to
> see if work is available again from the projects that have run out first

I understand why it works this way, but I do agree with you that the current algorithm doesn't keep CPUs fully occupied. I've got an old dual system here that runs only SETI and LHC. With the lack of work on LHC, one CPU is usually idle. Occasionally, it'll run SETI in both slots, but most of the time the system is waiting for LHC work to become available.

On the surface, it doesn't look right, but what if, say, the machine were doing CPDN and LHC? If the machine decided to crunch a second CPDN WU instead of waiting for LHC, the slot could be tied up for months and no LHC work would be done on that machine at all.

I see the current algorithm as a best effort to keep the machines busy enough and still satisfy the requirement that it be available to participate in all its configured projects.

trane

---

> > I have to disconnect from lhc to and wait for the next request to seti
> for it
> > to use the full cpu allocation
> >
> > It Should ensure that if work is not available from one project that it
> will
> > request more to compensate for it from another project , but still check
> to
> > see if work is available again from the projects that have run out first
>
>
> I understand why it works this way, but I do agree with you that the current
> algorithm doesn't keep CPUs fully occupied. I've got an old dual system here
> that runs only SETI and LHC. With the lack of work on LHC, one CPU is usually
> idle. Occasionally, it'll run SETI in both slots, but most of the time the
> system is waiting for LHC work to become available.
>
> On the surface, it doesn't look right, but what if, say, the machine were
> doing CPDN and LHC? If the machine decided to crunch a second CPDN WU instead
> of waiting for LHC, the slot could be tied up for months and no LHC work would
> be done on that machine at all.
>
> I see the current algorithm as a best effort to keep the machines busy enough
> and still satisfy the requirement that it be available to participate in all
> its configured projects.
>
There is a problem with the algorithm in that it does not currently detect idle CPUs. 3.x did detect idle CPUs, but it did not do a good job of load balancing. There ought to be a way to do both. The current algorithm will use all CPUs available if there are enough WUs of any sort available. The obvious solution is to set the cache size to long enough to get enough WUs to cover all of the CPUs * 2 or so. This will usually generate enough WUs to keep all of the CPUs busy.

---

BOINC WIKI

What about simple multiplication. Multiply normal cache amount by numbers of CPUs that system has (to a max of the "max CPUs to use" setting).

So if you are running seti on a computer with 4 CPUs, have it get 4 times the normal cache. Its simple, and it will work.

If the person ofcourse set "use max 2 cpus" then even if they have 4 only multiple it by 2.

---

I do not have a superman complex; for I am God, not superman!