HostID 1001562 - Richard Haselgrove's Q6600 Quad Core

Akos Fekete
Akos Fekete
Joined: 13 Nov 05
Posts: 561
Credit: 4527270
RAC: 0

RE: Akos is at #37 at the

Message 78877 in response to message 78866

Quote:

Akos is at #37 at the moment. He was down below 8000 seconds, then had a run of compute errors, and now he's back to 37000! Probably had to revert to stock to get his quota back up.....

I hope it was only the WUs he trashed, didn't blow a fuse on the box or something.

Those WUs were only "hand-aborted" without any computing problems.
I switched back to the official code because some users were irritated.

Richard Haselgrove
Richard Haselgrove
Joined: 10 Dec 05
Posts: 2139
Credit: 2752854530
RAC: 1396759

RE: RE: Akos is at #37 at

Message 78878 in response to message 78877

Quote:
Quote:

Akos is at #37 at the moment. He was down below 8000 seconds, then had a run of compute errors, and now he's back to 37000! Probably had to revert to stock to get his quota back up.....

I hope it was only the WUs he trashed, didn't blow a fuse on the box or something.


Those WUs were only "hand-aborted" without any computing problems.
I switched back to the official code because some users were irritated.


I'm glad the hear it was nothing more drastic than that.

But your switch from 'official' 4.26 to 'official' 4.32 power app has more than halved your run time (from 37Ksec to 17Ksec) - 4.32 is good, but I don't think it's been quite that good for the rest of us.

Any tips?

Astro
Astro
Joined: 18 Jan 05
Posts: 257
Credit: 1000560
RAC: 0

RE: I switched back to the

Message 78879 in response to message 78877

Quote:
I switched back to the official code because some users were irritated.


OK,,,,Now I'm irritated that you've switched to the official code.....LOL

Time to switch back....LOL

archae86
archae86
Joined: 6 Dec 05
Posts: 3145
Credit: 7024304931
RAC: 1807144

RE: But your switch from

Message 78880 in response to message 78878

Quote:
But your switch from 'official' 4.26 to 'official' 4.32 power app has more than halved your run time (from 37Ksec to 17Ksec) - 4.32 is good, but I don't think it's been quite that good for the rest of us.


Akos, did you perhaps change your clock rate at the same time? A quick comparison to my 3.006 GHz Q6600 running 4.32 suggests your 4.32 results are enough faster to imply a clock rate near 3.28 GHz, which is certainly reachable for most samples of Q6600 on many motherboards with sufficient voltage.

On the other hand, your 4.26 times are far slower than my 3.006 GHz 4.26 times.

Akos Fekete
Akos Fekete
Joined: 13 Nov 05
Posts: 561
Credit: 4527270
RAC: 0

RE: Akos, did you perhaps

Message 78881 in response to message 78880

Quote:
Akos, did you perhaps change your clock rate at the same time? A quick comparison to my 3.006 GHz Q6600 running 4.32 suggests your 4.32 results are enough faster to imply a clock rate near 3.28 GHz, which is certainly reachable for most samples of Q6600 on many motherboards with sufficient voltage. On the other hand, your 4.26 times are far slower than my 3.006 GHz 4.26 times.


My Q6600 runs on 2997MHz (9x333), but it was only 1600MHz for some days.

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5842
Credit: 109404481302
RAC: 35478493

I've uploaded the latest data

Message 78882 in response to message 78876

I've uploaded the latest data for the 5 hosts shown below.

1001562 belonging to RH.
997488 belonging to peanut.
1100395 belonging to smoked trout.
1084360 belonging to nivekfalk.
1101980 belonging to RAMA.

For some reason, nivekfalk's host hasn't accumulated any new results for the last 24 hours. I confirmed this by manually browsing his results list as well.

Please report any errors or problems here.

Cheers,
Gary.

Richard Haselgrove
Richard Haselgrove
Joined: 10 Dec 05
Posts: 2139
Credit: 2752854530
RAC: 1396759

RE: I've uploaded the

Message 78883 in response to message 78882

Quote:

I've uploaded the latest data for the 5 hosts shown below.

1001562 belonging to RH.
997488 belonging to peanut.
1100395 belonging to smoked trout.
1084360 belonging to nivekfalk.
1101980 belonging to RAMA.


Here are a couple of graphs from Gary's data:

RH -

(direct link)

Focussing on the wiggles at the bottom of the curve. Notice how asymmetric they are - I think that follows from, and confirms, Bikeman's theory. Ignore the slowdown for 909.25 between 442 and 471 - that corresponds exactly to the period I was running CPDN on the fourth core. But it's interesting, nonetheless - Peter (archae86) and others have commented that other projects speed up when running alongside Einstein: I think this is the first published evidence of the converse effect, and it's a small one (about 1%).

Peanut -

(direct link)

I've done a new chart for the 4.33 app, and the higher frequency band, only. This is getting towards the peak of his cycle - RR has that at 346.

The Ready Reckoner for all Peanut's data for this 10Hz frequency band (including some in the next cycle, not plotted here) gives

		Period of task cycle = 173
		Number of points = 199
		Minimum runtime in data = 13838
		Maximum runtime in data = 16208
		Estimated peak runtime = 16353
		Estimated average runtime = 14776
		Estimated trough runtime = 13876
		Estimated runtime variance = 0.151


I'm afraid I can't get anything out of the new data from Smoked Trout, Nivefalk, or Rama that we haven't seen before (except that Rama has become a Power User with 4.35). I'll keep an eye on them, and post any charts which aren't an inconclusive jumble.

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5842
Credit: 109404481302
RAC: 35478493

RE: Just a small

Message 78884 in response to message 78874

Quote:
Just a small observation: Peanut's file is sorted in the sequence you described to Bikeman: but the three 'first grab' files are unsorted - still seem to be in website order, or some such. Trivial to re-sort them here, but I just thought you'd like to know.

Yes, you are quite right with your observation.

When the data from a new host is collected for the very first time, what's collected becomes the final output with no other processing. When the data for a host is updated, the new items get blended with what has already been saved. Originally, the sorting was to make sure that the same lines of data that were being collected on subsequent runs didn't result in duplicate entries. The 'uniq' utility removes duplicate lines when they are adjacent in a data stream.

With a bit more thought, I had worked out some time ago how to not collect duplicate lines in the first place so the piping of the data through sort and uniq wasn't needed any more. The data was intended to be sent to RR where lines can be entered in any old order.

Obviously, for other processing schemes, and particularly for human readability, sorting of data is probably quite desirable. There's an easy change I can make to the script which will ensure that even first time collections of data are properly sorted in future.

Thanks for the report.

Cheers,
Gary.

Richard Haselgrove
Richard Haselgrove
Joined: 10 Dec 05
Posts: 2139
Credit: 2752854530
RAC: 1396759

RE: Obviously, for other

Message 78885 in response to message 78884

Quote:
Obviously, for other processing schemes, and particularly for human readability, sorting of data is probably quite desirable. There's an easy change I can make to the script which will ensure that even first time collections of data are properly sorted in future.


Yes please, if it's easy it would be helpful to have them sorted - makes it easy to see which points belong together in a series, and whether the sequence numbers are consecutive (I nearly put in a bug report for 'failure to make due progress' over the weekend, but just in time spotted that the scheduler had slipped in a _575 between _506 and _516 - added 10Ksec to the runtime!).

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3522
Credit: 686138689
RAC: 562245

Hi! RE: RH

Message 78886 in response to message 78883

Hi!

Quote:


RH -

(direct link)

Focussing on the wiggles at the bottom of the curve. Notice how asymmetric they are - I think that follows from, and confirms, Bikeman's theory.

...

Peanut -

(direct link)

Beautiful graphs!!
The wiggles seem to have a max amplitude at phase approx 0.3 and 0.7.

The declination of the skypoints at those phases should be about

arcsin(2 * phase -1) ~ +/-22 degrees

... matching the tilting of the ecliptic plane against the equatorial plane of the coordinate system. Yes, theory and observation match very well indeed.

CU

Bikeman

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.