• 0 Posts
  • 34 Comments
Joined 3 years ago
cake
Cake day: June 30th, 2023

help-circle



  • Scott Manley has a video on this:
    https://youtu.be/DCto6UkBJoI

    My takeaway is that it isn’t unfeasible. We already have satellites that do a couple kilowatts, so a cluster of them might make sense. In isolation, it makes sense.
    But there is launch cost, and the fact that de-orbiting/de-commissioning is a write-off, and the fact that preferred orbits (lots of sun) will very quickly become unavailable.
    So there is kinda a graph where you get the preferred orbit, your efficiency is good enough, your launch costs are low enough.
    But it’s junk.
    It’s literally investing in junk.
    There is no way this is a legitimate investment.

    It has a finite life, regardless of how you stretch your tech. At some point, it can’t stay in orbit.
    It’s AI. There is no way humans are in a position to lock in 4 years of hardware.
    It’s satellites. There are so many factors outside of our control that (beyond launch orbit success), that there is a massive failure rate.
    It’s rockets. They are controlled explosives with 1 shot to get it right. Again, massive failure rate.

    It just doesn’t make sense.
    It’s feasible. I’m sure humanity would learn a lot. AI is not a good use of kilowatts of power in space. AI is not a good use of the finite resource of earth to launch satellites (never mind a million?!). AI is not a good reason to pullute the “good” bits of LEO



  • I’d take each of your metrics and multiply it by 10, and then multiply it by another 10 for everything you haven’t thought about, then probably double it for redundancy.
    Because “fire temp” is meaningless in isolation. You need to know the temperature is evenly distributed (so multiple temperature probes), you need to know the temperature inside and the temperature outside (so you know your furnace isn’t literally melting), you need to know it’s not building pressure, you need to know it’s burning as cleanly as possible (gas inflow, gas outflow, clarity of gas in, clarity of gas out, temperature of gas in, temperature of gas out, status of various gas delivery systems (fans (motor current/voltage/rpm/temp), filters, louvres, valves, pressures, flow rates)), you need to know ash is being removed correctly (that ash grates, shakers, whatever are working correctly, that ash is cooling correctly, that it’s being transported away etc).
    The gas out will likely go through some heat recovery stages, so you need to know gas flow through those and water flow through those. Then it will likely be scrubbed of harmful chemicals, so you need to know pressures, flow rates etc for all that.
    And every motor will have voltage/current/rpm/temperature measurements. Every valve will have a commanded position and actual position. Every pipe will have pressure and temperature sensors.

    The multiple fire temperature probes would then be condensed into a pertinent value and a “good” or “fault” condition for the front panel display.
    The multiple air inlet would be condensed into pertinent information and a good/fault condition.
    Pipes of a process will have temperature/pressure good/fault conditions (maybe a low/good/over?)

    And in the old days, before microprocessors and serial communications, it would have been a local-to-sensors control/indicator panel with every reading, then a feed back to the control room where it would be “summarised”. So hundreds of signals from each local control/indicator panel.

    Imagine if the control room commanded a certain condition, but it wasn’t being achieved because a valve was stuck or because some local control over-rode it.
    How would the control room operators know where to start? Just guess?
    When you see a dangerous condition building, you do what is needed to get it under control and it doesn’t happen because…
    You need to know why.



  • Yeh, either proxy editing (where it’s low res versions until export).

    Or you could try a more suitable intermediary codec.
    I presume you are editing h.264 or something else with “temporal compression”. Essentially there are a few full frames every second, and the other frames are stored as changes. Massively reduces file size, but makes random access expensive as hell.

    Something like ProRes, DNxHD… I’m sure there are more. They store every frame, so decoding doesn’t require loading the last full frame and applying the changes to the current frame.
    You will end up with massive files (compared to h.264 etc), but they should run a lot better for editing.
    And they are lossless, so you convert source footage then just work away.

    Really high res projects will combine both of these. Proxy editing with intermediary codecs


  • What I’d recommend is setting up a few testing systems with 2-3GB of swap or more, and monitoring what happens over the course of a week or so under varying (memory) load conditions. As long as you haven’t encountered severe memory starvation during that week – in which case the test will not have been very useful – you will probably end up with some number of MB of swap occupied.

    And

    [… On Linux Kernel > 4.0] having a swap size of a few GB keeps your options open on modern kernels.

    And finally

    For laptop/desktop users who want to hibernate to swap, this also needs to be taken into account – in this case your swap file should be at least your physical RAM size.





  • In my experience, a Scheduler is something that schedules time on the CPU for processes (threads).

    So 10 processes (threads) say “I need to do something”:
    2 of those threads are “ready to continue” because they were previously waiting on some Disk IO (and responsibly released thread control while data was fetched).
    1 of the threads says “this is critical for GPU operations”.
    1 of those threads self declares it is elevated priority.

    The scheduler decides which of those threads actually gets time on an available CPU core to be processed.