Look at this:

hostid=369295
Owner Anonymous
Created 24 Nov 2004 23:04:19 UTC
Total Credit 0.00
Recent average credit 0.00
Average turnaround time 0 days
Results 1724

It's a waste of bandwidth and blocks validation.

This host shares WU's with ohter host having at short turnaround time.

What about setting Average turnaround time to 14 days or none, as a start value, so you have to send something back to make it lower?

Anders

---

> What about setting Average turnaround time to 14 days or none, as a start
> value, so you have to send something back to make it lower?
>
> Anders
>

Not trying to upset you here but why does it bother you? WUs that dont get used eventually get recycled anyway.

Peace!

I'm not angry or anything, BUT...

1. BOING is running on limeted resurses, why not use it as good as posible?

2. I'm chrunching as a "sport", to get higher and higher in the stats.
It _is_ for fun, I know, but...

3. I didn't say "kill the guy", but just don't let this host slow down others, like me :-)

4. This isn't a normal PC just running slow. If you don't want to contribute, stay away.

Sorry for my spelling.

Anders

---

I'm not positive the code has been turned on yet, but I have seen the code for "penalizing" turnaround for overdue worknits...and it should work, if turned on.

However, it will only work on results for a host that change from "I'm waiting" to "overdue". This is when the penalty is applied.

So, for example, if all of those 1700+ results became overdue before the code was/will be turned on, they won't affect its turnaround. Only somewhat recently "now overdue" results would affect it.

Did you look at any of the results? They show "client error" downloading the WU. And the error message from the "result" says it didn't even download anything, message is "couldn't get input files"

No harm done here, the error means the WU's are already set to be sent out again. So really, very little wasted bandwidth and the validator isn't being blocked (its getting "recycled" as soon as the error is returned). All thats wasted is a bit of processing time.

Looks more like the host has a configuration problem and the owner could use some help, too bad he has his computers hidden.

> I'm not positive the code has been turned on yet, but I have seen the code for
> "penalizing" turnaround for overdue worknits...and it should work, if turned
> on.
>

The code for "penalizing" someone missing the deadline is turned on and work as expected, but there's currently no code to change turnaround if all wu is returned with errors or all fails validation, so will either be stuck on zero or whatever the turnaround was before host went "bad".

> The code for "penalizing" someone missing the deadline is turned on and work
> as expected, but there's currently no code to change turnaround if all wu is
> returned with errors or all fails validation, so will either be stuck on zero
> or whatever the turnaround was before host went "bad".
>
Setting the start value for turnaround to 14/7 days will...:

1. keep the host from sharing WU's with fast hosts, until a fast turnaround is shown to be true.

2. be disapering in the average calculation, as soon as wu's start flowing (1% after 100 UW's)

3. have no need to change the average calculation for turnaround, make code for "penalizing" or put in more tests in the server programs.

4. seem unfair to newcommers, but make only statistical differens if the new host is sending back good WU's on a regular basis.

---

> > I'm not positive the code has been turned on yet, but I have seen the
> code for
> > "penalizing" turnaround for overdue worknits...and it should work, if
> turned
> > on.
> >
>
> The code for "penalizing" someone missing the deadline is turned on and work
> as expected, but there's currently no code to change turnaround if all wu is
> returned with errors or all fails validation, so will either be stuck on zero
> or whatever the turnaround was before host went "bad".
>

Ok, this is a slight bandwidth problem for Seti, but doesn't cause a crediting problem. If a machine has errors downloading WUs, at least the server knows right then that an error occured and can send it to another host.

My opinion, much worse is the system that downloads WUs, keeps quiet for 2 weeks and then lets them timeout...keeping other users in suspense until the WU is sent out to another user...and then hopefully processed.

> I'm not angry or anything, BUT...
>
> 1. BOING is running on limeted resurses, why not use it as good as posible?
>
> 2. I'm chrunching as a "sport", to get higher and higher in the stats.
> It _is_ for fun, I know, but...
>
> 3. I didn't say "kill the guy", but just don't let this host slow down others,
> like me :-)
>
> 4. This isn't a normal PC just running slow. If you don't want to contribute,
> stay away.
>
> Sorry for my spelling.
>
> Anders
>

You are getting upset over nothing. WUs not returned all recycle eventually.

Greg.

>
> You are getting upset over nothing. WUs not returned all recycle eventually.
>
> Greg.
>
Berkeley is trying a new thing....any unit that times out because of the 2 week time limit AUTOMATICALLY gets sent to a host that has an average return of UNDER 1 day! Should get those credits processed quicker and lessen the backlog. Could still be another 2 weeks after that if the second host also has problems and doesn't return it within 2 weeks but after that the chances are almost nil that it would happen again. That is the plan anyway.
They are slowly working thru the old units that have not been credited yet.

---

Greg,

Methinks thou mistaketh my meaning. I'm not in the least upset about this issue, concerned, yes...but not upset.

My concern is that the load of unprocessed WUs will bog down the validater/transitioner. As we are already aware from the "1 hour" shutdown today and the status page notices the validater was running behind from too much DB access...so it would seem mine is a..*cough* valid...concern ;)

Any code/concepts I can contribute to reducing this backlog are my only goal, such as my average turnaround.

Dunno if its been pointed out yet but check this one out...

http://setiweb.ssl.berkeley.edu/show_host_detail.php?hostid=428353

---

Kolch - Crunching for the BOINC@Australia team since July 2004.
Search for your own intelligence...

Don't know where to put this so

Every completed unit has this error

4.13

Bogus virtual array access

***UNHANDLED EXCEPTION****
Reason: Access Violation (0xc0000005) at address 0x76F3CBA3 read attempt to address 0x02684D7C

1: 01/06/05 04:00:35

1: StackWalk(): GetLastError = 487

***UNHANDLED EXCEPTION****
Reason: Access Violation (0xc0000005) at address 0x76F125BB read attempt to address 0xA6E99712

1: 01/06/05 09:37:47
1: SymGetLineFromAddr(): GetLastError = 126

***UNHANDLED EXCEPTION****
Reason: Access Violation (0xc0000005) at address 0x76F3CBA3 read attempt to address 0x0267A55C

1: 01/06/05 12:20:28

1: StackWalk(): GetLastError = 487



All claim around 0.02 credit 265 times

http://128.32.18.152/results.php?hostid=379474

---

Better to start a new thread, with the title describing the problem. The Windows forum in Questions and Problems is good but you'll probably get more responses here in Number Crunching.


Where did you get the stuff on the unhandle exception - from the event log or Dr Watson output?

If you have mor debugging info, include all the stuff up to and including the stack trace. That shows not only where the error occurred but where it came from,
register contents and the instructions around the error. Useful if its in the middle of Windows code or a graphics driver when it gets the error.

> Where did you get the stuff on the unhandle exception - from the event log or
> Dr Watson output?

Since the user having this host and the poster mentioning this host is different, most likely by sharing some wu with him and looking on the error-messages...

Since it doesn't seem the user behind this host have ever posted to these forums, probably the best suggestion is to try his team-forums... for anyone more fluent in german that is...

> >
> > You are getting upset over nothing. WUs not returned all recycle
> eventually.
> >
> > Greg.
> >
> Berkeley is trying a new thing....any unit that times out because of the 2
> week time limit AUTOMATICALLY gets sent to a host that has an average return
> of UNDER 1 day! Should get those credits processed quicker and lessen the
> backlog. Could still be another 2 weeks after that if the second host also has
> problems and doesn't return it within 2 weeks but after that the chances are
> almost nil that it would happen again. That is the plan anyway.
> They are slowly working thru the old units that have not been credited yet.
>
>
10-4 mikey I like your answer.

---

> I'm not positive the code has been turned on yet, but I have seen the code for
> "penalizing" turnaround for overdue worknits...and it should work, if turned
> on.
>
> However, it will only work on results for a host that change from "I'm
> waiting" to "overdue". This is when the penalty is applied.
>
> So, for example, if all of those 1700+ results became overdue before the code
> was/will be turned on, they won't affect its turnaround. Only somewhat
> recently "now overdue" results would affect it.
>
>
>
>
What is the penalty when there are overddue wus?

---

Red Bull Air Racing

Gas price by zip at Seti

> >
> What is the penalty when there are overddue wus?
>

30% of WU time limit. In the case of SETI it is 30% of 14 days.

After 8 timed out WUs in a row, you would reach 13.xxx turnaround, but from there on it just gets fractionally closer to 14 but never all the way there.

And to recover from 13.xx back to almost 1.0 would take 14 validated good units.
time avg
1 1
14 4.9
14 7.63
14 9.541
14 10.8787
14 11.81509
14 12.470563
14 12.9293941
14 13.25057587
1 9.575403109
1 7.002782176
1 5.201947523
1 3.941363266
1 3.058954286
1 2.441268001
1 2.0088876
1 1.70622132

Check this one out.

http://setiweb.ssl.berkeley.edu/results.php?hostid=146571

---

I looked at that and looked through some of the returned units and found one that got credit, yet was over due. How is that possible???

http://setiweb.ssl.berkeley.edu/result.php?resultid=23268102

---

<img src="http://boinc.mundayweb.com/seti2/stats.php?userID=2036&amp;trans=off"><img src="http://www3.telus.net/seti/teamtest1.gif">