• Resource management

    From Don Y@21:1/5 to All on Mon Jul 18 06:14:04 2022
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From a a@21:1/5 to Don Y on Mon Jul 18 06:26:18 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to blockedofcourse@foo.invalid on Mon Jul 18 07:21:22 2022
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From rbowman@21:1/5 to Don Y on Mon Jul 18 10:45:24 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to rbowman on Mon Jul 18 17:11:33 2022
    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! :>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to blockedofcourse@foo.invalid on Mon Jul 18 19:09:52 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to Don Y on Tue Jul 19 08:01:22 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Martin Brown on Tue Jul 19 02:41:58 2022
    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?]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)