the `BreakingPoint` tool conducts a binary search to find the ''stress factor'' where a given schedule breaks. There are some known deviations related to the measurement setup, which unfortunately impact the interpretation of the ''stress factor'' scale. Earlier, an attempt was made, to watch those factors empirically and work a ''form factor'' into the ''effective stress factor'' used to guide this measurement method. Closer investigation with extended and elastic load patters now revealed a strong tendency of the Scheduler to scale down the work resources when not fully loaded. This may be mistaken by the above mentioned adjustments as a sign of a structural limiation of the possible concurrency. Thus, as a mitigation, those adjustments are now only performed at the beginning of the measurement series, and also only when the stress factor is high (implying that the scheduler is actually overloaded and thus has no incentive for scaling down). These observations indicate that the »Breaking Point« search must be taken with a grain of salt: Especially when the test load does ''not'' contain a high degree of inter dependencies, it will be ''stretched elastically'' rather than outright broken. And under such circumstances, this measurement actually gauges the Scheduler's ability to comply to an established load and computation goal. |
||
|---|---|---|
| .. | ||
| draw | ||
| DIR_INFO | ||
| dump | ||
| empty.html | ||
| InterfaceConcept_Varga.mm | ||
| renderengine.html | ||
| thinkPad.ichthyo.mm | ||
| uml | ||
| workflow.mm | ||