Just noticed that a unit one of my computers resulted in an unfair credit result.

I claimed 714. My co-pilot claimed 67....

guess what, I got 67 for 387,742.90 seconds of CPU time.

---

Just noticed that a unit one of my computers resulted in an unfair credit result.

I claimed 714. My co-pilot claimed 67....

guess what, I got 67 for 387,742.90 seconds of CPU time.

http://setiathome.berkeley.edu/workunit.php?wuid=312349656

---

Ooooh, nasty.

Would a Linux specialist like to have a look at your wingman, host 4515096?

Running BOINC v5.10.45, which should be OK.

SETI MB 5.28 was running fine.

SETI MB 6.03 has been crashing consistently with Signal 11

Astropulse seemed to run to a finish, then start all over again: it was only a short way through the second run when it reported complete, hence the low credit claim. Yet it seems to have uploaded a complete result file, and it validated (the few restarts I've seen in the past, for SETI tasks, have uploaded an incomplete/partially overwritten result file, and hence been invalid).

@ Tuvok,

Extremely bad luck. You seem to have been paired with a fellow-cruncher with a very sick computer. Not your fault, not anything you would expect to happen (and certainly not anything designed into the Astropulse search). I hope it doesn't put you off crunching: the chance of this happening again is very, very low.

Ripoff, yes. Unfair, maybe not.

The simple truth is that we're all likely to run up against some machine that will radically underclaim from time to time, and when we do, we get ripped off.

If there was some mechanism that paired all of those low-claiming machines with you exclusively, that would be unfair.

It's a ripoff -- but it's an equal-opportunity ripoff.

---

I just started testing linux x86_64 v6.03 at beta and do get the same errors like host 4515096.

---

_\|/_
U r s

That's weird. It's getting a signal 11 after calling boinc_finish(). Hmmmmm.... time to delve into what boinc_finish() actually does and where it could segfault.

I just started testing linux x86_64 v6.03 at beta and do get the same errors like host 4515096.

Eric

---

@SETIEric@qoto.org (Mastodon)

BTW, I manually granted credit to the users and hosts involved in this one.

Eric

---

@SETIEric@qoto.org (Mastodon)

I'm going to deprecate 6.03 for x86_64 until I know what's causing this.

Eric

---

@SETIEric@qoto.org (Mastodon)

BTW, I manually granted credit to the users and hosts involved in this one.

Eric

wow...thanks.

Its nice to know the big guys are watching the forums.

---

That's weird. It's getting a signal 11 after calling boinc_finish(). Hmmmmm.... time to delve into what boinc_finish() actually does and where it could segfault.

I just started testing linux x86_64 v6.03 at beta and do get the same errors like host 4515096.

Eric

*Could* possibly be remotely related to some wrestling with boinc_finish() I had when profiling windows AK_v8 builds (not Linux, perhaps there's a similar issue there though) . The instrumented builds would dump out before writing their information. Looking deeper I found the exit strategy involved (after calling boinc_finish()) was using Windows' TerminateProcess() instead of ExitProcess() which, in an explanation from Rom Walton, was to counter a tendency in the graphics builds to not close threads fast enough. For me that was OK as I wasn't making graphics builds at the time, so I switched it to ExitProcess() with a preprocessor wrapped directive set for the non-graphics build.
My understanding is that TerminateProcess() will terminate all threads immediately, which is not advised by MS when using DLL's (and I guess other global data) as one or the other thread global data will be in an unknown state for a short time. So my guess is one thread is still reading/writing when shared memory is released, but of course may not apply to the Linux segfault situation at all, as I guess it'd be using some different mechanism.

Jason

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

I've completed 3 or 4 AP WUs now, all around the 250000 - 300000 second mark and the highest I've been granted was about 760 - half of what I claimed. Here's an example that hasn't been granted as of writing (the others have dropped off the end of the list):

http://setiathome.berkeley.edu/workunit.php?wuid=313876961

It does make me want to abort any further AP WUs until there's a fix or possibly at least a good explanation!

---

I've completed 3 or 4 AP WUs now, all around the 250000 - 300000 second mark and the highest I've been granted was about 760 - half of what I claimed. Here's an example that hasn't been granted as of writing (the others have dropped off the end of the list):

http://setiathome.berkeley.edu/workunit.php?wuid=313876961

It does make me want to abort any further AP WUs until there's a fix or possibly at least a good explanation!

I worked one that long and got half that much credit.---20 times longer to process than regular WU's only 5 times the credit.

No more AP units for me. Found the switch in preferences.

For me I've found that SETI Astropulse yields somewhere on the order of 7 to 8 credits per hour (one core of a dual core AMD 5200 or similar). Other projects vary but none of the others are that low -- typically they run from 13 to 20 credits per hour.

But there is something of a problem with the 'regular' SETI work units and multicore AMD processors where they go into 'black hole' mode of no progress with dozens or hours of processing time. So I'm in something of a bind. For now, I'll let the existing AP work units complete, but will wait until some correction is made.

I'll not engage in the 'our credits are right, and everyone else is wrong' discussion that seems to be running loose on the board here, I see that as something of a religious/political argument where parties on either side end up generating more heat than light -- I figure that would give ET a bad impression of the degree to which we are enlightened. Rather, for now, I'll simply shift over to other projects which also have social redeeming goals.

I've completed 3 or 4 AP WUs now, all around the 250000 - 300000 second mark and the highest I've been granted was about 760 - half of what I claimed. Here's an example that hasn't been granted as of writing (the others have dropped off the end of the list):

http://setiathome.berkeley.edu/workunit.php?wuid=313876961

It does make me want to abort any further AP WUs until there's a fix or possibly at least a good explanation!

I worked one that long and got half that much credit.---20 times longer to process than regular WU's only 5 times the credit.

No more AP units for me. Found the switch in preferences.

---

It has been known for some time, before AP was introduced here, that AMD cpu's do not do AP units well.
In a comparison on the Beta site two computers with similar benchmark numbers completed AP units in ~36 and ~86 hrs. The cpu's were Intel E6600 and AMD X2 6000+.
And before anyone jumps in and says in must be that bad AMD string that degrades performance, Berkeley does not use the Intel compiler, they cannot afford it.

For me I've found that SETI Astropulse yields somewhere on the order of 7 to 8 credits per hour (one core of a dual core AMD 5200 or similar). Other projects vary but none of the others are that low -- typically they run from 13 to 20 credits per hour.

But there is something of a problem with the 'regular' SETI work units and multicore AMD processors where they go into 'black hole' mode of no progress with dozens or hours of processing time. So I'm in something of a bind. For now, I'll let the existing AP work units complete, but will wait until some correction is made.

I'll not engage in the 'our credits are right, and everyone else is wrong' discussion that seems to be running loose on the board here, I see that as something of a religious/political argument where parties on either side end up generating more heat than light -- I figure that would give ET a bad impression of the degree to which we are enlightened. Rather, for now, I'll simply shift over to other projects which also have social redeeming goals.

I've completed 3 or 4 AP WUs now, all around the 250000 - 300000 second mark and the highest I've been granted was about 760 - half of what I claimed. Here's an example that hasn't been granted as of writing (the others have dropped off the end of the list):

http://setiathome.berkeley.edu/workunit.php?wuid=313876961

How did you claim 2 * granted, before introduction AP moved to flop counting for claimed credits, and when AP was introduced here claimed less than 700cr. Since than, due to Eric's credit adjustment the claims/granted have risen steadily to 775+.

It does make me want to abort any further AP WUs until there's a fix or possibly at least a good explanation!

I worked one that long and got half that much credit.---20 times longer to process than regular WU's only 5 times the credit.

No more AP units for me. Found the switch in preferences.

My AMD is working just fine for AP and MB. Since I upgraded, I only had one error in 8 mos.

---

Pluto will always be a planet to me.

Seti Ambassador
Not to late to order an Anni Shirt

It isn't that the AMD processors don't work for AstroPulse, but rather that the AstroPulse application apparently runs inefficiently on AMD processors. Thus, instead of taking 40 to 50 hours to complete an AstroPulse work unit (which apparently is the case on an Intel system of similar speed), the AMD based system will take 75 to 100 hours.

It is as if an Intel system runs a 'regular' application while the AMD runs a 'disoptimized' application.

No big deal for me, for now, I'm shifting elsewhere. I've configured my workstations for no new work. At some point, when the AP work units have flushed thru the farm, I'll reconfigure -- that is, I allow only the non AP work units for those AMD processors (via group definition), and run the optimized SETI application -- which apparently will resolve the problem I've encountered all too often with the 'regular' SETI work units and AMD multicores (of running hours with no progress). At that point, I'll be back in a 'happy SETI' place.

During the interim, other projects are picking up the slack for me.

My AMD is working just fine for AP and MB. Since I upgraded, I only had one error in 8 mos.

---

All the AP wu's I've crunched have only been on the AMD rigs on my farm.

The last AP wu crunched 4402202 totalled 177.89 hours with a granted credit of 673.70. This gives a c/ph of 3.79, low but it all helps.

---

OK -- sort of confirms the discussion here -- sounds like you have an older AMD for that last work unit (perhaps something like an XP1600).

The Astropulse work units yield about 1/2 the credit/hour on AMD's compared to the regular SETI work units. That is a fairly steep (and unintentional) tax on AMD processing power.

What I expect to do when I get the time, is get the optimized application in place and configure for the regular work units. My understanding is that combination will help me avoid the 'black hole' work units that the AMD multi-core processors running Win2K and WinXP seem to encounter with the current batch of regular work units (this used to happen rarely -- say two months ago, but I was running into it a LOT this past month).

All the AP wu's I've crunched have only been on the AMD rigs on my farm.

The last AP wu crunched 4402202 totalled 177.89 hours with a granted credit of 673.70. This gives a c/ph of 3.79, low but it all helps.

---

OK -- sort of confirms the discussion here -- sounds like you have an older AMD for that last work unit (perhaps something like an XP1600).

The Astropulse work units yield about 1/2 the credit/hour on AMD's compared to the regular SETI work units. That is a fairly steep (and unintentional) tax on AMD processing power.

What I expect to do when I get the time, is get the optimized application in place and configure for the regular work units. My understanding is that combination will help me avoid the 'black hole' work units that the AMD multi-core processors running Win2K and WinXP seem to encounter with the current batch of regular work units (this used to happen rarely -- say two months ago, but I was running into it a LOT this past month).

All the AP wu's I've crunched have only been on the AMD rigs on my farm.

The last AP wu crunched 4402202 totalled 177.89 hours with a granted credit of 673.70. This gives a c/ph of 3.79, low but it all helps.

Athlon 64 X2 4200

---

OK -- sort of confirms the discussion here -- sounds like you have an older AMD for that last work unit (perhaps something like an XP1600).

The Astropulse work units yield about 1/2 the credit/hour on AMD's compared to the regular SETI work units. That is a fairly steep (and unintentional) tax on AMD processing power.

What I expect to do when I get the time, is get the optimized application in place and configure for the regular work units. My understanding is that combination will help me avoid the 'black hole' work units that the AMD multi-core processors running Win2K and WinXP seem to encounter with the current batch of regular work units (this used to happen rarely -- say two months ago, but I was running into it a LOT this past month).

All the AP wu's I've crunched have only been on the AMD rigs on my farm.

The last AP wu crunched 4402202 totalled 177.89 hours with a granted credit of 673.70. This gives a c/ph of 3.79, low but it all helps.

Athlon 64 X2 4200

Hi, there appears to be a huge difference between the used CPU and probably the whole system compaired to crunching times, I use a QX9650 @ 3434MHz, X38 chipset, a AP WU takes about 24 hours, that gives about 30cr/hour. Credit claim was 750, got 720.
I wander, what causes this huge difference in crunching time, it's NOT FLOPs only or RAM, looks like these WU's are less memory dependent then MB Units, but I also doubt that?
Must be the code used?
Or the L2 cache (12MByte)?
Maybe my CPU has twice the FLOPs then the Athlon 64 X2 4200, per core. Or a bit more. ;) Beats me, so far.
Oh, I don't mind, crunching them, someone(s) got to do them, anyway ;)

---