Tribblix and static networking on AWS The Trouble with Tribbles...

I've just made available the m27 AMIs for Tribblix. As usual, these are just available in London (eu-west-2).

One thing I've noticed repeatedly while running illumos on AWS is that network stability isn't great. The instance will occasionally drop off the network and stubbornly refuse to reclaim its IP address even if you reboot it. It's not just Tribblix, I run a whole lot of OmniOS on AWS and that does the same thing.

The problem appears to be related to DHCP not being able to pick up the address (even though I can see it ending out the correct requests and getting what look like legitimate responses).

So what I do is convert the running instance from using NWAM and being a DHCP client to having statically configured networking. On first boot it needs to use DHCP, because it cannot know what its IP address and network configuration should be until it's booted up once and used DHCP to get the details. But it's really extremely rare to take an AWS instance and change its networking - you would simply build new instances rather than modifying existing ones - so changing it to static is fine, and eliminates any possibility of DHCP failures messing you up in future.

In the past I've always done this manually, but now there's a much easier way if you're using m27 or later:

zap staticnet

will show you what the system will do, just as a sanity check, and then

zap staticnet -y

will implement the change.

Private Web based IDE Nahum Shalman

These notes are a riff on a post by Chris Short. The biggest difference is that I will use the Tailscale TLS support rather than using external DNS access and a custom DNS record. This removes the need for a sensitive DNS API key. Chris's post is definitely worth a read first:

code-server, Caddy, Tailscale, and Hugo = My ultimate dev environment
I think I’ve discovered my development environment equivalent to nirvana: code-server, Caddy, Tailscale, and Hugo
alt

Welcome back. Here's the plan:

  1. Spin up an Ubuntu instance
  2. Add it to my Tailnet
  3. Install and run code-server
  4. Install, configure, and run Caddy
  5. ...
  6. Profit?

When we're done we should be able to go to a browser on any machine in the Tailnet and type http://vscode (I'm assuming you've set the hostname of the new instance to "vscode") and be redirected to the full https URL which will help reassure the browser (even though HTTP over Tailscale is already secure.)

Prerequisites:

  1. An existing Tailscale account and a machine on it to use as the client
  2. A Tailscale Auth Key to use
  3. MagicDNS needs to be enabled on your Tailnet.
  4. The Tailscale HTTPS Beta feature also needs to be enabled on your Tailnet.

Here's the code:

I tested that code by using it as user-data for cloud-init, so you can go from zero to code-server over Tailscale mostly unattended.

So, spin up Ubuntu in your favorite place and either add that as the user-data or run it as root manually. When it's done you can fetch the default password with:

ssh vscode grep password: .config/code-server/config.yaml

You should be able to navigate to http://vscode (or whatever hostname you used) and get redirected to the TLS-ified URL to log in.

Check back later for more shenanigans where I'll do this inside LX branded zones on illumos!

OmniOS Community Edition r151042i, r151040ai, r151038bi OmniOS Community Edition

OmniOS r151042i, r151040ai and r151038bi are now available.

In r151038, r151040 and r151042

In r151040 and r151042

  • OpenSSL 3.0.4 patched, fixing GSD-2022-1002526 heap overflow.

For further details, please see https://omnios.org/releasenotes


Any problems or questions, please get in touch.

OmniOS Community Edition r151042 has been released OmniOS Community Edition

OmniOSce v11 r151042 is out now!

On the 2nd of May 2022, the OmniOSce Association has released a new stable version of OmniOS - The Open Source Enterprise Server OS. The new release comes with many tool updates, brand-new features and additional hardware support. For details see the release notes.

Note, that r151030 LTS is now end-of-life. You should upgrade to r151038 to stay on a supported long-term-support track.

OmniOS is fully Open Source and free. Nevertheless, it takes a lot of time and money to keep maintaining a full-blown operating system distribution. Our statistics show that there are almost 2’000 active installations of OmniOS while fewer than 20 people send regular contributions. If your organization uses OmniOS based servers, please consider becoming a regular patron or taking out a support contract.


Any problems or questions, please get in touch.

555 Timer Comparison Josef "Jeff" Sipek

In the late 90s, I messed a little bit with electronics but I stopped because I got interested in programming. This last January, I decided to revisit this hobby.

I went through my collection of random components and found one 555 timer chip—specifically a TS555CN. I played with it on a breadboard and very quickly concluded that I should have more than just one. Disappointingly, sometime over the past 25 years, STM stopped making TS555 in DIP packages, so I ordered NA555PE4s thinking that they should be similar enough.

When they arrived, I tried to make use of them but I quickly noticed that their output seemed…weird. I tweeted about it and then tweeted some more. I concluded that precision 555s just weren’t fundamental enough to most circuits using DIP packages, and that I would have to make do with the NA555 parts.

Fast forward a few months, and I noticed ICM7555IPAZ on Mouser. The datasheet made it look a lot like the TS555…so I bought one to benchmark.

I went with a very simple astable multivibrator configuration—the same one that every 555 datasheet includes:

R1, R2 1kΩ
C1 220nF
C2 0.01μF
C3 10μF

The TS555 datasheet suggested 0.01μF for C2, and it didn’t seem to harm the other two chips so I went with it.

The NA555 datasheet suggested 0.01μF for C3. That cleaned up the rising edge slightly for TS555 and ICM7555. NA555’s rising edge actually became an edge instead of a huge mess, however it still seemed to be limited so I went with a bigger decoupling capacitor—namely 10μF. That didn’t seem to harm the other two chips.

Finally, note that the output is completely unloaded. I figure that this is reasonable since there are plenty of high input impedance loads that the 555 output could feed into. (A quick sanity check with a 1kΩ resitor to ground shows that the output voltage drops by about a volt, but the general shape of the wave doesn’t change.)

I assembled it on a breadboard with plenty of space for my fingers to swap out the chip:

The orange and red wires go to +5V and the black one goes to ground. All 3 are plugged in just right of the decoupling capacitor (off image).

Looking at the three datasheets, they all provide the same (or slightly rearranged) formulas for the frequency and duty cycle. Since I used 1kΩ for the two resistors and 220nF for the capacitor, I should be seeing:

f = 1.44 ( R A + 2 * R B ) * C = 2182 Hz

and duty cycle:

D = R A + R B R A + 2 * R B = 2 3 or 66.67%

Because I used a breadboard, there is some amount of stray capacitance which likely shifts the frequency a bit. Based on previous experience, that shouldn’t be too much of an issue.

I supplied the circuit with a power supply set to 5V and 0.2A. (It operated in constant-voltage mode the entire time.)

Unlike some of my previous experiments, I actually tried to get a nice clean measurement this time. I used the probe grounding spring to get a short ground and measured between pin 1 and 3 (ground and output, respectively).

Let’s look at the amplitude, frequency, duty cycle, and rise time of the three chips. I took screenshots of the scope as I was performing the various measurements. To make it easier to compare them, I made combined/overlayed images and tweaked the colors. This makes the UI elements in the screenshot look terrible, but it is trivial to see how the chips compare at a glance. In the combined images TS555 is always yellow, NA555 is cyan, and ICM7555 is magenta.

Amplitude, frequency, and duty cycle

(Individual screenshots: NA555, TS555, ICM7555)

It is easy to see that the output of both TS555 and ICM7555 goes to (and stays at) 5V. The NA555 spikes to 5V during the transition, but then decays to 4.5V. More on this later.

Similarly, it is easy to see that the TS555 and NA555 have a very similar positive cycle time but different enough negative cycle time that their frequencies and duty cycle will be different.

TS555 got close with the frequency (2.20 kHz) while NA555 got close with the duty cycle (65.75%). ICM7555 was the worst of the bunch with 2.28 kHz and 63.23% duty cycle.

Rise time

(Individual screenshots: NA555, TS555, ICM7555)

The NA555 has a comparatively awful rise time of 74.88 ns. The TS555 appears to be a speed demon clocking in at 18.69 ns. Finally, the ICM7555 appears to split the difference with 41.91 ns.

I still think that it is amazing that a relatively inexpensive scope (like the Siglent SDS 1104X-E used for these measurements) can visualize signal changes on nanosecond scales.

Revisiting amplitude

In a way, looking at the amplitude is what got me into this evaluation—specifically, the strange output voltage on the NA555 chip. Let’s take a look at the first microsecond following a positive edge.

(Individual screenshots: NA555, TS555, ICM7555)

After the somewhat leisurely rise time of ~75 ns, the output stays near 5V for about 200 ns, before dipping down to about 3.75V for almost 200 ns and then recovering to about 4.5V over the next 400 ns. The output stays at 4.5V until the negative edge.

This is weird and I don’t have any answers for why this happens. I tried a handful of the NA555s (all likely from the same batch), and they all exhibit this behavior.

NA555 decoupling

As I mentioned in the introduction, I didn’t follow the NA555’s decoupling capacitor suggestion. I wasn’t planning on writing this section, but I think that it is interesting to see just how much the output changes as the decoupling capacitor is varied.

As before, I made combined/overlayed images for easier comparison. This time, yellow is no decoupling capacitor, magenta is 0.01μF (suggested by the NA555 datasheet), cyan is 0.1μF, and green is 10μF (used in chip comparison circuit).

(Individual screenshots: no cap, 0.01μF, 0.1μF, 10μF)

As you can see, not having a decoupling capacitor makes the output voltage go to nearly 7V in a circuit with a 5V supply. Adding the suggested 0.01μ certainly makes things better (the peak is at about 5.8V) but it looks like the chip is still struggling to deal with the transient. Using 0.1μF or more results in approximately the same waveform with a peak just around 5V.

The suggested 0.01μF has another problem in my circuit. It makes the NA555’s output ring:

(Individual screenshots: no cap, 0.01μF, 0.1μF, 10μF)

Neither the TS555 nor the ICM7555 have this issue. They are both quite happy with a 0.01μF capacitor. Without any capacitor, they have a little bit of a ring around 5V (1.2Vpp for TS555, 200mVpp for ICM7555) but it subsides promptly. The ICM7555’s ringing is so minor, that it probably isn’t worth it to even use a decoupling capacitor.

Summary

I’ve collected the various measurements from the screenshots and put them into the following table:

Calculated TS555CN NA555PE4 ICM7555IPAZ
f (kHz) 2.182 2.20 (+0.8%) 2.24 (+2.7%) 2.28 (+4.4%)
D (%) 66.67 64.68 (-3.0%) 65.75 (-1.4%) 63.23 (-5.2%)
Rise (ns) 18.69 74.88 41.91
Logic high peak (V) 5 5.08 5.12 5.08
Logic high steady state (V) 5 5.08 ~4.5 5.08

So, what does this all mean? Ultimately, not a whole lot. The 555 is a versatile chip, but not a magical one. Despite what the NA555 datasheet says, the 555 is not a precision device by modern standards, but it is still an easy way to get a square(-ish) wave around the desired frequency.

With that said, not all 555s are created equal.

The NA555 with all its flaws still works well enough and has a low price. So, for any sort of “crude” timing, it should work well. If, however, the circuit making use of the timer output requires a cleaner signal, then I’d reach for something better.

The ICM7555 is very good. It produces a nice clean output with reasonably fast edges, but not as fast as the TS555. Unfortunately, the performance costs extra—an ICM7555 is about twice the cost of a NA555.

All things being equal, the TS555 and ICM7555 are on par. One has a faster edge, the other has less ringing (and is still actively manufactured). I’ll save the TS555 for future benchmarks. Depending on the application, I’ll either use a NA555 or ICM7555.

Relative __FILE__ With CMake Staring at the C

I have the misfortune of maintaining some things using CMake. One major annoyance is that __FILE__ is an absolute path, and that can’t be changed in CMake itself. Like most CMake annoyances, you can find a discussion online from about 15 years ago, but no sign of an actual fix.

Instead, you need a hack: this - I think - is the simplest one.

First, in our top-level CMakeLists.txt, we’ll define this helper function:

function(add_srcs NAME)
  set(${NAME} ${ARGN} PARENT_SCOPE)
  foreach(f IN LISTS ARGN)
    file(RELATIVE_PATH b ${CMAKE_SOURCE_DIR}
         ${CMAKE_CURRENT_SOURCE_DIR}/${f})
    set_source_files_properties(${f} PROPERTIES COMPILE_DEFINITIONS
                                "__FILE__=\"${b}\"")
  endforeach()
endfunction()

This will take each of the arguments, convert each file into a path relative to the top-level directory, then re-define __FILE__ on a per-source-file basis. We also set() a variable for our parent scope to use.

We’ll also need -Wno-builtin-macro-redefined.

Then, in each child CMakeLists.txt, we will do something like:

add_srcs(MYCODE_SRCS mycode.c mycode.h)
add_library(mycode ${MYCODE_SRCS})

add_srcs(CODE2_SRCS code2.c code2.h)
add_library(code2 ${CODE2_SRCS})