Got it! Javascript Math.ceil() does 'smallest integer greater than or equal to a number' so that's fine ( ie. pre-divide by ten, do ceil, then post-multiply by ten ).
I'll parameterise with defaults ( but user adjustment available ) the grid/density constant, Gary's 'fiddle' factor, and the step interval for that matter .... :-)
Cheers, Mike.
( edit ) With RR_V8 I'm going to construct a 'hard' parameter/metric which can be used to quantitatively compare curve fits ( exceeding Mark I eyeball ) between scenarios. Looks to be a big re-write so far .... :-)
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
- task cycle period determination formula altered as discussed.
- defaults to RR_V7C behaviour if FREQUENCY STEP FACTOR ( Q ) is set to zero.
See if you can dial in the data guys!! :-)
Cheers, Mike.
( edit ) Looking at Richard's box for 909.15 @ version 4.32, 7C -> 7D raises slightly : all time estimates, the variance, and of course the period. As mentioned, data for tasks spanning across a trough, or even better a peak, would be marvelous.
( edit ) FWIW, I've looked into MSIE's poor Javascript garbage collection - at MSDN they admit the poor performance and basically say 'get over it'. They're wanting you to go server side ie. their 'active server pages' .... as if! Give me PHP any day .....
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
I've seen that even/odd oscillation somewhere before, but don't recall where, and don't recall whether a plausible explanation turned up.
The closest thing I have to a guess is some sort of "drafting". If two processes running very similar applications in near sync may see the leading process be charged more CPU time for the same work, if the trailing process is less likely to get swapped out. But that does not feel very persuasive at all. Other bids?
It's beginning to look more like data, rather than processor time charging.
As mentioned, data for tasks spanning across a trough, or even better a peak, would be marvelous.
As it happens, both of my Conroe-class hosts, which have been given a steady dose of results from Work Unit's in a portion of one half of one cycle, yesterday downloaded new results at a frequency .05 Hz higher in the same skygrid which were much higher in sequence number--about a full cycle higher!
I did some selective pausing to get CPU times on one or two far ahead of schedule, and, while they can't resolve the "right answer" to anywhere near the precision in which Gary expressed the new parameter set, they do fit right in with RRv7d's curve generation. I also particularly like the fact that adding them in to the lower cycle data does not change RR's output parameter estimates materially:
For Stoll3, peak, variance, average without, then with two next cycle points:
23148, .268, 19205 vs. 23134, .266, 19217
For Stoll4, with one next cycle point added,
24015, .270, 19886 vs. 24006, .270, 19882
Here is the actual data, in the right column order and format for RR. However, if you want RR to consider all points, you will need to falsify some frequency entries so that all you wish to consider together are identical, and still within the same 10-Hz step as the true values.
This is far from "proving the revisions right", but overall suggests that this model is quite useful in the near greater than 800 Hz region currently being distributed.
I've got further into the sequence numbers running three cores instead of four (_421 cached), but at the expense of getting a lot of gaps - so I've just suspended CPDN again, and we're back up to full speed. I'd like to watch those wiggles on the graph: 909.25 is continuing to match 909.15 very closely, wiggle for wiggle.
I checked the logs, and I got a 'server requested file delete' for the bottom pair of data files, when I was switched from .15 to .25: I don't think I'll be going back there any time soon.
Interesting conversation between Peanut and Bernd in the Mac 433 Beta thread - we'll have to see if his amplitude decreases.
Data source from Gary's file in previous message.
Omitted: frequencies below 800, mixed app results, sequence numbers outside range plotted, frequencies with very few data points.
Observations:
The wiggles are real.
4.33 is a speed demon.
The cyclic variation is reduced in 4.33 (as Bernd expected), but I think it's still there - just.
There's a disjointedness between 909.75 and 909.95
Good, I'll go as per Peter's
)
Good, I'll go as per Peter's formula .... :-)
Quick check of the Excel semantics before I commit :
ceiling(frequency,10)
gives the least multiple of 10 to exceed the given frequency?
[ ie. round upwards to the nearest multiple of 10 ]
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: Good, I'll go as per
)
Yes, with the boundary case remaining as is (splitting hairs about the interpretation of "exceed" above, which is actually "equal or exceed"):
794.25 --> 800
799.95 --> 800
800.00 --> 800
800.05 --> 810
and thanks,
Peter A. Stoll
RE: Yes, with the boundary
)
Got it! Javascript Math.ceil() does 'smallest integer greater than or equal to a number' so that's fine ( ie. pre-divide by ten, do ceil, then post-multiply by ten ).
I'll parameterise with defaults ( but user adjustment available ) the grid/density constant, Gary's 'fiddle' factor, and the step interval for that matter .... :-)
Cheers, Mike.
( edit ) With RR_V8 I'm going to construct a 'hard' parameter/metric which can be used to quantitatively compare curve fits ( exceeding Mark I eyeball ) between scenarios. Looks to be a big re-write so far .... :-)
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
The special offcut RR_V7D
)
The special offcut RR_V7D version is available.
- task cycle period determination formula altered as discussed.
- defaults to RR_V7C behaviour if FREQUENCY STEP FACTOR ( Q ) is set to zero.
See if you can dial in the data guys!! :-)
Cheers, Mike.
( edit ) Looking at Richard's box for 909.15 @ version 4.32, 7C -> 7D raises slightly : all time estimates, the variance, and of course the period. As mentioned, data for tasks spanning across a trough, or even better a peak, would be marvelous.
( edit ) FWIW, I've looked into MSIE's poor Javascript garbage collection - at MSDN they admit the poor performance and basically say 'get over it'. They're wanting you to go server side ie. their 'active server pages' .... as if! Give me PHP any day .....
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
I've uploaded the latest data
)
I've uploaded the latest data for the two hosts of interest.
These results are from RH's machine and these are from peanut's.
Please report any errors or problems here.
Cheers,
Gary.
RE: I've seen that even/odd
)
It's beginning to look more like data, rather than processor time charging.
(sequence numbers 463 to 472)
RE: The special offcut
)
Thanks
As it happens, both of my Conroe-class hosts, which have been given a steady dose of results from Work Unit's in a portion of one half of one cycle, yesterday downloaded new results at a frequency .05 Hz higher in the same skygrid which were much higher in sequence number--about a full cycle higher!
I did some selective pausing to get CPU times on one or two far ahead of schedule, and, while they can't resolve the "right answer" to anywhere near the precision in which Gary expressed the new parameter set, they do fit right in with RRv7d's curve generation. I also particularly like the fact that adding them in to the lower cycle data does not change RR's output parameter estimates materially:
For Stoll3, peak, variance, average without, then with two next cycle points:
23148, .268, 19205 vs. 23134, .266, 19217
For Stoll4, with one next cycle point added,
24015, .270, 19886 vs. 24006, .270, 19882
Here is the actual data, in the right column order and format for RR. However, if you want RR to consider all points, you will need to falsify some frequency entries so that all you wish to consider together are identical, and still within the same 10-Hz step as the true values.
Stoll4 (Q6600):
freq, seq, cpu, Ein_ver
904.60, 434, 17623.67, 4.32
904.60, 435, 17320.36, 4.32
904.60, 446, 17465.38, 4.32
905.00, 646, 20252.50, 4.32
904.60, 447, 18479.69, 4.32
904.60, 448, 17935.95, 4.32
904.60, 450, 18480.08, 4.32
904.60, 453, 18551.22, 4.32
904.60, 454, 18258.20, 4.32
904.60, 456, 18067.16, 4.32
904.60, 458, 18736.16, 4.32
904.60, 459, 18444.95, 4.32
904.60, 460, 19279.30, 4.32
904.60, 461, 19448.66, 4.32
904.60, 463, 19374.88, 4.32
904.60, 465, 19612.11, 4.32
904.60, 466, 19648.47, 4.32
904.60, 470, 20111.22, 4.32
904.60, 471, 19701.16, 4.32
904.60, 473, 20130.98, 4.32
904.60, 474, 20057.66, 4.32
904.60, 475, 20697.64, 4.32
904.60, 476, 20858.88, 4.32
904.60, 477, 20820.27, 4.32
904.60, 478, 20709.66, 4.32
904.60, 479, 20422.11, 4.32
904.60, 480, 20828.66, 4.32
904.60, 481, 20626.97, 4.32
904.60, 483, 20740.45, 4.32
904.60, 484, 21103.28, 4.32
904.60, 485, 21998.91, 4.32
904.60, 486, 21396.33, 4.32
904.60, 487, 22197.89, 4.32
904.60, 488, 21653.22, 4.32
904.60, 489, 22599.33, 4.32
904.60, 490, 22567.25, 4.32
904.60, 491, 21827.66, 4.32
904.60, 492, 21588.36, 4.32
904.60, 422, 17749.73, 4.32
904.60, 441, 18090.94, 4.32
904.60, 432, 17832.14, 4.32
904.60, 452, 19121.77, 4.32
904.60, 462, 18544.66, 4.32
904.60, 472, 19764.03, 4.32
904.60, 482, 20931.42, 4.32
904.60, 493, 21991.45, 4.32
904.60, 494, 22236.44, 4.32
904.60, 496, 22378.09, 4.32
904.60, 499, 22662.08, 4.32
Stoll3 (E6600)
845.30, 413, 19571.58, 4.32
845.30, 414, 19491.13, 4.32
845.45, 557, 19157.80, 4.32
845.45, 558, 19250.83, 4.32
845.30, 415, 19643.30, 4.32
845.30, 416, 19973.16, 4.32
845.30, 417, 20078.53, 4.32
845.35, 426, 20985.27, 4.32
845.35, 427, 21022.42, 4.32
845.30, 419, 19982.84, 4.32
845.30, 420, 20347.86, 4.32
845.30, 421, 20469.03, 4.32
845.35, 383, 17292.17, 4.32
845.30, 422, 20143.72, 4.32
845.30, 423, 20710.36, 4.32
845.30, 424, 20455.42, 4.32
845.30, 425, 21058.67, 4.32
845.30, 426, 21004.58, 4.32
845.30, 427, 20902.97, 4.32
845.35, 394, 17705.59, 4.32
845.35, 403, 18369.94, 4.32
845.30, 408, 19062.56, 4.32
845.30, 418, 20099.73, 4.32
845.30, 428, 21037.22, 4.32
845.30, 429, 21325.89, 4.32
845.30, 433, 21969.25, 4.32
This is far from "proving the revisions right", but overall suggests that this model is quite useful in the near greater than 800 Hz region currently being distributed.
I've got further into the
)
I've got further into the sequence numbers running three cores instead of four (_421 cached), but at the expense of getting a lot of gaps - so I've just suspended CPDN again, and we're back up to full speed. I'd like to watch those wiggles on the graph: 909.25 is continuing to match 909.15 very closely, wiggle for wiggle.
I checked the logs, and I got a 'server requested file delete' for the bottom pair of data files, when I was switched from .15 to .25: I don't think I'll be going back there any time soon.
Interesting conversation between Peanut and Bernd in the Mac 433 Beta thread - we'll have to see if his amplitude decreases.
I've uploaded the latest data
)
I've uploaded the latest data for the two hosts of interest. Sorry for missing an upload yesterday.
These results are from RH's machine and these are from peanut's.
Please report any errors or problems here.
Cheers,
Gary.
I was going to save up
)
I was going to save up Peanut's chart until my 909.25 run was complete, but it's so pretty I can't resist.
Feast your eyeballs on this:
(direct link)
Data source from Gary's file in previous message.
Omitted: frequencies below 800, mixed app results, sequence numbers outside range plotted, frequencies with very few data points.
Observations:
The wiggles are real.
4.33 is a speed demon.
The cyclic variation is reduced in 4.33 (as Bernd expected), but I think it's still there - just.
There's a disjointedness between 909.75 and 909.95