Zombie67:

3) What the heck is rogue doing below *all* the P4s??? Something is not right here. I thought athlons were supposed to stomp all over P4s.

My single core Athlon 64 3000+ 2Ghz cpu is producing 310.6 credits per day (averaged over last week).
Rogue is producing an average of 336.6 credits per day. (averaged over last week.) It's using both cores - and producing 86400*2 seconds worth of work a day. But for some reason, you're only getting 50% of both cores. I don't know Linux - but it sure looks like you have something running on both cores with an equal priority to Rosetta. Or perhaps you're running two copies of Rosetta on a copy of Ubuntu that is only dealing with one core of the Athlon 64 (if that's even possible)?

---

I copy and paste the "results Page" for each individual computer into its' own worksheet.

copy paste....d'oh! I never even thought of it. Thanks!

---

Reno, NV
Team: SETI.USA

Zombie67:

3) What the heck is rogue doing below *all* the P4s??? Something is not right here. I thought athlons were supposed to stomp all over P4s.

My single core Athlon 64 3000+ 2Ghz cpu is producing 310.6 credits per day (averaged over last week).
Rogue is producing an average of 336.6 credits per day. (averaged over last week.) It's using both cores - and producing 86400*2 seconds worth of work a day. But for some reason, you're only getting 50% of both cores. I don't know Linux - but it sure looks like you have something running on both cores with an equal priority to Rosetta. Or perhaps you're running two copies of Rosetta on a copy of Ubuntu that is only dealing with one core of the Athlon 64 (if that's even possible)?

maybe "cool'n'quiet" or whatever it is for intel is throttling back his cpu?

Zombie67:

3) What the heck is rogue doing below *all* the P4s??? Something is not right here. I thought athlons were supposed to stomp all over P4s.

My single core Athlon 64 3000+ 2Ghz cpu is producing 310.6 credits per day (averaged over last week).
Rogue is producing an average of 336.6 credits per day. (averaged over last week.) It's using both cores - and producing 86400*2 seconds worth of work a day. But for some reason, you're only getting 50% of both cores. I don't know Linux - but it sure looks like you have something running on both cores with an equal priority to Rosetta. Or perhaps you're running two copies of Rosetta on a copy of Ubuntu that is only dealing with one core of the Athlon 64 (if that's even possible)?

According to the process meter, there is only the two rosetta application processes (one on each core). It's fairly new, and was close to climbing up the rac score to the pentium D machines...under the old credit system. Something is wrong with this new system.

---

Reno, NV
Team: SETI.USA

Well, there it is afterall. A drop of about 13% of credits so far.

What was expected. So what? Losing inflated credit does not mean losing anything worthful.

Norbert
PS: And if somebody now tells me, that the the FLOPs for Rosetta too dropped by 13%, he doesn't understand anything.

---

Well, there it is afterall. A drop of about 13% of credits so far.

What was expected. So what? Losing inflated credit does not mean losing anything worthful.

Norbert
PS: And if somebody now tells me, that the the FLOPs for Rosetta too dropped by 13%, he doesn't understand anything.

There's two things going on, as stated earlier in the thread. The opt credits are dropping, but that is a small % of the total user base. The majority of the user base appears to bet getting a small increase, they are finally getting "paid" for MMX work that was done, but not included in the std benchmark's claim. They've been getting "cheated" for that credit all this time. Give 90+% of the users a boost, and you can easily hide the overall credit drop from the opt clients. The only usefull info would be in actual work done, or FLOPS returned. Unless the FLOPS were measured from the benchmarks.. then they mean as much as the credits.

As for the FLOPS, I would seriously bet that they have dropped, but not directly from the new system as you are implying. They should be dropping from the hundreds of machines that are shut off or removed from the project.

---

1) wonder woman has been consistantly (slightly) faster than batman crunching SETI. Yet it is earning almost HALF the credit of slower batman.

This looks odd but I don't know nothing about OSX. Perhaps the difference in the OS version is responsible?

2) superman is ranked too low compared to the Pentium machines. The G5 should be faster than the Pentium on a per-thread basis, right?

Unfortunately this looks about right. The G5 does not so well with the Rosetta app.

3) What the heck is rogue doing below *all* the P4s??? Something is not right here. I thought athlons were supposed to stomp all over P4s.

This is really strange and points to a problem with your machine. You should get twice the number. As others have pointed it it looks if two instances would run on the same core thus each getting only half the CPU power. Then your numbers make sense. Please check, whether it might be both instances uses the same core, or try to install two instances of BOINC, each bound ot one core. But this does not indicate any problem with the new credit system, since similar X2 4200+ get exactly twice the credits (under Linux and Windows).

4) The Core chips are sweet! I can't wait to get my Core 2 Duo on line!

Yeah and Core 2 Duo will be even better. :-)

Edit: 5) There is no way a Pentium D 940 is as fast as a Core Duo 2.16. Something is not right here.

Actually it seems about right. The Pentium D 940 is clocked at 3.2 GHZ whereas the Core is clocked at 2.16 GHz. Both get the same numbers which indicate that the Core is about getting 150% per GHz. This looks about right. A core 2 duo clocked at 2.16 GHz will be even faster.

Bottom line: The only odd result, which I can verify is your poor Athlon performance. There must be a problem with your machine though, since your numbers are just the half others get with similar configuration. As to the old G4 I can't comment.

Well, there it is afterall. A drop of about 13% of credits so far.

What was expected. So what? Losing inflated credit does not mean losing anything worthful.

Norbert
PS: And if somebody now tells me, that the the FLOPs for Rosetta too dropped by 13%, he doesn't understand anything.

There's two things going on, as stated earlier in the thread. The opt credits are dropping, but that is a small % of the total user base. The majority of the user base appears to bet getting a small increase, they are finally getting "paid" for MMX work that was done, but not included in the std benchmark's claim. They've been getting "cheated" for that credit all this time. Give 90+% of the users a boost, and you can easily hide the overall credit drop from the opt clients. The only usefull info would be in actual work done, or FLOPS returned. Unless the FLOPS were measured from the benchmarks.. then they mean as much as the credits.

As for the FLOPS, I would seriously bet that they have dropped, but not directly from the new system as you are implying. They should be dropping from the hundreds of machines that are shut off or removed from the project.

It seems the loss of hosts is compensated by an inflow of new hosts. Since the new credit system was introduced, about 500 new hosts per day were added, which is considerably higher than before. Whether this is related I don't know.

Some of the new signups will be from Predictor@home which stopped producing work about 2 weeks ago.

---

The only usefull info would be in actual work done, or FLOPS returned. Unless the FLOPS were measured from the benchmarks.. then they mean as much as the credits.

They are. So only the project can tell, if there really is a decrease in "science" returned. Everything else is wild speculation.

---

Actually, Crunch3r's 5.5.0 client did return benchmarks that were higher than the physical abilities of a processor even if perfect efficiency was achieved.

This is my 2.3 GHz Athlon XP. It's a Barton core running at 11.5 * 200 MHz. Now look at my integer benchmarks, as given by Crunch3r's 5.5.0 client - "Measured integer speed 11476.56 million ops/sec". Thing is, an Athlon XP can only issue 3 integer instructions per clock cycle, meaning that my processor is only capable of 3 * 2,300,000,000 integer instructions per second. That means that with absolute perfect efficiency, which you don't get ever, my processor can issue 6,900 million ops/sec. Where did the extra 4,576,56 million ops/sec come from?!

This is my 2.14 GHz Duron. It runs Trux's 5.2.13 or something like that. Note it's integer benchmark - "Measured integer speed 6364.27 million ops/sec". But that is physically possible because 3 * 2,140,000,000 = 6,420 million ops/sec.

I am sick and tired of people saying that Crunch3r's 5.5.0 client rewards them based on what they can contribute. No, you can't contribute something that is physically beyond the capabilities of your processor.

Its been stated by some SETI people that the client actually DID produce 3x the work, and the opt bench was made to match it. If a proc can produce the work then it can produce the benchmark, and vice versa.

Now I am no guru by any stretch on modern processor architecture, but I do know they are incredibly complex, and measuring a cpu's power with remedial math just isn't possible. There are too many things happening in parallel or in different areas of the processor. So, you ask where those extra cycles can possibly come from? As I understand it, the instuction sets can act as "mini" calculators. They are simple calcs, not a full FPU or whatever, they only look for simple pieces that can be reduced or simplified, to take the load off the main math processor. Why waste a full cpu cycle to grind out 2+2, or other simple addition or subtraction bits. They take the simple load off, and let the main center do the big complex math. Each time you can reduce a number or simplify an equation, it frees up the main math proc to do more "real" calculations, so more work gets done. Each of these steps still gets counted as though it were an operation. So if your bench is reading more cycles than your proc has GHZ, that'd be my guess as to why. Again, I'm not an expert in this by any means, so take it as you will. If I'm off in left field, I wouldn't mind hearing a better description myself.

---

In order to allow modem users to continue participating in this discussion it is continued in this thread. With almost 170 posts it got very long.

Please make all new posts here.

---

I am a forum moderator! Am I?