20 ms·

PID Controller for controlling the number of servers in a data-center

83 points by se4u 5y ago

deleted 5y ago
[deleted]
lmilcin 5y ago
Why not something more intelligent than PID? Control theory knows a lot more algorithms. PID is arguably simple to implement but is not particularly good algorithm. It kinda seems to me as if everybody red only the first page on control theory and decided they don't need to read further and base their solution on it. PID will basically have you experience either large overshoots (which you will experience as overcorrecting to changes in demand) or slow adaptation to changes. There is also possibility that your system changes and your PID parameters will cause the whole controller to misbehave. I have implemented a controller for espresso machine boiler water temperature. Replacing PID with moving horizon estimator allowed me to cut time from startup until stable temperature by at least half and eliminate any measurable over or undershoots.
- haolez 5y ago
  PID is often good enough and more robust than ad hoc algorithms to do the same.
  - lmilcin 5y ago
    PID is poor algorithm in this case because there is relatively large delay between signal to spin up a server and observed effect of it. PID requires a lot of iterations to stabilize, which multiplied by delay will require a lot of time. A model predictive controller will need much less iterations because it would actually try to predict number of servers necessary based on some kind of model of the server farm. Parameters for that model can even be learned/adjusted over time, automatically.
    - kbumsik 5y ago
      > in this case because there is relatively large delay between signal to spin up a server and observed effect of it. PID requires a lot of iterations to stabilize, which multiplied by delay will require a lot of time. Then you can tune the PID parameters.
      - sk5t 5y ago
        Exactly, you can use PID to turn a small craft or a large ship, or to heat a tiny copper vessel or an enormous iron one. Delayed effect and tuning time to setpoint and overshoot are, like, well within its territory.
        lmilcin 5y ago
        PID doesn't care how long it takes to achieve stability but sometimes you do. In a lot of cases the time to settle is so short that it doesn't matter but sometimes it does. When you operate datacenter you might not want to wait for hours for PID to spin up the right amount of servers.
      - michaelt 5y ago
        Still, the performance of PID is limited if it takes three minutes to spin up a server. That means either you'd have to run the control loop comparatively slowly (e.g. once every five minutes), or you'd need to have the gain very low, or you'd ave to tolerate a lot of overshoot. None of which will produce great results. A more sophisticated controller would be able to take into account the fact there are servers currently starting up, and only call for more if those already on the way won't be sufficient.
        srean 5y ago
        I agree with your points but this particular point that you mention ... > A more sophisticated controller would be able to take into > account the fact there are servers currently starting up, > and only call for more if those already on the way won't be sufficient. cant that be modelled into the transfer function characterizing the system. Even linear dynamics are quite capable of modeling sluggish dynamics, so PIDs should be able to handle them fine. If there are strong nonlinearities and the system may start far from a desired set point (to the extent that local linearizations are far too inaccurate) or may venture far out, then yes PID may indeed have trouble.
  - srean 5y ago
    PID roughly occupies the same space that logistic regression does in ML. Sure one can use more complicated DNNs when the task really needs it but for many many classification or conditional probability estimation problems a regularized LR goes a long way and its hard to beat it on the axis of simplicity. Of course your resume wont look as shiny.
- jameshart 5y ago
  PID is a damn sight more sophisticated than most datacenter dynamic capacity control algorithms - most autoscalers barely even qualify as ‘bang bang’ controllers - they detect a need for more capacity, and add nodes at some artificially constrained rate until capacity is reached or they hit a max cluster size limit. Even rudimentary control theory is an improvement. Of course the problem with applying PID to server capacity is that compute resources come in discrete chunks that are slow to bring online (‘computers’) rather than being a continually variable resource.
  - lmilcin 5y ago
    I guess progress must be made in small steps... sigh...
  - whatshisface 5y ago
    If you have enough of anything it starts acting continuous.
  - nine_k 5y ago
    I suspect that datacenters do not implement PID not because nobody there is aware of control theory. I suspect they tried and decided against it.
    - oneplane 5y ago
      I think Hanlon's razor applies; most people in the datacenters have not heard of control theory whenever I interacted with them. The ones that did were usually from an academic background and might have had some side-track with robotics, industrial control software development or just plain theoretical studies. I suppose it's not as much that nobody wants it, or nobody wants to know about it, but there is so much else to be known that it might not 'fit' when assembling study materials or in-house learning systems. Maybe the best way to integrate control theory into the datacenter (or cloud) from an ops perspective would be starting out by getting some traction with control systems in general fist, just like a general software engineer might have had some software architecture and patterns for one or two semesters.
- keithnz 5y ago
  as soon as I saw the title I thought, "huh, that really doesn't sound like a good idea". It would likely be over sensitive or under sensitive and likely require lots of continual tweaking with the tuning. Not to mention the discrete step wouldn't be smoothed out till you have quite a lot of server resources in play.
- icegreentea2 5y ago
  I think a better set of arguments against the PID as implemented is that is that does not appropriately take into account the actual penalties of the system. As written, the controller will treat errors symmetrically - the it takes the same effort to correct for over and under provisioning. In reality, we know that this is not realistic. Over provisioning results in an immediate financial cost (that can be easily modeled in $$$), but under provisioning results in a far more complex penalty. I think it'd be important to understand these costs (along with the general shape of your traffic) before implementing a control system. Furthermore, it's very likely that you'll want to implement a deadzone, and almost certainly you'll want to implement a low pass filter, especially if you're sampling processing time significantly faster than ~30 seconds (the estimated startup time). Oh, and the usual things like anti-integral windup, and hard limits so you don't bankrupt yourself.
  - chillingeffect 5y ago
    But that's trivial to correct w an assyemtrical error function.
    - icegreentea2 5y ago
      Oh absolutely. But once you start adding all of these bits, then suddenly PIDs become much less simple, and more annoying to analyze. Like all of the LTI assumptions start getting significantly broken. Suddenly you have a fork in the road and you say: A) Make it "MORE complex" - go model predictive for example as suggested by OP (or whatever). Now that your PID is a gain scheduled, asymmetric, dead-zoned beast, maybe the difference between more complex systems and PID seems less daunting. B) Make it simpler! Just effectively make it bang bang (or pure P) with a deadzone. Leave some performance on the table, but gain the confidence that less will probably go wrong. C) Double down on PIDs. Gain scheduling is fun!. You can figure out how to constrain your system, and carve out regions of LTI goodness and be confident in your transitions. These are all valid solutions. As a lazy engineer, I think B) should be the first choice of any business. And honestly, I think that's where a lot of real businesses ended up.
      - 5y ago
- chillingeffect 5y ago
  My problem with PID is people don't wrap it around a model and use it to correct the errors in the model. Often their tuning ends up "carpet-bumping" between multiple critical points in the system. But as others have mentioned, it gets you ok, predictable performance.
- dahart 5y ago
  > Why not something more intelligent than PID? I'm curious if there exists something intelligent enough to be able to rely on it for a large-scale deployment without human oversight? In general, I would think dead simple and manually controllable is a feature in the context of expenditure. > Replacing PID with moving horizon estimator allowed me to cut time from startup until stable temperature by at least half and eliminate any measurable over or undershoots. I'm familiar with PID controllers, but haven't used MHE before. The formulas look really similar at first glance to me. Three terms and three weights? Is a slow PID controller due to poor tuning, or is MHE intrinsically better? What is the reason that MHE would adapt more quickly with less overshoot than PID? MHE appears to be three integrals instead of one, but I don't see immediately why that would be better, is there an intuitive and/or fundamental reason?
  - viraptor 5y ago
    > I'm curious if there exists something intelligent enough to be able to rely on it for a large-scale deployment without human oversight? I think without a context that's a no. Some systems will want good throughput, some want low latency and require pre-scaling on some cues (time of day, day of week), some want minimal cost but do want to allow bigger bursts for a max of N minutes, etc. Any intelligent scaling without human oversight has a good chance of either burning your money or not optimising for what you care about.
  - whatever1 5y ago
    Yes, Chemical and Oil manufacturing is running on fully automated economic model predictive control for literally decades.
- carlosf 5y ago
  Not sure if that's the case with others, but I have a really hard time connecting CT with actual applications. My classes were full of complex maths and toy examples, but very weak in actual engineering and heuristics.
  - Glawen 5y ago
    Well, you need control theory whenever you need to have something kept at a certain level. House temperature, cruise control speed, etc..
- wenc 5y ago
  Just curious, how did you replace PID with MHE? PID is a control algorithm, while MHE is a state estimation algorithm -- MHE is not a control algorithm and does not perform control. Did you mean MPC by any chance? (which MHE is often used in tandem with) If so, MPC is indeed a superior algorithm, but it also requires a dynamic model (LTI, or state space). Such a model may or may not be easy to identify -- it would require the characterization of the dynamics of data center operations. PID on the other hand, while less optimal, is "model-free" (technically it has a model, i.e. its tunings can be thought to derive from IMC or direct synthesis, even though in practice hand tuning is common) in that it can respond to a wide variety of circumstances without knowing much a priori about the underlying dynamics. PID tunings are also amenable to optimization (products like Loop Pro are used in industry) Due to their simplicity, PIDs are capable of operating at much higher frequencies than more complex algorithms like MPC. PIDs operate in the order of miliseconds or faster, while MPC operates in the order of seconds to minutes because it has to solve an optimization problem at every iteration, which is too slow for fast loops. In the hierarchy of control, there's supervisory layers on top (RTOs), then MPCs then PIDs. It's usually not either-or, but all together, working at different layers. Even in industries where MPC is dominant, PID control is still ubiquitous and used alongside it, especially for local regulatory control loops. I don't have enough insight into data center ops to know if PID control is good enough but in my experience PID can be good enough for many applications -- most control loops in the world are essentially still PID. Not because more advanced algorithms don't exist, but because PID has the advantage of being just good enough for most purposes. (cost is also an issue: PIDs are cheap, while licensing costs for industrial MPC software range from 10s to 100k$)
  - plaguuuuuu 5y ago
    I had no idea this stuff existed. This sounds pretty exciting actually. Is it really that hard/complex to calculate MPC that it can't be stuck inside a loop that runs at 1hz or less? Talking on decent generic or dedicated hardware. Some tiny SOC is a different story.
    - rland 5y ago
      The difficulty with MPC is in the name -- Model predictive control. You need a model.
- viertaxa 5y ago
  Can anyone recommend a “Control theory for the layman” type textbook? Specifically I’m interested in finding something that gives good overviews and examples, and while I’m not afraid of math, I’m not looking for something overly academic or advanced.
  - deepspace 5y ago
    The gold standard introductory book on control theory is "Feedback Control of Dynamic Systems" by Franklin, Powell and Emami-Naeini. While math is absolutely unavoidable when studying the subject, FCDS starts very gently and is quite accessible to the layman.
    - laichzeit0 5y ago
      For someone with a strong mathematical background, what would be a better book? Also, do you know of any that balance the theory with examples, say simulations using R?
      - lmilcin 5y ago
        I am using Optimal Control Theory An Introduction from Donald Kirk and Modern Control Engineering from Katsuhiko Ogata. Both are heavy in math, but are not that difficult (I studied theoretical math some 20 years ago and I can read them).
        deepspace 5y ago
        I recommend Ogata as well. Another classic.
- Sr_developer 5y ago
  Have you practiced control theory in an actual process plant? PID is not simple to tune it at all, well PI, nobody uses the derivative part. Countless studies published in the industry show that up to 30% of the PID control loops in operation are set to MANUAL by the operators and from the rest more than half have wrong parameters.Even then +90% of the controllers are PID, because despite all their problems they work better than the more sophisticated alternatives, they are more reliable, maintainable and cheaper to license. > PID will basically have you experience either large overshoots (which you will experience as overcorrecting to changes in demand) or slow adaptation to changes. Such a blanket statement is meaningless without a description of the system you are controlling, those kind of overshoot can be attributed to wrong parameters, to badly sized elements of control or even to bad measuring devices, the PID algorithm has zero to do with those cases. > I have implemented a controller for espresso machine boiler water temperature. Replacing PID with moving horizon estimator allowed me to cut time from startup until stable temperature by at least half and eliminate any measurable over or undershoots. Did you try a "bang-bang" controller,I would no be surprised if you'd get the same results with 1% of the complexity.
  - lmilcin 5y ago
    The problem with espresso machine startup is that there is 1.5kg piece of metal (grouphead) through which flows around 60ml of water from the boiler. What do you think is the relation between boiler water temperature and the water that actually reaches coffee? When the machine starts, the grouphead is cold. If you want to get good brewing temperature you need to, either a) Wait for 40 minutes until grouphead heats up slowly and everything stabilizes b) Heat up water for 10 minutes and then pump a lot of water through the grouphead to get it hot from the water and pray everything works well c) Build a model that will predict correct setting of water in the boiler given predicted temperature of the grouphead so that when you push water through the grouphead it cools just the right amount. Unfortunately, the correct brew temperature is 92C so you only have couple of degrees to work with. But, still, heating the water to higher temperature causes grouphead to heat up faster and you don't need to heat it as much because it will receive hotter water. Commercial machines do not have this problem because they are started in the morning and only turned off for the night and they have huge tanks of brewing water in them so inflowing water does not affect the temperature so much.
- justapassenger 5y ago
  I've used PID at some very large systems. Main reason is simplicity - dynamic control is introducing huge amount of chaos to your system. Having simple algo like PID (that you need to tune carefully, and retune after each big change, true) has a big benefit - you can reason easily about behavior of the system. And for big systems, that's _extremely_ valuable property, that's often underestimated.
- jzelinskie 5y ago
  I'll bite. What espresso machine? Temperature control and temperature profiling is actually quite bad on most machines. It's actually mostly that people don't even have a good way to measure temperature at the grouphead to really know if their coffee is improving or if they've just improved their temps at the boiler.
  - lmilcin 5y ago
    I built this for Rancilio Silvia (see explanation of the model in another answer in this thread). I chose Silvia mainly because it doesn't have its own electronics, it is all 230V AC wiring, thermostats, switches, etc. I made myself a precise thermometer with PT 1000 probe inside coffee puck and I learned the temperature can vary as much as 10-15 degrees. I first used PID but was not satisfied with long settling time, because when water is right temperature at the boiler it still needs to pass through huge hunk of metal that will determine to large extend the end temperature of brew water. So I built a bit more complex algorithm with the aim of first getting the water a little hotter in the boiler (while grouphead is still cold) and then slowly adjusting setting for the boiler as the grouphead heats up. But there were still problems, for example pumping cold water into the boiler threw everything into chaos. Then the problem that you get temperature readouts with delays and offsets. That's when I decided to just build a more complete model of the system that does not only take current but also past states of the system into account.
- mytailorisrich 5y ago
  > Replacing PID with moving horizon estimator allowed me to cut time from startup until stable temperature by at least half and eliminate any measurable over or undershoots. PID are simple to implement but tricky to tune. In your case you could probably have solved most issues by improving tuning.
- se4u 5y ago
  Hi OP here. To answer why PID, basically somebody I follow asked this question on twitter, and I thought yeah why not seems like a reasonable thing to try :) Actually I do conclude that PID is not quite the right thing for this problem. For me the learnings from making a PID sort of work for this problem were: 1. must use the right error function. like frequency not time. 2. must use shrinkage on the error to handle discrete number of server. 3. have to run controller at a multiple of server delay to avoid perturbations. Also I discuss the basic assumptions that a PID controller makes that are suboptimal in the video.
chrisbolt 5y ago
Useful if you’ve never heard of PID controller: https://en.wikipedia.org/wiki/PID_controller https://en.wikipedia.org/wiki/PID_controller
- yjftsjthsd-h 5y ago
  Thanks; I hadn't heard of it before
  - naoru 5y ago
    Do you work in a datacenter by any chance?
    - yjftsjthsd-h 5y ago
      Nope, just found the topic interesting:)
magicalhippo 5y ago
Not sure how relevant, but reminded me of this thesis[1] which is based on resource closure operators[2]. The thesis applies the model to that of CPU frequency scaling, but I guess a model could be made for something like scaling number of compute nodes. From the abstract of [2]: We evaluate a specific design for a resource closure operator by simulation and demonstrate that the operator achieves a near-optimal balance between cost and value without using any model of the relationship between resources and behavior. Instead, the resource operator relies upon its control of the resource to perform experiments and react to their results. These experiments allow the operator to be highly adaptive to change and unexpected contingencies. Not my field so not sure if anything significant has been done using this in the past 10 years, or if it fizzled out. [1]: https://www.duo.uio.no/handle/10852/8753 https://www.duo.uio.no/handle/10852/8753 [2]: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.304.3398 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.304....
jcalvinowens 5y ago
Why? A PID controller is always a kludge, here extremely so. Something ad hoc could easily be both more optimal and mathematically simpler to analyze and test.
- srean 5y ago
  > Something ad hoc could easily be both optimal and mathematically simpler to analyze and test. Could you give an example ? I don't think PIDs are chosen for their optimality properties.
  - jcalvinowens 5y ago
    More optimal, you deleted a word. Not optimal, but closer to optimal. For the problem we're looking at, the bang bang controller is a far better choice IMHO. I'd like to see an example of when you think PID is an ideal choice? I've never found a real usecase. Whenever I've hacked one into anything, I've quickly replaced it with something simpler and better (thermostats being the most obvious example).
    - ad8e 5y ago
      https://diffeq.sciml.ai/dev/extras/timestepping/ https://diffeq.sciml.ai/dev/extras/timestepping/ Current best method for solving ODEs is PI control. (At least, when I checked it a few years ago.)
    - sackerhews 5y ago
      A thermostat is certainly simpler than a PID controller. But it can't solve the problem that a PID does.
    - srean 5y ago
      You are throwing around words like 'better', 'optimal', "mathematically simpler" in a way that does not give me a lot of confidence. Seems padded with weasel to the point of being unfalsifiable and vapid. Engineering is a quantitative field after all. I did not claim PID to be optimal. It was your claim that you found ad hoc methods to be more optimal (whatever that is supposed to mean). Surely you would be able to give examples and in what quantitative way you have found them "better", or "more optimal" and in what ways you have found PID to be mathematically complex.
juangburgos 5y ago
Useful if you need to adjust the PID gains https://pidtuner.com https://pidtuner.com

83 points by se4u 5y ago

deleted 5y ago

[deleted]

Why not something more intelligent than PID? Control theory knows a lot more algorithms. PID is arguably simple to implement but is not particularly good algorithm. It kinda seems to me as if everybody red only the first page on control theory and decided they don't need to read further and base their solution on it. PID will basically have you experience either large overshoots (which you will experience as overcorrecting to changes in demand) or slow adaptation to changes. There is also possibility that your system changes and your PID parameters will cause the whole controller to misbehave. I have implemented a controller for espresso machine boiler water temperature. Replacing PID with moving horizon estimator allowed me to cut time from startup until stable temperature by at least half and eliminate any measurable over or undershoots.

haolez 5y ago
PID is often good enough and more robust than ad hoc algorithms to do the same.
- lmilcin 5y ago
  PID is poor algorithm in this case because there is relatively large delay between signal to spin up a server and observed effect of it. PID requires a lot of iterations to stabilize, which multiplied by delay will require a lot of time. A model predictive controller will need much less iterations because it would actually try to predict number of servers necessary based on some kind of model of the server farm. Parameters for that model can even be learned/adjusted over time, automatically.
  - kbumsik 5y ago
    > in this case because there is relatively large delay between signal to spin up a server and observed effect of it. PID requires a lot of iterations to stabilize, which multiplied by delay will require a lot of time. Then you can tune the PID parameters.
    - sk5t 5y ago
      Exactly, you can use PID to turn a small craft or a large ship, or to heat a tiny copper vessel or an enormous iron one. Delayed effect and tuning time to setpoint and overshoot are, like, well within its territory.
      - lmilcin 5y ago
        PID doesn't care how long it takes to achieve stability but sometimes you do. In a lot of cases the time to settle is so short that it doesn't matter but sometimes it does. When you operate datacenter you might not want to wait for hours for PID to spin up the right amount of servers.
    - michaelt 5y ago
      Still, the performance of PID is limited if it takes three minutes to spin up a server. That means either you'd have to run the control loop comparatively slowly (e.g. once every five minutes), or you'd need to have the gain very low, or you'd ave to tolerate a lot of overshoot. None of which will produce great results. A more sophisticated controller would be able to take into account the fact there are servers currently starting up, and only call for more if those already on the way won't be sufficient.
      - srean 5y ago
        I agree with your points but this particular point that you mention ... > A more sophisticated controller would be able to take into > account the fact there are servers currently starting up, > and only call for more if those already on the way won't be sufficient. cant that be modelled into the transfer function characterizing the system. Even linear dynamics are quite capable of modeling sluggish dynamics, so PIDs should be able to handle them fine. If there are strong nonlinearities and the system may start far from a desired set point (to the extent that local linearizations are far too inaccurate) or may venture far out, then yes PID may indeed have trouble.
- srean 5y ago
  PID roughly occupies the same space that logistic regression does in ML. Sure one can use more complicated DNNs when the task really needs it but for many many classification or conditional probability estimation problems a regularized LR goes a long way and its hard to beat it on the axis of simplicity. Of course your resume wont look as shiny.
jameshart 5y ago
PID is a damn sight more sophisticated than most datacenter dynamic capacity control algorithms - most autoscalers barely even qualify as ‘bang bang’ controllers - they detect a need for more capacity, and add nodes at some artificially constrained rate until capacity is reached or they hit a max cluster size limit. Even rudimentary control theory is an improvement. Of course the problem with applying PID to server capacity is that compute resources come in discrete chunks that are slow to bring online (‘computers’) rather than being a continually variable resource.
- lmilcin 5y ago
  I guess progress must be made in small steps... sigh...
- whatshisface 5y ago
  If you have enough of anything it starts acting continuous.
- nine_k 5y ago
  I suspect that datacenters do not implement PID not because nobody there is aware of control theory. I suspect they tried and decided against it.
  - oneplane 5y ago
    I think Hanlon's razor applies; most people in the datacenters have not heard of control theory whenever I interacted with them. The ones that did were usually from an academic background and might have had some side-track with robotics, industrial control software development or just plain theoretical studies. I suppose it's not as much that nobody wants it, or nobody wants to know about it, but there is so much else to be known that it might not 'fit' when assembling study materials or in-house learning systems. Maybe the best way to integrate control theory into the datacenter (or cloud) from an ops perspective would be starting out by getting some traction with control systems in general fist, just like a general software engineer might have had some software architecture and patterns for one or two semesters.
keithnz 5y ago
as soon as I saw the title I thought, "huh, that really doesn't sound like a good idea". It would likely be over sensitive or under sensitive and likely require lots of continual tweaking with the tuning. Not to mention the discrete step wouldn't be smoothed out till you have quite a lot of server resources in play.
icegreentea2 5y ago
I think a better set of arguments against the PID as implemented is that is that does not appropriately take into account the actual penalties of the system. As written, the controller will treat errors symmetrically - the it takes the same effort to correct for over and under provisioning. In reality, we know that this is not realistic. Over provisioning results in an immediate financial cost (that can be easily modeled in $$$), but under provisioning results in a far more complex penalty. I think it'd be important to understand these costs (along with the general shape of your traffic) before implementing a control system. Furthermore, it's very likely that you'll want to implement a deadzone, and almost certainly you'll want to implement a low pass filter, especially if you're sampling processing time significantly faster than ~30 seconds (the estimated startup time). Oh, and the usual things like anti-integral windup, and hard limits so you don't bankrupt yourself.
- chillingeffect 5y ago
  But that's trivial to correct w an assyemtrical error function.
  - icegreentea2 5y ago
    Oh absolutely. But once you start adding all of these bits, then suddenly PIDs become much less simple, and more annoying to analyze. Like all of the LTI assumptions start getting significantly broken. Suddenly you have a fork in the road and you say: A) Make it "MORE complex" - go model predictive for example as suggested by OP (or whatever). Now that your PID is a gain scheduled, asymmetric, dead-zoned beast, maybe the difference between more complex systems and PID seems less daunting. B) Make it simpler! Just effectively make it bang bang (or pure P) with a deadzone. Leave some performance on the table, but gain the confidence that less will probably go wrong. C) Double down on PIDs. Gain scheduling is fun!. You can figure out how to constrain your system, and carve out regions of LTI goodness and be confident in your transitions. These are all valid solutions. As a lazy engineer, I think B) should be the first choice of any business. And honestly, I think that's where a lot of real businesses ended up.
    - 5y ago
chillingeffect 5y ago
My problem with PID is people don't wrap it around a model and use it to correct the errors in the model. Often their tuning ends up "carpet-bumping" between multiple critical points in the system. But as others have mentioned, it gets you ok, predictable performance.
dahart 5y ago
> Why not something more intelligent than PID? I'm curious if there exists something intelligent enough to be able to rely on it for a large-scale deployment without human oversight? In general, I would think dead simple and manually controllable is a feature in the context of expenditure. > Replacing PID with moving horizon estimator allowed me to cut time from startup until stable temperature by at least half and eliminate any measurable over or undershoots. I'm familiar with PID controllers, but haven't used MHE before. The formulas look really similar at first glance to me. Three terms and three weights? Is a slow PID controller due to poor tuning, or is MHE intrinsically better? What is the reason that MHE would adapt more quickly with less overshoot than PID? MHE appears to be three integrals instead of one, but I don't see immediately why that would be better, is there an intuitive and/or fundamental reason?
- viraptor 5y ago
  > I'm curious if there exists something intelligent enough to be able to rely on it for a large-scale deployment without human oversight? I think without a context that's a no. Some systems will want good throughput, some want low latency and require pre-scaling on some cues (time of day, day of week), some want minimal cost but do want to allow bigger bursts for a max of N minutes, etc. Any intelligent scaling without human oversight has a good chance of either burning your money or not optimising for what you care about.
- whatever1 5y ago
  Yes, Chemical and Oil manufacturing is running on fully automated economic model predictive control for literally decades.
carlosf 5y ago
Not sure if that's the case with others, but I have a really hard time connecting CT with actual applications. My classes were full of complex maths and toy examples, but very weak in actual engineering and heuristics.
- Glawen 5y ago
  Well, you need control theory whenever you need to have something kept at a certain level. House temperature, cruise control speed, etc..
wenc 5y ago
Just curious, how did you replace PID with MHE? PID is a control algorithm, while MHE is a state estimation algorithm -- MHE is not a control algorithm and does not perform control. Did you mean MPC by any chance? (which MHE is often used in tandem with) If so, MPC is indeed a superior algorithm, but it also requires a dynamic model (LTI, or state space). Such a model may or may not be easy to identify -- it would require the characterization of the dynamics of data center operations. PID on the other hand, while less optimal, is "model-free" (technically it has a model, i.e. its tunings can be thought to derive from IMC or direct synthesis, even though in practice hand tuning is common) in that it can respond to a wide variety of circumstances without knowing much a priori about the underlying dynamics. PID tunings are also amenable to optimization (products like Loop Pro are used in industry) Due to their simplicity, PIDs are capable of operating at much higher frequencies than more complex algorithms like MPC. PIDs operate in the order of miliseconds or faster, while MPC operates in the order of seconds to minutes because it has to solve an optimization problem at every iteration, which is too slow for fast loops. In the hierarchy of control, there's supervisory layers on top (RTOs), then MPCs then PIDs. It's usually not either-or, but all together, working at different layers. Even in industries where MPC is dominant, PID control is still ubiquitous and used alongside it, especially for local regulatory control loops. I don't have enough insight into data center ops to know if PID control is good enough but in my experience PID can be good enough for many applications -- most control loops in the world are essentially still PID. Not because more advanced algorithms don't exist, but because PID has the advantage of being just good enough for most purposes. (cost is also an issue: PIDs are cheap, while licensing costs for industrial MPC software range from 10s to 100k$)
- plaguuuuuu 5y ago
  I had no idea this stuff existed. This sounds pretty exciting actually. Is it really that hard/complex to calculate MPC that it can't be stuck inside a loop that runs at 1hz or less? Talking on decent generic or dedicated hardware. Some tiny SOC is a different story.
  - rland 5y ago
    The difficulty with MPC is in the name -- Model predictive control. You need a model.
viertaxa 5y ago
Can anyone recommend a “Control theory for the layman” type textbook? Specifically I’m interested in finding something that gives good overviews and examples, and while I’m not afraid of math, I’m not looking for something overly academic or advanced.
- deepspace 5y ago
  The gold standard introductory book on control theory is "Feedback Control of Dynamic Systems" by Franklin, Powell and Emami-Naeini. While math is absolutely unavoidable when studying the subject, FCDS starts very gently and is quite accessible to the layman.
  - laichzeit0 5y ago
    For someone with a strong mathematical background, what would be a better book? Also, do you know of any that balance the theory with examples, say simulations using R?
    - lmilcin 5y ago
      I am using Optimal Control Theory An Introduction from Donald Kirk and Modern Control Engineering from Katsuhiko Ogata. Both are heavy in math, but are not that difficult (I studied theoretical math some 20 years ago and I can read them).
      - deepspace 5y ago
        I recommend Ogata as well. Another classic.
Sr_developer 5y ago
Have you practiced control theory in an actual process plant? PID is not simple to tune it at all, well PI, nobody uses the derivative part. Countless studies published in the industry show that up to 30% of the PID control loops in operation are set to MANUAL by the operators and from the rest more than half have wrong parameters.Even then +90% of the controllers are PID, because despite all their problems they work better than the more sophisticated alternatives, they are more reliable, maintainable and cheaper to license. > PID will basically have you experience either large overshoots (which you will experience as overcorrecting to changes in demand) or slow adaptation to changes. Such a blanket statement is meaningless without a description of the system you are controlling, those kind of overshoot can be attributed to wrong parameters, to badly sized elements of control or even to bad measuring devices, the PID algorithm has zero to do with those cases. > I have implemented a controller for espresso machine boiler water temperature. Replacing PID with moving horizon estimator allowed me to cut time from startup until stable temperature by at least half and eliminate any measurable over or undershoots. Did you try a "bang-bang" controller,I would no be surprised if you'd get the same results with 1% of the complexity.
- lmilcin 5y ago
  The problem with espresso machine startup is that there is 1.5kg piece of metal (grouphead) through which flows around 60ml of water from the boiler. What do you think is the relation between boiler water temperature and the water that actually reaches coffee? When the machine starts, the grouphead is cold. If you want to get good brewing temperature you need to, either a) Wait for 40 minutes until grouphead heats up slowly and everything stabilizes b) Heat up water for 10 minutes and then pump a lot of water through the grouphead to get it hot from the water and pray everything works well c) Build a model that will predict correct setting of water in the boiler given predicted temperature of the grouphead so that when you push water through the grouphead it cools just the right amount. Unfortunately, the correct brew temperature is 92C so you only have couple of degrees to work with. But, still, heating the water to higher temperature causes grouphead to heat up faster and you don't need to heat it as much because it will receive hotter water. Commercial machines do not have this problem because they are started in the morning and only turned off for the night and they have huge tanks of brewing water in them so inflowing water does not affect the temperature so much.
justapassenger 5y ago
I've used PID at some very large systems. Main reason is simplicity - dynamic control is introducing huge amount of chaos to your system. Having simple algo like PID (that you need to tune carefully, and retune after each big change, true) has a big benefit - you can reason easily about behavior of the system. And for big systems, that's _extremely_ valuable property, that's often underestimated.
jzelinskie 5y ago
I'll bite. What espresso machine? Temperature control and temperature profiling is actually quite bad on most machines. It's actually mostly that people don't even have a good way to measure temperature at the grouphead to really know if their coffee is improving or if they've just improved their temps at the boiler.
- lmilcin 5y ago
  I built this for Rancilio Silvia (see explanation of the model in another answer in this thread). I chose Silvia mainly because it doesn't have its own electronics, it is all 230V AC wiring, thermostats, switches, etc. I made myself a precise thermometer with PT 1000 probe inside coffee puck and I learned the temperature can vary as much as 10-15 degrees. I first used PID but was not satisfied with long settling time, because when water is right temperature at the boiler it still needs to pass through huge hunk of metal that will determine to large extend the end temperature of brew water. So I built a bit more complex algorithm with the aim of first getting the water a little hotter in the boiler (while grouphead is still cold) and then slowly adjusting setting for the boiler as the grouphead heats up. But there were still problems, for example pumping cold water into the boiler threw everything into chaos. Then the problem that you get temperature readouts with delays and offsets. That's when I decided to just build a more complete model of the system that does not only take current but also past states of the system into account.
mytailorisrich 5y ago
> Replacing PID with moving horizon estimator allowed me to cut time from startup until stable temperature by at least half and eliminate any measurable over or undershoots. PID are simple to implement but tricky to tune. In your case you could probably have solved most issues by improving tuning.
se4u 5y ago
Hi OP here. To answer why PID, basically somebody I follow asked this question on twitter, and I thought yeah why not seems like a reasonable thing to try :) Actually I do conclude that PID is not quite the right thing for this problem. For me the learnings from making a PID sort of work for this problem were: 1. must use the right error function. like frequency not time. 2. must use shrinkage on the error to handle discrete number of server. 3. have to run controller at a multiple of server delay to avoid perturbations. Also I discuss the basic assumptions that a PID controller makes that are suboptimal in the video.

chrisbolt 5y ago

Useful if you’ve never heard of PID controller: https://en.wikipedia.org/wiki/PID_controller https://en.wikipedia.org/wiki/PID_controller

yjftsjthsd-h 5y ago
Thanks; I hadn't heard of it before
- naoru 5y ago
  Do you work in a datacenter by any chance?
  - yjftsjthsd-h 5y ago
    Nope, just found the topic interesting:)

magicalhippo 5y ago

Not sure how relevant, but reminded me of this thesis[1] which is based on resource closure operators[2]. The thesis applies the model to that of CPU frequency scaling, but I guess a model could be made for something like scaling number of compute nodes. From the abstract of [2]: We evaluate a specific design for a resource closure operator by simulation and demonstrate that the operator achieves a near-optimal balance between cost and value without using any model of the relationship between resources and behavior. Instead, the resource operator relies upon its control of the resource to perform experiments and react to their results. These experiments allow the operator to be highly adaptive to change and unexpected contingencies. Not my field so not sure if anything significant has been done using this in the past 10 years, or if it fizzled out. [1]: https://www.duo.uio.no/handle/10852/8753 https://www.duo.uio.no/handle/10852/8753 [2]: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.304.3398 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.304....

jcalvinowens 5y ago

Why? A PID controller is always a kludge, here extremely so. Something ad hoc could easily be both more optimal and mathematically simpler to analyze and test.

srean 5y ago
> Something ad hoc could easily be both optimal and mathematically simpler to analyze and test. Could you give an example ? I don't think PIDs are chosen for their optimality properties.
- jcalvinowens 5y ago
  More optimal, you deleted a word. Not optimal, but closer to optimal. For the problem we're looking at, the bang bang controller is a far better choice IMHO. I'd like to see an example of when you think PID is an ideal choice? I've never found a real usecase. Whenever I've hacked one into anything, I've quickly replaced it with something simpler and better (thermostats being the most obvious example).
  - ad8e 5y ago
    https://diffeq.sciml.ai/dev/extras/timestepping/ https://diffeq.sciml.ai/dev/extras/timestepping/ Current best method for solving ODEs is PI control. (At least, when I checked it a few years ago.)
  - sackerhews 5y ago
    A thermostat is certainly simpler than a PID controller. But it can't solve the problem that a PID does.
  - srean 5y ago
    You are throwing around words like 'better', 'optimal', "mathematically simpler" in a way that does not give me a lot of confidence. Seems padded with weasel to the point of being unfalsifiable and vapid. Engineering is a quantitative field after all. I did not claim PID to be optimal. It was your claim that you found ad hoc methods to be more optimal (whatever that is supposed to mean). Surely you would be able to give examples and in what quantitative way you have found them "better", or "more optimal" and in what ways you have found PID to be mathematically complex.

juangburgos 5y ago

Useful if you need to adjust the PID gains https://pidtuner.com https://pidtuner.com