Win7-64 machine + 8800GTX + vanilla BOINC 6.10.18.: What now?

[Claggy]

Probably just leave it as it is for now,

i had problems with the different platform tags when the first multi app app_info's were posted,
you couldn't just remove the platform tag from the app_info, as it would still be in the client_state.xml,
and i don't think things worked properly, a detach/reattach would clear the platform tag from the client_state.xml
and set the seti portion of it back to normal.

Claggy

[PatrickV2]

Probably just leave it as it is for now,

i had problems with the different platform tags when the first multi app app_info's were posted,
you couldn't just remove the platform tag from the app_info, as it would still be in the client_state.xml,
and i don't think things worked properly, a detach/reattach would clear the platform tag from the client_state.xml
and set the seti portion of it back to normal.

Claggy

Well, the machine just finished the last few, cuda-only, WU's it still had (about 10 or so) but 4 of these ended with a 'Calculation error'. *sigh*

So, err, without trying to downscale your efforts, how do I run  the optimized CPU-apps, but keep the official setiathome cuda app, since that seems to be a bit more stable?

Regards,

Patrick.

[Raistmer]

So, err, without trying to downscale your efforts, how do I run  the optimized CPU-apps, but keep the official setiathome cuda app, since that seems to be a bit more stable?

Regards,

Patrick.

More stable ??
Did you bother to look on stderr for reason of computation error?

[PatrickV2]

So, err, without trying to downscale your efforts, how do I run  the optimized CPU-apps, but keep the official setiathome cuda app, since that seems to be a bit more stable?

Regards,

Patrick.

More stable ??
Did you bother to look on stderr for reason of computation error?

I tried to find the reason yes, but couldn't find anything. Where is the stderr output located?

Regards, Patrick.

[Raistmer]

Look at result page on website.

[PatrickV2]

Look at result page on website.

Aha, all 4 we-re VLAR-kills:

<core_client_version>6.10.18</core_client_version>
<![CDATA[
<message>
 - exit code -6 (0xfffffffa)
</message>
<stderr_txt>

VLAR WU (AR: 0.010757 )detected... autokill initialised
SETI@home error -6 Bad workunit header

File: ..\worker.cpp
Line: 144


</stderr_txt>
]]>

What would the 'regular' cuda app have done with these? Started the calculation and barfed out in-flight?

Regards,

Patrick.

[Claggy]

Look at result page on website.

Aha, all 4 we-re VLAR-kills:

<core_client_version>6.10.18</core_client_version>
<![CDATA[
<message>
 - exit code -6 (0xfffffffa)
</message>
<stderr_txt>

VLAR WU (AR: 0.010757 )detected... autokill initialised
SETI@home error -6 Bad workunit header

File: ..\worker.cpp
Line: 144


</stderr_txt>
]]>

What would the 'regular' cuda app have done with these? Started the calculation and barfed out in-flight?

Regards,

Patrick.

The stock Cuda app would have done the work, but would have done it at close to CPU speed,
on my 9800GTX+ they take over an hour to do, against 15 to 20 mins on mid range AR's.

Claggy

[PatrickV2]

Look at result page on website.

Aha, all 4 we-re VLAR-kills:

<core_client_version>6.10.18</core_client_version>
<![CDATA[
<message>
 - exit code -6 (0xfffffffa)
</message>
<stderr_txt>

VLAR WU (AR: 0.010757 )detected... autokill initialised
SETI@home error -6 Bad workunit header

File: ..\worker.cpp
Line: 144


</stderr_txt>
]]>

What would the 'regular' cuda app have done with these? Started the calculation and barfed out in-flight?

Regards,

Patrick.

The stock Cuda app would have done the work, but would have done it at close to CPU speed,
on my 9800GTX+ they take over an hour to do, against 15 to 20 mins on mid range AR's.

Claggy

I would not really mind having such units take the same time as on the CPU really; abandoning/'killing' them seems also rather harsh? Or does that have little impact on Seti@Home? Will my machine not be 'marked' as being unreliable in the seti database when it kills off units on a regular basis?

Also, I finally got some work for my machine, but the 8800GTX is taking about 5 to 7 minutes per cuda unit. That is as to be expected?

EDIT: Oh wait, that's not the 'real' time, as I just watched the counter going up. I suppose I could get the real time from the errlog from the seti website?

Same question for the CPU units: ~2 hours / unit on a non-overclocked Q6600?

Regards, Patrick.

[Claggy]

Use the rebranding program to move the VLAR Wu's to the CPU.

Claggy

[PatrickV2]

Use the rebranding program to move the VLAR Wu's to the CPU.

Claggy

OK, thread has 18 pages, and I see a V2 and V3 being posted on the first page. Checked the last 2 pages, no updates. Public beta and GPU areas do not contain it.

What's the most up-to-date rebranding tool, and how should this be run? Daily? Hourly?

Regards,

Patrick.

[Claggy]

The latest version is on Page 13:

Re: CPU <-> GPU rebranding

How often you run the rescheduling tool depends on your cache size, if you're got a larger cache you'll have a bit more time to reschedule any VLAR's,
with a smaller cache you'll need to run it more often to make sure any VLAR's don't get to the top of the cache and onto the GPU,

Claggy

[PatrickV2]

The latest version is on Page 13:

Re: CPU <-> GPU rebranding

How often you run the rescheduling tool depends on your cache size, if you're got a larger cache {ou'll have a bit more time to reschedule any VLAR's,
with a smaller cache you'll need to run it more often to make sure any VLAR's don't get to the top of the cache and onto the GPU,

Claggy

Thanks for point me in the right direction (towards the right page would be the better term ). Isn't it perhaps an option to put the rebranding tool in a more obvious place; this would also lessen the chances of someone downloading an old/outdated version of the tool?

However, I currently have another, non-Lunatics-related probably, problem with BOINC on the aforementioned machine:

It does not want to download WUs after it has been running for a while. I get the following errors (a small copy-paste selection):

01-Dec-09 18:38:54   SETI@home   Started download of 16no06ac.7279.1299.11.10.3
01-Dec-09 18:38:54   SETI@home   Started download of 16no06ab.22684.25021.16.10.224
01-Dec-09 18:38:56   SETI@home   Temporarily failed download of 16no06ac.7279.1299.11.10.3: connect() failed
01-Dec-09 18:38:56   SETI@home   Backing off 1 min 0 sec on download of 16no06ac.7279.1299.11.10.3
01-Dec-09 18:38:56   SETI@home   Temporarily failed download of 16no06ab.22684.25021.16.10.224: connect() failed
01-Dec-09 18:38:56   SETI@home   Backing off 1 min 0 sec on download of 16no06ab.22684.25021.16.10.224
01-Dec-09 18:39:20      Project communication failed: attempting access to reference site
01-Dec-09 18:39:21      Internet access OK - project servers may be temporarily down.
01-Dec-09 18:39:57   SETI@home   Started download of 16no06ac.7279.1299.11.10.1
01-Dec-09 18:39:57   SETI@home   Started download of 16no06ac.7279.1299.11.10.7
01-Dec-09 18:39:59      Project communication failed: attempting access to reference site
01-Dec-09 18:39:59   SETI@home   Temporarily failed download of 16no06ac.7279.1299.11.10.1: connect() failed
01-Dec-09 18:39:59   SETI@home   Backing off 1 min 9 sec on download of 16no06ac.7279.1299.11.10.1
01-Dec-09 18:39:59   SETI@home   Temporarily failed download of 16no06ac.7279.1299.11.10.7: connect() failed
01-Dec-09 18:39:59   SETI@home   Backing off 1 min 0 sec on download of 16no06ac.7279.1299.11.10.7
01-Dec-09 18:40:00      Internet access OK - project servers may be temporarily down.
01-Dec-09 18:43:39   SETI@home   Started download of 16no06ac.4594.72.12.10.245
01-Dec-09 18:43:39   SETI@home   Started download of 12se09ad.10017.19290.10.10.89
01-Dec-09 18:43:41      Project communication failed: attempting access to reference site
01-Dec-09 18:43:41   SETI@home   Temporarily failed download of 16no06ac.4594.72.12.10.245: connect() failed
01-Dec-09 18:43:41   SETI@home   Backing off 22 min 41 sec on download of 16no06ac.4594.72.12.10.245
01-Dec-09 18:43:41   SETI@home   Temporarily failed download of 12se09ad.10017.19290.10.10.89: connect() failed
01-Dec-09 18:43:41   SETI@home   Backing off 25 min 9 sec on download of 12se09ad.10017.19290.10.10.89
01-Dec-09 18:43:42      Internet access OK - project servers may be temporarily down.

However, the servers are not down, since other machines on my network (or the same machine running WinXP32 from another HD) have no problems downloading WUs. Uploading finished WUs also goes fine. Quitting/restarting BOINC (I run it in a cmd window) does not fix this. However, if I reboot the machine, and then start BOINC, it suddely starts downloading WUs again. But when I check back a day or so later, it has saved up another bunch of failed downloads.

I've tried disabling the Win7 firewall, but no change.

Any ideas here? People noticing something similar on their home-network?

Regards,

Patrick.

[_heinz]

Hi PatrickV2,
this is also been discussed in the seti at home forum.
solution is add the two following entries to your file hosts
usually you find it in C:\Windows\System32\drivers\etc
208.68.240.18 boinc2.ssl.berkeley.edu
208.68.240.13 boinc2.ssl.berkeley.edu

execute editor as admin, if you running Vista or W7.
hint: Don't forget to remove it when the issue in Berkeley is solved.

 

[Richard Haselgrove]

DON'T add the .13 address - that's the bad one.

The idea is to fix the reference to use .18 only - that was the good one last weekend.

But it's probably all historic now - I expect the rogue server will be rebooted before the end of maintenance.

[PatrickV2]

DON'T add the .13 address - that's the bad one.

The idea is to fix the reference to use .18 only - that was the good one last weekend.

But it's probably all historic now - I expect the rogue server will be rebooted before the end of maintenance.

OK, so I guess it's a problem at Seti's site (I was afraid my Win7 machine was misbehaving on my local network).

Should I now add the .18 to my hosts file, or leave it as is, and hope things clear up sometime tonight/tomorrow (local time)?

EDIT: Retried manually a few minutes ago, and WUs are, somewhat hesitantly, downloading again, so it looks like seti cleared the problem at their side...

Regards,

Patrick.