From 605d747b8d953ab3852fc05c80e128042795e548 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Thu, 7 Mar 2024 23:29:36 +0100 Subject: [PATCH] Scheduler-test: attempt to find a viable Scheduler setup for this measurement MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - better use a Test-Chain-Load without any dependencies - schedule all at once - employ instrumentation - use the inner »overall time« as dependent result variable The timing results now show an almost perfect linear dependency. Also the inner overall time seems to omit the setup and tear-down time. But other observed values (notably the avgConcurrency) do not line up --- src/vault/gear/scheduler.hpp | 2 +- tests/vault/gear/scheduler-stress-test.cpp | 15 ++- tests/vault/gear/stress-test-rig.hpp | 9 +- wiki/thinkPad.ichthyo.mm | 119 +++++++++++++++++++++ 4 files changed, 136 insertions(+), 9 deletions(-) diff --git a/src/vault/gear/scheduler.hpp b/src/vault/gear/scheduler.hpp index f43a379ab..8ae1930e2 100644 --- a/src/vault/gear/scheduler.hpp +++ b/src/vault/gear/scheduler.hpp @@ -461,7 +461,7 @@ namespace gear { /* ==== Implementation of the Concept ExecutionCtx ==== */ /** - * λ-post: enqueue for time-bound execution, possibly dispatch immediately. + * λ-post: enqueue for time-bound execution, within given ExecutionCtx. * @remark This function represents an _abstracted entrance to scheduling_ * for the ActivityLang and is relevant for recursive forwarding * of activations and notifications. The concrete implementation diff --git a/tests/vault/gear/scheduler-stress-test.cpp b/tests/vault/gear/scheduler-stress-test.cpp index 087af3c09..d7cc930e6 100644 --- a/tests/vault/gear/scheduler-stress-test.cpp +++ b/tests/vault/gear/scheduler-stress-test.cpp @@ -391,16 +391,21 @@ namespace test { 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); + TestChainLoad testLoad{nodes}; +// return testLoad.seedingRule(testLoad.rule().probability(0.6).minVal(2)) +// .pruningRule(testLoad.rule().probability(0.44)) +// .weightRule(testLoad.value(1)) +// .setSeed(55); + return testLoad.setWeight(1); } }; auto results = StressRig::with() .perform (2,64); + +cout<<"\"len\";\"dur\""< + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ einmal prüfen ob man das GroomingToken hat, und dann ein Enqueue +

+ + + + + + + + + + +

+ aber nur, wenn man Dependencies nicht »unlimitiert« scheduled. Aber selbst dann werden die Notifications mit »now« gescheduled, und bei einer (hier angestrebten) Überlast-Situation sind alle derzeit zurückgestauten Jobs zeitlich vorher einsortiert +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ 64*0.5 / 8 cores +

+ + + + + + + + + + + + + + + +

+ und eigentlich hatte ich den Pool auf 4 Worker limitiert +

+ + + + + + + + +