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

It downloaded more than 300 WUs and returned them ALL with client error after about a minute of processing. Can it be a cheater-want-to-be?

Cobbler

Hi

No, all the errors was by downloading.
I think this host has to reset the project or reatach.

greetz Mike

---

With each crime and every kindness we birth our future.

http://setiweb.ssl.berkeley.edu/show_host_detail.php?hostid=123036
http://setiweb.ssl.berkeley.edu/hosts_user.php?userid=30335

The 1st web site shows the faulty computer the 2nd web site shows all the computers for this person. There is something wrong with the host #123036 it has 315 wu's that all have downloading errors. Need to take this computer off line untill it gets fixed.

---

here is another host to look at
http://setiweb.ssl.berkeley.edu/show_host_detail.php?hostid=323127

this user has 280 results of which 249 haven't been run and will be in an over no reply state soon. just another person that has their connect to server settings set to high. a connect to server every 0.5 days is plenty of WU's to have on one computer. Seti hasn't had any server outages for some time now and there is no reason to hoard WU's.

---

---

> How about this one. Shows to have 16,072 computers. All I checked had
> downloaded at least 1 work unit.
>
> http://setiweb.ssl.berkeley.edu/hosts_user.php?userid=701952
>
This user seems to have attached and detached 16069 times. All of the computers after his 3rd one seem to be the same computer so he must have attached and detached to get that many computers to show up for his account.

---

> > ... connect to server every 0.5 days is plenty of WU's to
> > have on one computer. Seti hasn't had any server outages for some time
> now and
> > there is no reason to hoard WU's.
>
> If you are using any processors with Hyper-Threading; then this setting is too
> low

It shouldn't matter if you have HT machines or not as soon as the machine gets to the point that you will run out of work in 0.5 days it will download more WU's.

---

I found this in the error message section of one of the results (from original post)
"...setiathome_4.07_windows_intelx86.exe: signature verification error"

Can't recall ATM if that is the WU signature or the application itself.
I know you can compile your own version of the application, but if you just put it into the projects folder the boinc application will reject it (wrong signature).

---

2 days seems like a really good number. BOINC will keep 2 to 4 days of work, and if things are down, well, they're down.

Numbers bigger than about 5 days should probably not be allowed.

> Not if, as was my case, LHC and Seti were down for several days and CPDN had
> their first occurrance of the w.u. server locking up all week-end.
>
> LHC still shuts down every night from midnight C.E.T. until about 06:00 C.E.T.
> (23:00-05:00 Zulu) while no-one can convince me that Seti will never crash
> again, while CPDN still, occasionally, locks up - usually on weekends. Until 5
> projects are up and running, I do not advise a lower for H-T enabled
> processors.
>

---

---

>
> Perhaps I am wrong, but I thought if one is attached to say 3 projects, and
> has the setting at 1 day, then 1 day's of work would be downloaded from each
> project thereby providing 3 days worth of work - assuming all projects are set
> the same resource share.

No, you'll download 1 day with current share from each project, meaning roughly 8 hours cpu-time from each if 33% share in 3 projects.
If example seti-wu is expected to take 2 hours and lhc 5 hours you'll most likely download 5 seti & 2 lhc & 1 cpdn.

Well, actually you'll download roughly 2 days of work from each project, since the "connect every n days" gives you roughly 2n days cached, this means 9 seti & 4 lhc & 1 cpdn.

>
> Of course, if one is attached to CPDN, this becomes moot until towards the end
> of the CPDN work unit.
>

If you're not so unlucky CPDN crashes for some reason.

> > Of course, if one is attached to CPDN, this becomes moot until towards
> the end
> > of the CPDN work unit.
> >
>
> If you're not so unlucky CPDN crashes for some reason.
>
What? I am not the only one whose CPDN units started crashing (with -5 errors) as soon as the Beta unit (crunched with CPDN 4.02) was finished and the CPDN cruncher updated to 4.04?

Carl already told me that I may have to test one or two more CPDN units. If they keep crashing, my only hope would be another BOINC version. :(

Do watch out if CPDN crashes, for the hadsm3um will continue to run in the background.

---

>
> What? I am not the only one whose CPDN units started crashing (with -5 errors)
> as soon as the Beta unit (crunched with CPDN 4.02) was finished and the CPDN
> cruncher updated to 4.04?
>
> Carl already told me that I may have to test one or two more CPDN units. If
> they keep crashing, my only hope would be another BOINC version. :(
>
> Do watch out if CPDN crashes, for the hadsm3um will continue to run in the
> background.
>

Going a little off-topic here, but have also had a couple CPDN-crashes. But one crash was own stupidity, so can't really blame BOINC or CPDN for this. The 2nd was another program having a memory-leak, and during the night ran out of all memory & pagefile so both CPDN-wu crashed. :(

Is currently crunching both v4.03 & v4.04, and haven't had any problems.