I seem to remember that while running the new app. Mark had to up his voltage,for the new app. ran hotter, or something like that.So will we have to tone down a bit? I guess with the increase of the app. this will not matter that much.

Mark runs his boxes VERY close to the edge. For those of us not so close to the cliff edge should be ok.

edit
myself.....I prefere to be not be so close to the edge. Running that close, if your box goes down for only 1 hour, you have lost any advantage you would have had.
edit

I seem to remember that while running the new app. Mark had to up his voltage,for the new app. ran hotter, or something like that.So will we have to tone down a bit? I guess with the increase of the app. this will not matter that much.

In the interest of checking difference in core temps & vCore droop, I propose to divert Thurston to run R-2.4V SSSE3 client long enough to crunch 2WUs/core. (~4 hours)

I'll follow up by running RC1 SSSE3X and post Core_Temp and CPU-Z screen caps to show temps & vCore idle and under load with each client...

Anyn interest in this set of tests ?
Might this information be beneficial?

Regards,
JDWhale

@john deneer - Agreed. My room temp is 27C, case open, I'll snap the caps when the AC isn't blowing. Also I'll supply power through Kill-A Watt to get system draw.

In the interest of checking difference in core temps & vCore droop, I propose to divert Thurston to run R-2.4V SSSE3 client long enough to crunch 2WUs/core. (~4 hours)

I'll follow up by running RC1 SSSE3X and post Core_Temp and CPU-Z screen caps to show temps & vCore idle and under load with each client...

Anyn interest in this set of tests ?
Might this information be beneficial?

Might be interesting, although (I think) probably not very beneficial. But whatever you do, make sure that you measure actual ambient temps during the runs as well (use an old fashioned thermometer) in order to rule out that any observed differences were due to differences in ambient temps.

Regards,
John.

Also I'll supply power through Kill-A Watt to get system draw.

Then it would be extra good to use the cumulative number divided by time to get an average. Some BOINC science aps have appreciable variation in power consumption with time, some at the scale of a second or two (can see the Kill-a-Watt jumping around at its one second sampling interval) while others seem to have distinct phases of execution at a time scale of many minutes.

Personally, I think the power draw number much more interesting than the temperature one.

---

I seem to remember that while running the new app. Mark had to up his voltage for the new app. ran hotter, or something like that.So will we have to tone down a bit? I guess with the increase of the app. this will not matter that much.

In the interest of checking difference in core temps & vCore droop, I propose to divert Thurston to run R-2.4V SSSE3 client long enough to crunch 2WUs/core. (~4 hours)

I'll follow up by running RC1 SSSE3X and post Core_Temp and CPU-Z screen caps to show temps & vCore idle and under load with each client...

Anyn interest in this set of tests ?
Might this information be beneficial?

Regards,
JDWhale

@john deneer - Agreed. My room temp is 27C, case open, I'll snap the caps when the AC isn't blowing. Also I'll supply power through Kill-A Watt to get system draw.

John

I would be interested in the core temperatures under each optimised client.

My Penny is air cooled and clocked to 4.0GHz. The core temperatures are high, but stable. There may be some compulsion on me to tone down the CPU frequency if the Alex port pushes the cores much hotter!

---

It's good to be back amongst friends and colleagues

Anyn interest in this set of tests ?

Definately interested here.

---

I would be interested in the core temperatures under each optimised client.

My Penny is air cooled and clocked to 4.0GHz. The core temperatures are high, but stable. There may be some compulsion on me to tone down the CPU frequency if the Alex port pushes the cores much hotter!

Sorry buddy, I'll post Thurston (Q6600@3375) numbers but don't have a penny in the corral to test. I feel that the Q6600 firmly owns the "sweet spot", the most bang for the buck.

That said... I've got a mobo and some quality memory available if someone wants to rush me a QX9770 Yorkfield chip to test ;-) (PM me for shipping address)


All joking aside.... Tests are underway, expect results in a couple hours. (stage 2 beginning in ~45 minutes) I wish I knew how to reset the clock/KWh feature on the Kill-A-Watt so I wouldn't have to record values longhand. (I think I can record the numbers and still drink bourbon, I might not remember doing it tomorrow... but that's nothing new ;-) Trust me... I'm a professional!!! Ehll, I didn't even remember porting this AK code the next day ;-)

@David - There might babble on this Friday night... ample supplies available ;-)

Cheers,
JDWhale

---

I wish I knew how to reset the clock/KWh feature on the Kill-A-Watt so I wouldn't have to record values longhand.

So far as I know, only temporarily removing line power will reset accumulation on the Kill-A-Watt. Which, by the way, to my thinking is the most significant flaw of an otherwise admirable little piece of gear.

---

I wish I knew how to reset the clock/KWh feature on the Kill-A-Watt so I wouldn't have to record values longhand.

So far as I know, only temporarily removing line power will reset accumulation on the Kill-A-Watt. Which, by the way, to my thinking is the most significant flaw of an otherwise admirable little piece of gear.

Ummm...mine has a button labeled 'Reset'. Doesn't yours??

---

Clk2HlpSetiCty:::PayIt4ward

Sorry buddy, I'll post Thurston (Q6600@3375) numbers but don't have a penny in the corral to test. I feel that the Q6600 firmly owns the "sweet spot", the most bang for the buck.

Cheers,
JDWhale

I was interested in the differences to core temperature on Thurston, as you stated. I wanted to see if the different clients worked the CPU harder, and, therefore, raised the core temperatures.

My reference to the Penny was that mine runs fine, but I do not know how close it is to the edge.

Any increase in core temperatures on Thurston could be mentally transferred, and I would have a warning for what to look for (if any changes actually occurred).

---

It's good to be back amongst friends and colleagues

At this stage it looks as though initial releases will likely be (6 of):

32 bit Windows:
sse3 (AMD & Intel that support sse3)
ssse3x
sse4.1
64 bit Windows:
sse3 (AMD & Intel that support sse3)
ssse3x
sse4.1

Sorry, no graphics (Yet), and no less than SSE3 (Yet). We'll be exploring those items, along with Linux and potentially other ports, in the not too distant future. We are however hoping to squeeze a little more performance out of these builds after release, as Alex is likely off working on version 9....

Jason

Hi Jason,

Thanks for the list and all the hard work I do appreciate it. I might even buy you a coffee one day :-)

How come the SSSE3x is called a Xeon version? It isn't specific to a Xeon is it? Presumably we select the highest instruction set the cpu is capable of and use that version of the app, as we do with the 2.4v chicken?

---

BOINC blog

Ummm...mine has a button labeled 'Reset'. Doesn't yours??

Ummm...No!

Actual photo gathering stats...

KWSN client had 3 hours, will give RC1 same time... so still ~1 hour before results are posted.

---

@David - There might babble on this Friday night... ample supplies available ;-)

Sounds like fun, but it's already 11:45am Saturday, so wheres the results.. Oh wait, thats right, your living in the past. Darn timezones ;)

---

Ummm...mine has a button labeled 'Reset'. Doesn't yours??

Ummm...No!

Two different models--note the "EZ" up above the display on the model which not only has reset, but also will "do the math" of multiplying your rate by your consumption to get dollars. I figured I could multiply, but did not notice that I was passing up a reset button--good to know.

---

Observed.... RC1 client draws 13 Watts more than KWSN_2.4V client.
CoreTemp, vDroop demonstrate indifference to optimized client version.

[edit]
27C refers to room temperature... Thurston case is open... CPU & case fans not powered by Mobo connects (running full speed).
[/edit]

Thurston - 129 Watts 27C
Idle


Observations: After 10 minutes with SETI client "suspended".


Thurston - 256 Watts 27C
AK_v8_win_SSSE3x_RC1


Observations: Kill-A-Watt readings observed as high as 263 Watts near 50% completion af all WUs. WUs still pretty much in-sync with all 4 starting within 5 minutes of each other. Draw normally staying within 253-258W range. Kill-A-Watt sampling begins 5 minutes after last RC1 client starts. Draw averaged over 3 hours.



Thurston - 243 Watts 27C
KWSN_2.4V_SSSE3_MB


Observations: Watching the Kill-A-Watt, first 1/2 of WU was reading 246 Watts... last 1/2 draw was 238 Watts..... I didn't believe, so I closely monitored when the 2nd round of WU started up... I watched draw rise from 235 Watts at the tail end of all 4 WUs to 246 Watts when the 4 new WUs were crunching. Similarly when 2nd round of WUs reached 50% completion draw fell to 236 Watts. Power draw is averaged over 3 hours.


Thurston will remain running RC1 client for next ~60 hours to compensate for running these tests in quest to reach RAC 7090...

Regards,
JDWhale

Ummm...mine has a button labeled 'Reset'. Doesn't yours??

Ummm...No!

Two different models--note the "EZ" up above the display on the model which not only has reset, but also will "do the math" of multiplying your rate by your consumption to get dollars. I figured I could multiply, but did not notice that I was passing up a reset button--good to know.

Yeah, I didn't know there was a difference until now, Wow, Thanks John Galt 007 and archae86.

---

The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's

At this stage it looks as though initial releases will likely be (6 of):

32 bit Windows:
sse3 (AMD & Intel that support sse3)
ssse3x
sse4.1
64 bit Windows:
sse3 (AMD & Intel that support sse3)
ssse3x
sse4.1

Sorry, no graphics (Yet), and no less than SSE3 (Yet). We'll be exploring those items, along with Linux and potentially other ports, in the not too distant future. We are however hoping to squeeze a little more performance out of these builds after release, as Alex is likely off working on version 9....

Jason

Hi Jason,

Thanks for the list and all the hard work I do appreciate it. I might even buy you a coffee one day :-)

How come the SSSE3x is called a Xeon version? It isn't specific to a Xeon is it? Presumably we select the highest instruction set the cpu is capable of and use that version of the app, as we do with the 2.4v chicken?

Originally in development there have been these versions, each in both 32 & 64 Bit:

SSE3 (AMD & Intel)
SSSE3 (non-xeon) ... deleting from initial release (consistently slower)
SSSE3x (xeon)
SSE4.1 (non-xeon)
SSE4.1x (xeon) ... deleting from initial release (redundant)

The x (xeon) builds [, which are not xeon specific by the way, it's a technigue that uses ] a particular compilation directive placed in the code By Alex that sets certain computationally intense areas to use a smaller stride in calculation loops. In testing this has shown to have most performance impact on systems with architecturally pressured RAM/FSB/Cache characteristics, though originally apparently intended for xeon based Mac Pros that use FBDimms, it seems to apply to pretty much all 65nm chips to some extent. Ask any V8 platform owner that's been querying RAM bandwidth and you'll get the picture.

Perhaps we'll change the name of that flag to something else less confusing such as USE_MEMSQUEEZE or some such.

Using specially weighted test work units (By Joe) designed to approximate the current AR distribution, for each app each WU time is summed to compare & choose which app might be the best for that machine, pending AR Pot Luck. [Joe's Crystal Ball]

ssse3 machines have shown to consistently prefer the xeon build from 0%-10%, thus rendering the non-x version unnecessary. However, for the time being we'll keep that active in development to maintain diversity should it prove easier to tweak later on. (genetic diversity)

sse4.1 machines on the other hand, with their much higher FSB (Mine runs at 1600MHz), were showing little if any difference between ssse3,ssse3x,ssse41 & ssse41x. Though across several test machines both Wolfdale & Yorkfield did seem to show a minute preference for non-x builds, it becomes an exercise it splitting hairs across all four builds on these machines ...

So SSE4.1 users will initially have the choice between SSE4.1 or SSSE3x ... Should some systems prefer the latter consistently then we may resurrect the ssse4.1x.
At this stage the extra builds seem unnecessary and would only confuse people. releasing 6 builds instead of 10 makes more sense.

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.

the machine with AK code is on its way to 13K RAC.

V

At this stage it looks as though initial releases will likely be (6 of):

32 bit Windows:
sse3 (AMD & Intel that support sse3)
ssse3x
sse4.1
64 bit Windows:
sse3 (AMD & Intel that support sse3)
ssse3x
sse4.1

Sorry, no graphics (Yet), and no less than SSE3 (Yet). We'll be exploring those items, along with Linux and potentially other ports, in the not too distant future. We are however hoping to squeeze a little more performance out of these builds after release, as Alex is likely off working on version 9....

Jason

Hi Jason,

Thanks for the list and all the hard work I do appreciate it. I might even buy you a coffee one day :-)

How come the SSSE3x is called a Xeon version? It isn't specific to a Xeon is it? Presumably we select the highest instruction set the cpu is capable of and use that version of the app, as we do with the 2.4v chicken?

Originally in development there have been these versions, each in both 32 & 64 Bit:

SSE3 (AMD & Intel)
SSSE3 (non-xeon) ... deleting from initial release (consistently slower)
SSSE3x (xeon)
SSE4.1 (non-xeon)
SSE4.1x (xeon) ... deleting from initial release (redundant)

The x (xeon) builds [, which are not xeon specific by the way, it's a technigue that uses ] a particular compilation directive placed in the code By Alex that sets certain computationally intense areas to use a smaller stride in calculation loops. In testing this has shown to have most performance impact on systems with architecturally pressured RAM/FSB/Cache characteristics, though originally apparently intended for xeon based Mac Pros that use FBDimms, it seems to apply to pretty much all 65nm chips to some extent. Ask any V8 platform owner that's been querying RAM bandwidth and you'll get the picture.

Perhaps we'll change the name of that flag to something else less confusing such as USE_MEMSQUEEZE or some such.

Using specially weighted test work units (By Joe) designed to approximate the current AR distribution, for each app each WU time is summed to compare & choose which app might be the best for that machine, pending AR Pot Luck. [Joe's Crystal Ball]

ssse3 machines have shown to consistently prefer the xeon build from 0%-10%, thus rendering the non-x version unnecessary. However, for the time being we'll keep that active in development to maintain diversity should it prove easier to tweak later on. (genetic diversity)

sse4.1 machines on the other hand, with their much higher FSB (Mine runs at 1600MHz), were showing little if any difference between ssse3,ssse3x,ssse41 & ssse41x. Though across several test machines both Wolfdale & Yorkfield did seem to show a minute preference for non-x builds, it becomes an exercise it splitting hairs across all four builds on these machines ...

So SSE4.1 users will initially have the choice between SSE4.1 or SSSE3x ... Should some systems prefer the latter consistently then we may resurrect the ssse4.1x.
At this stage the extra builds seem unnecessary and would only confuse people. releasing 6 builds instead of 10 makes more sense.

Jason

In preparation for the upcoming release of the ported SSE3 code I have switched my old 3.2GHz P4-Prescott (@3.6GHZ) back to all SETI. This way I get to see some good comparisons between the 2.4 and this port. I know the RAC won't settle out in time but there will be enough wu's to see the speed up....woohoo! Seeing a RAC near 1200-1300 will be awesome for this aging beast!

Live long and BOINC!

---

Paul
(S@H1 8888)
And proud of it!

At this stage it looks as though initial releases will likely be (6 of):

32 bit Windows:
sse3 (AMD & Intel that support sse3)
ssse3x
sse4.1
64 bit Windows:
sse3 (AMD & Intel that support sse3)
ssse3x
sse4.1

Sorry, no graphics (Yet), and no less than SSE3 (Yet). We'll be exploring those items, along with Linux and potentially other ports, in the not too distant future. We are however hoping to squeeze a little more performance out of these builds after release, as Alex is likely off working on version 9....

Jason

Will these releases on May 1 be able to handle variable credit multipliers properly?