benn/lumiera_documentation
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Scheduler-test: simple implementation of range coverage

Browse source 
- fill the range randomly with probe points
- use the node count as independent parameter
- measurement method *works as intended*
- results indeed show a linear relationship

Results are ''interesting'' however, since the (par,time) points
seem to be arranged into two lines, implying that about half
of the runs were somehow ''degraded'' and performed way slower.
This commit is contained in:
Fischlurch 2024-02-24 04:17:05 +01:00
parent a117e6e8c5
commit 2556151304
3 changed files with 176 additions and 73 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

58
tests/vault/gear/scheduler-stress-test.cpp
View file

@ -81,8 +81,9 @@ namespace test {
{
//smokeTest();
// setup_systematicSchedule();
search_breaking_point();
// verify_instrumentation();
// search_breaking_point();
watch_expenseFunction();
// investigateWorkProcessing();
walkingDeadline();
}
@ -328,16 +329,22 @@ namespace test {
/** @test TODO determine the breaking point towards scheduler overload
/** @test determine the breaking point towards scheduler overload
* - use the integrated StressRig
* - demonstrate how parameters can be tweaked
* - perform a run, leading to a binary search for the breaking point
* @note on my machine, I observe stress factors close below 0.5, due to the fact
* that the ComputationalLoad typically takes 2 times as long in concurrent
* usage compared to its calibration, which is done in a tight loop. This
* is strange and may well be due to some peculiarity of my system. Which
* also implies that this test's behaviour might be difficult to verify,
* other than by qualitative interpretation of the log output on STDOUT.
* @remark this stress-test setup uses instrumentation internally note to deduce
* some systematic deviations from the theoretically established behaviour.
* For example, on my machine, the ComputationalLoad performs slower within the
* Scheduler environment compared to its calibration, which is done in a tight loop.
* This may be due to internals of the processor, which show up under increased
* contention combined with more frequent cache misses. In a similar vein, the
* actually observed concurrency turns out to be consistently lower than could
* be expected by accounting for the work units in isolation, without considering
* dependency constraints. These observed deviations are cast into an empirical
* »form factor«, which is then used to correct the applied stress factor.
* Only with taking these corrective steps, the observed stress factor at
* _breaking point_ comes close to the theoretically expected value of 1.0
* @see stress-test-rig.hpp
* @todo WIP 1/24 ✔ define ⟶ ✔ implement
*/
@ -363,6 +370,41 @@ namespace test {
/** @test TODO Investigate the relation of run time (expense) to input length.
* @see vault::gear::bench::ParameterRange
* @todo WIP 1/24 🔁 define ⟶ 🔁 implement
*/
void
watch_expenseFunction()
{
ComputationalLoad cpuLoad;
cpuLoad.timeBase = 200us;
cpuLoad.calibrate();
//////////////////////////////////////////////////////////////////TODO for development only
MARK_TEST_FUN
struct Setup : StressRig
{
usec LOAD_BASE = 500us;
uint CONCURRENCY = 4;
bool showRuns = true;
auto testLoad(size_t nodes)
{
TestChainLoad<8> testLoad{nodes};
return testLoad.seedingRule(testLoad.rule().probability(0.6).minVal(2))
.pruningRule(testLoad.rule().probability(0.44))
.weightRule(testLoad.value(1))
.setSeed(55);
}
};
auto results = StressRig::with<Setup>()
.perform<bench::ParameterRange> (2,64);
}
/** @test TODO
* @todo WIP 1/24 🔁 define ⟶ implement
*/

53
tests/vault/gear/stress-test-rig.hpp
View file

@ -93,7 +93,7 @@
#include "lib/meta/function.hpp"
#include "lib/format-string.hpp"
#include "lib/format-cout.hpp"//////////////////////////TODO RLY?
//#include "lib/util.hpp"
#include "lib/util.hpp"
//#include <functional>
#include <utility>
@ -194,9 +194,9 @@ namespace test {
protected:
/** Extension point: build the computation topology for this test */
auto
testLoad()
testLoad(size_t nodes =64)
{
return TestChainLoad<>{64};
return TestChainLoad<>{nodes};
}
/** (optional) extension point: base configuration of the test ScheduleCtx */
@ -431,27 +431,62 @@ namespace test {
class ParameterRange
: public CONF
{
using TestLoad = decltype(declval<ParameterRange>().testLoad());
using TestLoad = decltype(declval<ParameterRange>().testLoad(1));
using TestSetup = decltype(declval<ParameterRange>().testSetup (declval<TestLoad&>()));
template<typename PAR>
using Point = std::pair<PAR, double>;
template<typename PAR>
void
runTest (Point<PAR>& point)
{
PAR param = point.first;
double stressFac = 1.0;
TestLoad testLoad = CONF::testLoad(param).buildTopology();
TestSetup testSetup = CONF::testSetup (testLoad)
.withLoadTimeBase(CONF::LOAD_BASE)
.withBaseExpense (CONF::BASE_EXPENSE)
.withSchedNotify (CONF::SCHED_NOTIFY)
.withSchedDepends(CONF::SCHED_DEPENDS)
.withAdaptedSchedule(stressFac, CONF::CONCURRENCY);
point.second = testSetup.launch_and_wait() / 1000;
cout << "x="<<point.first<<" y="<<point.second<<endl;
}
public:
/**
* Launch a measurement sequence running the Scheduler with a
* varying parameter value to investigate (x,y) correlations.
* @return ////TODO a tuple `[stress-factor, ∅delta, ∅run-time]`
*/
template<typename PAR>
auto
perform()
perform (PAR lower, PAR upper)
{
TRANSIENTLY(work::Config::COMPUTATION_CAPACITY) = CONF::CONCURRENCY;
TestLoad testLoad = CONF::testLoad().buildTopology();
TestSetup testSetup = CONF::testSetup (testLoad);
PAR dist = upper - lower;
uint cnt = CONF::REPETITIONS;
vector<Point<PAR>> results(cnt);
PAR minP{upper}, maxP{lower};
for (uint i=0; i<cnt; ++i)
{
auto random = double(rand())/RAND_MAX;
PAR pos = lower + PAR(floor (random*dist + 0.5));
results[i].first = pos;
minP = min (pos, minP);
maxP = max (pos, maxP);
}
// ensure the bounds participate in test
if (maxP < upper) results[cnt-2].first = upper;
if (minP > lower) results[cnt-1].first = lower;
UNIMPLEMENTED ("parametric runs");
// return make_tuple (res.stressFac, res.avgDelta, res.avgTime);
for (auto& point : results)
runTest (point);
return results;
}
};
//

138
wiki/thinkPad.ichthyo.mm
View file

@ -111146,8 +111146,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
erster Versuch: <i>&#252;berhaupt keinen </i>Graph konstruieren
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<node COLOR="#435e98" CREATED="1707960829288" ID="ID_1851262882" MODIFIED="1707960963715" TEXT="geht das?">
<node CREATED="1707960839374" ID="ID_1245687450" MODIFIED="1707960846370" TEXT="Bauchgef&#xfc;hl sagt: sollte gehen"/>
<node CREATED="1707960847717" ID="ID_185775784" MODIFIED="1707960867598" TEXT="es ist dann topLevel() &#x2261; 0"/>
@ -111176,8 +111175,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
fast alle Threads sind im Contention-wait
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node BACKGROUND_COLOR="#cdc17d" COLOR="#a50125" CREATED="1708021069617" ID="ID_146646167" MODIFIED="1708021356534" TEXT="Wichtiger Umstand: habe Vor-Dimensionierung des IncidenceCount noch nicht implementiert">
<richcontent TYPE="NOTE"><html>
@ -111187,8 +111185,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
das ist zwar ganz klar geplant, aber ich jetzt lasse ich die Tests erst mal so laufen...
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="messagebox_warning"/>
</node>
<node CREATED="1708021150829" ID="ID_841513991" MODIFIED="1708021415380" TEXT="Theorie: der Basis-Vector f&#xfc;r die Threads wird concurrent erweitert">
@ -111199,8 +111196,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
Zwar beobachte ich die Memory-Corruption dann ehr beim Einf&#252;gen der Events, aber das kann sehr wohl ein Folge-Fehler sein. Ich sehe auch anderes Verhalten, das &#8222;eigentlich gar nicht m&#246;glich ist&#8220;
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="idea"/>
<node CREATED="1708021200631" ID="ID_1507367200" MODIFIED="1708021325426" TEXT="das ist nicht threadsafe">
<richcontent TYPE="NOTE"><html>
@ -111210,8 +111206,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
Hier passiert ein Vector-realloc. Wenn w&#228;hrenddessen der n&#228;chste Thread kommt, macht der ebenfalls ein re-Alloc und die Memory-corruption w&#228;re garantiert.
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1708021206366" ID="ID_34842564" MODIFIED="1708021215512" TEXT="eigentlich m&#xfc;&#xdf;te hier ein Mutex verwendet werden"/>
<node CREATED="1708021217380" ID="ID_1094048458" MODIFIED="1708021275576" TEXT="KISS &#x27f9; stattdessen richtig vor-Dimensionieren">
@ -111222,8 +111217,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
Das ist ein Instrumentierungs-Hilfsmittel, und generell nur darauf ausgelegt, &#187;richtig verwendet zu werden&#171;
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
</node>
<node COLOR="#338800" CREATED="1708025327359" ID="ID_461738408" MODIFIED="1708025344662" TEXT="mit Vor-Dimensionierung nicht mehr beobachtet">
@ -111273,8 +111267,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
...waren aber geblockt, solange noch die eigentlichen Jobs mit t=0 in der Queue stehen
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1708029502085" ID="ID_43040367" MODIFIED="1708029516159" TEXT="auch hierf&#xfc;r kommt nur ein Worker zum Zug"/>
<node CREATED="1708029516987" ID="ID_650283156" MODIFIED="1708029523286" TEXT="einige Contention w&#xe4;hrenddessen"/>
@ -111295,8 +111288,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
...und die Selbstreguliertung sorgt schntell daf&#252;r, da&#223; der gr&#246;&#223;te Teil der WorkForce in contention-Wait geht
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1708029641698" ID="ID_1689204888" MODIFIED="1708029653045" TEXT="trotzdem findet noch eine gewisse Parallelisierung statt"/>
</node>
@ -111311,8 +111303,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
zweiter Versuch: <i>unconnected Nodes with weight</i><font size="2">&#160;(500&#181;s)</font>
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<node COLOR="#338800" CREATED="1708033299088" ID="ID_1415838317" MODIFIED="1708033320164" TEXT="hierf&#xfc;r neue setWeight()">
<icon BUILTIN="button_ok"/>
<node CREATED="1708033322701" ID="ID_1244159152" MODIFIED="1708033352875" TEXT="infolge der neuen Einsicht, da&#xdf; keine Topologie notwendig ist"/>
@ -111333,8 +111324,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
das entspricht<b>&#160;exakt</b>&#160;der Concurrency
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1708033977406" ID="ID_1893515841" MODIFIED="1708033994569" TEXT="Planung abgeschlossen bei t=2.8ms"/>
<node CREATED="1708034237043" ID="ID_858054398" MODIFIED="1708034251356" TEXT="binnen 1.3ms sind alle 8 Worker da und haben einen Job &#xfc;bernommen"/>
@ -111357,8 +111347,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
das ist effektiv <b>concurrency &#8801; 6</b>
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="idea"/>
</node>
</node>
@ -111389,8 +111378,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
mit 400 Nodes&#160;&#160;&#10236; real &#8709; 12ms und <b>Concurrency &#8801; 7.9</b>
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<font NAME="SansSerif" SIZE="12"/>
</node>
<node CREATED="1708051327255" ID="ID_695348528" MODIFIED="1708051345087" TEXT="mit 800 Nodes (und l&#xe4;ngerer Dealine): Scheuler l&#xe4;uft f&#xfc;r 1.2 sec"/>
@ -111414,8 +111402,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
...weil keine Festlegung auf eine bestimmte Zahl an Cores m&#246;glich ist und auch die Werte stark statistisch schwanken, besonders bei den relativ kurzen Laufzeiten, die hier aus praktischen Gr&#252;nden erforderlich sind, schon um das Test-Setup einfach zu halten
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
</node>
<node COLOR="#338800" CREATED="1708268252064" ID="ID_1446014590" MODIFIED="1708650315798" TEXT="effektive Concurrency f&#xfc;r StressFac ber&#xfc;cksichtigen">
@ -111431,8 +111418,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
Stichwort: Box stacking. Das ist ein NP-hartes Problem und wir l&#246;sen es hier nicht; vielmehr wird so getan, als k&#246;nnte man um die durchschnittliche Concurrency elastisch stauchen. Das f&#252;hrt dann zum Auftreten eines weiteren &#187;Form-Faktors&#171;, der eben genau darin besteht, zu welchem Grad diese Annahme zu den strukturellen Beschr&#228;nkugeneni im Widerspruch steht.
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1708268487001" ID="ID_1962998809" MODIFIED="1708268499603" TEXT="wird erst w&#xe4;hrend der Messung entdeckt"/>
<node CREATED="1708268571343" ID="ID_1673801414" MODIFIED="1708268584520" TEXT="verschiebt dann das Koordinatensystem der Proze&#xdf;steuerung"/>
@ -111476,8 +111462,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</li>
</ul>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
</node>
<node CREATED="1708270380308" ID="ID_631811144" MODIFIED="1708270582922" TEXT="&#x27f9; &#xd83d;&#xdca1; mehrfach pro Me&#xdf;punkt ausf&#xfc;hren und nachjustieren">
@ -111500,8 +111485,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
Mehraufwand &#10233; bereits ein <i>entsprechend kleinerer </i>Stress-Faktor hat die gleiche Stress-Wirkung
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node COLOR="#338800" CREATED="1708271377036" ID="ID_999482443" MODIFIED="1708273322761" TEXT="es geht ein: nominalConcurr / realConcurr">
<icon BUILTIN="button_ok"/>
@ -111524,8 +111508,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
...das l&#228;&#223;t dann die nominelle Concurrency als integral-Zahl intakt
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="button_ok"/>
</node>
</node>
@ -111603,8 +111586,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
denn das Schedule wird ja auf eine <i>nominelle </i>Concurrency ausgelegt
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1708353549722" ID="ID_739919619" MODIFIED="1708353588560">
<richcontent TYPE="NODE"><html>
@ -111614,8 +111596,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
und diese wird ggfs aus <i>strukturellen Gr&#252;nden </i>nicht ausgesch&#246;pft
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1708353589901" ID="ID_753673138" MODIFIED="1708353635590" TEXT="was dann mithin nicht als Leistungsreserve gedeutet werden darf">
<icon BUILTIN="messagebox_warning"/>
@ -111631,8 +111612,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
...die Berechnung l&#228;uft zwar genauso, n&#228;mlich &#252;ber eine Gruppierung per Level, jedoch m&#252;ssen dann nur die reinen Nodes pro Level ber&#252;cksichtigt werden
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1708357060445" ID="ID_1779085910" MODIFIED="1708357108807" TEXT="mu&#xdf; dabei aber die Gewichte beachten">
<richcontent TYPE="NOTE"><html>
@ -111642,8 +111622,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
weil die Gewichte entsprechend proportional auch in die durchschnittliche empirische Concurrency eingehen
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1708357112590" ID="ID_823184827" MODIFIED="1708357137110" TEXT="Idee: den f&#xfc;r&apos;s Schedule berechneten Level-WeightFactor ins Verh&#xe4;ltnis setzen"/>
<node CREATED="1708357576600" ID="ID_630915220" MODIFIED="1708357610199" TEXT="die Reduktion im Vergleich zur reinen weightSum wird als effektive Concurrency gedeutet"/>
@ -111690,8 +111669,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
ohne starke Abh&#228;ngigkeiten ist durchaus <i>elastisches Verhalten </i>denkbar
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<richcontent TYPE="NOTE"><html>
<head/>
<body>
@ -111699,8 +111677,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
Zwar ist die nun entwickelte Me&#223;methode durchaus elegant, wird aber zunehmend ungenau, wenn es kein klar definiertes &#187;Brechen&#171; mehr gibt, bzw. wenn man nur noch einen numerischen Grenzwert festlegen kann, der dann von den Dimensionen des konketen Falls abh&#228;ngen. F&#252;r das wohldefinierte &#187;Brechen&#171; ist eine komplexe Abh&#228;ngikeitsstruktur notewendig, die durch einen R&#252;ckstau komplett aus der Balance kippt. Das ist dann doch ein sehr spezieller Fall, denn in der Praxis erwarte ich im Durchschnitt ehr viele kleine 2-er und 3-er-Ketten ohne viel Verkn&#252;fpungen (ein IO-Job und ein Render-Job). Und bei l&#228;nger laufenden Berechnungen w&#228;re definitiv zu erwarten (ja sogar zwingend gefordert), da&#223; sich freie Kapazit&#228;t elastisch auf die n&#228;chsten Aufgaben verschieben l&#228;&#223;t.
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1708651570100" ID="ID_1828305401" MODIFIED="1708652227401" TEXT="Setup- und Technologie-Effekte verhindern genaue Untersuchung &#xbb;am Nullpunkt&#xab;">
<richcontent TYPE="NOTE"><html>
@ -111710,8 +111687,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
Der Scheduler ist ein komplexer Mechanismus, und allein das Hochfahren des Worker-Pools, alsauch das Erstellen des initialen Schedule erzeugt einen festen Overhead, der mehr oder weniger unkontrolliert in den Start der Arbeitsphase hineinwirkt. Je nachdem wann und wo der erste Eintrag im Schedule auftaucht, erscheinen zu einem bestimmten Zeitpunkt alle Worker und sorgen erst mal f&#252;r deutlich me&#223;bare Contention-Verz&#246;gerungen. Des Weiteren erzeugt auch die Abh&#228;ngigkeit auf den Wake-up-Job einen erheblichen Overhead, sobald es nicht mehr einen einzigen stringenten Berchnungspfad gibt. Hinzu kommt, da&#223; wir nicht auf einem Realtime-Betriebssystem arbeiten, und die vermutete Basis-Last stark von der Optimierung abh&#228;ngig ist. Und au&#223;erdem hat der Scheduler nun einen speziellen Schutzmechanismus, der den Worker-Pool beim Auftreten von Contention effektiv herunterregelt. All dies zusammen macht eine Beobachtung des &#187;Leerlauf-Aufwandes&#171; sehr schwer...
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1708652230771" ID="ID_10502230" MODIFIED="1708652415101" TEXT="Daher soll versucht werden, ein affin-lineares N&#xe4;herungsmodell aufzustellen">
<richcontent TYPE="NOTE"><html>
@ -111721,8 +111697,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
Nebenbei sollten sich dabei auch nicht-lineare Basis-Effekte zeigen, aber idealerweise sollte das Verhalten ab einem gewissen Punkt linear werden; aus diesem n&#228;herungsweise linearen Verhalten lie&#223;e sich auf theoretischem Weg auch ein hypothetischer / amortisierter Basis-Aufwand ableiten. Die Hoffung ist, da&#223; durch den Abgleich dieser verschiedenen Me&#223;methoden ein klareres Verst&#228;ndnis der Grenzen der Me&#223;anordnung gewonnen werden kann.
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1708652417482" ID="ID_350523685" MODIFIED="1708652439760" TEXT="brauche daf&#xfc;r ein anderes Me&#xdf;werkzeug">
@ -111732,8 +111707,23 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1708652942700" ID="ID_1844757015" MODIFIED="1708652953623" TEXT="soll einen Skalen-Parameter variieren"/>
<node CREATED="1708652954547" ID="ID_650515837" MODIFIED="1708652960989" TEXT="ein Parameter-Bereich wird vorgegeben"/>
<node CREATED="1708652961866" ID="ID_289578111" MODIFIED="1708653011804" TEXT="der Parameter wird f&#xfc;r jeden Me&#xdf;punkt zuf&#xe4;llig gesampelt"/>
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1708653013774" ID="ID_1826883977" MODIFIED="1708653098216" TEXT="(optional) soll aber jeder Me&#xdf;punkt mehrfach laufen k&#xf6;nnen?">
<node COLOR="#5b280f" CREATED="1708653013774" ID="ID_1826883977" MODIFIED="1708738858456" TEXT="(optional) soll aber jeder Me&#xdf;punkt mehrfach laufen k&#xf6;nnen?">
<icon BUILTIN="help"/>
<icon BUILTIN="button_cancel"/>
<node CREATED="1708738769854" ID="ID_1335531875" MODIFIED="1708738775540" TEXT="macht hier keinen Sinn"/>
<node CREATED="1708738776218" ID="ID_1705315845" MODIFIED="1708738811435">
<richcontent TYPE="NODE"><html>
<head>
</head>
<body>
<p>
<i>verschiedene </i>Parameter-Werte f&#252;hren zu besserer statistischer Abdeckung
</p>
</body>
</html>
</richcontent>
</node>
</node>
<node CREATED="1708653109374" ID="ID_1339763043" MODIFIED="1708653120296" TEXT="Ergebnis ist eine (x,y)-Wolke"/>
</node>
@ -111742,7 +111732,8 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node COLOR="#5b280f" CREATED="1708653752832" ID="ID_1837975712" MODIFIED="1708653864446" TEXT="habe mich aber leider komplett auf den einen Testfall eingeschossen">
<icon BUILTIN="stop-sign"/>
</node>
<node COLOR="#5b280f" CREATED="1708653766790" ID="ID_621093180" MODIFIED="1708653855760" TEXT="allein schon die sch&#xf6;ne Schreibweise StressRig::with&lt;Setup&gt;().invocation()">
<node COLOR="#5b280f" CREATED="1708653766790" ID="ID_621093180" MODIFIED="1708738915011" TEXT="allein schon die sch&#xf6;ne Schreibweise StressRig::with&lt;Setup&gt;().invocation()">
<arrowlink COLOR="#725346" DESTINATION="ID_765627090" ENDARROW="Default" ENDINCLINATION="177;0;" ID="Arrow_ID_1910232991" STARTARROW="None" STARTINCLINATION="140;5;"/>
<icon BUILTIN="smily_bad"/>
</node>
</node>
@ -111750,9 +111741,10 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1708652910217" ID="ID_1065173939" MODIFIED="1708652910217" TEXT="m&#xfc;ssen hier jedes mal das Grund-Setup neu bauen k&#xf6;nnen"/>
<node CREATED="1708652911961" ID="ID_151694383" MODIFIED="1708653217715" TEXT="braucht vermutlich mehr Offenheit/Flexibilit&#xe4;t"/>
<node CREATED="1708653266575" ID="ID_974267734" MODIFIED="1708653290547" TEXT="sowohl f&#xfc;r den Parameter, alsauch f&#xfc;r den Beobachtungswert"/>
<node CREATED="1708704390490" ID="ID_1955311779" MODIFIED="1708704482518" TEXT="erscheint l&#xf6;sbar">
<node COLOR="#338800" CREATED="1708704390490" ID="ID_1955311779" MODIFIED="1708738756134" TEXT="erscheint l&#xf6;sbar">
<icon BUILTIN="button_ok"/>
<node CREATED="1708704485480" ID="ID_1418959649" MODIFIED="1708704532222" TEXT="mu&#xdf; &#x201e;lediglich&#x201c; die Builder-Notation auf das konrete TOOL parametrisieren"/>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#0f1269" CREATED="1708704444553" ID="ID_765627090" MODIFIED="1708704513327" STYLE="bubble">
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#0f1269" CREATED="1708704444553" ID="ID_765627090" MODIFIED="1708738903548" STYLE="bubble">
<richcontent TYPE="NODE"><html>
<head/>
<body>
@ -111764,10 +111756,45 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</p>
</body>
</html></richcontent>
<linktarget COLOR="#725346" DESTINATION="ID_765627090" ENDARROW="Default" ENDINCLINATION="177;0;" ID="Arrow_ID_1910232991" SOURCE="ID_621093180" STARTARROW="None" STARTINCLINATION="140;5;"/>
<icon BUILTIN="idea"/>
</node>
</node>
</node>
<node CREATED="1708738935308" ID="ID_762477739" MODIFIED="1708738938240" TEXT="Parameter">
<node CREATED="1708738939092" ID="ID_1336682025" MODIFIED="1708738949919" TEXT="REPETITIONS : meint hier die Zahl der Me&#xdf;l&#xe4;ufe"/>
<node CREATED="1708738958993" ID="ID_366857603" MODIFIED="1708739018813" TEXT="lower, upper : Grenzen des Parameterbereichs"/>
<node CREATED="1708744051168" ID="ID_832742285" MODIFIED="1708744058443" TEXT="Typ des Parameters als Template PAR"/>
</node>
<node CREATED="1708743962212" ID="ID_1501901450" MODIFIED="1708743996092" TEXT="Result-Vector...">
<node CREATED="1708743998321" ID="ID_1433691531" MODIFIED="1708744007997" TEXT="mit zuf&#xe4;lligen Me&#xdf;punkten f&#xfc;llen">
<node CREATED="1708744023987" ID="ID_1484783314" MODIFIED="1708744039517" TEXT="vorsicht rand() &#x27fc; int"/>
<node CREATED="1708744039986" ID="ID_699704031" MODIFIED="1708744044277" TEXT="besser mit double rechnen"/>
</node>
<node CREATED="1708744009942" ID="ID_1661435132" MODIFIED="1708744019908" TEXT="sicherstellen da&#xdf; die Grenzpunkte mit dabei sind"/>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1708744078861" ID="ID_1023448351" MODIFIED="1708744085468" TEXT="Integration / Untersuchungen">
<icon BUILTIN="pencil"/>
<node CREATED="1708744086675" ID="ID_551606292" MODIFIED="1708744105373" TEXT="erster Me&#xdf;lauf">
<node CREATED="1708744106371" ID="ID_508772586" MODIFIED="1708744111228" TEXT="20 Punkte 2...64"/>
<node CREATED="1708744112098" ID="ID_179043543" MODIFIED="1708744119235" TEXT="Parameter: ist Anzahl Nodes"/>
<node CREATED="1708744120246" ID="ID_490758949" MODIFIED="1708744134224" TEXT="verwende den massiv breiten Graph mit kurzen Ketten"/>
<node COLOR="#338800" CREATED="1708744344761" ID="ID_318922479" MODIFIED="1708744354075" TEXT="zun&#xe4;chst einmal: Me&#xdf;methode funktioniert">
<icon BUILTIN="button_ok"/>
</node>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1708744139244" ID="ID_955581717" MODIFIED="1708744366315" TEXT="Ergebnis ist &#xbb;interessant&#xab;">
<icon BUILTIN="smiley-oh"/>
<node CREATED="1708744149859" ID="ID_1536683924" MODIFIED="1708744164463" TEXT="es zeigt sich grunds&#xe4;tzlich eine lineare Korrelation"/>
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1708744165001" ID="ID_310456345" MODIFIED="1708744332819" TEXT="aber die Punkt-Wolke zeigt deutlich zwei Linien">
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1708744191606" ID="ID_1135040835" MODIFIED="1708744219397" TEXT="die obere Linie stammt von &#xbb;Langl&#xe4;ufern&#xab;"/>
<node CREATED="1708744220396" ID="ID_1711428581" MODIFIED="1708744297061" TEXT="die untere Linie schneidet die Ordinate bei ca 2.5ms"/>
<node CREATED="1708744308614" ID="ID_347796665" MODIFIED="1708744319296" TEXT="beide Linien treten &#xfc;ber nahezu den ganzen Bereich auf"/>
<node CREATED="1708744320979" ID="ID_382078009" MODIFIED="1708744327943" TEXT="beide Linien sind sehr gut parallel"/>
</node>
</node>
</node>
</node>
</node>
@ -112178,8 +112205,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
das beobachte ich mit dem DUMP-Logging immer wieder. Und zwar ohne eine ausgepr&#228;gte Contention-Spitze. Nach dem Absetzen des letzten regul&#228;ren Node-Jobs sieht man das Log vom Continuation-Aufruf, dann lang nichts, dann die Sequenz der dependencies.
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="help"/>
<node CREATED="1708047710359" ID="ID_1233103402" MODIFIED="1708047732392" TEXT="Beobachtung: davon gehen ~2ms in buildTerm()"/>
</node>