Windows S5R3 "power users" App 4.26 available

archae86
archae86
Joined: 6 Dec 05
Posts: 3,146
Credit: 7,101,144,931
RAC: 1,068,941

RE: I've just assumed that

Message 77569 in response to message 77566

Quote:

I've just assumed that the waveform is displaced evenly so it will be very interesting to see if that assumption is valid or not.


On extremely preliminary matching, my indication on my cleanest host is that the variation as a fraction of total increased going from 4.15 to 4.26.

However, as all but one of my points are in sequence, near a minimum, this conclusion is very strongly driven by a single point, and thus subject to severe revision when reality intervenes.

Brian Silvers
Brian Silvers
Joined: 26 Aug 05
Posts: 772
Credit: 282,700
RAC: 0

RE: RE: I've just assumed

Message 77570 in response to message 77569

Quote:
Quote:

I've just assumed that the waveform is displaced evenly so it will be very interesting to see if that assumption is valid or not.


On extremely preliminary matching, my indication on my cleanest host is that the variation as a fraction of total increased going from 4.15 to 4.26.

However, as all but one of my points are in sequence, near a minimum, this conclusion is very strongly driven by a single point, and thus subject to severe revision when reality intervenes.

Then I guess it would be best if I revise my question as:

Did the amplitude change? (instead of decrease)

Klimax
Klimax
Joined: 27 Apr 07
Posts: 87
Credit: 1,370,205
RAC: 0

I think that amplitude did

I think that amplitude did not change.However this app is sensitive to memory timing.

WU Before
WU after

The first one was run on standard memory timing.(all 5) the second one got all changed by 1 in the faster/unstable direction.(list of changed parameters can be written down).
Unless there is huge difference between 75 and 112 WUs then increase of speed is around 10k secs.While core speed increased as well +0.1GHz cca it did not yeld similar improvement...

Brian Silvers
Brian Silvers
Joined: 26 Aug 05
Posts: 772
Credit: 282,700
RAC: 0

RE: I think that amplitude

Message 77572 in response to message 77571

Quote:

I think that amplitude did not change.However this app is sensitive to memory timing.

WU Before
WU after

The first one was run on standard memory timing.(all 5) the second one got all changed by 1 in the faster/unstable direction.(list of changed parameters can be written down).
Unless there is huge difference between 75 and 112 WUs then increase of speed is around 10k secs.While core speed increased as well +0.1GHz cca it did not yeld similar improvement...

I think you're just seeing some extreme, but natural, runtime variation. You have 2 other tasks that were run on 4.25 that are consecutive that also show a wide spread in runtime. Those two results are:
h1_0721.25_S5R2__115 @ 92495.94 seconds
h1_0721.25_S5R2__116 @ 86130.95 seconds

Since that is a laptop processor, I'm going to guess the real factor at work here is Speedstep...as I don't think it should be that slow anyway...

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5,852
Credit: 111,183,136,969
RAC: 34,918,799

RE: Unless there is huge

Message 77573 in response to message 77571

Quote:

Unless there is huge difference between 75 and 112 WUs then increase of speed is around 10k secs....

It is pretty much useless to compare these two tasks. Your task frequency is 721.25 so you can calculate your cycle period using the formula in the linked thread.

Period = Freq^2 * 0.000206 = 721.25 * 721.25 * 0.000206 = 107

This means that your slowest tasks will have sequence numbers of 0, 107, 214, etc, and your fastest tasks will have sequence numbers of 54, 161, 268, etc.

So your 112 task is very close to the peak in a cycle and will have a long crunch time whilst your 75 task is much closer to a trough at 54. Because the troughs are relatively wide compared to the much sharper peaks (check out the graph in the link above) your 75 task is going to be fairly close to the fastest possible crunch time. I wouldn't be surprised to find that virtually all of the 10K improvement you mention is due to the sequence number only.

Cheers,
Gary.

Svenie25
Svenie25
Joined: 21 Mar 05
Posts: 139
Credit: 2,436,862
RAC: 0

RE: This means that your

Quote:

This means that your slowest tasks will have sequence numbers of 0, 107, 214, etc, and your fastest tasks will have sequence numbers of 54, 161, 268, etc. [/quoted]

Okay, how to calculate the slowest WUs of a frequencyfile I understood. For 754.85 Hz for example 0, 117, 234, ... But how can I get the number of the fastest WUs?

Klimax
Klimax
Joined: 27 Apr 07
Posts: 87
Credit: 1,370,205
RAC: 0

RE: RE: Unless there is

Message 77575 in response to message 77573

Quote:
Quote:

Unless there is huge difference between 75 and 112 WUs then increase of speed is around 10k secs....

It is pretty much useless to compare these two tasks. Your task frequency is 721.25 so you can calculate your cycle period using the formula in the linked thread.

Period = Freq^2 * 0.000206 = 721.25 * 721.25 * 0.000206 = 107

This means that your slowest tasks will have sequence numbers of 0, 107, 214, etc, and your fastest tasks will have sequence numbers of 54, 161, 268, etc.

So your 112 task is very close to the peak in a cycle and will have a long crunch time whilst your 75 task is much closer to a trough at 54. Because the troughs are relatively wide compared to the much sharper peaks (check out the graph in the link above) your 75 task is going to be fairly close to the fastest possible crunch time. I wouldn't be surprised to find that virtually all of the 10K improvement you mention is due to the sequence number only.


Sigh...I knew why I was unsure.OK that answers diff part.
(All threads were read through ,but I failed to realize that it will have far bigger change in run-time.)

Sorry to anybody,who would be thrilled by such sharp improvement...
Next time I'll just use few more days before posting... :-)

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3,522
Credit: 692,140,497
RAC: 17,866

RE: Okay, how to calculate

Message 77576 in response to message 77574

Quote:

Okay, how to calculate the slowest WUs of a frequencyfile I understood. For 754.85 Hz for example 0, 117, 234, ... But how can I get the number of the fastest WUs?

Should be about mid-way between the slowest, so slowest + half the period.

CU

Bikeman

Svenie25
Svenie25
Joined: 21 Mar 05
Posts: 139
Credit: 2,436,862
RAC: 0

Ah, thanks a lot. Will look

Ah, thanks a lot. Will look for it. :)

Example frequency 754.85 fastest WUs: 58 175 292 409
Am I correct?

Wedge009
Wedge009
Joined: 5 Mar 05
Posts: 117
Credit: 16,078,249,765
RAC: 7,154,773

If WU reports are still

If WU reports are still useful, I have four completed so far, with times ~14 hours against ~15-16 hours for the 4.15 application.

Soli Deo Gloria

Comment viewing options

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