WirelessMoves – Page 2 – My Thoughts on the Evolution of Wireless, FOSS and the Past, Present and Future of Computing

The Old Cloud – CPU and Disk Performance

In the previous, I have taken a first look at Scaleway’s bare metal servers that are around 10 years old at the time of writing. Compared to other companies offering more recent hardware, their prices are significantly lower for some of their configurations. Despite the dated hardware, the offer is still interesting to me, as my main two requirements is RAM and disk space. Performance is only a secondary requirement, as my services are only used by a few people concurrently. But still, it would be good to know how Scaleway’s old servers compare against other offers. The two most important data points for me are CPU and SSD performance. So here we go:

The Old Cloud

In the previous post, I’ve been looking at a number of different companies that offer bare metal servers in their data centers. An interesting offer that is also the cheapest one I have found so far is from Scaleway. For a monthly price of 33 euros, they offer an Intel Xeon E3 E1220 or equivalent based server with 32 GB of RAM and 2x 1 TB SSDs, located in one of their Paris data centers. Compared to prices elsewhere this is very cheap. So where’s the catch?

Who Rents-Out Bare Metal Servers and How

Following on from the previous post about having a plan C for a bare metal server in the cloud for running my own services, I’ve had a look at a number of different data center operators in Europe and how they offer bare metal servers. I’ve been very happy so far with Hetzner, as they make it very simple to rent a physical server and get an operating system installed. If you already have an account, that bare metal server is only a few clicks away. Entry level offers with two 500GB SSDs start around 50 euros a month, currently without an installation fee, give or take a few euros. So what are others doing?

The Gigabit At Home Now a Requirement

And here we go, another capacity / demand cycle is coming to a close. The voices are getting weaker, but every now and then, people still ask me why somebody needs a 1 Gbps fiber link at home.

It is a valid question, and from my personal experience I could answer it so far that I frequently transfer large amounts of data, and I feel quite limited by my 100 Mbps VDSL line I have in Cologne, with no fiber in sight. I have definitely outgrown my VDSL line. So perhaps I am a bit of a special case. Well perhaps. But now, first main stream games are coming to the market that stream most of the data and content they require from servers ‘in the cloud’.

The Hetzner Plan C

Once upon a time, not so long ago, I decided to duplicate my services running on a bare metal server at home on a bare metal server I rent in a Hetzner data center. This has worked out really well. As the server offers ample capacity, I have additionally migrated quite a number of virtual machines with public IP addresses to it. In other words, there are a number of services now for which I do not have a redundant copy at home. So I needed a ‘Plan C’ in case that server goes south one day. Recently, I became aware of one more reason why that server could suddenly ‘go offline’ that had me raise an eyebrow: Malicious outgoing port scanning activities.

VoLTE / VoWifi Transfer Smoothness

Perhaps a bit of a strange title but I recently attended an event that had excellent LTE/5G coverage outside buildings, and good Wi-Fi coverage mainly inside buildings. In other words: A good opportunity to have a look at how well an ongoing IMS voice call is switched between LTE (VoLTE) and Wi-Fi (VoWifi) these days.

Tcpdump Inside a Container – What Can I See?

Using tcpump to trace on a Docker virtual bridge interface to see the traffic between all connected containers (see previous post) got me thinking a bit: What can I see if I ran tcpump inside a container connected to a bridge? Will I only be able to see my own traffic, or would I be able to see traffic between other containers as well?

Wireshark and Containers behind Proxies

If your web services run in Docker containers behind reverse proxies, you can of course run a tcpdump / Wireshark trace on the physical Ethernet interface of your server, or on the virtual Ethernet interface of the virtual machine your containers run in. That’s nice, but it only gives you the encrypted https traffic. So if your http server logs are not enough for debugging, it would be really nice to get to the unencrypted http traffic.

There are methods to forward the encryption keys from web browsers and servers to Wireshark, which will then do the decryption for you, but that’s a bit inconvenient. So let’s look for something that is easier to do: If you run your web services in containers behind a reverse proxy, it’s possible to remotely trace the decrypted requests via Docker’s virtual bridge interface to which the web services are connected to!

Power and Fan Management With Ubuntu on Notebooks

When you look back a decade or so, one of the things that sometimes was a bit of a hassle when installing Linux on a notebook was to get fan control working correctly. And correctly means that the fan doesn’t run all the time, or on full speed for just a few seconds when the temperature rises, just to stop again and then repeating this every few seconds. Also, I noticed in the past that power control, which is a related topic, was sometimes not working well with older Linux kernels. As soon as the temperature started to rise, the CPU clock frequency went to the lowest possible setting and just remained there for a long time. In other words, the notebook would run fine, but was seriously lacking performance. Fortunately, this seems to be something of the past, and I didn’t have to tweak anything in that regard on the Lenovo and HP notebooks I installed Ubuntu on in the past two years. That being said, there are some interesting differences how power and heat management is handled on different notebooks with the same Ubuntu Linux (22.04), and I thought I’d document this here for my and your reference.

A Small Ubuntu in a Docker Container

Recently, I wanted to try out a few things around networking in a Docker container environment. What I wanted to have was a simple container I could open a Bash shell in. Turns out that it’s actually quite easy to do. As I wanted to play around with some options, I decided to use a docker-compose yaml file instead of instantiating the container from the command line. So here’s the docker-compose.yml content: