How long does it take for pending units to be approved?

Questions and Answers : Getting started : How long does it take for pending units to be approved?
Message board moderation

To post messages, you must log in.

AuthorMessage
Scott Stitson

Send message
Joined: 3 Apr 99
Posts: 1
Credit: 11,140
RAC: 0
United States
Message 1962 - Posted: 25 Jun 2004, 16:13:30 UTC

It has been 24 hours.
ID: 1962 · Report as offensive
Profile Jord
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 15184
Credit: 4,362,181
RAC: 3
Netherlands
Message 1989 - Posted: 25 Jun 2004, 17:20:54 UTC

http://setiboinc.ssl.berkeley.edu/sah/forum_thread.php?id=413

----------------------
Jordâ„¢
[url=http://www.boinc.dk/index.php?page=user_statistics&userid=41965]
ID: 1989 · Report as offensive
Profile Mburggraf

Send message
Joined: 3 Apr 99
Posts: 18
Credit: 7,201
RAC: 0
United States
Message 2192 - Posted: 26 Jun 2004, 1:26:56 UTC - in response to Message 1989.  

> http://setiboinc.ssl.berkeley.edu/sah/forum_thread.php?id=413

SO THE ANSWER IS 413?

Great answer... what does it mean?!?

What it REALLY MEANS IS "Thanks for the answer. I would like to point out that this is contary to what is written on http://boinc.ssl.berkeley.edu/intro_user.php:

This is a classic example of "If you don't know... then I ain't gonna tell you till you beg... cuz I don't really know either" mentality.

Look, all we want to do is help ya'll.

But you're forcing us to learn a whole new set of 'rules', languages, etc.

What was the Beta for... didn't you learn anything?!?

Latest crap from 'the client'...

SETI@home - 2004-06-25 18:17:57 - Requesting 317656 seconds of work
SETI@home - 2004-06-25 18:17:57 - Sending request to scheduler: http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
SETI@home - 2004-06-25 18:18:02 - Scheduler RPC to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi succeeded
SETI@home - 2004-06-25 18:18:02 - Message from server: No work available
SETI@home - 2004-06-25 18:18:02 - No work from project
SETI@home - 2004-06-25 18:18:02 - Deferring communication with project for 17 minutes and 22 seconds
--- - 2004-06-25 18:35:25 - Cache low-water mark hit; requesting more work
SETI@home - 2004-06-25 18:35:25 - Requesting 318116 seconds of work
SETI@home - 2004-06-25 18:35:25 - Sending request to scheduler: http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
SETI@home - 2004-06-25 18:35:31 - Scheduler RPC to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi succeeded
SETI@home - 2004-06-25 18:35:31 - Message from server: No work available
SETI@home - 2004-06-25 18:35:31 - No work from project
SETI@home - 2004-06-25 18:35:31 - Deferring communication with project for 7 minutes and 13 seconds
--- - 2004-06-25 18:42:45 - Cache low-water mark hit; requesting more work
SETI@home - 2004-06-25 18:42:45 - Requesting 318279 seconds of work
SETI@home - 2004-06-25 18:42:45 - Sending request to scheduler: http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
SETI@home - 2004-06-25 18:42:51 - Scheduler RPC to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi succeeded
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
--- - 2004-06-25 18:56:10 - Cache low-water mark hit; requesting more work
SETI@home - 2004-06-25 18:56:10 - Requesting 318322 seconds of work
SETI@home - 2004-06-25 18:56:10 - Sending request to scheduler: http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
SETI@home - 2004-06-25 18:56:36 - Scheduler RPC to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi failed
SETI@home - 2004-06-25 18:56:36 - No schedulers responded
SETI@home - 2004-06-25 18:56:36 - Deferring communication with project for 3 hours, 43 minutes, and 8 seconds
SETI@home - 2004-06-25 19:56:36 - Deferring communication with project for 2 hours, 43 minutes, and 8 seconds


1. Stupid server-clinet relationship... RPC this, RPC that. My stupid client is wasting MY TIME and BANDWIDTH asking for crap that will be denied because 'it's too soon'. It wastes the SERVERS TIME TOO!

It's also causing us a lot of needless anxiety because we DO want to help, but can't get work units to do the crunching.

Didn't you guys check ANYTHING before launching this project?!

2. Look at the last two lines... I've got TWO DAYS WORTH of addition and subtraction errors... but this is the most sad.

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.

I'm just about ready to go back to 'folding'.

ID: 2192 · Report as offensive
Profile Jord
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 15184
Credit: 4,362,181
RAC: 3
Netherlands
Message 2204 - Posted: 26 Jun 2004, 1:50:57 UTC - in response to Message 2192.  

> > http://setiboinc.ssl.berkeley.edu/sah/forum_thread.php?id=413
>
> SO THE ANSWER IS 413?
>
> Great answer... what does it mean?!?
>
> What it REALLY MEANS IS "Thanks for the answer. I would like to point out that
> this is contary to what is written on
> http://boinc.ssl.berkeley.edu/intro_user.php:
>
> This is a classic example of "If you don't know... then I ain't gonna tell you
> till you beg... cuz I don't really know either" mentality.

Look here kiddo, I could have easily sent you off to the Keyword search, yet I pointed you to a whole thread in which I gave the same answer again, after having given the same answer 14 times before that time that same day.

That you are too lazy to either look on these forums or use the above given search option to see if other people were out there with your same question, upon which you only had to press the "I have this same question" button in the right upper corner, is not my fault.

I pointed you to a thread that had the answer at the time it was the answer. You wanted to be abusive. You now got an abusive answer back.

Read the main page for updates on what is happening. It's what we all do.
And in case you're too lazy to scroll all the way down to Return to SETI@home main page, then you just got the link to that main page.

Am I now allowed to go back and help real people in need?

----------------------
Jordâ„¢
[url=http://www.boinc.dk/index.php?page=user_statistics&userid=41965]
ID: 2204 · Report as offensive
Heffed
Volunteer tester

Send message
Joined: 19 Mar 02
Posts: 1856
Credit: 40,736
RAC: 0
United States
Message 2212 - Posted: 26 Jun 2004, 1:59:18 UTC - in response to Message 2192.  

> What was the Beta for... didn't you learn anything?!?

The "launch" was a surprise for beta as well...

But you can whine, or you can deal with it.
ID: 2212 · Report as offensive
Profile KWSN - MajorKong
Volunteer tester
Avatar

Send message
Joined: 5 Jan 00
Posts: 2892
Credit: 1,499,890
RAC: 0
United States
Message 2227 - Posted: 26 Jun 2004, 2:37:45 UTC
Last modified: 26 Jun 2004, 2:38:15 UTC

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)
http://www.kwsnforum.com

S@H participant since May 28, 1999
BOINC Beta Tester since Nov 19, 2003
ID: 2227 · Report as offensive
Heffed
Volunteer tester

Send message
Joined: 19 Mar 02
Posts: 1856
Credit: 40,736
RAC: 0
United States
Message 2246 - Posted: 26 Jun 2004, 4:10:53 UTC - in response to Message 2227.  

> > 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.

Very well said MajorKong! It's an improved version of the point I was trying to make in my post above. :)
ID: 2246 · Report as offensive

Questions and Answers : Getting started : How long does it take for pending units to be approved?


 
©2024 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.