Uhhh, DA, are you watching this?

Probably not, but he does watch boinc_alpha. Report posted.

Uhhh, DA, are you watching this?

Probably not, but he does watch boinc_alpha. Report posted.

Thank you very much, Richard.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

new behavior for SETI@home Enhanced?
got -0.06 Credits for 4,539.72 CPU Time (yes, there is a minus before the Credit)

LOL. I knew they were using rand() to "calculate" the credit. But I thought they would at least do something like this

r = (r < 0) ? 0-r : r;

new behavior for SETI@home Enhanced?
got -0.06 Credits for 4,539.72 CPU Time (yes, there is a minus before the Credit)

LOL. I knew they were using rand() to "calculate" the credit. But I thought they would at least do something like this

r = (r < 0) ? 0-r : r;

To quote a project administrator from elsewhere in the BOINC world, who had better remain anonymous:

Ha! Assigning negative credit is epic. Maybe the server is assigning so much credit, that it appears to be a negative number when put in a signed variable.

LOL. I knew they were using rand() to "calculate" the credit. But I thought they would at least do something like this

r = (r < 0) ? 0-r : r;

Doesn't rand() return (pseudo)random numbers between 0.0 and 1.0 anyways? ;-)

Gruß,
Gundolf

Uhhh, DA, are you watching this?

Probably not, but he does watch boinc_alpha. Report posted.

David has worked his way down through his inbox to this report. Unfortunately, the 'negative credit' host seems to have cured itself around 22 July, and diagnostic logs are only kept on the server for 5-7 days - so we missed this one.

David asks "If it happens again please let me know ASAP." We won't see negative credit, because he's put in a fix (changeset [trac]changeset:23909[/trac]) which put in a floor at 0.00

So, if anyone sees a succession of zero credit awards from a host running a recent version of BOINC - don't worry about the BOINC 4s, we know about them - please let David know about them by email, or post details here and I'll pass them on.

David asks "If it happens again please let me know ASAP." We won't see negative credit, because he's put in a fix (changeset [trac]changeset:23909[/trac]) which put in a floor at 0.00

?

How is this fix related to our current problem?

 	303	        if (srip->elapsed_time < 0) { 
 	304	            log_messages.printf(MSG_NORMAL, 
 	305	                "[HOST#%d] [RESULT#%d] [WU#%d] negative elapsed time: %f\n", 
 	306	                srip->hostid, srip->id, srip->workunitid, 
 	307	                srip->elapsed_time 
 	308	            ); 
 	309	            srip->elapsed_time = 0; 
 	310	        }

FWIW Richard, I just found 3 WU's with negative credit.

Workunit 795029057
Workunit 795029051
Workunit 795029045

I wanted to provide some feedback since you indicated that the fix had been implemented. I thought these might help troubleshoot the issue of negative credit.

---

It's always because of hostid=5582092.

Is this the already upper mentioned machine?


- Best regards! - Sutaru Tsureku, team seti.international founder. - Optimize your PC for higher RAC. - SETI@home needs your help. -

---

It's always because of hostid=5582092.

Is this the already upper mentioned machine?

Before I posted above I looked at a number of the links to WU's above and they all "can't find workunit" messages. I found an additional 3 WU's that have negative credit and in all cases the same hostid you identified (5582092). I have no idea if this was the same hostid to which you were referring as I can't see any prior WU information above in the thread when I click on the links.

---

The question wasn't necessarily directed to you.

Matthias Lehmkuhl and the following members which looked to the WU could know if this is the same machine.

A pity that noone made an URL to the upper mentioned (1st) host with negative granted Cr. ..

;-)


(The WUs/results disappear normally after ~ 1 day out of the overview if the Cr. are granted. So then result/WU-URLs go to 'nothing'.)


[EDIT: BTW. I'll send PM to the owner.]
[EDIT#2: Done.]


- Best regards! - Sutaru Tsureku, team seti.international founder. - Optimize your PC for higher RAC. - SETI@home needs your help. -

---

@ Dave Lewis

Excellent - many thanks. Host 5582092 was doing this as recently as yesterday, so David will have some fresh records to examine. And it proves that the fix he thought he'd put in place last time didn't cure it.

@ Sutaru

The previous host was 6104235.

What did you hope to achieve by PMing the owner? What cure were you able to suggest that he carried out, since none of the rest of us have any idea what's causing it? I can imagine that David might ask for diagnostic data from that computer - the sched_request.xml files could be useful, for example. If dragon changes his setup in the meantime, that forensic evidence might be lost forever.

Boinc 6.13.0 is likely causing it as it was supplying the wrong information to projects (a lot of stuff was side shifted), the previous host has now upgraded to 6.13.1 and is getting a normal amount of credit now,

Claggy

@ Dave Lewis

Excellent - many thanks. Host 5582092 ...

Richard, I'm glad that info was helpful. Thanks for all the help you guys provide to the project.

---

@ Dave Lewis

Excellent - many thanks. Host 5582092 ...

Richard, I'm glad that info was helpful. Thanks for all the help you guys provide to the project.

Certainly was:

This time I was able to see the log,
and was surprised to see that what was negative was
not the elapsed time, but rather the GPU's peak FLOPS.
Probably (due to an NVIDIA driver bug) the # of GPU processors
was being reported as -1.
-- David

That should bolt another stable door - he'll use a default value (low but positive) instead, which should help avoid wingmates getting screwed.

And I'm sure it will give the devs food for thought....

Richard, I just noticed 3 zero credit WU's today - all coming from computer 4557700. They are:

WU 796950802
WU 796950863
WU 796950857

Looking at computer 4557700's recent valid credit shows over 30 WU's with a run time of 0. I don't recall having seen that in the past though I might be wrong.

Any help is appreciated. Since I previously saw negative credits and now I see some zero credits, I'm beginning to thing that my computer may have something misconfigured and/or may be causing problems. Hopefully it is coincidence.

I noticed you indicated above "So, if anyone sees a succession of Zero credit awards from a host running a recent version of BOINC - don't worry about the BOINC 4s, we know about them - please let David know about them by email, or post details here and I'll pass them on." Since these were zero I wanted to let you know.

Thanks in advance.

---

Richard, I just noticed 3 zero credit WU's today - all coming from computer 4557700. They are:

WU 796950802
WU 796950863
WU 796950857

Looking at computer 4557700's recent valid credit shows over 30 WU's with a run time of 0. I don't recall having seen that in the past though I might be wrong.

Any help is appreciated. Since I previously saw negative credits and now I see some zero credits, I'm beginning to thing that my computer may have something misconfigured and/or may be causing problems. Hopefully it is coincidence.

I noticed you indicated above "So, if anyone sees a succession of Zero credit awards from a host running a recent version of BOINC - don't worry about the BOINC 4s, we know about them - please let David know about them by email, or post details here and I'll pass them on." Since these were zero I wanted to let you know.

Thanks in advance.

OK, thanks.

First, the previous lot. The guess at a solution which might have created a run of zero credit awards turned out to be a red herring - it didn't work. And that explains why you were able to find the second lot of negative credit. That should have been fixed properly now - it was your previous wingmate running BOINC v6.13.0 that caused it. So, we can rule out a repeat of last time.

The 'zero run time' report from 4557700 isn't of itself a problem. He's running an older, but good, version of BOINC - v5.10.13 (I ran that myself for a long time past its 'use by' date!). Those old BOINC clients didn't keep track of 'elapsed time', so it shows as zero.

You're getting normal credit on most WUs, so I don't think you have a configuration problem. And he's getting normal credit on most WUs, so I don't think he has a configuration problem, either. But you seem to consistently get zero credit when paired with each other. I'm going to have to think about that, and perhaps try to understand Joe Segur's explanation about how CreditNew handles Anonymous Platform in cases like this. I may be some time....

That host is running Boinc 5.10.13 which doesn't report runtime, runtime is used in the calculation of NewCredit,
i reported to DA probably a year or so ago about AP tasks getting Zero credits when they were matched to a wingman whose Boinc didn't report runtime,
i think the fix for that was to use CPU time instead in those cases, i wonder if the latest fix has broken that?

Why 0 Credit for this AP WU?

Those two hosts i reported in the above thread are still running Boinc's 5.2.5 & 6.4.7, the runtime and the CPU time are the same for each result,
now why isn't Boinc 5.10.13 showing that?

Claggy

Richard and Claggy, thanks for your replies. I had completely forgotten about BOINC ver. 5.10.13's not reporting run time. Heck, I have trouble remembering where I parked my car. <grin>

I was more concerned about hosing or delaying wingmen's credit if I had a config issue. Thanks for your help.

---

Wait a minute. Does all this mean that CreditNew uses values submitted by the client for the credit calculation? I find this a bit... disturbing.

---