I'm designing an AI to manage resources without the need
for a sysadmin. So, have been canvasing colleagues as to
how they "manually" manage the resources on their
workstations (as most appliances have static requirements
and, thus, don't usually need such management).

In terms of a workstation, resources are usually space and
time -- storage space (short term and secondary) and
how long you, the user, are willing to wait for some or
all of the currently executing activities to complete.

There seem to be two primary strategies:
- let the machine work on ONE thing exclusively to
ensure it has all of the resources that it may need
- let the machine work on everything of interest and
walk away for a while (i.e., remove the time constraint
on results)

For example, when doing SfM, I let the machine work exclusively
on that task as I know it will greedily consume all the
resources it can get its hands on.

OTOH, when recoding video, I'll enqueue everything and let
the machine chew on them all while I find some other activity
to assume my focus.

But, both of these are front-loaded decisions; you
implement your strategy up front. They assume the
machine doesn't have its own agenda to implement
(i.e., you assume any periodic/scheduled tasks are
insignificant in terms of their resource impact
as you likely are unaware of WHEN they are triggered)

It also assumes you can estimate the magnitude of a
workload /a priori/ -- usually from past experience.
I.e., you KNOW that a certain activity will be a resource
hog -- or not. "Surprises" brought about by unexpected
differences in task complexity are rare.

What happens when something you've set out to do takes
considerably longer than you expected? Do you kill off
less important tasks? Renice them? Or, just grin and
bear it?

How do you choose which activities to kill off/defer?
Is this a static decision or an assessment that is
made dynamically based on your perceived "need" of
certain work results?

On Monday, 18 July 2022 at 15:14:26 UTC+2, Don Y wrote:
> I'm designing an AI to manage resources without the need
> for a sysadmin. So, have been canvasing colleagues as to
> how they "manually" manage the resources on their
> workstations (as most appliances have static requirements
> and, thus, don't usually need such management).
>
> In terms of a workstation, resources are usually space and
> time -- storage space (short term and secondary) and
> how long you, the user, are willing to wait for some or
> all of the currently executing activities to complete.
>
> There seem to be two primary strategies:
> - let the machine work on ONE thing exclusively to
> ensure it has all of the resources that it may need
> - let the machine work on everything of interest and
> walk away for a while (i.e., remove the time constraint
> on results)
>
> For example, when doing SfM, I let the machine work exclusively
> on that task as I know it will greedily consume all the
> resources it can get its hands on.
>
> OTOH, when recoding video, I'll enqueue everything and let
> the machine chew on them all while I find some other activity
> to assume my focus.
>
> But, both of these are front-loaded decisions; you
> implement your strategy up front. They assume the
> machine doesn't have its own agenda to implement
> (i.e., you assume any periodic/scheduled tasks are
> insignificant in terms of their resource impact
> as you likely are unaware of WHEN they are triggered)
>
> It also assumes you can estimate the magnitude of a
> workload /a priori/ -- usually from past experience.
> I.e., you KNOW that a certain activity will be a resource
> hog -- or not. "Surprises" brought about by unexpected
> differences in task complexity are rare.
>
> What happens when something you've set out to do takes
> considerably longer than you expected? Do you kill off
> less important tasks? Renice them? Or, just grin and
> bear it?
>
> How do you choose which activities to kill off/defer?
> Is this a static decision or an assessment that is
> made dynamically based on your perceived "need" of
> certain work results?
it's easy and has nothing to do with any AI

Just set your priorities, targets and draw your ideas on a piece of paper as a graph supported by timeline
since it's hard to guess what sits in your mind.

Priorities can by set and managed by IP ports

On Mon, 18 Jul 2022 06:14:04 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>I'm designing an AI to manage resources without the need
>for a sysadmin. So, have been canvasing colleagues as to
>how they "manually" manage the resources on their
>workstations (as most appliances have static requirements
>and, thus, don't usually need such management).
>
>In terms of a workstation, resources are usually space and
>time -- storage space (short term and secondary) and
>how long you, the user, are willing to wait for some or
>all of the currently executing activities to complete.
>
>There seem to be two primary strategies:
>- let the machine work on ONE thing exclusively to
> ensure it has all of the resources that it may need
>- let the machine work on everything of interest and
> walk away for a while (i.e., remove the time constraint
> on results)
>
>For example, when doing SfM, I let the machine work exclusively
>on that task as I know it will greedily consume all the
>resources it can get its hands on.
>
>OTOH, when recoding video, I'll enqueue everything and let
>the machine chew on them all while I find some other activity
>to assume my focus.
>
>But, both of these are front-loaded decisions; you
>implement your strategy up front. They assume the
>machine doesn't have its own agenda to implement
>(i.e., you assume any periodic/scheduled tasks are
>insignificant in terms of their resource impact
>as you likely are unaware of WHEN they are triggered)
>
>It also assumes you can estimate the magnitude of a
>workload /a priori/ -- usually from past experience.
>I.e., you KNOW that a certain activity will be a resource
>hog -- or not. "Surprises" brought about by unexpected
>differences in task complexity are rare.
>
>What happens when something you've set out to do takes
>considerably longer than you expected? Do you kill off
>less important tasks? Renice them? Or, just grin and
>bear it?
>
>How do you choose which activities to kill off/defer?
>Is this a static decision or an assessment that is
>made dynamically based on your perceived "need" of
>certain work results?

What is SfM?

The only thing I do that uses visible amounts of compute power is
running Spice. Shutting down other stuff doesn't make much difference.
Well, launching eDrawings is slow but then it runs fine.

PCB layout takes a few seconds to run a check on a hairy 8-layer
board. It used to take two people two days to check a 2-side board.
That was intense. I fell in love once doing that.

Why not get another PC or two for the compute-bound stuff?

On 07/18/2022 07:14 AM, Don Y wrote:
>
> How do you choose which activities to kill off/defer?
> Is this a static decision or an assessment that is
> made dynamically based on your perceived "need" of
> certain work results?

I usually run into memory problems rather than CPU usage. 16GB is not
enough for Windows 11. Angular development tends to be a hog when using
'ng serve'. It's convenient since it rebuilds when the code changes but
uses much more memory than nginx with a static build.

Typically I'm working on several projects in virtual desktops. What gets
killed depends on my priority at the time.

One 'advantage' of being on the Windows Insider Dev channel is frequent
updates requiring rebooting to clear out the cruft.

On 7/18/2022 9:45 AM, rbowman wrote:
> On 07/18/2022 07:14 AM, Don Y wrote:
>>
>> How do you choose which activities to kill off/defer?
>> Is this a static decision or an assessment that is
>> made dynamically based on your perceived "need" of
>> certain work results?
>
> I usually run into memory problems rather than CPU usage. 16GB is not enough
> for Windows 11. Angular development tends to be a hog when using 'ng serve'.
> It's convenient since it rebuilds when the code changes but uses much more
> memory than nginx with a static build.

But memory just translates into time as you can fault in/out pages as req'd.

> Typically I'm working on several projects in virtual desktops. What gets killed
> depends on my priority at the time.

Are the desktops essentially idle, save "The Current"? I.e., can you
losslessly kill off one (or more) without losing anything -- either because
they are at a logical checkpoint *or* because they are inherently resumable
processes?

Windows is a bad example of this "management" issue as most windows "glutton
apps" have mechanisms built in to self-regulate in instances of overload
(disk defragment runs at off-hours, disk indexer, etc.)

Also, the user only has a small impact on what processes run -- and has to
explicitly invoke them. E.g., there were 61 processes/710 threads running on
this box while the desktop was idle (before I started email client). I'd never
consider looking through those to see which I can kill of, NOW, to conserve
resources; chances are, none are real pigs (unless Firefox was running!)
and they are likely poorly defined: "Can I kill off the on-screen display
process? I can't recall what it does or when it's used -- does that make it
benign?" How savvy is the user expected to be?

[OTOH, it seems intuitive that a user could "change his mind" and kill off
an app he just *opened* without requiring much "system knowledge"]

Finally, the only thing that can make matters degrade is adding apps;
the hardware is never degraded.

> One 'advantage' of being on the Windows Insider Dev channel is frequent updates
> requiring rebooting to clear out the cruft.

Yeah, but the downside is being a windows developer! :>

On Mon, 18 Jul 2022 17:11:33 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>On 7/18/2022 9:45 AM, rbowman wrote:
>> On 07/18/2022 07:14 AM, Don Y wrote:
>>>
>>> How do you choose which activities to kill off/defer?
>>> Is this a static decision or an assessment that is
>>> made dynamically based on your perceived "need" of
>>> certain work results?
>>
>> I usually run into memory problems rather than CPU usage. 16GB is not enough
>> for Windows 11. Angular development tends to be a hog when using 'ng serve'.
>> It's convenient since it rebuilds when the code changes but uses much more
>> memory than nginx with a static build.
>
>But memory just translates into time as you can fault in/out pages as req'd.
>
>> Typically I'm working on several projects in virtual desktops. What gets killed
>> depends on my priority at the time.
>
>Are the desktops essentially idle, save "The Current"? I.e., can you
>losslessly kill off one (or more) without losing anything -- either because
>they are at a logical checkpoint *or* because they are inherently resumable
>processes?
>
>Windows is a bad example of this "management" issue as most windows "glutton
>apps" have mechanisms built in to self-regulate in instances of overload
>(disk defragment runs at off-hours, disk indexer, etc.)
>
>Also, the user only has a small impact on what processes run -- and has to
>explicitly invoke them. E.g., there were 61 processes/710 threads running on
>this box while the desktop was idle (before I started email client). I'd never
>consider looking through those to see which I can kill of, NOW, to conserve
>resources; chances are, none are real pigs (unless Firefox was running!)

Lately Firefox kicks off scores of processes and gobbles ram. There is
an about:config setting to tame that.

On 18/07/2022 14:14, Don Y wrote:
> I'm designing an AI to manage resources without the need
> for a sysadmin.  So, have been canvasing colleagues as to
> how they "manually" manage the resources on their
> workstations (as most appliances have static requirements
> and, thus, don't usually need such management).
>
> In terms of a workstation, resources are usually space and
> time -- storage space (short term and secondary) and
> how long you, the user, are willing to wait for some or
> all of the currently executing activities to complete.
>
> There seem to be two primary strategies:
> - let the machine work on ONE thing exclusively to
>   ensure it has all of the resources that it may need
> - let the machine work on everything of interest and
>   walk away for a while (i.e., remove the time constraint
>   on results)
>
> For example, when doing SfM, I let the machine work exclusively
> on that task as I know it will greedily consume all the
> resources it can get its hands on.

Although there are tasks that are so resource hungry that they make the
system slower to do other things there are very few that use enough
resources to prevent you from text editing or compiling at the same
time. My computer is often running something very heavy in the
background whilst I am dealing with emails and text editing.
>
> OTOH, when recoding video, I'll enqueue everything and let
> the machine chew on them all while I find some other activity
> to assume my focus.

Workstations are fast enough that it isn't worth the effort to schedule
things carefully unless you know that there will be a resource conflict.
eg Two programmes that will each try to create 100+GB scratch files.
Even then SSD's have changed the dynamics somewhat.

> But, both of these are front-loaded decisions; you
> implement your strategy up front.  They assume the
> machine doesn't have its own agenda to implement
> (i.e., you assume any periodic/scheduled tasks are
> insignificant in terms of their resource impact
> as you likely are unaware of WHEN they are triggered)
>
> It also assumes you can estimate the magnitude of a
> workload /a priori/ -- usually from past experience.
> I.e., you KNOW that a certain activity will be a resource
> hog -- or not.  "Surprises" brought about by unexpected
> differences in task complexity are rare.
>
> What happens when something you've set out to do takes
> considerably longer than you expected?  Do you kill off
> less important tasks?  Renice them?  Or, just grin and
> bear it?

Usually the latter.

The most annoying thing is when Windows in its infinite wisdom resets
the flag that lets it reboot the machine willy nilly and without asking
first. Some long running programmes are not interruptible. :(

> How do you choose which activities to kill off/defer?
> Is this a static decision or an assessment that is
> made dynamically based on your perceived "need" of
> certain work results?

It is hardly ever worth meddling unless there is a really serious
competition for either memory or disk access. Setting two programmes
running together that you know will fight for resources is a recipe for
trouble. It was very *much* more of a problem with spinning rust.

Most CPU based computationally intensive things I do will saturate
memory bandwidth at around 6 threads irrespective of the total number of
CPUs/Threads available in the machine (typically now 8 or 12).

One thing that is worth doing is experimenting with the maximum number
of threads you allow very CPU intensive tasks to spawn. There is a sweet
spot where you get the results marginally faster and with a lot less
heat generation. Chess programme parallel implementations show this
effect big time. Working out things quickly that then get thrown away!

--
Regards,
Martin Brown

On 7/19/2022 12:01 AM, Martin Brown wrote:
> On 18/07/2022 14:14, Don Y wrote:
>> I'm designing an AI to manage resources without the need
>> for a sysadmin. So, have been canvasing colleagues as to
>> how they "manually" manage the resources on their
>> workstations (as most appliances have static requirements
>> and, thus, don't usually need such management).
>>
>> In terms of a workstation, resources are usually space and
>> time -- storage space (short term and secondary) and
>> how long you, the user, are willing to wait for some or
>> all of the currently executing activities to complete.
>>
>> There seem to be two primary strategies:
>> - let the machine work on ONE thing exclusively to
>> ensure it has all of the resources that it may need
>> - let the machine work on everything of interest and
>> walk away for a while (i.e., remove the time constraint
>> on results)
>>
>> For example, when doing SfM, I let the machine work exclusively
>> on that task as I know it will greedily consume all the
>> resources it can get its hands on.
>
> Although there are tasks that are so resource hungry that they make the system
> slower to do other things there are very few that use enough resources to
> prevent you from text editing or compiling at the same time. My computer is
> often running something very heavy in the background whilst I am dealing with
> emails and text editing.

Text processing is dribble in the grand scheme of things. Those apps
already spend most of their time spinning on keyboard I/O.

Try running TWO "heavy" things. Granted, the machine (likely) won't
crash, but will you be willing to wait twice as long for either of
those "heavy" things to complete?

E.g., I've noticed that trying to recode more than three video streams
simultaneously increases the time that I wait for ANY of them to
complete; the machine dutifully tries to apportion it's compute
resources between them all, slowing all of them down.

If the goal is to finish all of them, then the end time may be unchanged.
But, there may be opportunities to exploit early finishers in subsequent
actions. E.g., copying a FINISHED conversion onto a thumb drive (uses
very little compute resources but lots of USB channel bandwidth) can
be done in parallel with other recoding operations in progress -- *if*
you've been judicious in how you submitted the recoding jobs (i.e., to
allow some to finish before introducing others).

I limit my FTP clients to two concurrent transfers as the local disk
is effectively as fast as the Gbe pipe connected to the machine; why
have 5 transfers each proceeding at 20% of that rate when I can
serialize them (or let the client do so) -- and have them available
on the other end of the wire sooner.

[Bandwidth being just another resource so manage]

>> OTOH, when recoding video, I'll enqueue everything and let
>> the machine chew on them all while I find some other activity
>> to assume my focus.
>
> Workstations are fast enough that it isn't worth the effort to schedule things
> carefully unless you know that there will be a resource conflict. eg Two

Exactly. An AI watching the current job list can make better decisions
as to how the resources can be used, based on knowledge gleaned from
past observations.

When I place a phone call, another job is triggered to record the contents
of that call. The existence of a (new) recording (even if "in progress")
triggers a speaker diarisation job to parse the audio into independant
streams. Each of these streams triggers another job(s) to identify the
speaker in each stream. These, then, are used to retrain the speaker
models to improve subsequent efforts.

At least, that's how a resource *abundant* solution happens.

But, the only current "need" is for the job that records the audio
streams as the audio is only available in current time. Each of the
other activities can be serialized thereafter, based on the resources
available when those jobs are scheduled.

Why "load" all of those jobs (increasing demand for VMM) simultansously
if you can load them sequentially? Thus, minimizing the PEAK resource
requirement. (should the *user* have to make that decision? Isn't it
better suited to an AI?) After all, the *practical* deadline is to
have this work finished before the next "phone call" (or other opportunity
to use this data)

> programmes that will each try to create 100+GB scratch files.
> Even then SSD's have changed the dynamics somewhat.

Now, move out of the workstation and into an appliance. How much
do you overprovision the appliance to handle those peak demands,
solely because you didn't want to sort out how to level that load
through judicious rescheduling?

>> But, both of these are front-loaded decisions; you
>> implement your strategy up front. They assume the
>> machine doesn't have its own agenda to implement
>> (i.e., you assume any periodic/scheduled tasks are
>> insignificant in terms of their resource impact
>> as you likely are unaware of WHEN they are triggered)
>>
>> It also assumes you can estimate the magnitude of a
>> workload /a priori/ -- usually from past experience.
>> I.e., you KNOW that a certain activity will be a resource
>> hog -- or not. "Surprises" brought about by unexpected
>> differences in task complexity are rare.
>>
>> What happens when something you've set out to do takes
>> considerably longer than you expected? Do you kill off
>> less important tasks? Renice them? Or, just grin and
>> bear it?
>
> Usually the latter.

I routinely kill off Firefox as it's process footprint seems
to just keep growing. Tbird often spins for the better
portion of a minute before painting its window into the display.

> The most annoying thing is when Windows in its infinite wisdom resets the flag
> that lets it reboot the machine willy nilly and without asking first. Some long
> running programmes are not interruptible. :(

And, a machine may be "active" (from the user's standpoint) yet
not detectable as such by the sleep timer. If your product allows
third party code to coexecute alongside "factory" code, then your
users are at the mercy of each of these vendors -- yet, they see
it as YOUR product that is "misbehaving".

>> How do you choose which activities to kill off/defer?
>> Is this a static decision or an assessment that is
>> made dynamically based on your perceived "need" of
>> certain work results?
>
> It is hardly ever worth meddling unless there is a really serious competition
> for either memory or disk access. Setting two programmes running together that
> you know will fight for resources is a recipe for trouble. It was very *much*
> more of a problem with spinning rust.

That falls in the
- let the machine work on ONE thing exclusively to
ensure it has all of the resources that it may need
strategy.

But, you have to LEARN that to be the case -- by running said apps
concurrently and "noticing" the conflict. That's the role for the
AI to fill so the user doesn't have to "tune the fish".

> Most CPU based computationally intensive things I do will saturate memory
> bandwidth at around 6 threads irrespective of the total number of CPUs/Threads
> available in the machine (typically now 8 or 12).
>
> One thing that is worth doing is experimenting with the maximum number of
> threads you allow very CPU intensive tasks to spawn. There is a sweet spot
> where you get the results marginally faster and with a lot less heat
> generation. Chess programme parallel implementations show this effect big time.
> Working out things quickly that then get thrown away!

My environment is more draconian than a desktop; I can enforce compute,
space, comms, etc. quotas to ensure no job "misbehaves".

But, depending on circumstances, a wiser move may be to kill off or
defer certain jobs to facilitate responsiveness for those that remain.
E.g., do all that telephone audio processing when the system load is
*naturally* lower (when is that? Ah, the AI knows!)

[Imagine the available hardware resources dynamically varying and
consider how the job selection criteria can change; pull a few
DRAM sticks out of your workstation or disable a few cores
WHILE it is "running normally". Would you still be happy with
the apps that are running, at that time?]