I have an "open" system to which "uncertified" binaries can be added,
at any time. Once added, they can be invoked at will (even their own!).
[Core services are implemented at a different level -- different
resource controls, scheduling, etc. -- to ensure their continuous availability and service guarantees. These services tend to be
either more demanding (e.g., multimedia) or essential (e.g., comms).
Letting foreign binaries compete with that closed system jeopardizes
those guarantees and the functionality of the system, as a whole]
The resources available in the system vary, over time. This is a consequence of the dynamic nature of task invocations as well as
the dynamic nature of hardware availability (i.e., more nodes
on-line means more potential resources). Because the system is open,
none of these decisions can be made at design time.
Resource usage per task (lowercase T) is tracked and constrained.
So, the system can see who's using what and act on (against!)
abusers. This can be with or without prejudice (e.g., "Sorry,
I assume you're only using the resources that you NEED to perform
your job but we don't have those resources to spare, currently.
Too bad, so sad, good bye!")
The real-time scheduler makes scheduling decisions based on deadline data (with input from the resource manager... some greedy task may be deemed
a poor choice to run even though it looks to be the most urgent!)
With no certifying authority in place, there's nothing to keep a task
from claiming it has urgent deadlines in an attempt to buck the queue.
This, of course, can work against it because the scheduler's job isn't
to ensure the most urgent deadlines are met but, rather, that the
most "work" gets done (because there is no independent authority
to indicate that task A's job is more meaningful than task B's!).
So, the scheduler may decide that the resource (i.e., time) spent
on that "urgent" task is better spent on helping some other task(s)
achieve *their* goals. (Too bad, so sad, good bye!)
Treating the expressed deadline as always "hard" -- after which, there
is no point in continuing the task's work -- is artificially draconian.
If a (foreign!) task knows that it faces termination if its deadline *happens* to be too soon (for current conditions), then there is
pressure on it to delay that deadline -- perhaps too long.
There are occasions when a "softer" deadline is more appropriate and
could provide opportunity for the workload scheduler to bring more
resources on-line and rebalance the load.
This suggests a simple/intuitive approach is to allow these foreign tasks
to express TWO deadlines:
- the deadline that they would LIKE to meet
- the deadline after which their efforts are irrelevant
Noting, of course, that they might not meet *either* of them and, in
some cases, may never be granted admission if the workload scheduler
deems resources to be insufficient.
Two questions:
- what situation(s) does this approach fail to address?
- how could a hostile actor manipulate these parameters to game the system
(i.e., artificially inflate his significance)?
There's an AI that advises the workload scheduler so the system can eventually adjust its bias towards (or against) the task in question.
But, the time for the AI to learn that can be long (in user time),
depending on how often the task is invoked and how often the system
needs to kill() it.
Email preferred (for those of you that have access to it)
Handling totally unverified programs is of course tough. I presume the system sandboxes each application well enough that they can't really do any harm besides using up resources, but that does sort of limit what they can productively do.
My general approach to system like this is to schedule based on some performance vs cost metric, with cost be a combination of resources needed and
urgency, so tasks that want resource NOW, pay a premium for them, and if they don't quickly produce some useful work, they quickly starve themselves of resource since they can't afford them. You only penalize tasks that start with
short deadlines, if the task has been around for a while, and then the deadline
starts to loom, but resources haven't been given to it, gets some real priority.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 293 |
Nodes: | 16 (2 / 14) |
Uptime: | 238:33:37 |
Calls: | 6,624 |
Files: | 12,172 |
Messages: | 5,319,942 |