[Karl Schimanek]

The reference unit is done:

init_data.xml file:
<wu_cpu_time>11402.188373</wu_cpu_time>

System: Power Mac G4 Quicksilver
CPU: Motorola MPC7450
CPU speed: 733MHz
Level 1 cache: 64kb
Level 2 cache: 256kb
Level 3 cache: none

Karl

EDIT: For comparison:
Pentium 4 1.6GHz (Willamette) 11.321 seconds
Xeon (Dual) 2GHz (Prestonia) 11.625 seconds
Athlon XP 2000+ (Thoroughbred) 1,66GHz 14.465 seconds

The MHz-Myth lives on

[alexkan]

Thanks! In the future (or if you decide to run the test again), can you all give both the times given in init_data.xml and from the UNIX time command? I figure it might be a good chance to compare SETI's measured times with OS X's time, to see if we're actually overestimating in the general case (as opposed to the short-work-unit case), and also whether or not you're running the stock CPU that your computer came with? In our experience so far, it seems that a CPU that was installed as part of an upgrade tends to be slower than an equivalent-clocked CPU that was originally part of a machine.

[BTBlomberg]

Karl,

Just courious, but were the PC comparisons with optimized clients (SSE,MMX,etc.)? Just asking as I thought that would be a more fair comparison. I know I am running Optimized clients on my Athlon XP 1700+ (1450 Mhz) homebuild system (I use for DVB satelite) and for my old IBM P3 550.

The Athlon had been besting the Dual G4 866 by 10 to 25 Credits on average and the P3 550 was at twice the Credits of the Powerbook G4 500.

The Athlon XP 1700+ has been averageing 11956.02 sec. with optimized Client.
The P3 550 has been averaging 24331.88 sec. with optimized Client.

With the Client for the P3 550 I have had quite a few of the Normal Short results and it says this for the stderr out:
(Maniacally optimized with Intel C++ compiler 9.0/IPP library 4.1
by Tetsuji Maverick Rai, rev.08.1, Wed Jun 15 17:51:14 2005)
SETI@Home Informational message -9 result_overflow
NOTE: The number of results detected exceeds the storage space allocated.

The Athlon had 58 results with no short ones at all. And says this:
(Maniacally optimized with Intel C++ compiler 9.0/IPP library 4.1
by Tetsuji Maverick Rai, rev.08.1, Wed Jun 15 17:51:14 2005)

Now the PM Dual G4 866 is averaging 8621.03 sec. with Alpha-5. 256 KB L2, 1 MB L3 Cache (per processor)
The Powerbook G4 500 is averaging 9948.34 sec. with Alpha-5. 1 MB L2 Cache

So I think this shows that the AltiVec set is better than MMX or SSE, but we all knew that, but it's nice to finally benifit.

[BTBlomberg]

By the way, the Javalizard client had been having the two G4 machines in the 40000 sec. range per WU.

Also, the PC stderr out may give Rick and Alex something to go from for their client stderr out.

[Snake_doctor]

Originally Posted by rick

1. Download the reference work unit.
2. Make sure that it is called "work_unit.sah".
3. Put the "seti@home-G4-a5" in this folder.
4. Open Terminal.
5. Change your current working directory to the above folder. If you don't know how to do this then have a look at my previous post about running the setiURL script. If you're still stuck I can give you more advice.
6. Run the command "time ./seti@home-G4-a5 -standalone".

Rick,

I am sure you have posted this somewhere but I can't find it. Where can I get the Reference WU? I am about to upgrade one of my systems to OS 10.4, and would like to test the system before and after the upgrade.

Regards
Phil

[alexkan]

Originally Posted by BTBlomberg

Karl,

Just courious, but were the PC comparisons with optimized clients (SSE,MMX,etc.)? Just asking as I thought that would be a more fair comparison. I know I am running Optimized clients on my Athlon XP 1700+ (1450 Mhz) homebuild system (I use for DVB satelite) and for my old IBM P3 550.

Yes, these times were taken using Tetsuji Maverick Rai's IPP-optimized clients. Both the PC comparison times and the reference work unit for testing purposes can be found at http://www.marisan.nl/seti/reference.htm. There is an even faster PC client available at http://naparst.name/, which is not tested in the first link. There are currently discussion on the main SETI boards about its accuracy, as seems to be the case with optimized clients in general. According to the website, work units validate about 95% of the time. I personally haven't tried it, but I probably ought to at some point to see how it compares. For now, it's kind of depressing to think that my primary box, a P4 2.4, is about fast as a 1 GHz PowerBook on SETI. It's testament to the skill of the Apple engineers who put vecLib (the framework that contains the vDSP library), I suppose.

In addition, I think the reference work unit and the typical SETI work unit are slightly different lengths, so the average work unit times from your computers' statistics may not actually correspond to reference work unit processing times.

[rick]

Originally Posted by Snake_doctor

I am sure you have posted this somewhere but I can't find it. Where can I get the Reference WU? I am about to upgrade one of my systems to OS 10.4, and would like to test the system before and after the upgrade.

It's normally distributed with the SETI@home source code. I've also included a copy in the alpha client source code. Look for the "work_unit.sah" file in the "seti_apple" directory.

Originally Posted by rick

Run the command "time ./seti@home-G4-a5 -standalone".

Ha, when I was looking through the code I noticed that the code for the "-standalone" flag doesn't actually do anything so you can just use "time ./seti@home-G4-a5". Makes absolutely no difference. It might horrify you but I've found quite a bit of "code that does nothing" in the original client. I think I shaved off 10 minutes this way.



I've also figured out part of the short work unit thing. Turns out that probably most (maybe all, still needs extra research) short work units are noisy work units.

If you get a short work unit (200-400 seconds or whatever) and the results page says that it has exit status 0 and it validates then it is probably a noisy work unit. The problem is that there's a small bug in the BOINC code that causes the client to terminate before it can write the "-9 result_overflow" message. This bug is Apple specific and so won't apply to other operating systems. For example, with this result only the Mac client doesn't have the "-9 result_overflow" error.

This is a problem with the original BOINC source code. I'll suggest a fix on the boinc_dev mailing list but I don't know when this will get fixed in the mainline code and how quickly it will propagate to the people who do the optimised BOINC clients. A quick fix is literally one line of code so I guess if the right people get harassed it might get sorted out quickly.

This has absolutely no impact on credits, result accuracy or performance. The only thing that it affects is the printing of the "-9 result_overflow" error.

[rick]

Originally Posted by alexkan

It's testament to the skill of the Apple engineers who put vecLib (the framework that contains the vDSP library), I suppose.

And our bitchin' chirp routine.

[Snake_doctor]

Originally Posted by rick

Ha, when I was looking through the code I noticed that the code for the "-standalone" flag doesn't actually do anything so you can just use "time ./seti@home-G4-a5". Makes absolutely no difference. It might horrify you but I've found quite a bit of "code that does nothing" in the original client. I think I shaved off 10 minutes this way.

You guys are really scary. Next you you'll find a way to process the WUs without wasting the time to download them.

I've also figured out part of the short work unit thing. Turns out that probably most (maybe all, still needs extra research) short work units are noisy work units.

The problem is that there's a small bug in the BOINC code that causes the client to terminate before it can write the "-9 result_overflow" message. This bug is Apple specific and so won't apply to other operating systems.

But this one Here is not explained by your description. All of the intel systems processed the WU successfully and did not get a -9. I would agree that this one Here matches your description, and is probably the result of just such a problem.

So the REALLY short ones that validate and other system take long CPU times and also validate are still a mystery. I just hope I can catch one of these for you guys.

Keep up the good work, and I hope you are feeling better (although you do really great work when you are home sick)

Regards
Phil

[Karl Schimanek]

Unix time command:

real 181m49.124s
user 175m49.694s
sys 3m29.080s

init_data.xml:

<wu_cpu_time>11651.226740</wu_cpu_time>

System: Power Mac G4 Quicksilver
CPU: Motorola MPC7450 (stock CPU)
CPU speed: 733MHz
Level 1 cache: 64kb
Level 2 cache: 256kb
Level 3 cache: none

And yes, the "Harold Naparst" client is terrible fast!.
Under Linux Gentoo, a A64 +4000 took 2.500 seconds to complete a WU. Nearly twice as fast as a G5 2.5GHz

Karl

[rick]

Originally Posted by Snake_doctor

But this one Here is not explained by your description. All of the intel systems processed the WU successfully and did not get a -9.

Yeah, this is really starting to confuse me. What's strange is that yours got selected as the canonical result.

Originally Posted by Snake_doctor

Keep up the good work, and I hope you are feeling better (although you do really great work when you are home sick)

Well unfortunately I'm feeling much better today. I feel so chipper... screw this SETI stuff...

Originally Posted by Karl Schimanek

And yes, the "Harold Naparst" client is terrible fast!.
Under Linux Gentoo, a A64 +4000 took 2.500 seconds to complete a WU. Nearly twice as fast as a G5 2.5GHz

Such is the beauty of having access to their source code: their optimisations become our optimisations (evil grin). They've obviously got some Intel specific improvements in their client but Harold Naparst also figured out a faster way to calculate the code that calculates the Gamma function (weird complicated math function). We'll probably integrate this if it meets the accuracy requirements.

The main thing with optimising for the G5 is that it's an exceedingly greedy bastard and that if you don't keep feeding it data it will sulk. Alpha 6 should improve this, no idea by how much though.

Also, their fastest client "has accuracy limited to three digits for the trig and log functions. This client seems to receive credit for about 95% of the workunits submitted". Doesn't really count in my opinion...

Once we get our Gaussian code sorted we should validate 100% of the time.

[alexkan]

Originally Posted by rick

Such is the beauty of having access to their source code: their optimisations become our optimisations (evil grin). They've obviously got some Intel specific improvements in their client but Harold Naparst also figured out a faster way to calculate the code that calculates the Gamma function (weird complicated math function). We'll probably integrate this if it meets the accuracy requirements.

{snip}

Also, their fastest client "has accuracy limited to three digits for the trig and log functions. This client seems to receive credit for about 95% of the workunits submitted". Doesn't really count in my opinion...

Once we get our Gaussian code sorted we should validate 100% of the time.

Don't forget that our source is available too, so our improvements could become everyone's improvements as well.

There's been some interesting discussion on the SETI boards with regard to accuracy (and Harold Naparst's client) that we should probably be thinking about for ourselves. For example, it's probably worth looking at whether or results are actually identified as "strongly similar" or "weakly similar" to see how close our calculations really are. Also, Harold's newest release comes in two versions, one of which solves the accuracy problems for a moderate speed hit.

Given my bias with regard to the Gaussian code (having been the one that modified it, after all), I'm still skeptical as to the extent to which it's broken. The SETI discussion about the extent to which the chirp affects accuracy has me wondering as well. Have the results of the Gaussian calculations really changed that much through the different alphas? I imagine it's much too late for us to see how much the earliest changes (like the FFT replacement) affected things, but if you can figure out how to get the Ooura code in there, that might help with regression testing.

[Snake_doctor]

The run of the standard work just finished. Prior to starting the run I restarted the system. I allowed it to start normally and left all of the normal startup stuff running except the network connection was off. The startup for this machine does not include any apps or CPU intensive stuff. I did not touch the machine until the run completed to avoid stealing CPU cycles from the test run. The BOINC system was not running as you might expect (though this overhead might produce a more accurate reflection of actual system performance in the real world)

I will be upgrading the system to OS 10.4.x over the next few hours, and will run the test again after that using the OS 10.4 version of the alpha app.

The system is -

Machine Model: PowerBook G4 17"
CPU Type: PowerPC G4 (3.3)
Number Of CPUs: 1
CPU Speed: 1 GHz
L2 Cache (per CPU): 256 KB
L3 Cache (per CPU): 1 MB
Memory: 1 GB
Bus Speed: 167 MHz
Boot ROM Version: 4.6.2f1

Running -

System Version: Mac OS X 10.3.9 (7W98)
Kernel Version: Darwin 7.9.0

SETI Alpha Application - setiathome-4.18-applevdsp-panther-G4-alpha-4

The stats are as follows -

This is the terminal time command output string -

6628.530u 68.740s 1:53:27.34 98.3% 0+0k 8+80io 0pf+0w

This is from the init_data.xml file

wu_cpu_time>7494.070000
user_total_credit>1000.000000
user_expavg_credit>500.000000
host_total_credit>1000.000000
host_expavg_credit>500.000000
checkpoint_period>300.000000


I will report later on the OS 10.4 outputs

Regards
Phil

EDIT: Just for fun Here Is a result from my other machine that reflects a short time compared to the other systems, but it is not one of the short timers we have been discussing (though I did download the WU just in case you wanted it). It is simply to give you guys an idea of just HOW MUCH FASTER YOU HAVE MADE THIS STUFF RUN!! While the other systems in the quorum are certainly not speed demons it is a fair comparison because they are all Windoze.

[Karl Schimanek]

HOHOHO, that's a very detailed info

One more question:

Does the SETI core take advantage of the two FPUs and the other features in the G5?

Karl

P.S. add. info of mine: FSB: 133MHz

[Karl Schimanek]

Here are the reference unit result from Amigoivo:

CPU-Time: 4215.034836

init_data.xml only, sorry
PowerMac G5 Dual 2.5GHz, you know the specs (too lazy )

Karl

[Karl Schimanek]

Here we go again, second run from Amigoivo:

4236,596922 (init_data.xml)

Results from the Terminal:

Last login: Sun Oct 2 21:21:29 on ttyp1
Welcome to Darwin!
IVOsPowerMacG5:~ imaynick$ cd /Users/imaynick/Desktop/referenceunits/
IVOsPowerMacG5:~/Desktop/referenceunits imaynick$ time ./seti@home-G5-a5

real 55m42.399s
user 53m56.417s
sys 0m42.302s
IVOsPowerMacG5:~/Desktop/referenceunits imaynick$

Regards
Karl

Edit: We don't get a line like this:

6628.530u 68.740s 1:53:27.34 98.3% 0+0k 8+80io 0pf+0w

[alexkan]

Thanks to amigoivo for submitting times! (Was the CPU speed setting in Energy Saver set to Automatic or Highest? This is something we might also consider collecting as part of the system information, in case it actually makes a lot of difference.)

Originally Posted by Karl Schimanek

HOHOHO, that's a very detailed info

One more question:

Does the SETI core take advantage of the two FPUs and the other features in the G5?

Karl

P.S. add. info of mine: FSB: 133MHz

Well, Apple's vDSP code ought to, although for the most part, we're using the Altivec unit, not the FPUs, since that still gets us more throughput.

Incidentally, you can see how much of a difference there is between init_data.xml and time by observing that 53:46 is actually 3226 seconds, which means that the client overestimated its CPU time by 31%! Kind of puts the short-work-unit problem in perspective.

What's actually hurting us on the G5 might be considered one of its features. While the G5 can have way more instructions in-flight at a time than the G4, this comes at a cost--it takes a bit longer for each individual instruction to complete once it's been issued. This hurts us on the chirp function, which mostly maxes out the Altivec unit on the G4, but which might only be using 50% of the G5's possible throughput, depending on how much of a difference memory bandwidth makes. This is something that will be in place by the time alpha-6 rolls around.

[amigoivo]

Originally Posted by alexkan

Thanks to amigoivo for submitting times! (Was the CPU speed setting in Energy Saver set to Automatic or Highest? This is something we might also consider collecting as part of the system information, in case it actually makes a lot of difference.)

Well, Apple's vDSP code ought to, although for the most part, we're using the Altivec unit, not the FPUs, since that still gets us more throughput.

Incidentally, you can see how much of a difference there is between init_data.xml and time by observing that 53:46 is actually 3226 seconds, which means that the client overestimated its CPU time by 31%! Kind of puts the short-work-unit problem in perspective.

What's actually hurting us on the G5 might be considered one of its features. While the G5 can have way more instructions in-flight at a time than the G4, this comes at a cost--it takes a bit longer for each individual instruction to complete once it's been issued. This hurts us on the chirp function, which mostly maxes out the Altivec unit on the G4, but which might only be using 50% of the G5's possible throughput, depending on how much of a difference memory bandwidth makes. This is something that will be in place by the time alpha-6 rolls around.

Hello alexkan,

i put the energie saver settings at "maximum".
I also realized that the energie settings have hardly no influence. :o
I have crunched a lot of WUs at any setting and there is no difference between low and maximum.
Just only a few seconds.
(with the alpha5 client)

CU Ivo
p.s.: Sorry that karl have to write for me, but I am rather rare in your forum.

[amigoivo]

Hello,
i crunched the WU mit minimal energie Settings.
Here the Terminal output:

Last login: Mon Oct 3 01:19:13 on ttyp1
Welcome to Darwin!
IVOsPowerMacG5:~ imaynick$ cd /Users/imaynick/Desktop/referenceunits/
IVOsPowerMacG5:~/Desktop/referenceunits imaynick$ time ./seti@home-G5-a5
real 59m35.809s
user 58m45.955s
sys 0m37.134s
IVOsPowerMacG5:~/Desktop/referenceunits imaynick$

Good N8,
CU Ivo

[Snake_doctor]

All four runs of the standard work are complete. For all runs I restarted the system. I allowed it to start normally (with inits) and left all of the normal startup stuff running. The startup for this machine does not include any apps or CPU intensive stuff. I did not touch the machine until the run completed to avoid stealing CPU cycles from the test run. The BOINC system was not running as you might expect (though this overhead might produce a more accurate reflection of actual system performance)

Running under OS 10.4 - All hardware conditions are the same as below and startups were performed the same for each run. For runs 2 and 3, I did not perform any software updates, I just installed OS 10.4 as it comes on the DVD from apple. Booted the system and ran the test. All conditions were as above including turning off the network.

The first set of results are form OS 10.3.9, and are the stats posted earlier for the A4 app (posted again for your convenience) The second set of stats if from the OS 10.4 run using the A5 app. Set three is from OS 10.4 with the A4 application. Set four is after using the apple software updater to bring the system up to the current rev of OS 10.4 and run using A5 again. If you think it would be useful I can run the test one more time using the A4 app with the updated OS 10.4. Let me know.

The Hardware system is -

Machine Model: PowerBook G4 17"
CPU Type: PowerPC G4 (3.3)
Number Of CPUs: 1
CPU Speed: 1 GHz
L2 Cache (per CPU): 256 KB
L3 Cache (per CPU): 1 MB
Memory: 1 GB
Bus Speed: 167 MHz
Boot ROM Version: 4.6.2f1

Run 1
System Version:
Mac OS X 10.3.9 (7W98)
Kernel Version:
Darwin 7.9.0

SETI Alpha Application -
setiathome-4.18-applevdsp-panther-G4-alpha-4

This is from the terminal time command -
6628.530u 68.740s 1:53:27.34 98.3% 0+0k 8+80io 0pf+0w

This is from the init_data.xml file -
wu_cpu_time>7494.070000

Run 2
System Version:
Mac OS X 10.4 (8A428)
Kernel Version:
Darwin 8.0.0

SETI Alpha Application -
seti@home-G4-a5

This is from the terminal time command -
6049.399u 87.454s 1:45:31.94 96.9% 0+0k 13+74io 0pf+0w

This is from the init_data.xml file -
7105.695675

Run 3
System Version:
Mac OS X 10.4 (8A428)
Kernel Version:
Darwin 8.0.0

SETI Alpha Application -
setiathome-4.18-applevdsp-panther-G4-alpha-4

This is from the terminal time command -
6510.634u 92.512s 1:52:28.45 97.8% 0+0k 8+77io 0pf+0w

This is from the init_data.xml file -
wu_cpu_time>7457.025827

Run 4
System Version
Mac OS X 10.4.2 (?)
Kernel Version:
Darwin 8.?.?

SETI Alpha Application -
seti@home-G4-a5

This is from the terminal time command -

This is from the init_data.xml file -


Regards
Phil

[Karl Schimanek]

Originally Posted by alexkan

Incidentally, you can see how much of a difference there is between init_data.xml and time by observing that 53:46 is actually 3226 seconds, which means that the client overestimated its CPU time by 31%! Kind of puts the short-work-unit problem in perspective.

In the past, i observed the same thing on the BOINC Manager. BOINC Manager (WU) reached 100%, but the time was continuing. I thought the BOINC Manager showed the false percentage, only

Regards
Karl

[Snake_doctor]

All four runs of the standard work are complete. For all runs I restarted the system. I allowed it to start normally (with inits) and left all of the normal startup stuff running. The startup for this machine does not include any apps or CPU intensive stuff. I did not touch the machine until the run completed to avoid stealing CPU cycles from the test run. The BOINC system was not running as you might expect (though this overhead might produce a more accurate reflection of actual system performance)

Running under OS 10.4 - All hardware conditions are the same as below and startups were performed the same for each run. For runs 2 and 3, I did not perform any software updates, I just installed OS 10.4 as it comes on the DVD from apple. Booted the system and ran the test. All conditions were as above including turning off the network.

The first set of results are form OS 10.3.9, and are the stats posted earlier for the A4 app (posted again for your convenience) The second set of stats if from the OS 10.4 run using the A5 app. Set three is from OS 10.4 with the A4 application. Set four is after using the apple software updater to bring the system up to the current rev of OS 10.4 and run using A5 again. If you think it would be useful I can run the test one more time using the A4 app with the updated OS 10.4. Let me know.

The Hardware system is -

Machine Model: PowerBook G4 17"
CPU Type: PowerPC G4 (3.3)
Number Of CPUs: 1
CPU Speed: 1 GHz
L2 Cache (per CPU): 256 KB
L3 Cache (per CPU): 1 MB
Memory: 1 GB
Bus Speed: 167 MHz
Boot ROM Version: 4.6.2f1

Run 1
System Version:
Mac OS X 10.3.9 (7W98)
Kernel Version:
Darwin 7.9.0

SETI Alpha Application -
setiathome-4.18-applevdsp-panther-G4-alpha-4

This is from the terminal time command -
6628.530u 68.740s 1:53:27.34 98.3% 0+0k 8+80io 0pf+0w

This is from the init_data.xml file -
wu_cpu_time>7494.070000

Run 2
System Version:
Mac OS X 10.4 (8A428)
Kernel Version:
Darwin 8.0.0

SETI Alpha Application -
seti@home-G4-a5

This is from the terminal time command -
6049.399u 87.454s 1:45:31.94 96.9% 0+0k 13+74io 0pf+0w

This is from the init_data.xml file -
7105.695675

Run 3
System Version:
Mac OS X 10.4 (8A428)
Kernel Version:
Darwin 8.0.0

SETI Alpha Application -
setiathome-4.18-applevdsp-panther-G4-alpha-4

This is from the terminal time command -
6510.634u 92.512s 1:52:28.45 97.8% 0+0k 8+77io 0pf+0w

This is from the init_data.xml file -
wu_cpu_time>7457.025827

Run 4
System Version
Mac OS X 10.4.2 (?)
Kernel Version:
Darwin 8.?.?

SETI Alpha Application -
seti@home-G4-a5

This is from the terminal time command -

This is from the init_data.xml file -


Regards
Phil

[Knightrider]

As a footnote (perhaps) to the message

--- SETI@Home Informational message -9 result_overflow
NOTE: The number of results detected exceeds the storage space allocated. ---

HERE is a link to a short wu which has it on 3/4 of results. Just to show that other systems have this error message as well.

K.

[rick]

Originally Posted by Knightrider

As a footnote (perhaps) to the message

--- SETI@Home Informational message -9 result_overflow
NOTE: The number of results detected exceeds the storage space allocated. ---

Yeah, we've got these results sorted out now. They're perfectly normal and are not a problem with the client. However, in certain cases, all BOINC clients for Mac will not display this message. They will process the data in exactly the same way as other clients but due to a small bug in the BOINC code will not display the above message in stderr.txt.

[beadman]

alex and rick:

Using the SETIGrabber, I was able to copy 3 WU had had short times for me and "normal" times for others.

Powerbook G4, OS 10.3.9, 4.44 Superbench, Alpha-4 G4 - normal time for me is about 6,500 sec
...121 2552 sec, others had 12K and 13K sec.
...78 2762 sec, other had 13K sec.

iBook G4, OS 10.3.9, 4.44 Superbench, Alpha-4 G4 - normal time for me is about 8,000 sec
...104 997 sec, others had 9K and 7K sec.

If you'd like these WU to look at, send me an email at beadman at mac dot com.

beadman

[Snake_doctor]

Originally Posted by rick

Yeah, we've got these results sorted out now. They're perfectly normal and are not a problem with the client. However, in certain cases, all BOINC clients for Mac will not display this message. They will process the data in exactly the same way as other clients but due to a small bug in the BOINC code will not display the above message in stderr.txt.

Rick,

I just got another short WU (not a -9). This time my time and credit claim are both "0". The first system from the quorum has reported and was 13554 CPU time. This is the first one I have seen from the Powerbook. Also the first one I have seen using 10.4.2 and A5. I have captured the WU and will PM it to you. The link to the WU is here


EDIT: here Is yet another one from the G4 Dual system (10.3.9, A4). This one is the more classic claime of less than 90 CPU seconds and the other systems claiming 10000 plus. I managed to grab the WU for this one as well.

Regards
Phil

Hello!

I finished 2 WUs which took about 300s, but other systems also finished in a very short time.
One already got validated, but the other still is "pending"
There was no -9 error in stderr.txt.
Just to be save I made a copy of the two WUs. Should I send them to you?

I could also post the links to the results if you like.

regards,
manu

[rick]

Originally Posted by manu

Just to be save I made a copy of the two WUs. Should I send them to you?

These sound like the "-9 result_overflow" errors that I mentioned above. This is a problem with the BOINC software exiting before the error message gets written to the file. I posted this to the boinc_dev mailing list. It looks as though this will get fixed in a new release of BOINC.

I've pretty much got copies of all the work units that exhibit weird behaviour and I'm still chugging away on them so there's not much point in sending me new ones at the moment unless it's an error that we haven't encountered before.

[BTBlomberg]

Yep, the "-9 result_overflow" are all over, but you won't see it in your results unless one of the other clients in the quarum (3 other working on the same WU) spits this out with it's results. So it's a matter of who else got that WU and what they are running on if you even will see "-9 result_overflow" with WU. Also, if just you or you and one other client are the only results back on a WU so far your odds are even less for seeing the message as we know, and Rick just said, this client and ones for some otehr platforms do not spit out the "-9 result_overflow" message.

Likely you guys are chasing possible bugs and library hole for Fat version, but I was courious as to how Alpha-6 was progressing. As things go I don't expect a big speed bump, unless you guys have managed to refine things even better, but I am sure your additional refinements will improve the client in other ways too.

[Snake_doctor]

Rick, Alex,

I have just stumbled on something that may be related to the short WU issue, or it could be yet a new thing. I watched a WU tonight in the GUI manager. While the Manager and the activity monitor both showed a SETI WU as active, the stats were not incrementing for the SETI WU but they were on a PP@H WU that was also in the cue, but shown as paused. I attempted to intervene but the system would not correct itself. I did not try shutting off BOINC as I had a Rosetta WU in the Cue and did not want to lose the CPU counts on it (they have a bug that causes the loss of CPU stats if you shutdown BOINC in the middle of processing).

When the SETI WU finally reported, it showed 0 CPU time and 0 claimed credit. After the SETI WU was gone the PP@H WU corrected itself and began showing proper stats in the BOINC Manager. The PP@H WU completed and reported normally.

I think we have all known for some time that PP@H and SETI do not always work and play well together when it comes to switching, but this is the first time I saw them get their files crossed. Is it possible that the short WUs (not the -9 type) could be the result of some sort of file cross up between these two apps during an app swap out?

Just a thought

Regards
Phil

[Knightrider]

Snake_doctor wrote

I watched a WU tonight in the GUI manager. While the Manager and the activity monitor both showed a SETI WU as active, the stats were not incrementing for the SETI WU but they were on a PP@H WU that was also in the cue, but shown as paused.

Which version of the GUI Manager were you using?


K.

[Snake_doctor]

Originally Posted by Knightrider

Which version of the GUI Manager were you using?
K.

MacNN 4.44 Superbench

[beadman]

Originally Posted by Snake_doctor

...Is it possible that the short WUs (not the -9 type) could be the result of some sort of file cross up between these two apps during an app swap out?
...
Phil

I doubt it's specifically those two, Phil. <a href="http://setiathome.berkeley.edu/workunit.php?wuid=29997588"> This one </a> is on my Powebook G4 (4.44 superbench and Alpha 4 on 10.3.9) I run SETI, E@H, and CPDN on that machine. I wasn't able to grab this one, as I have the SETIGrabber on my work machine and it's at the office.

C

[Snake_doctor]

Originally Posted by beadman

I doubt it's specifically those two, Phil ... I run SETI, E@H, and CPDN on that machine. I wasn't able to grab this one, as I have the SETIGrabber on my work machine and it's at the office.

C

Beadman,

I don't know how it could be any other two. These were the two WUs that were there, (along with a Rosetta) and exhibited the problem. Remember this is Beta testing, we should be reporting any unusual behavior that involves SETI or the WUs we process. I certainly think that watching one WU show active while another increments qualifies. Rick and Alex are smart guys, if it is nothing they will know it pretty quick.

Also just today I noticed a SETI WU here upload with "0" CPU time, and "0" credit claimed. This is not the first of these I have had (see here). I still was awarded credit and in both cases the WU seems to have processed ok, and in fact in both cases my result was selected as the canonical result for the WU. That is even stranger!

In both cases PP@H was running alongside the SETI WU. So when I actually witness what looks like the two WUs crossing up the output files I have to wonder. So far I have not seen anything odd in my predictor results, but I have never had a SETI Wu show active while the PP@H number are incrementing. All that has to happen to cause this is for the PP@H Wu to start just as a SETI WU is about to upload, This would zero the results and that is what would get sent. In the first of the two links above, when the WU reported, BOINC crashed, I actually saw it happen, and the WU was showing "0" CPU time when it went to report.

Now I admit that that would be a PP@H problem and not a SETI issue. But if that is what is happening, Rick or Alex have a far better chance of reaching out to the PP@H guys than I do. In any case it is still odd behavior.

Regards
Phil

PS - Where do you hail from in Virginia?

[alexkan]

Originally Posted by BTBlomberg

Likely you guys are chasing possible bugs and library hole for Fat version, but I was courious as to how Alpha-6 was progressing. As things go I don't expect a big speed bump, unless you guys have managed to refine things even better, but I am sure your additional refinements will improve the client in other ways too.

I've been quiet for a long time, but I wanted to pop in and let you guys know how things are doing, at least for me. In short, midterms and projects at Berkeley are starting to pick up, so I don't have as much time to work on the client as I used to. The tweaks I was looking at for alpha-6 are of dubious usefulness (I'll have to figure out which are good and which actually make the client slower).

True, the PC side of things has been making a lot of progress lately, and it would be nice if we could repeatedly claim 15-20% speedups with each new version, but we have a different set of challenges (slow memory, etc.) to deal with.

Also, I know you guys are probably more concerned about the reported work unit times than about making the client go any faster. Rick's definitely the one to talk to on this one--he's looked at the non-math code much more than I have, which is why I don't have as much to say when you guys report in on your WUs.

More later, I hope (hopefully much more, since I'll be buying myself a PB tomorrow if Apple speedbumps them).

[Karl Schimanek]

Originally Posted by alexkan

More later, I hope (hopefully much more, since I'll be buying myself a PB tomorrow if Apple speedbumps them).

7448, 1MB L2C, OoO AltiVec *drool*
8641D would be nice, too
The Dual Dual-Core G5 is mine

Karl

[beadman]

Originally Posted by Snake_doctor

Beadman,

I don't know how it could be any other two. These were the two WUs that were there, (along with a Rosetta) and exhibited the problem. Remember this is Beta testing, we should be reporting any unusual behavior that involves SETI or the WUs we process. I certainly think that

Sorry - I think I was interpreting you as saying it was only SETI and PP@H that had this problem...I totally agree about reporting anything unusual. It's up to us to report the stuff we think is weird, and then alex/rick or others can sort through our reports to see if any of it is critical and/or fixable.
...

PS - Where do you hail from in Virginia?

Woodbridge - how about you?

beadman

[Snake_doctor]

Originally Posted by beadman

... Woodbridge - how about you?

beadman

Manassas.

I have been tracking all this a lot more closely, and I think I have discovered a few things. First it is a SETI issue. I watched today as a P@H WU was listed as running, and a SETI WU was incrementing its stats in the Monitor window. The SETI WU was listed as paused. I checked the Application Monitor and sure enough the SETI App was dormant, and the P@H App was running. I forced the SETI App to quit using the application monitor and instantly the P@H WU began to increment and the SETI WU stopped. At the time this occurred the numbers on both WU became exactly the same (P@H was all zeros until I killed the SETI app). The P@H Wu picked up at exactly the point where the numbers stopped incrementing on the S@H WU.

Subsequently when the S@H WU started up again it was showing 98% complete and it finished and reported with a short CPU time. I have now just witnessed this same thing only the cross-up was with a Rosette WU and a S@H WU. Again the SETI App was dormant and when I forced it to stop the R@H WU began to increment normally, leaving the S@H WU showing paused with the counters set at the point they were when I Quit the app.

I also have determined that this occurs at a point where there is a S@H Wu in the cue that is almost finished and a second one that is somewhere along in the process. The system will sometimes download a new WU from S@H just before a WU completes. When it does, the system will complete the WU and upload it, which will initiate an App switch. This is where the trouble starts. BOINC will switch to the other App but somehow the stats files get crossed up and the processing for the new App gets stored in the Partially completed SETI WU stats file. so what you see is the SETI WU incrementing while it is actually paused, and the numbers are not related to SETI at all. When it switches back to the S@H WU the system will put a "0" in the CPU time, complete the process and upload the WU with a short time, but it will validate because the upload finish file is not the same file as the BOINC state stats file and it is ok.

If for some reason the the system does not fix itself before a S@H Wu uploads, the WU will not always validate, and I have seen some of these as well.

So I am guessing that the -9 problem and the short WU problem MAY actually be a symptom of a similar problem. In one case the system stops and uploads so fast that the error is not entered into the upload file (a flushing issue), and in the case of the Short WU times, the system is not closing out all it's SETI files before it completes the App switch.

In any case it looks like SETI to me because I am seeing this happen with more than one other application, but it always involves a SETI WU.

Good luck with Mid- terms Alex, we are all pulling for you.

Regards
Phil

[beadman]

Phil:
You may be right about this. I have a few of the very short time but full credit WU, but I have quite a lot of the WU with "medium" time (half, 2/3, etc. of normal) but full credit. I have had my "connect to" set at 0.0000005 day. On my faster machines, this means there is only a half second or so between the time a new WU is requested and computation ends, but if I'm using the machine with my normal lot of open apps, it could be delayed long enough that SETI pauses with only a second or two of computation left. I think I'll change my connect to time to a bit longer, maybe a half-hour, and see if I find a reduction in low times.

beadman

[Snake_doctor]

Originally Posted by beadman

Phil:
You may be right about this. I have a few of the very short time but full credit WU, but I have quite a lot of the WU with "medium" time (half, 2/3, etc. of normal) but full credit. I have had my "connect to" set at 0.0000005 day. On my faster machines, this means there is only a half second or so between the time a new WU is requested and computation ends, but if I'm using the machine with my normal lot of open apps, it could be delayed long enough that SETI pauses with only a second or two of computation left. I think I'll change my connect to time to a bit longer, maybe a half-hour, and see if I find a reduction in low times.

beadman

I have been researching this a bit on the other boards. I found this thread on the E@H boards describing the same issue. I have now seen this happen on all of my projects running on G4 machines. I have not seen it yet on the G5, but it is a very fast system. So far the only app not affected by this has been CP@H. I am beginning to think that this may actually be a P@H issue. But it still might be possible to fix it with buffer flushing and file close outs in other apps like S@H during a switch.

I also have a number of S@H Wu that show time that seem short based on similar work in the past. As you correctly point out, when my queue is full I do not see this happen, it is only when there is one WU per project. I too frequently see S@H Wus pause with just a min or so left. I have adjusted my contact frequency to see what happens.

Last night I actually saw a P@H WU start up and the CPU time for the pausing S@H WU got reset to zero. In this case the P@H WU proceed normally. When the S@H WU started up again it started from zero CPU seconds, counted off until it finished, but reported the wrong time.

I have posted a new thread on the P@H problems boards here to see if I can get the P@H folks to look into this. I think if they programed in a short delay during the App switch this might solve the issue.

Regards
Phil

EDIT: The P@H guys are saying this may be a BOINC Client issue. According to them the application does not maintain the CPU stats, BOINC does. So if there is a problem with the stats at an application switch out, BOINC is the problem. While this may be true, (and it does make some sense) I still think it is odd that P@H is always involved somehow. Last night I actually saw a S@H WU that went the other way on CPU time. When the switch occured a fresh S@H WU started off at 1:23:00 and counted from there. It also showed a completion time of over 200 hours at startup. Very strange.

[beadman]

Alex and Rick:
Had two invalid WU recently. Unfortunately, wasn't able to grab either one and download it for you. Computer is my 1.33 GHZ iBook G4 running 10.3.9, Superbench 4.44, and Alpha-4-G4. The two WU are

129639256 30716413 14 Oct 2005 2:03:36 UTC 15 Oct 2005 16:30:16 UTC Over Success Done 7,857.14 33.98 0.00
123605324 29390966 4 Oct 2005 0:17:44 UTC 4 Oct 2005 5:40:39 UTC Over Success Done 7,733.07 33.51 0.00

The 4 Oct one had three successful, an Intel/Win and Intel/Linux and me, but the other two machines were the only ones "valid".
The 14 Oct one had four successful, two Intel/Win and one PowerMac G5 and me, but mine was again invalid. The PowerMac seems to be using the standard issue BOINC and SETI...

beadman

[beadman]

Alex and Rick:
Here's an interesting one for you. In the Terminal Log below, you can see that it took SETI a total of 2 hours and 9 minutes to run on my 1.66 GHz PowerBook G4. At 10:23:49, SETI paused, Einstein resumed, and SETI received an "exit with zero status" message. After an hour, SETI restarted and took 21 minutes to finish, which is basically the amount of CPU time reported. The earlier hour and 48 minutes of crunch time were not counted. Unfortunately, I was not able to keep a copy of the WU.

2005-10-21 08:34:59 [SETI@home] Starting result 16my04aa.19669.2848.665908.35_2 using setiathome version 4.18
2005-10-21 08:35:00 [SETI@home] Started upload of 07my04aa.12165.12882.890912.99_2_0
2005-10-21 08:35:02 [SETI@home] Finished upload of 07my04aa.12165.12882.890912.99_2_0
2005-10-21 08:35:02 [SETI@home] Throughput 138434 bytes/sec
2005-10-21 08:35:03 [SETI@home] Sending scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
2005-10-21 08:35:04 [SETI@home] Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi succeeded
2005-10-21 09:34:59 [---] schedule_cpus: time 3600.049412
2005-10-21 10:23:45 [SETI@home] Requesting 0.46 seconds of work
2005-10-21 10:23:45 [SETI@home] Sending scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
2005-10-21 10:23:46 [SETI@home] Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi succeeded
2005-10-21 10:23:46 [SETI@home] Deferring communication with project for 10 minutes and 5 seconds
2005-10-21 10:23:46 [SETI@home] Deferring communication with project for 10 minutes and 5 seconds
2005-10-21 10:23:47 [SETI@home] Started download of 07no03ab.9522.8304.465900.29
2005-10-21 10:23:49 [SETI@home] Finished download of 07no03ab.9522.8304.465900.29
2005-10-21 10:23:49 [SETI@home] Throughput 281244 bytes/sec
2005-10-21 10:23:49 [---] request_reschedule_cpus: files downloaded
2005-10-21 10:23:49 [---] schedule_cpus: must schedule
2005-10-21 10:23:49 [SETI@home] Pausing result 16my04aa.19669.2848.665908.35_2 (left in memory)
2005-10-21 10:23:49 [Einstein@Home] Starting result l1_0078.0__0078.2_0.1_T05_S4lC_2 using einstein version 4.82
2005-10-21 10:24:19 [SETI@home] Result 16my04aa.19669.2848.665908.35_2 exited with zero status but no 'finished' file
2005-10-21 10:24:19 [SETI@home] If this happens repeatedly you may need to reset the project.
2005-10-21 10:24:19 [---] request_reschedule_cpus: process exited
2005-10-21 10:24:19 [---] schedule_cpus: must schedule
2005-10-21 11:24:20 [---] schedule_cpus: time 3600.087580
2005-10-21 11:24:20 [SETI@home] Restarting result 16my04aa.19669.2848.665908.35_2 using setiathome version 4.18
2005-10-21 11:24:20 [Einstein@Home] Pausing result l1_0078.0__0078.2_0.1_T05_S4lC_2 (left in memory)
2005-10-21 11:45:15 [---] request_reschedule_cpus: process exited
2005-10-21 11:45:15 [SETI@home] Computation for result 16my04aa.19669.2848.665908.35_2 finished

I don't remember any of my previouos "short run time" WU haviing the zero status message, but they may have...

beadman

[beadman]

Hi, guys - me again!

The same problem also happened today on my 1.33 GHz iBook. Forgot to mention on the above post that I was running 10.3.9, Superbench 4.44, and Alphas-4-G4 on both machines. The Powerbook in CLI, and this iBook in MenuBar.
Here's the log for the iBook:

2005-10-21 10:53:11 [SETI@home] Starting result 07no03ab.175.5714.667316.30_0 using setiathome version 4.18
2005-10-21 10:53:12 [Einstein@Home] Started upload of l1_1233.0__1233.2_0.1_T03_S4lC_2_0
2005-10-21 10:53:15 [Einstein@Home] Finished upload of l1_1233.0__1233.2_0.1_T03_S4lC_2_0
2005-10-21 10:53:15 [Einstein@Home] Throughput 859520 bytes/sec
2005-10-21 10:53:16 [Einstein@Home] Sending scheduler request to http://einstein.phys.uwm.edu/EinsteinAtHome_cgi/cgi
2005-10-21 10:53:17 [Einstein@Home] Scheduler request to http://einstein.phys.uwm.edu/EinsteinAtHome_cgi/cgi succeeded
2005-10-21 10:53:17 [Einstein@Home] Deferring communication with project for 1 minutes and 0 seconds
2005-10-21 10:53:26 [SETI@home] Requesting 10.64 seconds of work
2005-10-21 10:53:26 [SETI@home] Sending scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
2005-10-21 10:53:27 [SETI@home] Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi succeeded
2005-10-21 10:53:28 [SETI@home] Started download of 07no03ab.9522.8450.492326.188
2005-10-21 10:53:30 [SETI@home] Finished download of 07no03ab.9522.8450.492326.188
2005-10-21 10:53:30 [SETI@home] Throughput 263425 bytes/sec
2005-10-21 10:53:30 [---] request_reschedule_cpus: files downloaded
2005-10-21 10:53:30 [---] schedule_cpus: must schedule
2005-10-21 11:01:28 [SETI@home] Deferring communication with project for 2 minutes and 4 seconds
2005-10-21 11:53:30 [---] schedule_cpus: time 3600.092317
2005-10-21 12:53:30 [---] schedule_cpus: time 3600.047149
2005-10-21 12:53:31 [Einstein@Home] Requesting 1728.00 seconds of work
2005-10-21 12:53:31 [Einstein@Home] Sending scheduler request to http://einstein.phys.uwm.edu/EinsteinAtHome_cgi/cgi
2005-10-21 12:53:32 [Einstein@Home] Scheduler request to http://einstein.phys.uwm.edu/EinsteinAtHome_cgi/cgi succeeded
2005-10-21 12:53:32 [Einstein@Home] Deferring communication with project for 1 minutes and 0 seconds
2005-10-21 12:53:32 [---] request_reschedule_cpus: files downloaded
2005-10-21 12:53:32 [---] schedule_cpus: must schedule
2005-10-21 12:53:32 [SETI@home] Pausing result 07no03ab.175.5714.667316.30_0 (left in memory)
2005-10-21 12:53:32 [Einstein@Home] Starting result l1_1233.0__1233.3_0.1_T03_S4lC_2 using einstein version 4.82
2005-10-21 12:54:02 [SETI@home] Result 07no03ab.175.5714.667316.30_0 exited with zero status but no 'finished' file
2005-10-21 12:54:02 [SETI@home] If this happens repeatedly you may need to reset the project.
2005-10-21 12:54:02 [---] request_reschedule_cpus: process exited
2005-10-21 12:54:02 [---] schedule_cpus: must schedule
2005-10-21 12:54:02 [SETI@home] Restarting result 07no03ab.175.5714.667316.30_0 using setiathome version 4.18
2005-10-21 12:54:02 [Einstein@Home] Pausing result l1_1233.0__1233.3_0.1_T03_S4lC_2 (left in memory)
2005-10-21 13:12:04 [---] request_reschedule_cpus: process exited
2005-10-21 13:12:04 [SETI@home] Computation for result 07no03ab.175.5714.667316.30_0 finished

Same basic thing happened; on this one, SETI ran for 2 hours, then swapped out with Einstein. Exactlyh 30 seconds after the pause, in both cases, SETI exited with the zero status message.

beadman

[Knightrider]

exited with zero status but no 'finished' file
2005-10-21 10:24:19 [SETI@home] If this happens repeatedly you may need to reset the project.

This problem has been discussed in another thread which I can't find.

I have had it myself several times and mostly after I had made some changes which left (old) wu's still to be proccessed in the projects folder. After the change, whatever it was, the new setup could not recognize the prior wu's as valid wu's although it tried to process them. The result was a message as above. The new set up worked through each of these old wu's, and then carried on as normal with no more error messages.

K.

[alexkan]

Alright, in case you all thought Rick and I had disappeared off the face of the earth...

I have a 2-week break between midterms, but I still have what is apparently a rather large project for my compilers course that will be filling that gap. Anyways, Rick informs me that there will be an alpha-6 coming out eventually, once he sorts out some issues with the optimizations that he's come up with since then. I haven't gotten the code from him yet, so I can't say how extensive the optimizations are, but there is a speedup.

Also, thank you all for reporting your issues with short work unit times. We should emphasize, though, that the SETI@home BOINC project is really logically two pieces of code: the SETI analysis code, which does all the mathematically heavy lifting and the BOINC client code, which takes care of work unit reporting and timing. Our optimization really only touches the SETI analysis code, so these reporting issues are sort of not in our area of expertise (and definitely not in mine).

Also, if you're reading this thread and you have a new dual-core G5, please come forward! Rick and I have been looking forward to seeing how the 1 MB L2 caches help with performance. Remember how fast the original G4s were given their clock speed? Part of that might have been due to low multipliers relative to memory, but a lot of that has to do with having large L2 caches. So yeah...I'm excited.

In summary:

• alpha-6 is coming
• if you have a dual-core G5, PM us ASAP or post benchmarks!

[darcybaston]

Thanks for contacting me personally Alex. Always a pleasure to put a new machine through its paces.

I have a Dual Core 2.0GHz, stock config (http://www.apple.com/powermac/specs.html) and Alex walked me through the process of doing a benchmark. Because of the 2x1MB caches, you're going to love these results:

Code:
~/Downloads/seti@home-G5-a5 >time ./seti@home-G5-a5

real    37m11.570s
user    36m50.564s
sys     0m19.551s

init_data.xml contains: <wu_cpu_time>3098.689364</wu_cpu_time>

I now plan on doing some profiling using CHUD tools like Shark. I'm new at all this, so forgive some confused jargon/understanding from time to time.

I've been doing RC5-72 crunching since I had an Amiga 1200 14MHz (later accelerated with a 25MHz 68EC030) in the early 90s, but all this excitement surrounding SETI@Home is very alluring!

While the test was running, I took a few seconds to launch Activity monitor and watch the two "bars". The process seemed to alternate 1/3 to FULL use of either core, but not both simultaneously. So it was alternating like this:

1s
============
===

2s
===
============

3s
============
===

4s
===
============

I don't know what *that* means, but it was fun to watch for a bit before turning it off to let the cpu do its thing.

[darcybaston]

With menu bar Boinc app:

Code:
2005-10-25 23:26:54 [---] Running CPU benchmarks
2005-10-25 23:27:52 [---] Benchmark results:
2005-10-25 23:27:52 [---]    Number of CPUs: 2
2005-10-25 23:27:52 [---]    1056 double precision MIPS (Whetstone) per CPU
2005-10-25 23:27:52 [---]    2515 integer MIPS (Dhrystone) per CPU
2005-10-25 23:27:52 [---] Finished CPU benchmarks

[darcybaston]

Command line version:

Code:
2005-10-25 23:29:51 [---] Running CPU benchmarks
2005-10-25 23:30:48 [---] Benchmark results:
2005-10-25 23:30:48 [---]    Number of CPUs: 2
2005-10-25 23:30:48 [---]    1061 double precision MIPS (Whetstone) per CPU
2005-10-25 23:30:48 [---]    2573 integer MIPS (Dhrystone) per CPU
2005-10-25 23:30:48 [---] Finished CPU benchmarks

In these benchmark tests, Activity monitor shows both cpu bars at full tilt the whole time.

[mikkyo]

Originally Posted by darcybaston

In these benchmark tests, Activity monitor shows both cpu bars at full tilt the whole time.

Activity Monitor eats some cpu, so youll get higher results if you don't peek at what the cpus are doing.
The CPUs switching between max levels it probably occurring whenever the pipeline is flushed, like when Activity monitor steals some cpu time to redraw its window.

Now you should try the Team MacNN optimized clients.

[darcybaston]

I was guessing "whole time" since I only had AM running for 5 seconds.