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.
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:
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...
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...
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.
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.
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?
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.
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... :-)
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.
RE: I've just assumed that
)
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.
RE: RE: I've just assumed
)
Then I guess it would be best if I revise my question as:
Did the amplitude change? (instead of decrease)
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...
RE: I think that amplitude
)
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...
RE: Unless there is huge
)
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 = 107This 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.
RE: This means that your
)
RE: RE: Unless there is
)
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... :-)
RE: Okay, how to calculate
)
Should be about mid-way between the slowest, so slowest + half the period.
CU
Bikeman
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?
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