Comment by icegreentea2 | Hacker News Reader

Comment by icegreentea2 | Hacker News Reader

Parent Full thread

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.

Hi OP here. Yes you are right about the asymmetrical nature of the penalties. Actually I do handle this case by using an asymmetric `shrinkage` on the error. See the function called shrinkage in the notebook.

Good day :)

But that's trivial to correct w an assyemtrical error function.

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.

There is one more dimension to this problem. It is how engineers are going to be interacting with the model which includes ability to understand, predict and configure it.

For a mechanism to scale server farm, it cannot be too surprising to engineers that work on it. They need to be able to understand what it does more or less to be able to figure out what is going and deal with problems.

This is even more important in corner cases. What is going to be startup behavior? What happens when a large number of servers goes down? Etc. These behaviors can be very rarely encountered but engineers must be able to predict and reason about them.

Reply on news.ycombinator.com