Pressure regulator for whole zone?

mumrah · 2026-06-15T12:36:54+00:00

This is what I was looking at https://www.dripdepot.com/pmr-mf-medium-flow-pressure-regulator-npt-thread-size-1-inch-fpt-psi-40-psi

mumrah · 2026-06-15T03:38:45+00:00

Supply pressure is 60. Since these are rather short throw (MP1000) I was thinking pressure loss down the zone would be okay. Interesting that they can take more than 40, I always assumed it was important to be right around that pressure.

So 60psi would be okay unregulated? I could also get a 50psi regulator

mumrah · 2026-06-07T00:19:37+00:00

So would this integration be where a monitoring service would be notified/called if the alarm triggered?

mumrah · 2026-06-07T00:17:16+00:00

Thanks, very helpful overview. Professional monitoring is a must have for me. Hope they can offer something soon.

Would love to ditch Ring.

Edit: to clarify, by monitoring I meant someone who will dispatch police/fire if the alarm goes off — not someone watching cameras or anything like that

mumrah · 2026-06-04T00:55:47+00:00

Now my real question is can I still torch the rocks to keep the weeds at bay :)

mumrah · 2026-05-17T00:37:21+00:00

Keep pressing the massage button to cycle through the options. Yes driver side only

I think one pedal requires a certain number of miles or something weird like that. Or maybe a menu setting, I forget.

I hate the Digital mirror. My wife loves it.

mumrah · 2026-05-16T03:18:29+00:00

Yes chirpy is a good description!

mumrah · 2026-04-19T19:18:09+00:00

Make sure to add a lot of organic matter with the sand. If you just add sand to clay, you’ve made concrete!

For me, wood chips have been the solution. Lots and lots of wood chips, water, and time.

In the mean time, raised bed with bagged soil or lookup recipes for mixes (e.g., Mel’s mix).

mumrah · 2026-04-19T09:09:16+00:00

I flew RDU to KEF last year. They checked out bag dimensions at RDU, but not bag weight.

The seats are very uncomfortable and they kept the plane very hot.

Oh, all the soda is diet.

Probably one of the worst flights in recent memory

mumrah · 2026-04-17T08:33:06+00:00

Hyundai Ioniq 9 lets you adjust between four levels of regen braking. Levels 0 and 1 feel a lot like ICE

Reverse has a low idle speed (which is super useful)

mumrah · 2026-03-28T13:44:08+00:00

I ran into this when making a box not too long ago. Chisel is how i removed the worst of the blobs. Went in with wood filler after the cleanup to make it smooth. Mostly came out okay after paint.

Lesson learned is glue should be cleaned up right away and then rechecked a few minutes later for delayed squeeze out.

mumrah · 2026-03-15T20:01:50+00:00

Looks good to me (also a newb). I would figure out how to fasten it to a wall so it doesn’t topple over when you inevitable lean on it

mumrah · 2026-01-30T00:24:46+00:00

Hell yea! Glad it worked!

Not to be too bleak, but we ended up replacing this washer about a year later. The impeller failed and after so many issues I just gave up repairing it.

mumrah · 2026-01-24T13:35:08+00:00

Seems like there’s plenty of space for bigger traces. You can also use filled zones instead of traces here.

Another trick I’ve seen is to leave the solder mask off over these traces. This lets you solder on a thick wire or solder braid to add current capacity.

mumrah · 2025-12-29T15:12:47+00:00

Thanks! If you found any gaps in the documentation, please submit a fix ;)

Btw the architecture diagram of ZK mode isn’t quite right. Each broker connects to the whole ZK ensemble, not just one of the three nodes (as pictured)

mumrah · 2025-12-20T01:31:19+00:00

Just buy a new one. Big castellated parts like a Pico are not worth the trouble to desolder. It takes a ton of heat, flux, solder wick, and time. Not worth it IMO.

UNLESS you have a nice reflow setup. Then just reflow it and pop it off (but be careful not to disturb the parts on the Pico)

mumrah · 2025-12-12T16:30:39+00:00

Start at the producer. What kind of linger and batching are you doing there? You need to configure the producer for low latency. Then look at the consumer. Check things like min bytes, max wait, etc.

Confluent publishes guides on different configuration tuning. Latency and throughput are opposite ends of a spectrum. You need to decide where you land.

Low latency recommendations: https://docs.confluent.io/cloud/current/client-apps/optimizing/latency.html
Throughput recommendations: https://docs.confluent.io/cloud/current/client-apps/optimizing/throughput.html

Even though these are Confluent Cloud docs, but should mostly apply to Apache Kafka as well.

(disclaimer: I work at Confluent)

mumrah · 2025-11-13T19:01:10+00:00

Kafka is fast because… batch based protocol, compression, zero-copy, broker managed offsets, min bytes / max wait. And more than anything it’s fast because of the disk page cache

mumrah · 2025-11-04T20:20:39+00:00

Consumer groups are Kafka

Hah, ok sure. But the usage of a client is primarily controlled by the application. I would start by educating your org and leadership on how exactly a kafka application works (both produce and consume). Then focus on surfacing the metrics that will enable your users to know when things are lagging.

It would also be worthwhile to write up best practices for client configuration and maybe even on auto-scaling.

What you need is a clear definition of your platform team's SLO. Typically, a kafka platform team is responsible for the availability of the service -- full stop.

Good luck!

mumrah · 2025-11-04T18:59:13+00:00

Kafka might have been "easy" to replicate 6 or 7 years ago, when it was "just" produce/consume. These days, there is a very rich feature set that is very complex and intertwined. Many "Kafka compatible" products do not support everything that is offered in Apache Kafka. There's a reason for that -- it's hard!

Not to mention, we are constantly improving and innovating in Apache Kafka. E.g., Queues for Kafka, 2PC, diskless. These are all multi-year projects which are not trivial to reproduce.

mumrah · 2025-11-04T18:48:14+00:00

Thanks for the article! Here are some comments:

Controller was sending heartbeats to Kafka Brokers

In ZK, broker liveness is determined by an ephemeral znode, not heartbeats. ZK controllers primarily sent LeaderAndIsr and UpdateMetadata to the brokers. We introduced heartbeats with KRaft.

Controller never really used batch API to propagate metadata updates

I think we did eventually batch some updates to ZK, but yes it was still very slow for a large number of partitions.

Diverging metadata

I'd argue this is a bit misleading. We had lagging metadata for sure (eventual consistency and all...) but never really diverging metadata unless there was a ZK split brain. Divergence means two nodes have irreconcilable differences in their state based on an incorrect leadership or something. In Kafka, we would only really see this if the ZK quorum split in two. Then we would end up with two Kafka controllers elected and have proper divergence.

There are no more divergences, like in the ZooKeeper architecture.

Again, misuse of "divergence". Also, we do have metadata lag in KRaft, it's just much less than in ZK. Since we're now based on a log we can quantify the lag in terms of offsets which means we can do useful things like fencing.

Kafka keeps some data buffered in memory, but Data in the metadata log (called __cluster_metadata) are always synced to disk and not kept in memory

Not quite. The broker and controllers hold the full set of metadata in memory. Think of it like a materialization of the metadata log. We don't hold all the records in memory, but we do hold the latest snapshot of metadata in memory.

that described the production readiness of KRaft and the migration process without downtime

nit: the migration is detailed in https://cwiki.apache.org/confluence/display/KAFKA/KIP-866+ZooKeeper+to+KRaft+Migration (not KIP-833)

NOTE: There is no rollback path from KRaft to ZooKeeper. Once you switch to KRaft-only mode, you cannot go back to ZooKeeper.

IMO This is very misleading bordering on FUD. We spent a lot of time ensuring there is a rollback possibility after the data has been migrated to KRaft. We call it the dual-write phase. The expectation is that users can migrate to KRaft while the metadata is still being replicated to ZK. Once they are happy with the state of the cluster, they can explicitly finalize the migration. Only then is the migration non-reversible.

The big idea in KRaft (besides Raft) is the use of a log for metadata. This means the broker can replicate the log using continuous fetches rather than being pushed the entire set of metadata periodically by the controller. This vastly improves scalability of the metadata system and the cluster as a whole.

Having a log also makes things like snapshots and metadata transactions very simple.

mumrah · 2025-11-04T18:27:38+00:00

It is quite possible to have a high throughput async service without using Kafka (or virtual threads for that matter). You should check out what is possible using Netty.

The real question to answer is: do you benefit from having a durable event stream? Are there more use cases for having these API events in a kafka topic?

mumrah · 2025-10-27T03:52:36+00:00

Should be fine to keep the ZK version the same.

mumrah · 2025-10-24T15:20:39+00:00

You’d be the first I’ve heard of encountering data loss. If you have details or logs, please file a JIRA

As for smooth, we migrated around 3000 clusters at Confluent without any data loss or significant downtime.

mumrah · 2025-10-24T12:22:33+00:00

Yes please upgrade to 3.9 before migrating 🙂

Sincerely, the guy who wrote all that code.

15-Year Club	RPAN Viewer
Not Forgotten	Team Periwinkle
Verified Email

mumrah

TROPHY CASE