CPU Utilization Not As Easy As It Sounds

If you ever develop an embedded system in a corporate environment, someone will probably tell you that you can only use 80% of the CPU or some other made-up number. The theory is that you will need some overhead for expansion. While that might have been a reasonable thing to do when CPUs and operating systems were very simple, those days are long gone. [Brendan Long] explains at least one problem with the idea in some recent tests he did related to server utilization.

[Brendan] recognizes that a modern CPU doesn’t actually scale like you would think. When lightly loaded, a modern CPU might run faster because it can keep other CPUs in the package slower and cooler. Increase the load, and more CPUs may get involved, but they will probably run slower. Beyond that, a newfangled processor often has fewer full CPUs than you expect. The test machine was a 24-core AMD processor. However, there are really 12 complete CPUs that can fast switch between two contexts. You have 24 threads that you can use, but only 12 at a time. So that skews the results, too.

Of course, our favorite problem is even more subtle. A modern OS will use whatever resources would otherwise go to waste. Even at 100% load, your program may work, but very slowly. So assume the boss wants you to do something every five seconds. You run the program. Suppose it is using 80% of the CPU and 90% of the memory. The program can execute its task every 4.6 seconds. So what? It may be that the OS is giving you that much because it would otherwise be idle. If you had 50% of the CPU and 70% of the memory, you might still be able to work in 4.7 seconds.

A better method is to have a low-priority task consume the resources you are not allowed to use, run the program, and verify that it still meets the required time. That solves a lot of [Brendan’s] observations, too. What you can’t do is scale the measurement linearly for all these reasons and probably others.

Not every project needs to worry about performance. But if you do, measuring and predicting it isn’t as straightforward as you might think. If you are interested in displaying your current stats, may we suggest analog? You have choices.

CP/M Gently

If you are interested in retrocomputers, you might be like us and old enough to remember the old systems and still have some of the books. But what if you aren’t? No one is born knowing how to copy a file with PIP, for example, so [Kraileth] has the answer: A Gentle Introduction to CP/M.

Of course, by modern standards, CP/M isn’t very hard. You had disks and they had a single level of files in them. No subdirectories. We did eventually get user areas, and the post covers that near the end. It was a common mod to treat user 0 as a global user, but by default, no.

Continue reading “CP/M Gently”

The (RF) Sniff Test

Sometimes the old tricks are the best. [Kevin] learned an old trick about using a ‘scope to sniff RF noise and pays it forward by sharing it in a recent video. He uses an oscilloscope. But does he need some special probe setup? Nope. He quickly makes a little RF pickup probe, and if you have a ‘scope, we’re pretty sure you can make one in a few seconds, too.

Of course, you can get probes made for that, and there are advantages to using them. But the quick trick of quickly and non-destructively modifying the existing probe to pick up RF means you always have a way to make these measurements.

Continue reading “The (RF) Sniff Test”

Hackaday Podcast Episode 335: Beer, Toast, And Pi

What happens when you listen in on Elliot Williams and Al Williams? You get a round up of the best of last week’s Hackaday posts, of course. The topics this week range from beer brewing to lightning protection, with a little bit of everything in between.

This week, many problems find solutions. Power drill battery dead? Your car doesn’t have a tire pressure monitor? Does your butter tear up your toast? You can find the answer to these problems, and more, on the Hackaday podcast.

For the can’t miss section, the guys are annoyed that Google wants to lock down their phones, and also talk about measuring liquid levels in outer space.

Check out the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Or download in DRM-free MP3 without requiring developer registration.

Continue reading “Hackaday Podcast Episode 335: Beer, Toast, And Pi”

The (Data) Plot Thickens

You’ve generated a ton of data. How do you analyze it and present it? Sure, you can use a spreadsheet. Or break out some programming tools. Or try LabPlot. Sure, it is sort of like a spreadsheet. But it does more. It has object management features, worksheets like a Juypter notebook, and a software development kit, in case it doesn’t do what you want out of the box.

The program is made to deal with very large data sets. There are tons of output options, including the usual line plots, histograms, and more exotic things like Q-Q plots. You can have hierarchies of spreadsheets (for example, a child spreadsheet can compute statistics about a parent spreadsheet). There are tons of regression analysis tools, likelihood estimation, and numerical integration and differentiation built in.

Continue reading “The (Data) Plot Thickens”

Homebrew Tire Pressure Monitoring System

When [upir] saw that you could buy tire valve stem caps that read pressure electronically, he decided to roll his own Tire Pressure Monitoring System (TPMS) like the one found on modern cars. An ESP32 and an OLED display read the pressure values. He didn’t have a car tire on his workbench though, so he had to improvise there.

Of course, a real TPMS sensor goes inside the tire, but screwing them on the valve stem is much easier to deal with. The sensors use Bluetooth Low Energy and take tiny batteries. In theory, you’re supposed to connect to them to your phone, although two different apps failed to find the sensors. Even a BLE scanner app wouldn’t pick them up. Turns out — and this makes sense — the sensors don’t send data if there’s no pressure on them, so as not to run down the batteries. Putting pressure on them made them pop up on the scanner.

Continue reading “Homebrew Tire Pressure Monitoring System”

The Android Bluetooth Connection

Suppose someone came to talk to you and said, “I need your help. I have a Raspberry Pi-based robot and I want to develop a custom Android app to control it.” If you are like me, you’ll think about having to get the Android developer tools updated, and you’ll wonder if you remember exactly how to sign a manifest. Not an appealing thought. Sure, you can buy things off the shelf that make it easier, but then it isn’t custom, and you have to accept how it works. But it turns out that for simple things, you can use an old Google Labs project that is, surprisingly, still active and works well: MIT’s App Inventor — which, unfortunately, should have the acronym AI, but I’ll just call it Inventor to avoid confusion.

What’s Inventor? It lives in your browser. You lay out a fake phone screen using drag and drop, much like you’d use QT Designer or Visual Basic. You can switch views and attach actions using a block language sort of like Scratch. You can debug in an emulator or on your live phone wirelessly. Then, when you are ready, you can drop an APK file ready for people to download. Do you prefer an iPhone? There’s some support for it, although that’s not as mature. In particular, it appears that you can’t easily share an iPhone app with others.

Is it perfect? No, there are some quirks. But it works well and, with a little patience, can make amazingly good apps. Are they as efficient as some handcrafted masterpiece? Probably not. Does it matter? Probably not. I think it gets a bad rep because of the colorful blocks. Surely it’s made for kids. Well, honestly, it is. But it does a fine job, and just like TinkerCad or Lego, it is simple enough for kids, but you can use it to do some pretty amazing things.

Continue reading “The Android Bluetooth Connection”