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

Scheduler-test: consider using a complementary measurement method

Browse source 
With the latest improvements, the »breaking point search« works as expected
and yields meaningful data; however — it seems to be well suited rather
for specific setups, which involve an extended graph with massive dependencies,
because only such a setup produces a clearly defined ''breaking point.''

Thus I'm considering to complement this research by another measurement setup
to establish a linear regression model of the Scheduler expense.

To allow integration of this different setup into the existing stress-test-rig,
some rearrangements of the builder notation are necessary; especially we need
to pass the type name of the actual tool, and it seems indicated to
reorder the source code to provide the config base class `StressRig`
at the top, followed by a long (and very technical) implementation
namespace.
This commit is contained in:
Fischlurch 2024-02-23 03:04:24 +01:00
parent 93729e5667
commit a117e6e8c5
3 changed files with 313 additions and 185 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -355,7 +355,8 @@ namespace test {
auto testLoad() { return TestChainLoad<>{64}.configureShape_chain_loadBursts(); }
};
auto [stress,delta,time] = StressRig::with<Setup>().searchBreakingPoint();
auto [stress,delta,time] = StressRig::with<Setup>()
.perform<bench::BreakingPoint>();
CHECK (delta > 2.5);
CHECK (1.15 > stress and stress > 0.9);
}
@ -429,7 +430,8 @@ SHOW_EXPR(loadMicros)
return testLoad;
}
};
auto [stress,delta,time] = StressRig::with<Setup>().searchBreakingPoint();
auto [stress,delta,time] = StressRig::with<Setup>()
.perform<bench::BreakingPoint>();
SHOW_EXPR(stress)
SHOW_EXPR(delta)
SHOW_EXPR(time)

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

@ -64,6 +64,13 @@
** which is 2 times the basic failure indicator.
**
** ## Observation tools
** As a complement to the bench::BreakingPoint tool, another tool is provided to
** run a specific Scheduler setup while varying a single control parameter within
** defined limits. This produces a set of (x,y) data, which can be used to search
** for correlations or build a linear regression model to describe the Scheduler's
** behaviour as function of the control parameter. The typical use case would be
** to use the input length (number of Jobs) as control parameter, leading to a
** model for the Scheduler's expense.
**
** @see TestChainLoad_test
** @see SchedulerStress_test
@ -132,18 +139,106 @@ namespace test {
}
namespace stress_test_rig {
/** configurable template framework for running Scheduler Stress tests */
class StressRig
: util::NonCopyable
{
public:
/***********************************************************************//**
* Entrance Point: build a stress test measurement setup using a dedicated
* \a TOOL class, takes the configuration \a CONF as template parameter
* and which is assumed to inherit (indirectly) from StressRig.
* @tparam CONF specialised subclass of StressRig with customisation
* @return a builder to configure and then launch the actual test
*/
template<class CONF>
static auto
with()
{
return Launcher<CONF>{};
}
/* ======= default configuration (inherited) ======= */
using usec = std::chrono::microseconds;
usec LOAD_BASE = 500us;
usec BASE_EXPENSE = 0us;
bool SCHED_NOTIFY = true;
bool SCHED_DEPENDS = false;
uint CONCURRENCY = work::Config::getDefaultComputationCapacity();
bool INSTRUMENTATION = true;
double EPSILON = 0.01; ///< error bound to abort binary search
double UPPER_STRESS = 0.6; ///< starting point for the upper limit, likely to fail
double FAIL_LIMIT = 2.0; ///< delta-limit when to count a run as failure
double TRIGGER_FAIL = 0.55; ///< %-fact: criterion-1 failures above this rate
double TRIGGER_SDEV = FAIL_LIMIT; ///< in ms : criterion-2 standard derivation
double TRIGGER_DELTA = 2*FAIL_LIMIT; ///< in ms : criterion-3 average delta above this limit
bool showRuns = false; ///< print a line for each individual run
bool showStep = true; ///< print a line for each binary search step
bool showRes = true; ///< print result data
bool showRef = true; ///< calculate single threaded reference time
static uint constexpr REPETITIONS{20};
BlockFlowAlloc bFlow{};
EngineObserver watch{};
Scheduler scheduler{bFlow, watch};
protected:
/** Extension point: build the computation topology for this test */
auto
testLoad()
{
return TestChainLoad<>{64};
}
/** (optional) extension point: base configuration of the test ScheduleCtx */
template<class TL>
auto
testSetup (TL& testLoad)
{
return testLoad.setupSchedule(scheduler)
.withJobDeadline(100ms)
.withUpfrontPlanning();
}
template<class CONF>
struct Launcher : CONF
{
template<template<class> class TOOL, typename...ARGS>
auto
perform (ARGS&& ...args)
{
return TOOL<CONF>{}.perform (std::forward<ARGS> (args)...);
}
};
};
namespace bench { ///< Specialised tools to investigate scheduler performance
/**
using std::declval;
/**************************************************//**
* Specific stress test scheme to determine the
* »breaking point« where the Scheduler starts to slip
*/
template<class CONF>
class BreakingPointBench
: CONF
class BreakingPoint
: public CONF
{
using TestLoad = decltype(std::declval<CONF>().testLoad());
using TestSetup = decltype(std::declval<CONF>().testSetup (std::declval<TestLoad&>()));
using TestLoad = decltype(declval<BreakingPoint>().testLoad());
using TestSetup = decltype(declval<BreakingPoint>().testSetup (declval<TestLoad&>()));
struct Res
{
@ -301,7 +396,7 @@ namespace test {
* @return a tuple `[stress-factor, ∅delta, ∅run-time]`
*/
auto
searchBreakingPoint()
perform()
{
TRANSIENTLY(work::Config::COMPUTATION_CAPACITY) = CONF::CONCURRENCY;
@ -323,73 +418,43 @@ namespace test {
return make_tuple (res.stressFac, res.avgDelta, res.avgTime);
}
};
}//namespace stress_test_rig
/** configurable template for running Scheduler Stress tests */
class StressRig
: util::NonCopyable
{
public:
using usec = std::chrono::microseconds;
usec LOAD_BASE = 500us;
usec BASE_EXPENSE = 0us;
bool SCHED_NOTIFY = true;
bool SCHED_DEPENDS = false;
uint CONCURRENCY = work::Config::getDefaultComputationCapacity();
bool INSTRUMENTATION = true;
double EPSILON = 0.01; ///< error bound to abort binary search
double UPPER_STRESS = 0.6; ///< starting point for the upper limit, likely to fail
double FAIL_LIMIT = 2.0; ///< delta-limit when to count a run as failure
double TRIGGER_FAIL = 0.55; ///< %-fact: criterion-1 failures above this rate
double TRIGGER_SDEV = FAIL_LIMIT; ///< in ms : criterion-2 standard derivation
double TRIGGER_DELTA = 2*FAIL_LIMIT; ///< in ms : criterion-3 average delta above this limit
bool showRuns = false; ///< print a line for each individual run
bool showStep = true; ///< print a line for each binary search step
bool showRes = true; ///< print result data
bool showRef = true; ///< calculate single threaded reference time
static uint constexpr REPETITIONS{20};
BlockFlowAlloc bFlow{};
EngineObserver watch{};
Scheduler scheduler{bFlow, watch};
/** Extension point: build the computation topology for this test */
auto
testLoad()
{
return TestChainLoad<>{64};
}
/** (optional) extension point: base configuration of the test ScheduleCtx */
template<class TL>
auto
testSetup (TL& testLoad)
{
return testLoad.setupSchedule(scheduler)
.withJobDeadline(100ms)
.withUpfrontPlanning();
}
/**
* Entrance Point: build a stress test measurement setup
* to determine the »breaking point« where the Scheduler is unable
* to keep up with the defined schedule.
* @tparam CONF specialised subclass of StressRig with customisation
* @return a builder to configure and then launch the actual test
*/
template<class CONF>
static auto
with()
{
return stress_test_rig::BreakingPointBench<CONF>{};
}
};
}}} // namespace vault::gear::test
/**************************************************//**
* Specific test scheme to perform a Scheduler setup
* over a given control parameter range to determine
* correlations
*/
template<class CONF>
class ParameterRange
: public CONF
{
using TestLoad = decltype(declval<ParameterRange>().testLoad());
using TestSetup = decltype(declval<ParameterRange>().testSetup (declval<TestLoad&>()));
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]`
*/
auto
perform()
{
TRANSIENTLY(work::Config::COMPUTATION_CAPACITY) = CONF::CONCURRENCY;
TestLoad testLoad = CONF::testLoad().buildTopology();
TestSetup testSetup = CONF::testSetup (testLoad);
UNIMPLEMENTED ("parametric runs");
// return make_tuple (res.stressFac, res.avgDelta, res.avgTime);
}
};
//
}// namespace bench
}}}// namespace vault::gear::test
#endif /*VAULT_GEAR_TEST_STRESS_TEST_RIG_H*/

275
wiki/thinkPad.ichthyo.mm
View file

@ -140,9 +140,7 @@
<icon BUILTIN="button_ok"/>
<node CREATED="1481332855167" ID="ID_362694314" MODIFIED="1557498707215">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
<font color="#cf1445">AUA</font>: Henne oder Ei?
@ -152,9 +150,7 @@
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1481332888362" ID="ID_85978592" MODIFIED="1576282358165" TEXT="Nexus braucht CoreService braucht Nexus...">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
denn:
@ -176,9 +172,7 @@
<icon BUILTIN="button_ok"/>
<node CREATED="1481338222672" ID="ID_318056010" MODIFIED="1576282358165" TEXT="Bus-Term greift tats&#xe4;chlich nicht auf Uplink zu">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
gemeint ist: im ctor
@ -198,9 +192,7 @@
<node CREATED="1481338237550" ID="ID_781727426" MODIFIED="1557498707215" TEXT="kann also eine Referenz auf lokalen Speicher reinreichen"/>
<node CREATED="1481338295614" ID="ID_1811061645" MODIFIED="1576282358164" TEXT="Folglich mu&#xdf; Nexus lokal in CoreServices angesiedelt werden">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
oder anders herum,
@ -53506,9 +53498,7 @@
<node CREATED="1489717927279" ID="ID_845301501" MODIFIED="1489717959263" TEXT="Command-ID erf&#xfc;llt keine regulierende Funktion"/>
<node CREATED="1491003369611" ID="ID_854080320" MODIFIED="1576282357979" TEXT="Instanz-Management funktioniert anonym">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...weil es zu jedem InvocationPath
@ -53527,9 +53517,7 @@
</node>
<node CREATED="1489546998918" HGAP="43" ID="ID_668687712" MODIFIED="1576282357978" TEXT="Aktivierung">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
gemeint ist:
@ -53566,9 +53554,7 @@
</node>
<node CREATED="1489547112255" ID="ID_270498008" MODIFIED="1576282357978" TEXT="generische Rollen">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
die Idee ist hier,
@ -53612,9 +53598,7 @@
<icon BUILTIN="closed"/>
<node CREATED="1489719257426" ID="ID_1618753270" MODIFIED="1576282357977" TEXT="wer erzeugt den InvocationTrail">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...eben!
@ -53736,9 +53720,7 @@
<node CREATED="1489786245024" ID="ID_430222749" MODIFIED="1489786255810" TEXT="alle Definitionen in Makros einwickeln"/>
<node CREATED="1489786393908" ID="ID_1345826013" MODIFIED="1576282357977" TEXT="spezielle Inclusion-Rituale">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
vermutlich l&#228;uft es immer darauf hinaus
@ -53844,9 +53826,7 @@
<icon BUILTIN="button_cancel"/>
<node CREATED="1490986345879" ID="ID_1736956933" MODIFIED="1576282357976" TEXT="denn: Dispatch bedeutet Verz&#xf6;gerung">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...also ist eine Instanz durchaus noch am Leben,
@ -53863,9 +53843,7 @@
</node>
<node CREATED="1490986336425" ID="ID_1955343463" MODIFIED="1576282357976" TEXT="Konsequenz: leerer Eintrag">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...damit die Nummer erhalten bleibt
@ -110670,7 +110648,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1704502966511" ID="ID_1561993195" MODIFIED="1704502993624" TEXT="wird aber danach wieder rasch aufgefangen, wenn gen&#xfc;gend &#xbb;Luft&#xab; im Schedule ist"/>
<node CREATED="1704503002882" ID="ID_893513147" MODIFIED="1704503021717" TEXT="&#x27f9; &#xdc;berlastung zeigt sich indem diese Fluktuationen &#xbb;durchschlagen&#xab;"/>
</node>
<node CREATED="1704503038702" ID="ID_1005585769" MODIFIED="1704503122646">
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1704503038702" ID="ID_1005585769" MODIFIED="1708650795076">
<richcontent TYPE="NODE"><html>
<head/>
<body>
@ -110730,6 +110708,18 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="button_cancel"/>
</node>
</node>
<node COLOR="#338800" CREATED="1708650675029" ID="ID_582492163" MODIFIED="1708650807596" TEXT="durch Beobachten und korrigieren um situative Faktoren &#xd83e;&#xdc32; nahe 1.0">
<arrowlink COLOR="#3895bf" DESTINATION="ID_3066237" ENDARROW="Default" ENDINCLINATION="-1136;-1018;" ID="Arrow_ID_1263603979" STARTARROW="None" STARTINCLINATION="1149;47;"/>
<icon BUILTIN="button_ok"/>
</node>
</node>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1708651041802" ID="ID_493702418" MODIFIED="1708651197464" TEXT="auch mit verschiedensten Lastszenarien ist die Job-Zeit erh&#xf6;ht">
<arrowlink COLOR="#9455c4" DESTINATION="ID_638536593" ENDARROW="Default" ENDINCLINATION="-678;-86;" ID="Arrow_ID_365229383" STARTARROW="None" STARTINCLINATION="344;16;"/>
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1708651212948" ID="ID_411081941" MODIFIED="1708651228445" TEXT="einzeln gemessen stimmt die Kalibrierung aber auch unter Concurrency"/>
<node BACKGROUND_COLOR="#e0baaa" COLOR="#690f14" CREATED="1708651230201" HGAP="43" ID="ID_1820970520" LINK="#ID_1084113416" MODIFIED="1708651320917" TEXT="Komplexer Ablauf &#x2014; Detail-Untersuchungen zwingend erforderlich" VSHIFT="-16">
<icon BUILTIN="yes"/>
</node>
</node>
<node CREATED="1704677622809" ID="ID_276645813" MODIFIED="1704680965552">
<richcontent TYPE="NODE"><html>
@ -110965,8 +110955,8 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="stop-sign"/>
</node>
</node>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1707697757045" ID="ID_1084113416" MODIFIED="1707954709271" TEXT="Instrumentierung im Job &#x27fc; effektive Concurrenvcy">
<icon BUILTIN="pencil"/>
<node COLOR="#338800" CREATED="1707697757045" ID="ID_1084113416" MODIFIED="1708651346551" TEXT="Instrumentierung im Job &#x27fc; effektive Concurrenvcy">
<icon BUILTIN="button_ok"/>
<node CREATED="1707753850583" ID="ID_974443691" MODIFIED="1707753886880" TEXT="beide Instrumentierungen kann man hier gemeinsam machen">
<icon BUILTIN="idea"/>
</node>
@ -111115,8 +111105,8 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1707755101530" ID="ID_219913539" MODIFIED="1707954714696" TEXT="Integration">
<icon BUILTIN="pencil"/>
<node COLOR="#338800" CREATED="1707755101530" ID="ID_219913539" MODIFIED="1708650524009" TEXT="Integration">
<icon BUILTIN="button_ok"/>
<node COLOR="#338800" CREATED="1707755106784" ID="ID_1004950823" MODIFIED="1707960767740" TEXT="neue Flag schaltbar machen">
<icon BUILTIN="button_ok"/>
<node CREATED="1707755159128" ID="ID_159603961" MODIFIED="1707755173776" TEXT="kann der smart-ptr selber sein">
@ -111150,9 +111140,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node CREATED="1707960810363" ID="ID_1898538089" MODIFIED="1707960828231">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
erster Versuch: <i>&#252;berhaupt keinen </i>Graph konstruieren
@ -111182,9 +111170,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1708020942683" ID="ID_1311204177" MODIFIED="1708021017716" TEXT="passiert irgendwo in den Workern"/>
<node CREATED="1708021019319" ID="ID_933251621" MODIFIED="1708021051197" TEXT="Callstacks lassen auf heftige Contention schlie&#xdf;en">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
fast alle Threads sind im Contention-wait
@ -111195,9 +111181,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</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>
<head>
</head>
<head/>
<body>
<p>
das ist zwar ganz klar geplant, aber ich jetzt lasse ich die Tests erst mal so laufen...
@ -111209,9 +111193,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node CREATED="1708021150829" ID="ID_841513991" MODIFIED="1708021415380" TEXT="Theorie: der Basis-Vector f&#xfc;r die Threads wird concurrent erweitert">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
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;
@ -111222,9 +111204,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="idea"/>
<node CREATED="1708021200631" ID="ID_1507367200" MODIFIED="1708021325426" TEXT="das ist nicht threadsafe">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
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.
@ -111236,9 +111216,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<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">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
Das ist ein Instrumentierungs-Hilfsmittel, und generell nur darauf ausgelegt, &#187;richtig verwendet zu werden&#171;
@ -111289,9 +111267,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1708029441269" ID="ID_188822401" MODIFIED="1708029458039" TEXT="werden alle Notification-Jobs aktivierbar"/>
<node CREATED="1708029458939" ID="ID_1665382552" MODIFIED="1708029498911" TEXT="(sie liegen dann schon in der Vergangenheit)">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...waren aber geblockt, solange noch die eigentlichen Jobs mit t=0 in der Queue stehen
@ -111313,9 +111289,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1708029738565" ID="ID_1641558536" MODIFIED="1708029756350" TEXT="w&#xe4;hrend der Organisations-Arbeit blockt das GroomingToken"/>
<node CREATED="1708029627922" ID="ID_242925751" MODIFIED="1708029790131" TEXT="der Scheduler ist nicht auf Contention ausgelegt">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...und die Selbstreguliertung sorgt schntell daf&#252;r, da&#223; der gr&#246;&#223;te Teil der WorkForce in contention-Wait geht
@ -111331,9 +111305,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node CREATED="1708029837603" ID="ID_641612793" MODIFIED="1708033285779">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
zweiter Versuch: <i>unconnected Nodes with weight</i><font size="2">&#160;(500&#181;s)</font>
@ -111355,9 +111327,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1708033541160" ID="ID_716582623" MODIFIED="1708033567799" TEXT="coveredTime 5.118ms"/>
<node CREATED="1708033575180" ID="ID_1360284834" MODIFIED="1708033591128">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
das entspricht<b>&#160;exakt</b>&#160;der Concurrency
@ -111381,9 +111351,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node CREATED="1708034908809" ID="ID_1836121465" MODIFIED="1708034936555">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
das ist effektiv <b>concurrency &#8801; 6</b>
@ -111409,13 +111377,13 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node CREATED="1708050404196" ID="ID_951934036" MODIFIED="1708050408863" TEXT="weitere Experimente">
<node CREATED="1708050412751" ID="ID_638536593" MODIFIED="1708050422134" TEXT="l&#xe4;ngere Node-Zeiten">
<linktarget COLOR="#9455c4" DESTINATION="ID_638536593" ENDARROW="Default" ENDINCLINATION="-678;-86;" ID="Arrow_ID_365229383" SOURCE="ID_493702418" STARTARROW="None" STARTINCLINATION="344;16;"/>
<icon BUILTIN="list"/>
<node CREATED="1708050425513" ID="ID_567927785" MODIFIED="1708050453145" TEXT="5ms &#x27fc; real &#x2205; 6ms"/>
<node CREATED="1708050458589" ID="ID_1695942732" MODIFIED="1708050467855" TEXT="10ms &#x27fc; real &#x2205; 11ms"/>
<node CREATED="1708050481797" ID="ID_1497974818" MODIFIED="1708050641215">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
mit 400 Nodes&#160;&#160;&#10236; real &#8709; 12ms und <b>Concurrency &#8801; 7.9</b>
@ -111440,9 +111408,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1708202940088" ID="ID_1078042444" MODIFIED="1708202953985" TEXT="kann zumindest einen einfachen Scheduler-Lauf machen"/>
<node CREATED="1708202954868" ID="ID_575048126" MODIFIED="1708203062489" TEXT="kann dann aber nicht sonderlich viel verifizieren">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...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
@ -111452,16 +111418,14 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</richcontent>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1708268252064" ID="ID_1446014590" MODIFIED="1708268303222" TEXT="effektive Concurrency f&#xfc;r StressFac ber&#xfc;cksichtigen">
<icon BUILTIN="flag-yellow"/>
<node COLOR="#338800" CREATED="1708268252064" ID="ID_1446014590" MODIFIED="1708650315798" TEXT="effektive Concurrency f&#xfc;r StressFac ber&#xfc;cksichtigen">
<icon BUILTIN="button_ok"/>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1708268310664" ID="ID_1275839146" MODIFIED="1708268330317" TEXT="problematisch...">
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1708268331813" ID="ID_1488193496" MODIFIED="1708268351974" TEXT="ist ein Durchschnittswert"/>
<node CREATED="1708268352561" ID="ID_499399388" MODIFIED="1708268481369" TEXT="nicht genau bekannt, wie sie wirkt">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
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.
@ -111486,9 +111450,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1708269678586" ID="ID_1258803425" MODIFIED="1708269778784" TEXT="Ergebnis l&#xe4;ge dann am Rand des Intervalls &#x27f9; m&#xf6;glicherweise grob falsch"/>
<node CREATED="1708269787930" ID="ID_1448332820" MODIFIED="1708270312970" TEXT="das ist sowiso bereits ein Problem in der Praxis (statistische Fluktuationen)">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
da wir die &#220;berschreitung einer Grenze beobachten, kann bereits ein zuf&#228;lliger &quot;outlier&quot; den Suchmechanismus in ein falsches Intervall &#8222;abbiegen lassen&#8220;. Denn eine einmal etablierte Intervall-Grenze wird grunds&#228;tzlich nicht nochmal gepr&#252;ft. Ich hatte deswegen regelm&#228;&#223;ig grob daneben liegende Ergebnisse beobachtet. Ein typisches Beispiel
@ -111532,9 +111494,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1708271149076" ID="ID_1320464252" MODIFIED="1708271223063" TEXT="dieser enth&#xe4;lt zus&#xe4;tzlich zu ber&#xfc;cksichtigenden Aufwand"/>
<node CREATED="1708271225458" ID="ID_1722094971" MODIFIED="1708271352966" TEXT="d.h es wird der stressFac dadurch geteilt">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
Mehraufwand &#10233; bereits ein <i>entsprechend kleinerer </i>Stress-Faktor hat die gleiche Stress-Wirkung
@ -111558,9 +111518,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node COLOR="#338800" CREATED="1708271748403" ID="ID_979134538" MODIFIED="1708272179424" TEXT="formFac besser als Zusatz-Parameter in adaptedSchedule()">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...das l&#228;&#223;t dann die nominelle Concurrency als integral-Zahl intakt
@ -111578,7 +111536,8 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1708275070790" ID="ID_989990379" MODIFIED="1708275106286" TEXT="Konsequenz: Anpassung des Schedule sollte graduell konvergieren"/>
</node>
</node>
<node CREATED="1708295682057" ID="ID_1692984155" MODIFIED="1708295686540" TEXT="Verhalten im Test">
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1708295682057" ID="ID_1692984155" MODIFIED="1708650309261" TEXT="Verhalten im Test">
<icon BUILTIN="list"/>
<node COLOR="#435e98" CREATED="1708295760082" ID="ID_1240131502" MODIFIED="1708295777613" TEXT="kumulierte Statistik nicht ber&#xfc;cksichtigt">
<icon BUILTIN="broken-line"/>
<node CREATED="1708295779333" ID="ID_34626875" MODIFIED="1708295812603" TEXT="Zeit und Summen werden ja nicht zur&#xfc;ckgesetzt"/>
@ -111638,9 +111597,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1708353529389" ID="ID_1264074130" MODIFIED="1708353581342">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
denn das Schedule wird ja auf eine <i>nominelle </i>Concurrency ausgelegt
@ -111651,9 +111608,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node CREATED="1708353549722" ID="ID_739919619" MODIFIED="1708353588560">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
und diese wird ggfs aus <i>strukturellen Gr&#252;nden </i>nicht ausgesch&#246;pft
@ -111670,9 +111625,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1708355316244" ID="ID_1132423890" MODIFIED="1708355357499" TEXT="l&#xe4;uft auf eine Berechnung hinaus analog zum Schedule"/>
<node CREATED="1708355455934" ID="ID_1644260527" MODIFIED="1708355549750" TEXT="mu&#xdf; es aber from scratch berechnen">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...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
@ -111683,9 +111636,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node CREATED="1708357060445" ID="ID_1779085910" MODIFIED="1708357108807" TEXT="mu&#xdf; dabei aber die Gewichte beachten">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
weil die Gewichte entsprechend proportional auch in die durchschnittliche empirische Concurrency eingehen
@ -111700,9 +111651,121 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node COLOR="#338800" CREATED="1708359933075" ID="ID_559935495" MODIFIED="1708359945343" TEXT="nur die Abweichung von der erwarteten Concurrency in den Form-Faktor">
<icon BUILTIN="button_ok"/>
</node>
<node COLOR="#435e98" CREATED="1708650329163" ID="ID_489815369" MODIFIED="1708650505361" TEXT="Reflexion; das ist auch logisch sinnvoll">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...denn es ist tats&#228;chlich sowas wie ein &#187;Form-Faktor&#171;, ergibt sich also aus der konkreten Dependency-Struktur und der konkreten Scheduling-Situation. Umso besser, da&#223; dieser Wert sich auch nur leicht vom &#187;Druck&#171; abh&#228;ngig erweist; es ist also <i>etwas Situatives, </i>und insofern arbeitet der &#187;Stre&#223;&#171; relativ dazu
</p>
</body>
</html></richcontent>
<icon BUILTIN="yes"/>
</node>
</node>
<node COLOR="#338800" CREATED="1708359949377" ID="ID_3066237" MODIFIED="1708359973277" TEXT="damit kommt ein Stre&#xdf;-Faktor ganz nah an 1 heraus!!">
<linktarget COLOR="#3895bf" DESTINATION="ID_3066237" ENDARROW="Default" ENDINCLINATION="-1136;-1018;" ID="Arrow_ID_1263603979" SOURCE="ID_582492163" STARTARROW="None" STARTINCLINATION="1149;47;"/>
<icon BUILTIN="ksmiletris"/>
<node CREATED="1708650176871" ID="ID_1138728780" MODIFIED="1708650184954" TEXT="mehrere gute Indikatoren..."/>
<node CREATED="1708650185842" ID="ID_1126166801" MODIFIED="1708650232171" TEXT="die Abweichung der Job-Zeiten ist (bis auf statistische Schwankunen) sehr konsistent"/>
<node CREATED="1708650238320" ID="ID_1511620555" MODIFIED="1708650269982" TEXT="die tats&#xe4;chliche Concurrency is ebenfalls nahezu stabil (1.25 vs 2 etwartet)"/>
<node CREATED="1708650271826" ID="ID_1697336474" MODIFIED="1708650283604" TEXT="unter Druck nimmt die Concurrency ganz leicht zu"/>
</node>
</node>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1708651353088" ID="ID_9850721" MODIFIED="1708651367397" TEXT="erg&#xe4;nzende Me&#xdf;methode : lineare Regression">
<icon BUILTIN="flag-yellow"/>
<node CREATED="1708651381229" ID="ID_34422716" MODIFIED="1708651432845" TEXT="Ansatz: Verhaltesmuster durch anderen Me&#xdf;-Ansatz best&#xe4;tigen">
<icon BUILTIN="idea"/>
<node CREATED="1708651455035" ID="ID_154910298" MODIFIED="1708651476794" TEXT="das Kriterium &#xbb;Schedule gebrochen&#xab; ist sehr spezifisch">
<icon BUILTIN="messagebox_warning"/>
</node>
<node CREATED="1708651478703" ID="ID_464008145" MODIFIED="1708651910901">
<richcontent TYPE="NODE"><html>
<head/>
<body>
<p>
ohne starke Abh&#228;ngigkeiten ist durchaus <i>elastisches Verhalten </i>denkbar
</p>
</body>
</html>
</richcontent>
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
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>
</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>
<head/>
<body>
<p>
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>
</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>
<head/>
<body>
<p>
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>
</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">
<icon BUILTIN="yes"/>
<node CREATED="1708652645156" ID="ID_1558350785" MODIFIED="1708652664818" TEXT="&#xbb;ParameterRangeBench&#xab;">
<icon BUILTIN="info"/>
<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?">
<icon BUILTIN="help"/>
</node>
<node CREATED="1708653109374" ID="ID_1339763043" MODIFIED="1708653120296" TEXT="Ergebnis ist eine (x,y)-Wolke"/>
</node>
<node CREATED="1708652867679" ID="ID_691426611" MODIFIED="1708652871625" TEXT="Konstruktion">
<node CREATED="1708652873661" ID="ID_603525757" MODIFIED="1708653741701" TEXT="StressRig sollte idealerweise erweitert werden">
<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()">
<icon BUILTIN="smily_bad"/>
</node>
</node>
<node CREATED="1708652882062" ID="ID_143789267" MODIFIED="1708652909325" TEXT="Probleme">
<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 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">
<richcontent TYPE="NODE"><html>
<head/>
<body>
<p>
<font face="Monospaced" size="2">auto [stress,delta,time] = StressRig::with&lt;Setup&gt;() </font>
</p>
<p>
<font face="Monospaced" size="2">&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;.perform&lt;bench::BreakingPoint&gt;(); </font>
</p>
</body>
</html></richcontent>
<icon BUILTIN="idea"/>
</node>
</node>
</node>
</node>
@ -112109,9 +112172,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1708044890924" ID="ID_1806382832" MODIFIED="1708045069169" TEXT="warum braucht das Planen des wake-up-Job so extrem lang (&gt;3ms)?">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
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.