April 7, 2025

Feedback Ch 5 6

I am tired. I have been travelling and sick and oncall for the past couple weeks. I hope you're all having a good time.

I have been thinking lately about the nature of study and theory in engineering, and I think so much about this post which I linked in an earlier issue. I'm starting to think there are few posts that have influenced my thinking on the notion of "learning" as much as this one. I shared some thoughts before but I think some of them have crystallized a bit for me.

We teach children in school how to do arithmetic, but we don't expect them to do more and more complicated arithmetic as they get older and more advanced, that's neither useful nor fun. We teach them arithmetic to train their brain pathways to have better intuition for when they move on to algebra. And then we don't (for the most part) expect them to go on to do more and more complicated algebra, the algebra is a building block that enables them to work on something else. And eventually you know, they work on the problems they actually set out to solve. The actual skill of doing arithmetic is perhaps not actually that important except for its role in enabling that later learning.

Is the reason we teach math majors group theory because group theory specifically is an important thing for them to know? Well...probably to some extent. But it's also a convenient tool for giving people opportunities to solve fun and interesting problems that require mathematical thinking.

I wonder sometimes if we have the infrastructure to treat learning for professionals in the same sort of way. People with jobs, when they set out to learn something, have an expectation (or a need, more realistically) for that to directly translate into something they can do at work. But a lot of things are not usefully learned that way. As best I can tell, most people exposure to queueing theory is not "and then I learned how to model real systems I use," it's "it taught me how to think in a systematic way about queues as objects and then I used that to employ other problem solving techniques." But how do you as a professional justify that kind of time investment? Do we socially encourage that kind of learning for professionals? I don't know.

Feedback Control Ch 5/6

Since chapter 6 is a very short review chapter let’s focus on chapter 5. This chapter is about taking problems you already have and recasting them in the view of control, and the tradeoffs and engineering decisions involved in that.

I think it’s funny how many times he feels the need to repeat “the control outputs and functional outputs are different things”—seemed like beating a dead horse to me but I can only imagine he’s had the experience of people being confused about it.

To reiterate the point made, the process of control is very concerned with that of tracking the "output signal," that is, something that we are monitoring to guide our feedback. That is different from like, the "output" of the process itself, like if we are some factory that is producing toys, the "functional output" is different from the queue fullness of a given machine. Confused? No, me neither. But I trust that this has been a problem area.

There’s a lot of examples so I want to dive deeper into the one that particularly interests me, and seems most relevant to my interests, which is “Server Scaling.” He describes this as a single queue of CPU-intensive jobs served by a set of servers. The input we are controlling is the number of workers.

Let's simulate this: In a Golang program we have a single channel and some set of workers. We send jobs down that channel and one of the worker plucks it off. The jobs are exponentially distributed with mean 100ms. We have the ability to scale up and down the number of workers.

In this example, we aim to keep the channel about half full. It might be interesting, as he says in the book, to experiment with other signals.

We can achieve this with a PID controller. Here's the results of my attempt:

The fullness of the channel dances around and doesn't stay super close to 0.5, but I think within the bounds of the problem this is a pretty reasonable place to keep it—as long as we're not oscillating between full and empty I think it's probably pretty reasonable. It does take a while to get going at the beginning, when it's still finding the right number of workers to hover around. I guess in a real-world scenario you might want to prime the system with a reasonable guess at the amount of concurrency it will need at startup. We do talk about that later, if I remember correctly from my first time around reading the book.

I don't have much more commentary on this—it's just a bunch of examples and I adapted a bit of code I wrote before to play around with the same ideas. It's fun though—I encourage you to try too! It works a lot better than I would have thought possible, but the job sizes I have are big and coarse enough that they're not super noisy, I suspect if they were smaller and more realistic it might be a little trickier.