KWSN Auto Install

[bLaZeR666_uk]

Hi

I have a Core 2 Duo E6600

Just installed the auto install version of KWSN. I ran the benchmark programme and it came up and said that the sse2 (not even the SSE2 P4) application was the fastest on my system (43 secs) The SSE2 PM, SSE P4 and SSE 3 apps all scored 45 secs, how is this? as the Conroe chip has SSE 1 2 3 and 4 I would of thought that using the sse3 app would be correct? Also I ran the KWSN on my P4 Mobile laptop and it said that the sse2 was also the fastest and not the SSE2 PM one! which again is strange. Any ideas/suggestions???

TIA

[Simon]

Hiya,

I've had that result, as well. The problem is mainly that people get bored easily - the short test (sub 1 minute on a quick machine per app) still takes ~5 mins to run. Would I use a bit longer run times, the results would probably jibe a bit better with all machines - in your case, I recommend the SSE3 version for your Core 2 (SSE4 doesn't give any performance, already tested).

Also, a P4-M is NOT a P-M! A P4-M is a P4 with less power usage that can do speedstep (i.e. on-the-fly frequency change), but not a P-M, which is an evolved P3. For a P4-M, depending on model, I would also recommend the SSE2-P4 or SSE3-P4, SSE3 if it's supported by your chip (the test app should have told you).

HTH,
Simon.

[bLaZeR666_uk]

Hi

How do I change the length of the test then? I cant see any options on the app to increase the test time (must be blind  )

Yes sorry its a Pentium Mobile 770 2.13Ghz  and not a P4 M !

Cheers

[Simon]

Well, then you should really use the P-M one

The way to make the test WU run longer is like so:

Edit the work_unit.sah file in a text editor, find the two occurrences of "<chirp_limit>[value]</chirp_limit>" and multiply all values by the same factor.

So, the preset values are:

Code: [Select]

    <chirp_parameter_t>
      <chirp_limit>0.00000001</chirp_limit>
      <fft_len_flags>262136</fft_len_flags>
    </chirp_parameter_t>
    <chirp_parameter_t>
      <chirp_limit>0.000000025</chirp_limit>
      <fft_len_flags>65528</fft_len_flags>
    </chirp_parameter_t>

Note the lots of zeros right of the decimal point. Also, note that the values should be 4:1 (first one is 4 times as large as the second one).

To make it run longer, just remove the same amount of zeros from both - say, remove two for starters, and you will notice quite a difference in runtime.

HTH,
Simon.

[Josef W. Segur]

Well, then you should really use the P-M one

The way to make the test WU run longer is like so:

Edit the work_unit.sah file in a text editor, find the two occurrences of "<chirp_limit>[value]</chirp_limit>" and multiply all values by the same factor.
...
Note the lots of zeros right of the decimal point. Also, note that the values should be 4:1 (first one is 4 times as large as the second one).

To make it run longer, just remove the same amount of zeros from both - say, remove two for starters, and you will notice quite a difference in runtime.

HTH,
Simon.

Inaddition, you can look at the same section in a real full-length WU:

Code: [Select]

      <chirp_parameter_t>
        <chirp_limit>20</chirp_limit>
        <fft_len_flags>262136</fft_len_flags>
      </chirp_parameter_t>
      <chirp_parameter_t>
        <chirp_limit>50</chirp_limit>
        <fft_len_flags>65528</fft_len_flags>
      </chirp_parameter_t>

Note the second limit is 2.5 times the first; that's the ratio which should be maintained.

Also, The program does a minimum chirp step of about 0.001428. Any limit less than that results in no chirping at all, just 15 sets of tests are done on unchirped data. Chirp limit values of 0.01 and 0.25 will begin to lengthen the test time, but for a fast system anything less than 1 and 2.5 isn't sensible. Those give test times of under 10 minutes and still aren't very thorough or repeatable.
                                                                           Joe

[Simon]

Thanks for putting me right there Josef

I did notice the values for runtime didn't change much as I decreased the chirp_limit below the value you mentioned. Also, guess I lost track of the 2.5 instead of 4 multiplier...
Too much to do, too little time.

I have to agree the test results aren't very conclusive at this short run time, but I really do not believe many people would sit through a benchmark that takes 30 minutes, much less several hours. Test group members are a notable exception This was my real rationale behind choosing very low values - I tested them on a 1.6 GHz machine and they already took ~7 mins to run, vs. about 2 mins on my P-D at the value currently set.

I really don't see an easy way to have a short, repeatable and meaningful performance measurement as far as S@H goes - it all takes lots of time.

Regards,
Simon.

[Josef W. Segur]

I really don't see an easy way to have a short, repeatable and meaningful performance measurement as far as S@H goes - it all takes lots of time.

For sure! I gave up trying to figure out whether the generic SSE2 or P4 SSE2 version was "best" for my Willamette P4. They're so close that sufficient testing would waste far more time than would ever be recouped.

One possibility might be to install both and switch between them by putting one or the other first in app_info.xml. But that would require quitting and restarting BOINC to get it to read the change. Perhaps we need a custom version of BOINC which would switch automatically when a  new WU was started...
                                                                     Joe

[Darkclown]

So for the C2D E6600, you're recommending the SSE3 client over any of the SSE2 ones?

[BenHer]

Hey Dark (clown),

Is your first name Bobo? 

Anyway - Your best bet would be to check the list of Top Computers...and see if you can find a Core2Duo computer running  Simon's SSE2 version...vs some other Core 2 running SSE3 (same speed of course).

Core 2 Duo 6600s sorted by RAC should be somewhere around 20-50 on the list.  Most systems in that range are running some optimized client.

Example host with SSE3 speed = 3690 MHz

Another host running SSE2 Speed = 3510 MHz

Seti's database might still be down for weekly database cleanup however.

You find what version of client they are running by going to Computer -> Results -> Click on the Result link for a finished (completed) result and the client version info is displayed in the <std_err> section of the page.