Blog

This post presents the various options one may use to synchronize WALT nodes, and what will change with WALT version 11. Many IoT experiments require precise synchronization between nodes, so it was one of the first features we worked on when designing WALT. Here is a short history of our main steps on this topic: 2013: One of our interns compared the accuracy of NTP and PTP for synchronizing our Raspberry Pi boards. 2015: When the setup procedure of the WALT server was first automated, the WALT server was already equipped with an NTP service. 2016 (included in WALT 1.0): We added a PTP service to the setup procedure too. 2019 (included in WALT 2.0): We included a generic mechanism to synchronize all nodes on bootup. 2026 (to be included in WALT 11.0): The generic synchronization will be improved, as shown below. Current synchronization options Option 1 - PTP: Precision Time Protocol The WALT server is equipped with a PTP service, so when a node boots a WALT OS image equipped with a PTP daemon, its clock is precisely synchronized with the server’s clock. That is the case with default images of Raspberry Pi boards for instance. ...

WALT relies on the famous docker technology to pack its OS images. For some users, this underlying technology may remain unnoticed (e.g., when just using high level tools such as walt image shell). However, if you want to build a new image from scratch, or make the image build process more reproducible, working with a Dockerfile is the solution. This post proposes a few tips and best practices regarding the writing of Dockerfiles. ...

The walt command line tool provides handy auto-completion features (since WALT 8.0 for bash, and WALT 9.0 for zsh). This post describes how to set up auto-completion (if not working directly on the WALT server), presents some of its features, and provides a few insights of how it works. Setup (if needed) Bash and zsh auto-completion are automatically set up when you install or upgrade the WALT server. So if you use walt directly on the server (typically using your SSH account) there is no setup step needed. However, if you use the walt client tool on another machine, you will have to follow the few setup steps described in the documentation page for enabling the shell completion, and repeat these steps when you upgrade this walt client tool. ...

Historically, the walt command was the only way to interact with a WALT platform. So, to automate experiments, users had to resort to shell scripts. Since then, a handy python scripting feature was introduced with WALT 8.0. This post proposes a short overview of this feature. You can get more details by looking at the related documentation pages. Python setup If not already in a python virtual environment, we should initialize one and activate it: ...

WALT is best known for working with Raspberry Pi boards. Early versions of the software proposed only this kind of node. Virtual nodes were then introduced in WALT 2.0, in April 2019. The main purpose at this time, for us, was to ease the setup of automated tests of the WALT software. But virtual nodes could also be used for experiments. Six years later, various features have been added to virtual nodes, making them even more handy and useful, as this post will recap. ...

The default boot mode of WALT nodes, network boot mode, was described in the previous post. Experience confirms that it is suitable for most experiments. The alternative boot mode we describe below can be used when this is not the case. Network boot mode: short reminder Let’s start with a short reminder about the default boot mode of WALT nodes, i.e., network boot mode. Refer to the previous post for more details. As of WALT version 10, the network boot mode can be described by the following figure: ...

Unlike various other systems such as Mender or Kubernetes, WALT was designed from the ground-up for experimentation and testing, not for building production systems. In this context, the default boot mode of WALT nodes (i.e., network boot mode) has some interesting features. However, some of the consequences of this mode may surprise new users. Reproducibility at each reboot If you are used to WALT, you probably noticed the message displayed when using walt node shell: ...

WALT offers powerful tools to customize an OS image, as demonstrated in the previous blog post. Upon reflection, the curious user might wonder how the WALT server, which has a classical x86 CPU, can customize OS images that often target a different CPU architecture (e.g., an ARM CPU architecture for a Raspberry Pi image). How can a command such as walt image shell handle this scenario? Introduction Let us consider the command walt image shell specifically.1 ...

OS customization is a very easy task with WALT, and it is probably one of the most popular features. Users can very quickly adapt one or more OS images to their research experiment or industrial test, and then boot these custom OS images on nodes in a snap. Let’s start by a quick reminder. Behind the scene, WALT OS images are just docker-compatible container images. However: WALT only uses this container image format for packaging OS images. The deployment on nodes relies on Network Boot instead. Unlike a usual container image, a WALT image contains not only an application but the whole OS, including a Linux kernel and bootloader scripts. For more info, check out the blog post presenting the concept of Network bootable containers. ...

This post is a bit more developer-oriented than usual. It describes a powerful python source code tracing system recently introduced in WALT. You can get more details by looking at the new developer documentation we introduced with WALT 9.0, more precisely at this page. Purpose of Trackexec Since WALT 9.0, the server component now includes a powerful tracing system called Trackexec. It is useful for replaying a previous run of the python code, for post-mortem analysis, or for analyzing code paths. ...