Scheduler: complete work-Function / conception work
Notably the work-function is now completely covered, by adding this last test, and the detailed investigations yesterday ultimately unveiled nothing of concern; the times sum up. Further reflection regarding the overall concept led me to a surprising solution for the problem with priority classes.
This commit is contained in:
parent
e26d251867
commit
552d8dec0e
4 changed files with 294 additions and 47 deletions
|
|
@ -244,6 +244,8 @@ namespace gear {
|
|||
};
|
||||
|
||||
|
||||
|
||||
|
||||
/**
|
||||
* @remark when due, the scheduled Activities are performed within the
|
||||
* [Activity-Language execution environment](\ref ActivityLang::dispatchChain());
|
||||
|
|
|
|||
|
|
@ -100,6 +100,21 @@ namespace test {
|
|||
* - this implies we can show timing-delay effects in the millisecond range
|
||||
* - demonstrated behaviour
|
||||
* + an Activity already due will be dispatched immediately by post()
|
||||
* + an Activity due at the point when invoking the work-function is dispatched
|
||||
* + while queue is empty, the work-function returns immediately, indicating sleep
|
||||
* + invoking the work-function when there is still some time span up to the next
|
||||
* planned Activity will enter a targeted sleep, returning shortly after the
|
||||
* next schedule. Entering then again will cause dispatch of that activity.
|
||||
* + if the work-function dispatches an Activity while the next entry is planned
|
||||
* for some time ahead, the work-function will likewise go into a targeted
|
||||
* sleep and only return at or shortly after that next planned time entry
|
||||
* + after dispatching an Activity in a situation with no follow-up work,
|
||||
* the work-function inserts a targeted sleep of random duration,
|
||||
* to re-shuffle the rhythm of sleep cycles
|
||||
* + when the next planned Activity has already be »tended for« (by placing
|
||||
* another worker into a targeted sleep), further workers entering the
|
||||
* work-function will be re-targeted by a random sleep to focus capacity
|
||||
* into a time zone behind the next entry.
|
||||
* @note Invoke the Activity probe itself can take 50..150µs, due to the EventLog,
|
||||
* which is not meant to be used in performance critical paths but only for tests,
|
||||
* because it performs lots of heap allocations and string operations. Moreover,
|
||||
|
|
@ -158,6 +173,7 @@ namespace test {
|
|||
cout << "pullWork() on empty queue..."<<endl;
|
||||
pullWork(); // Call the work-Function on empty Scheduler queue
|
||||
CHECK (activity::WAIT == res); // the result instructs this thread to go to sleep immediately
|
||||
CHECK (delay_us < 40);
|
||||
|
||||
|
||||
cout << "Due at pullWork()..."<<endl;
|
||||
|
|
@ -172,11 +188,11 @@ namespace test {
|
|||
CHECK (wasInvoked(start));
|
||||
CHECK (slip_us < 300); // Note: typically there is a slip of 100..200µs, because sleep waits longer
|
||||
CHECK (scheduler.empty()); // The scheduler is empty now and this thread will go to sleep,
|
||||
CHECK (delay_us < 20000); // however the sleep-cycle is first re-shuffled by a wait between 0 ... 20ms
|
||||
CHECK (delay_us < 20200); // however the sleep-cycle is first re-shuffled by a wait between 0 ... 20ms
|
||||
CHECK (activity::PASS == res); // this thread is instructed to check back once
|
||||
pullWork();
|
||||
CHECK (activity::WAIT == res); // ...yet since the queue is still empty, it is sent immediately to sleep
|
||||
CHECK (delay_us < 20);
|
||||
CHECK (delay_us < 40);
|
||||
|
||||
|
||||
cout << "next some time ahead => up-front delay"<<endl;
|
||||
|
|
@ -193,12 +209,12 @@ namespace test {
|
|||
pullWork(); // if we now re-invoke the work-Function as instructed...
|
||||
CHECK (wasInvoked(start)); // then the next schedule is already slightly overdue and immediately invoked
|
||||
CHECK (scheduler.empty()); // the queue is empty and thus this thread will be sent to sleep
|
||||
CHECK (delay_us < 20000); // but beforehand the sleep-cycle is re-shuffled by a wait between 0 ... 20ms
|
||||
CHECK (delay_us < 20200); // but beforehand the sleep-cycle is re-shuffled by a wait between 0 ... 20ms
|
||||
CHECK (slip_us < 300);
|
||||
CHECK (activity::PASS == res); // instruction to check back once
|
||||
pullWork();
|
||||
CHECK (activity::WAIT == res); // but next call will send this thread to sleep right away
|
||||
CHECK (delay_us < 20);
|
||||
CHECK (delay_us < 40);
|
||||
|
||||
|
||||
cout << "follow-up with some distance => follow-up delay"<<endl;
|
||||
|
|
@ -208,16 +224,8 @@ namespace test {
|
|||
post (start+t1ms); // But another schedule is placed 1ms behind
|
||||
sleep_for (100us); // wait for "soon" to pass...
|
||||
pullWork();
|
||||
SHOW_EXPR(_raw(now))
|
||||
SHOW_EXPR(_raw(start))
|
||||
SHOW_EXPR(_raw(detector.invokeTime(probe)))
|
||||
SHOW_EXPR(res);
|
||||
SHOW_EXPR(delay_us)
|
||||
SHOW_EXPR(slip_us)
|
||||
SHOW_EXPR(wasInvoked(start))
|
||||
SHOW_EXPR(scheduler.empty())
|
||||
CHECK (wasInvoked(start)); // Result: the first invocation happened immediately
|
||||
CHECK (slip_us < 200);
|
||||
CHECK (slip_us < 300);
|
||||
CHECK (delay_us > 900); // yet this thread was afterwards kept in sleep to await the next one
|
||||
CHECK (activity::PASS == res); // instruction to re-invoke immediately
|
||||
CHECK (not scheduler.empty()); // since there is still work in the queue
|
||||
|
|
@ -226,13 +234,32 @@ SHOW_EXPR(scheduler.empty())
|
|||
pullWork(); // re-invoke immediately as instructed
|
||||
CHECK (wasInvoked(start)); // Result: also the next Activity has been dispatched
|
||||
CHECK (slip_us < 400); // not much slip
|
||||
CHECK (slip_us < 20000); // ...and the post-delay is used to re-shuffle the sleep cycle as usual
|
||||
CHECK (delay_us < 20200); // ...and the post-delay is used to re-shuffle the sleep cycle as usual
|
||||
CHECK (activity::PASS == res); // since queue is empty, we will call back once...
|
||||
CHECK (scheduler.empty());
|
||||
pullWork();
|
||||
CHECK (activity::WAIT == res); // and then go to sleep.
|
||||
|
||||
cout << detector.showLog()<<endl; // HINT: use this for investigation...
|
||||
|
||||
cout << "already tended-next => re-target capacity"<<endl;
|
||||
now = RealClock::now();
|
||||
start = now + t500us; // Set the next schedule with some distance...
|
||||
post (start);
|
||||
|
||||
// Access scheduler internals (as friend)
|
||||
CHECK (start == scheduler.layer1_.headTime()); // next schedule indeed appears as next-head
|
||||
CHECK (not scheduler.loadControl_.tendedNext(start)); // but this next time was not yet marked as "tended"
|
||||
|
||||
scheduler.loadControl_.tendNext(start); // manipulate scheduler to mark next-head as "tended"
|
||||
CHECK ( scheduler.loadControl_.tendedNext(start));
|
||||
|
||||
CHECK (start == scheduler.layer1_.headTime()); // other state still the same
|
||||
CHECK (not scheduler.empty());
|
||||
|
||||
pullWork();
|
||||
CHECK (not wasInvoked(start)); // since next-head was marked as "tended"...
|
||||
CHECK (not scheduler.empty()); // ...this thread is not used to dispatch it
|
||||
CHECK (delay_us < 6000); // rather it is re-focussed as free capacity within WORK_HORIZON
|
||||
}
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -7041,7 +7041,7 @@ __see also__
|
|||
&rarr; the protocol [[how to operate the nodes|NodeOperationProtocol]]
|
||||
</pre>
|
||||
</div>
|
||||
<div title="RenderOperationLogic" creator="Ichthyostega" modifier="Ichthyostega" created="202307272322" modified="202309011506" tags="Rendering operational draft" changecount="29">
|
||||
<div title="RenderOperationLogic" creator="Ichthyostega" modifier="Ichthyostega" created="202307272322" modified="202310272134" tags="Rendering operational draft" changecount="30">
|
||||
<pre>//The operational logic of Activity execution is the concrete service provided by the [[Scheduler]] to implement interwoven [[render Activities|RenderActivity]] and [[Job execution|RenderJob]].//
|
||||
* logically, each {{{Activity}}} record represents a //verb// to describe some act performed by »the render process«
|
||||
* the {{{ActivityLang}}} provides a //builder notation// to build „sentences of activities“ and it sets the framework for //execution// of Activities
|
||||
|
|
@ -7049,7 +7049,7 @@ __see also__
|
|||
* the ''Scheduler Layer-1'' ({{{SchedulerInvocation}}}) provides the low-level coordination and invocation mechanics to launch [[render Jobs|RenderJob]].
|
||||
|
||||
!Framework for Activity execution
|
||||
The individual {{{Activity}}} records serve as atomic execution elements; an Activity can be invoked once, either by time-bound trigger in the Scheduler's priority queue, or by receiving an activation message (directly when in //management mode,// else indirectly through the invocation queue). The data structure of the {{{Activity}}} record (&rarr; [[description|RenderActivity]]) is maintained by the [[»block flow« memory allocation scheme|SchedulerMemory]] and can be considered stable and available (within the logical limits of its definition, which means until the overarching deadline has passed). The ''activation'' of an Activity causes the invocation of a hard-wired execution logic, taking into account the //type field// of the actual {{{Activity}}} record to be »performed«. This hard-wired logic however can be differentiated into a //generic// part (implemented directly in {{{class Activity}}}) and a //contextual// part, which is indirected through a ''λ-binding'', passed as ''execution context'', yet actually implemented by functions of ''Scheduler Layer-2''.
|
||||
The individual {{{Activity}}} records serve as atomic execution elements; an Activity shall be invoked once, either by time-bound trigger in the Scheduler's priority queue, or by receiving an activation message (directly when in //management mode,// else indirectly through the invocation queue). The data structure of the {{{Activity}}} record (&rarr; [[description|RenderActivity]]) is maintained by the [[»block flow« memory allocation scheme|SchedulerMemory]] and can be considered stable and available (within the logical limits of its definition, which means until the overarching deadline has passed). The ''activation'' of an Activity causes the invocation of a hard-wired execution logic, taking into account the //type field// of the actual {{{Activity}}} record to be »performed«. This hard-wired logic however can be differentiated into a //generic// part (implemented directly in {{{class Activity}}}) and a //contextual// part, which is indirected through a ''λ-binding'', passed as ''execution context'', yet actually implemented by functions of ''Scheduler Layer-2''.
|
||||
!!!execution patterns
|
||||
Since the render engine can be considered performance critical, only a fixed set of //operational patterns// is supported, implemented with a minimum of indirections and thus with limited configurability. It seems indicated to confine the scope of this operational logic to a finite low-level horizon, assuming that //all relevant high-level render activities// can actually be //expressed in terms of these fundamental patterns,// in combination with an opaque JobFunctor.
|
||||
;Frame Render Job
|
||||
|
|
@ -7201,7 +7201,7 @@ The Scheduler is now considered an implementation-level facility with an interfa
|
|||
&rarr; [[Workers|SchedulerWorker]]
|
||||
</pre>
|
||||
</div>
|
||||
<div title="SchedulerLoadControl" creator="Ichthyostega" modifier="Ichthyostega" created="202310240240" modified="202310241743" tags="Rendering operational spec draft" changecount="34">
|
||||
<div title="SchedulerLoadControl" creator="Ichthyostega" modifier="Ichthyostega" created="202310240240" modified="202310272133" tags="Rendering operational spec draft" changecount="48">
|
||||
<pre>The scheduling mechanism //requires active control of work parameters to achieve good performance on average.//
|
||||
In a nutshell, the scheduler arranges planned [[render activities|RenderActivity]] onto a time axis -- and is complemented by an [[active »work force«|SchedulerWorker]] to //pull and retrieve// the most urgent next task when free processing capacity becomes available. This arrangement shifts focus from the //management of tasks// towards the //management of capacity// -- which seems more adequate, given that capacity is scarce while tasks are abundant, yet limited in size and processed atomically.
|
||||
|
||||
|
|
@ -7217,15 +7217,30 @@ Notably the use of special purpose hardware or special OS privileges is //not re
|
|||
|
||||
This fundamental strategy translates into the goal to provide each worker with the next piece of work as soon as the thread returns from previous work. Putting this scheme into practice however faces major obstacles stemming from //work granularity// and //timing patterns.// Threads will call for work at essentially random time points, and in no way related to the calculation schedule laid out in advance based on reasoning about dependencies, resource allocation and deadlines. This is a problem hard to overcome on the level of individual operationality. And thus, in accordance to the goals set out above, demanding to aim at optimal use of recurses //on average// -- it is indicated to change to a //statistical perspective// and to interpret the worker call as an //capacity event.//
|
||||
!!!The statistical flow of capacity
|
||||
By employing this changed perspective, the ongoing train of worker calls transliterates into a flow of capacity. And this capacity can be grouped and classified. The optimal situation -- which should be achieved on average -- is to be able to provide the next piece of work //immediately// for each worker calling in. On the other hand, target times set out for scheduling should be observed, and thus this optimum state can be characterised as »being slightly overdue«. Ideally, capacity should thus flow-in //slightly behind schedule.// On an operational level, since „capacity flow“ is something generated stochastically, the desired state translates into adjustments to re-distribute the worker callback time points into some focal time zone, located slightly behind the next known [[render activity|RenderActivity]] to tend for. (As aside, an //alternative approach// -- likewise considered for the scheduler design -- would be to pre-attribute known capacity to the next round of known scheduling events; this solution was rejected however, presumably leading to excessively fine-grained and unnecessarily costly computation, disregarding the overall probabilistic nature of the rendering process.)
|
||||
By employing this changed perspective, the ongoing train of worker calls transliterates into a flow of capacity. And this capacity can be grouped and classified. The optimal situation -- which should be achieved on average -- is to be able to provide the next piece of work //immediately// for each worker calling in. On the other hand, target times set out for scheduling should be observed, and optimum state can thus be characterised as »being slightly overdue«. Ideally, capacity should thus flow-in //slightly behind schedule.// At operational level, since „capacity flow“ is something generated stochastically, the desired state translates into adjustments to re-distribute the worker callback time points into some focal time zone, located slightly behind the next known [[render activity|RenderActivity]] to tend for. (As aside, an //alternative approach// -- likewise considered for the scheduler design -- would be to pre-attribute known capacity to the next round of known scheduling events; this solution was rejected however, presumably leading to excessively fine-grained and unnecessarily costly computation, disregarding the overall probabilistic nature of the rendering process.)
|
||||
|
||||
Drawing upon these principles, the treatment of worker calls can be aligned to the upcoming schedule. On average, the planning of this schedule can be assumed to happen in advance with suitably safety margin (notwithstanding the fact that re-scheduling and obliteration of established schedule can happen any time, especially in response to user interaction). The next-known »head element« of the schedule will thus play a //pivotal role,// when placed into the context of the //current time of request.// On average, this head element will be the next activity to consider, and the distance-of-encounter can be taken as indicator for //current density of work.// This allows to establish a priority of concerns to consider when answering a worker pull call, thereby transitioning the capacity-at-hand into a delineated segment of the overall capacity:
|
||||
Drawing upon these principles, the treatment of worker calls can be aligned to the upcoming schedule. On average, the planning of this schedule can be assumed to happen in advance with suitable safety margin (notwithstanding the fact that re-scheduling and obliteration of established schedule can happen any time, especially in response to user interaction). The next-known »head element« of the schedule will thus play a //pivotal role,// when placed into the context of the //current time of request.// On average, this head element will be the next activity to consider, and the distance-of-encounter can be taken as indicator for //current density of work.// This allows to establish a priority of concerns to consider when answering a worker pull call, thereby transitioning the capacity-at-hand into a dedicated segment of the overall capacity:
|
||||
# ideally, activities slightly overdue can be satisfied by //active capacity//
|
||||
# spinning-wait is adequate for imminent events below scheduling latency
|
||||
# next priority to consider is a head element located more into the future
|
||||
# beyond that, capacity can be redirected into a focussed zone behind the head
|
||||
# and if the head is far away, capacity is transitioned into the reserve segment
|
||||
Worker capacity events can be further distinguished into //incoming capacity// and //outgoing capacity.// The latter is the most desirable transition, since it corresponds to a worker just returning from a computation task, while incoming capacity stems from workers calling back after a sleep period. Thus a high priority is placed on re-assigning the outgoing capacity immediately back to further active work, while for incoming capacity there is an increased preference to send it back to sleep. A worker placed into the sleeping reserve for an extended stretch of time can be considered excess capacity and will be removed from the [[work force|SchedulerWorker]]. This kind of asymmetry creates a cascading flow, and allows in the end to synthesise an average load factor, which in turn can be used to regulate the Engine on a global level. If scheduling is overloaded, increasing the slip of planned timings, more capacity might be added back when available, or the planning process should be throttled accordingly.
|
||||
Worker capacity events can be further distinguished into //incoming capacity// and //outgoing capacity.// The latter is the most desirable transition, since it corresponds to a worker just returning from a computation task, while incoming capacity stems from workers calling back after a sleep period. Thus a high priority is placed on re-assigning the outgoing capacity immediately back to further active work, while for incoming capacity there is a preference to send it back to sleep. A worker placed into the sleeping reserve for an extended stretch of time can be considered excess capacity and will be removed from the [[work force|SchedulerWorker]]. This kind of asymmetry creates a cascading flow, and allows in the end to synthesise an average load factor, which in turn can be used to regulate the Engine on a global level. If scheduling is overloaded, increasing the slip of planned timings, more capacity might be added back when available, or the planning process should be throttled accordingly.
|
||||
|
||||
!!!Playback and processing priority
|
||||
Not all tasks are on equal footing though. Given the diverse nature of functions fulfilled by the render engine, several kinds of render processes can be distinguished:
|
||||
;Free-wheeling
|
||||
:Final quality rendering must be completed flawlessly, //whatever it takes.//
|
||||
:Yet there is no temporal limit, rather it is tantamount to use resources efficiently.
|
||||
;Time-bound
|
||||
:Media playback has to observe clear temporal constraints and is obsolete when missing deadlines.
|
||||
:Making progress when possible is more important than completing every chain of activities
|
||||
;Background
|
||||
:Various service tasks can be processed by the render engine when there is excess capacity to use.
|
||||
For the likes of UI audio visualisation or preview caching there is typically no deadline at all, as long as they do not jeopardise important work
|
||||
These distinct »processing classes« seem to impose almost contradictory calculation patterns and goals, hard to fit into a single organisational scheme. Yet the //statistical view angle// outlined above offers a way to reconcile such conflicting trends -- assuming that there is a pre-selection on a higher organisational level to ensure the overall processing load can be handled with the given resources. Indeed it is pointless even to start three real-time playback processes in a situation where it is blatantly clear that the system can handle only two. Yet when a rough guess of expected load indicates that a real-time playback will only consume half of the system's processing capacity, even overprovisioning of background processes to some degree is feasible, as long as the real-time playback gets the necessary headroom. And all these different processing patterns can be handled within the same scheduling framework, as long as they can be translated into a //probability to acquire the resources.//
|
||||
|
||||
A task placed into the scheduling timeline basically represents some //»cross-section of probability«.// If work capacity happens to „land“ into its definition realm and no further overdue task is scheduled before, the task can use the available capacity. Yet when the deadline of the task has passed without any free capacity „hitting“ its scope, its chances are wasted and the scheduler will discard the entry. And by exploiting these relationships, it is possible to craft a scheme of time slot allocation to translate an abstract processing priority into a probabilistic access to some fraction of capacity. Even more so, since it is possible to place multiple instances of the same task into the scheduling timeline, relying on the [[»Gate« mechanism|RenderOperationLogic]] of the [[Activity-Language|RenderActivity]], to spread out a small level of background processing probability over an extended period of time.
|
||||
</pre>
|
||||
</div>
|
||||
<div title="SchedulerMemory" creator="Ichthyostega" modifier="Ichthyostega" created="202307031622" modified="202310241427" tags="Rendering operational draft" changecount="31">
|
||||
|
|
|
|||
|
|
@ -82420,8 +82420,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1697663918107" ID="ID_210862409" MODIFIED="1697675123151" TEXT="Load-Controller vorsehen">
|
||||
<linktarget COLOR="#75769b" DESTINATION="ID_210862409" ENDARROW="Default" ENDINCLINATION="-667;72;" ID="Arrow_ID_1800712901" SOURCE="ID_464175339" STARTARROW="None" STARTINCLINATION="-540;37;"/>
|
||||
<linktarget COLOR="#af587f" DESTINATION="ID_210862409" ENDARROW="Default" ENDINCLINATION="-33;645;" ID="Arrow_ID_204955453" SOURCE="ID_1110932778" STARTARROW="None" STARTINCLINATION="250;17;"/>
|
||||
<linktarget COLOR="#75769b" DESTINATION="ID_210862409" ENDARROW="Default" ENDINCLINATION="-667;72;" ID="Arrow_ID_1800712901" SOURCE="ID_464175339" STARTARROW="None" STARTINCLINATION="-540;37;"/>
|
||||
<icon BUILTIN="flag-pink"/>
|
||||
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1697808322602" ID="ID_1787549088" MODIFIED="1697808340997" TEXT="Entwickelt sich wohl in Richtung einer Steuerzentrale">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
|
|
@ -82722,9 +82722,10 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<node CREATED="1697941881102" ID="ID_1281507935" MODIFIED="1697941890218" TEXT="else: switch to sleep"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1698020504097" ID="ID_1156275715" MODIFIED="1698020521449" TEXT="Bedeutung der Zeit-Ordnung">
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#420117" CREATED="1698020504097" ID="ID_1156275715" MODIFIED="1698432446373" TEXT="Bedeutung der Zeit-Ordnung">
|
||||
<icon BUILTIN="idea"/>
|
||||
<node CREATED="1698020524734" ID="ID_1985773186" MODIFIED="1698020550679" TEXT="hier hilft eine probabilistische Betrachtung ⟶ Flow">
|
||||
<node BACKGROUND_COLOR="#eada9f" COLOR="#990000" CREATED="1698020524734" ID="ID_1985773186" MODIFIED="1698432667093" TEXT="hier hilft eine probabilistische Betrachtung ⟶ Flow">
|
||||
<arrowlink COLOR="#722322" DESTINATION="ID_1475863913" ENDARROW="Default" ENDINCLINATION="888;-37;" ID="Arrow_ID_1254135767" STARTARROW="None" STARTINCLINATION="741;41;"/>
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
<node CREATED="1698020552307" ID="ID_124426025" MODIFIED="1698020593813" TEXT="Worker melden sich regelmäßig ⟶ Kapazität fließt in bestimmte Kategorien"/>
|
||||
|
|
@ -83169,8 +83170,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1698159441179" ID="ID_486995126" MODIFIED="1698372610717" TEXT="Scheduler-Tick">
|
||||
<linktarget COLOR="#994d72" DESTINATION="ID_486995126" ENDARROW="Default" ENDINCLINATION="-91;14;" ID="Arrow_ID_973238030" SOURCE="ID_1391329454" STARTARROW="None" STARTINCLINATION="71;5;"/>
|
||||
<linktarget COLOR="#fffcc5" DESTINATION="ID_486995126" ENDARROW="Default" ENDINCLINATION="579;-95;" ID="Arrow_ID_1801107947" SOURCE="ID_671338782" STARTARROW="None" STARTINCLINATION="292;11;"/>
|
||||
<linktarget COLOR="#994d72" DESTINATION="ID_486995126" ENDARROW="Default" ENDINCLINATION="-91;14;" ID="Arrow_ID_973238030" SOURCE="ID_1391329454" STARTARROW="None" STARTINCLINATION="71;5;"/>
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -88169,11 +88170,12 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<arrowlink COLOR="#ff1924" DESTINATION="ID_996573918" ENDARROW="Default" ENDINCLINATION="-817;60;" ID="Arrow_ID_226641198" STARTARROW="None" STARTINCLINATION="-848;-40;"/>
|
||||
<icon BUILTIN="hourglass"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1697484506891" ID="ID_1292738036" MODIFIED="1698247370951" TEXT="den kompletten Work-Funktor durchspielen">
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node COLOR="#338800" CREATED="1697484506891" ID="ID_1292738036" MODIFIED="1698448216625" TEXT="den kompletten Work-Funktor durchspielen">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1698243387222" ID="ID_1151484757" MODIFIED="1698243397453" TEXT="und zwar direkten Aufruf, ohne WorkForce"/>
|
||||
<node CREATED="1698243399946" ID="ID_525069730" MODIFIED="1698243412341" TEXT="es kann zu Sleeps kommen"/>
|
||||
<node CREATED="1698243426549" ID="ID_1975979569" MODIFIED="1698243431240" TEXT="das bedeutet: Zeitmessung">
|
||||
<node CREATED="1698243426549" ID="ID_1975979569" MODIFIED="1698448212804" TEXT="das bedeutet: Zeitmessung">
|
||||
<icon BUILTIN="clock"/>
|
||||
<node CREATED="1698269582160" ID="ID_211702790" MODIFIED="1698269611010" TEXT="und Prüfen unscharfer Zeitabstände">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
<node CREATED="1698269686974" ID="ID_586911111" MODIFIED="1698269697257" TEXT="wie viel Genauigkeit kann man da überhaupt erwarten?"/>
|
||||
|
|
@ -88187,35 +88189,37 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1698269741040" ID="ID_868809913" MODIFIED="1698269752607" TEXT="verusche mal mein Glück mit 500µs">
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1698269741040" ID="ID_868809913" MODIFIED="1698448202804" TEXT="verusche mal mein Glück mit ~ 500µs">
|
||||
<icon BUILTIN="bell"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1698269618101" ID="ID_561925985" MODIFIED="1698269648550" TEXT="...das macht diesen Test ziemlich fragwürdig">
|
||||
<icon BUILTIN="broken-line"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1698269656739" ID="ID_851832685" MODIFIED="1698269684671" TEXT="muß auf sehr deutliche Zeitungerschiede abzielen">
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1698269656739" ID="ID_851832685" MODIFIED="1698448182187" TEXT="muß auf sehr deutliche Zeitungerschiede abzielen">
|
||||
<icon BUILTIN="yes"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1698243664309" ID="ID_654541946" MODIFIED="1698243687277" TEXT="was kann man sinnvollerweise prüfen?">
|
||||
<node COLOR="#435e98" CREATED="1698243664309" ID="ID_654541946" MODIFIED="1698448102750" TEXT="was kann man sinnvollerweise prüfen?">
|
||||
<icon BUILTIN="help"/>
|
||||
<node COLOR="#435e98" CREATED="1698243697817" ID="ID_83311166" MODIFIED="1698282740280" TEXT="eine eingespiele Activity wird aufgerufen"/>
|
||||
<node COLOR="#435e98" CREATED="1698243756225" ID="ID_489965107" MODIFIED="1698282742903" TEXT="was fällig ist, wird direkt vom post() aufgerufen"/>
|
||||
<node COLOR="#435e98" CREATED="1698243756225" ID="ID_831882516" MODIFIED="1698282748223" TEXT="was fällig wurde, wird unverzögert aufgerufen"/>
|
||||
<node CREATED="1698243881573" ID="ID_1520192624" MODIFIED="1698243892539" TEXT="es wird genau eine scheduled Activity aufgerufen"/>
|
||||
<node CREATED="1698243927930" ID="ID_1326757783" MODIFIED="1698243935709" TEXT="die Zeit wird in etwa eingehalten"/>
|
||||
<node CREATED="1698243794737" ID="ID_1290805695" MODIFIED="1698243800463" TEXT="das Delay-Regime">
|
||||
<node COLOR="#435e98" CREATED="1698243927930" ID="ID_1326757783" MODIFIED="1698445119916" TEXT="die Zeit wird in etwa eingehalten"/>
|
||||
<node COLOR="#435e98" CREATED="1698243794737" ID="ID_1290805695" MODIFIED="1698448111059" TEXT="das Delay-Regime">
|
||||
<icon BUILTIN="forward"/>
|
||||
<node COLOR="#338800" CREATED="1698243828655" ID="ID_763249245" MODIFIED="1698377479489" TEXT="Abstand davor ⟶ delay">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1698243897342" ID="ID_1722957398" MODIFIED="1698377481239" TEXT="Abstand danch ⟶ delay">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
<node CREATED="1698243973380" ID="ID_664100190" MODIFIED="1698244000012" TEXT="tendedNext ⟶ re-Fokussiert"/>
|
||||
<node COLOR="#338800" CREATED="1698245002134" ID="ID_1016395299" MODIFIED="1698377444088" TEXT="nichts danach ⟶ re-Distribution">
|
||||
<node COLOR="#338800" CREATED="1698243973380" ID="ID_664100190" MODIFIED="1698448098679" TEXT="tendedNext ⟶ re-Fokussiert">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1698245002134" ID="ID_1016395299" MODIFIED="1698448116126" TEXT="nichts danach ⟶ re-Distribution">
|
||||
<linktarget COLOR="#758fa6" DESTINATION="ID_1016395299" ENDARROW="Default" ENDINCLINATION="302;-22;" ID="Arrow_ID_1135387860" SOURCE="ID_28419292" STARTARROW="None" STARTINCLINATION="246;369;"/>
|
||||
<linktarget COLOR="#76a2bf" DESTINATION="ID_1016395299" ENDARROW="Default" ENDINCLINATION="334;25;" ID="Arrow_ID_318616986" SOURCE="ID_506319711" STARTARROW="None" STARTINCLINATION="186;-10;"/>
|
||||
<linktarget COLOR="#76a2bf" DESTINATION="ID_1016395299" ENDARROW="Default" ENDINCLINATION="334;27;" ID="Arrow_ID_318616986" SOURCE="ID_506319711" STARTARROW="None" STARTINCLINATION="186;-10;"/>
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1698245073987" ID="ID_1953896637" MODIFIED="1698377472196" TEXT="leer ⟶ Schlaf">
|
||||
|
|
@ -88263,7 +88267,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1698285072189" ID="ID_1552477309" MODIFIED="1698377307677" TEXT="Logik-Fehler mit tendNext">
|
||||
<node COLOR="#435e98" CREATED="1698285072189" FOLDED="true" ID="ID_1552477309" MODIFIED="1698448138291" TEXT="Logik-Fehler mit tendNext">
|
||||
<icon BUILTIN="broken-line"/>
|
||||
<node CREATED="1698285085530" ID="ID_991445216" MODIFIED="1698285104841">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
|
|
@ -88279,7 +88283,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<icon BUILTIN="ksmiletris"/>
|
||||
</node>
|
||||
<node COLOR="#435e98" CREATED="1698285158209" ID="ID_506319711" MODIFIED="1698377451936" TEXT="korrekt wäre: per Nach-Verzögerung die Schläfer umverteilen">
|
||||
<arrowlink COLOR="#76a2bf" DESTINATION="ID_1016395299" ENDARROW="Default" ENDINCLINATION="334;25;" ID="Arrow_ID_318616986" STARTARROW="None" STARTINCLINATION="186;-10;"/>
|
||||
<arrowlink COLOR="#76a2bf" DESTINATION="ID_1016395299" ENDARROW="Default" ENDINCLINATION="334;27;" ID="Arrow_ID_318616986" STARTARROW="None" STARTINCLINATION="186;-10;"/>
|
||||
<icon BUILTIN="forward"/>
|
||||
<node COLOR="#338800" CREATED="1698377318108" ID="ID_362432031" MODIFIED="1698377343794" TEXT="tendedNext muß explizit die Rand-Zeiten korrekt ausschließen">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
|
|
@ -88568,8 +88572,14 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1698448145932" ID="ID_1467908821" MODIFIED="1698448171087" TEXT="abgesehen davon: alle Timings sind jetzt plausibel">
|
||||
<icon BUILTIN="bookmark"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1698448289137" ID="ID_737541011" MODIFIED="1698448319081" TEXT="einen Render-Job (high-level) schedulen">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1697473158929" ID="ID_1723058065" MODIFIED="1697484548083" TEXT="vollständiger Ende-zu-Ende Test incl. WorkForce">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
|
|
@ -88594,14 +88604,15 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</node>
|
||||
</node>
|
||||
<node CREATED="1697758391611" ID="ID_124711923" MODIFIED="1697758397083" TEXT="Fälle">
|
||||
<node CREATED="1697758425500" ID="ID_1450418166" MODIFIED="1697758430911" TEXT="simpleUsage">
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1697758425500" ID="ID_1450418166" MODIFIED="1698448262765" TEXT="simpleUsage">
|
||||
<icon BUILTIN="hourglass"/>
|
||||
<node CREATED="1697758440737" ID="ID_1211803424" MODIFIED="1697758454084" TEXT="zeigt hier vor allem was man braucht"/>
|
||||
<node COLOR="#338800" CREATED="1697842432420" ID="ID_1052962927" MODIFIED="1697842447753" TEXT="Scheduler läßt sich instantiieren">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1698247388556" ID="ID_1402046356" MODIFIED="1698247391396" TEXT="invokeWorkFunction">
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node COLOR="#338800" CREATED="1698247388556" ID="ID_1402046356" MODIFIED="1698448243571" TEXT="invokeWorkFunction">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node COLOR="#338800" CREATED="1698247394051" ID="ID_198829622" MODIFIED="1698247420009" TEXT="kann einfachen Aufruf einer vorher eingespielten Activity belegen">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
|
|
@ -88621,6 +88632,9 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<node COLOR="#338800" CREATED="1698284614614" ID="ID_98846661" MODIFIED="1698284618170" TEXT="delay danach">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1698448228557" ID="ID_238462097" MODIFIED="1698448239965" TEXT="re-Fokussieren der Kapazität">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -91744,7 +91758,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</node>
|
||||
</node>
|
||||
<node CREATED="1685316762484" ID="ID_779629114" MODIFIED="1685316844661" TEXT="wir nutzen Zeitsteuerung als integrierendes Agens" VSHIFT="18">
|
||||
<arrowlink COLOR="#f9ffd5" DESTINATION="ID_503599380" ENDARROW="Default" ENDINCLINATION="-127;-352;" ID="Arrow_ID_215108045" STARTARROW="None" STARTINCLINATION="-65;91;"/>
|
||||
<arrowlink COLOR="#f9ffd5" DESTINATION="ID_503599380" ENDARROW="Default" ENDINCLINATION="-127;-352;" ID="Arrow_ID_215108045" STARTARROW="None" STARTINCLINATION="-107;177;"/>
|
||||
<linktarget COLOR="#ffeac4" DESTINATION="ID_779629114" ENDARROW="Default" ENDINCLINATION="13;-20;" ID="Arrow_ID_1083704754" SOURCE="ID_1469791" STARTARROW="None" STARTINCLINATION="-69;0;"/>
|
||||
<icon BUILTIN="idea"/>
|
||||
<node CREATED="1685317008821" ID="ID_75624396" MODIFIED="1685317551995" TEXT="den zusätzlichen Overhead müssen wir durch Parallelisierungs-Gewinn aufwiegen">
|
||||
|
|
@ -91815,10 +91829,10 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1687652356899" ID="ID_1155443486" MODIFIED="1687652375875" TEXT="Können Prioritäts-Klassen überhaupt dargestellt werden?">
|
||||
<node COLOR="#435e98" CREATED="1687652356899" ID="ID_1155443486" MODIFIED="1698433460035" TEXT="Können Prioritäts-Klassen überhaupt dargestellt werden?">
|
||||
<icon BUILTIN="help"/>
|
||||
<node CREATED="1687652377638" ID="ID_927055665" MODIFIED="1687652408889" TEXT="z.B. Realtime vs. Background"/>
|
||||
<node CREATED="1687652466615" ID="ID_98119896" MODIFIED="1687652589634" TEXT="der Background-Task könnte eine frühere Deadline haben....">
|
||||
<node CREATED="1687652466615" ID="ID_98119896" MODIFIED="1698432345620" TEXT="Problem: der Background-Task könnte eine frühere Deadline haben....">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
|
|
@ -91829,6 +91843,195 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</html></richcontent>
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#e8e78a" COLOR="#a34037" CREATED="1698431962633" ID="ID_1475863913" MODIFIED="1698433650097" TEXT="Heureka! mit dem probabilstischen Ansatz verbinden">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
Gruß vom Vollmond in Pullach (noch nicht ganz voll, morgen ist Mondfinsternis), der geht das Tal entlang mit
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<arrowlink COLOR="#f5fd9d" DESTINATION="ID_323819142" ENDARROW="Default" ENDINCLINATION="44;-68;" ID="Arrow_ID_116183984" STARTARROW="None" STARTINCLINATION="-157;7;"/>
|
||||
<linktarget COLOR="#722322" DESTINATION="ID_1475863913" ENDARROW="Default" ENDINCLINATION="888;-37;" ID="Arrow_ID_1254135767" SOURCE="ID_1985773186" STARTARROW="None" STARTINCLINATION="741;41;"/>
|
||||
<font BOLD="true" NAME="SansSerif" SIZE="12"/>
|
||||
<icon BUILTIN="idea"/>
|
||||
<node CREATED="1698433179997" HGAP="46" ID="ID_477130123" MODIFIED="1698433421017" TEXT="Kapazitäts- und Laststeuerung gehört eigentlich auf eine höhere Ebene" VSHIFT="41">
|
||||
<icon BUILTIN="full-1"/>
|
||||
</node>
|
||||
<node CREATED="1698433228231" HGAP="32" ID="ID_1931146744" MODIFIED="1698433423425" TEXT="denn wenn ein Task mal im Scheuler ist — hat er Chancen, Kapazität zu erlangen" VSHIFT="-1">
|
||||
<icon BUILTIN="full-2"/>
|
||||
</node>
|
||||
<node CREATED="1698433311382" HGAP="24" ID="ID_788626614" MODIFIED="1698433453837" TEXT="allerdings erforder Kapazitäts-Steuerung eine Priorisierung — und zwar segmentweise">
|
||||
<icon BUILTIN="full-3"/>
|
||||
</node>
|
||||
<node CREATED="1698433349337" ID="ID_773792225" MODIFIED="1698433434845" TEXT="also kann man mit Tasks auch segmentweise „schraffieren“">
|
||||
<icon BUILTIN="full-4"/>
|
||||
</node>
|
||||
<node CREATED="1698433382797" ID="ID_856572541" MODIFIED="1698433400374" TEXT="�� das ist die �� Lösung"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1698433489965" ID="ID_323819142" MODIFIED="1698433626101">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
<font size="4"><u>Priorität</u></font> bestimmt die <b>Wahrscheinlichkeit</b>,
|
||||
</p>
|
||||
<p>
|
||||
Kapazität zufällig zu erlangen
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<linktarget COLOR="#f5fd9d" DESTINATION="ID_323819142" ENDARROW="Default" ENDINCLINATION="44;-68;" ID="Arrow_ID_116183984" SOURCE="ID_1475863913" STARTARROW="None" STARTINCLINATION="-157;7;"/>
|
||||
<icon BUILTIN="forward"/>
|
||||
<node CREATED="1698433687865" HGAP="17" ID="ID_1856291258" MODIFIED="1698436739705" TEXT="ein Render-Prozeß setzt Kapazität voraus" VSHIFT="16">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
Grundsätzlich darf ein Render-Prozeß nur bei vorhandener Kapazität zugelassen werden. Aber die Anwendung dieses Prinzips hat Abstufungen, die sich aus der Art des Prozesses bestimmen.
|
||||
</p>
|
||||
<ul>
|
||||
<li>
|
||||
ein <i>whatever it takes</i> - Render bekommt die gesamte Kapazität. Punkt. (alles andere würde ihm schaden)
|
||||
</li>
|
||||
<li>
|
||||
ein realtime-Playback muß im Stande sein, seine Termine zu halten; unter dieser Maßgabe muß er Vorfahrt bekommen, kann aber durchaus noch Raum freilassen, wenn er nicht außerdem auch noch die Leistungsfähigkeit des Systems komplett ausschöpft
|
||||
</li>
|
||||
<li>
|
||||
demgegenüber kann man Background-Prozesse dem Wettbewerb überlassen, und dabei sogar noch verschiedene Level definieren. Es sind nur zwei Bedingungen einzuhalten:
|
||||
</li>
|
||||
<ul>
|
||||
<li>
|
||||
Activities müssen feingranular sein, damit sie wirklich nur die Reste verbrauchen
|
||||
</li>
|
||||
<li>
|
||||
es muß dafür gesorgt werden, daß der Prozeß tatsächlich fortschreitet
|
||||
</li>
|
||||
</ul>
|
||||
</ul>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1698434259630" ID="ID_1030217927" MODIFIED="1698434360871" TEXT="ein geSchedulter Task hat einen Wahrscheinlichkeitsquerschnitt">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
die aktuelle Situation bestimmt darüber, wie Kapazität zugeführt wird; aber der Querschnitt bestimmt, wie gute Chancen ein konkreter Task hat, davon etwas abzubekommen
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<node CREATED="1698434362407" ID="ID_1045531877" MODIFIED="1698434532770" TEXT="solange etwas davor steht, ist er verdeckt">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
Ein <i>frei stehender</i> Task bekommt durch den tend-Next-Mechanismus auch schon sehr viel früher die nächste frei werdende Kapazität zugeordnet; solange aber in der einfachen zeitlichen Ordnung noch etwas vor ihm steht (selbst wenn überfällig), dann zieht dieses die Priorität auf sich
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1698434413940" ID="ID_1412965140" MODIFIED="1698434678138">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
sobald er aber frei steht, bestimmt seine <b>Länge</b> die Priorität
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
Und zwar durch das Ende (die Deadline), nach deren Überstreichen der Task effektiv unwirksam ist und im Vorrübergehen entnommen und verworfen wird. Wenn nun verschiedene Tasks jeweils in der Länge beschränkt sind, dann fällt ihnen diejenige Kapazität zu, die zufällig in ihrem Wirkradius <i>„landet“</i>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1698434700812" ID="ID_1790239617" MODIFIED="1698434978201" TEXT="weitere Faktoren modulieren dieses Schema">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
Da sind zunächst die Gates von Relevanz. Ein noch geschlossenes Gate kann einen Task nach hinten schieben und damit andere Tasks aufdecken. Ein getriggertes und endgültig geschlossenes Gate nimmt den Task aus der Konkurrenz komplett heraus. Und außerdem werden Tasks auch noch über eine Prozeß/Kontext-ID gekennzeichnet, wodurch eine Revision und Aktualisierung eines gesamten Planungsvorgangs möglich wird.
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1698434985257" ID="ID_1456084825" MODIFIED="1698435345311" TEXT="man kann die gleiche Chain mehrfach schedulen — sofern sie ein Gate-Enablement hat">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
...das bedeutet, wenn wir einmal durch das Gate gegangen sind, ist es endgültig geschlossen. Deshalb können gewissermaßen mehrere »Instanzen« eingeplant werden, denn das Wegräumen von Müll ist in einer Priority-Queue relativ effizient, O(logₙ), und läuft bei uns im einstelligen µs-Bereich pro Einzelschritt
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#411d16" CREATED="1698435413188" HGAP="18" ID="ID_988639193" MODIFIED="1698436797466" STYLE="bubble" TEXT="⟹ Wir definieren ein Schema, nach dem Tasks in Zeitfenster gesetzt werden" VSHIFT="4">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
Ein Task der nur Restkapazität bekommen soll, darf niemals am Anfang des Fensters stehen, und auch möglichst nicht ganz am Ende. Je kürzer und je mehr in der Mitte, desto geringer seine Chancen. Ein Task der in jedem Fall Kapazität bekommen soll, muß nur hinreichend weit nach hinten reichen (aber unter der Einschränkung, unseren Epochen-basierten BlockFlow nicht zu überlasten). Oder er muß hinreichend oft wiederholt werden. Es wird also ein generelles Segment-Schema etabliert, und in diesem gibt es vorgefertigte »Slots«. Gemäß übergeordnete Kapazitätsplanung werden diese Slots in Anspruch genommen. Wenn wir beispielsweise eine Restkapazität 10-fach überprovisionieren, dann bedeutet das, jeden einzelnen Task (ggfs. mit Zeitabstand) 10+x-mal einzuplanen, wobei x einen empirisch bestimmten safety-margin darstellt, um die tatsächlichen Fluktuationen der Kapazität abzufedern...
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1698436618074" HGAP="23" ID="ID_145123835" MODIFIED="1698436752191" VSHIFT="5">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p style="text-align: center">
|
||||
dadurch übersetzen wir multidimensionale Zusammenhänge
|
||||
</p>
|
||||
<p style="text-align: center">
|
||||
von der übergeordneten Planungsebene
|
||||
</p>
|
||||
<p style="text-align: center">
|
||||
in ein low-Level-Ausführungsschema
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<icon BUILTIN="yes"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1698097270027" ID="ID_1129105536" MODIFIED="1698097290884" TEXT="Timing-Genauigkeit">
|
||||
|
|
@ -91866,7 +92069,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</node>
|
||||
</node>
|
||||
<node CREATED="1685320663808" ID="ID_503599380" MODIFIED="1685320675723" TEXT="Struktur-Elemente">
|
||||
<linktarget COLOR="#f9ffd5" DESTINATION="ID_503599380" ENDARROW="Default" ENDINCLINATION="-127;-352;" ID="Arrow_ID_215108045" SOURCE="ID_779629114" STARTARROW="None" STARTINCLINATION="-65;91;"/>
|
||||
<linktarget COLOR="#f9ffd5" DESTINATION="ID_503599380" ENDARROW="Default" ENDINCLINATION="-127;-352;" ID="Arrow_ID_215108045" SOURCE="ID_779629114" STARTARROW="None" STARTINCLINATION="-107;177;"/>
|
||||
<node CREATED="1685320702161" ID="ID_1864388669" MODIFIED="1685320717483">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
|
|
|
|||
Loading…
Reference in a new issue