1. Pending credit becomes granted credit only when all three issues of the work unit come back in, AND they all agree in their data (NOT number of credits claimed). The middle number of claimed credits becomes the granted credit for all three people doing that work unit. For instance, if the three come back (and pass the validation tests), and claim 30, 40, and 50 credits... all three get 40 credits. Nobody gets granted credit until ALL three come back. If, for some reason, one or more of the three do not make it back before the unit expiration date/time, the server will automatically reissue the work unit to additional people. If I remember correctly, the expiration date/time is 2 weeks from when that work unit instance was issued originally. If we have cases where a lot of people are throwing away work units, this may mean that the credit will stay *pending* for quite some time. On the BOINC/Beta project, I still have some work units pending from MONTHS ago, because we were testing this feature. Hopefully, if everyone keeps thrown away work units to an absolute minimum, and uses small cache sizes, you will get granted credit in a reasonable amount of time.
People using large cache sizes, where the work units sit there for more than a few days before processing, just slow down the works. I have my cache preferences set to 2 to 3 days, for instance. I consider those to be a reasonable amount.
Mberggraf posted a clip from his/her log, with issues about various lines.
> SETI@home - 2004-06-25 18:42:51 - Message from server: Not sending work - last RPC too recent: 439 sec
> SETI@home - 2004-06-25 18:42:51 - No work from project
> SETI@home - 2004-06-25 18:42:51 - Deferring communication with project for 13 minutes and 18 seconds
This feature ('last RPC too recent') was put in to prevent a situtation that caused clients to effectively DDoS the server, each client trying 1 or more times a second to request work... which wasn't available. Far from 'wasteing' the server's time, it triggers a delay backoff which makes the client 'shut up' for a while, *saving* the server from a deluge of requests. The best way to solve this issue? Maybe not. But its the way THEY chose to solve it.
There is an extreme shortage of work in this project because Berkeley seems to have underestimated both the rate at which people move from S@H-Classic, and they underestimated how many units each person would try and grab. Large cache sizes might have been necessary in S@H-Classic because of the downtime and connection difficulties. However, in my opinion, here they are a detriment at this time. Berkeley staff are upgrading splitting capacity. Until that gets installed and running, and a reasonable surplus of work units generated, if people would reduce their cache sizes, it MIGHT help us get something approaching a fair distribution. If there are (totally made up number) 1000 work units available, then 20 people could grab 50 (current hardwired maximum per host [not account] per 24 hour period)... or 100 people grab 10.
> Didn't you guys check ANYTHING before launching this project?!
Yes, we DID check things... A LOT. Berkeley caught us (the Beta testers) totally by surprise when they went public when they did. Myself, I was not expecting it for another month or two. Please don't blame the Beta Testers for this. But, since the staff at Berkeley went public, we gotta live with it. Many of us are watching the forums and this area and trying to help those new to BOINC. Carping, moaning, whineing, and groaning on people with questions' part does NOT help our attitudes, nor does it help our willingness to do so. Politeness *IS* appreciated.
> 3. Why doesn't the client even save my preferences locally?!? If I tell the
> thing to operate ALL THE TIME and DON'T CONNECT... then I MEAN IT!!! When I
> re-boot it goes back to "I'll do what I want when I want" mode.
The 'disable network access' failure to be sticky is a known bug. It is being worked on.
Have a nice day, and be well.
KWSN Forum Admin (retired)
S@H participant since May 28, 1999
BOINC Beta Tester since Nov 19, 2003