All Posts

“Smoke on the line in the Raines area” – whatever that means.
This is of course in the addition to running short formation trains due to a common type of carriage being “grounded” due to a suspected fault.

I’m currently running SmokePing in a container on a Mac mini – using Docker for Mac, and of course HyperKit. And after a couple of hours of running Hyperkit suddenly consumes all CPU allocated to it, and freezes the container. Nothing short of killing Hyperkit will stop or restart the container.


And trying to read up on this reveals a lot of postings with this problem, but very few (if any) consistent solutions.

Fairly frustrating.

What seems to be a common thread is the use of the MacOs filesystem to persist data from the applications running in the container. In my case Smoking stores all its configuration and data files in a configurable place in the hosts filesystem through a setup like this :

docker create –name smokeping -e PUID=1000 -e PGID=1000 -e TX=Europe/London -p 82:80 -v /Users/gisvold/docker/smokeping/config:/config \
-v /Users/gisvold/docker/smokeping/data:/data –restart unless-stopped linuxserver/smokeping

Running “top” inside the container show no real cpu usage in the container


And it does not increase significantly up until the moment it freezes the container and my terminal session is terminated by the container.

So it looks like Hyperkit is the problem here, and reading documentation there seems to be a possibility that the use of the MacOs filesystem to store the data files may be the culprit, but with one new theory I have on why.

It runs out that there is a new configuration for syncing filesystem data between the host OS and the container.

According to the official documentation of Docker for Mac,
Docker 17.04 CE Edge adds support for two new flags to the docker run -v, –volume option, cached and delegated, that can significantly improve the performance of mounted volume access on Docker for Mac.
There are 3 different flags that you can use in the –volume option:
consistent: perfect consistency (host and container have an identical view of the mount at all times)
cached: the host’s view is authoritative (permit delays before updates on the host appear in the container)
delegated: the container’s view is authoritative (permit delays before updates on the container appear in the host)

So I have tried the following new configurations :

docker create –name smokeping -e PUID=1000 -e PGID=1000 -e TX=Europe/London -p 82:80 -v /Users/gisvold/docker/smokeping/config:/config:cached \
-v /Users/gisvold/docker/smokeping/data:/data:cached –restart unless-stopped linuxserver/smokeping

This did not help, so the last option was :

docker create –name smokeping -e PUID=1000 -e PGID=1000 -e TX=Europe/London -p 82:80 -v /Users/gisvold/docker/smokeping/config:/config:delegated \
-v /Users/gisvold/docker/smokeping/data:/data:delegated –restart unless-stopped linuxserver/smokeping

In addition to this I excluded the data directory from Time Machine backups – as there are around 80 RRD database files there – and this means that they change constantly, and all of them are therefore being backed up every hour, or rather every 2 hours, coinciding with the extremely high CPU load.

For now the container has been running with very low Cpu usage  < 4% – but it has only been 4 hours so I’m not going to break out the champagne yet.


We have a SmartCitizen node in one of our courtyards ( which gies us cute a lot of data – including the all important laser based dust sensors – look it up.




Snow forecast for Thursday in Norway – time to change to winter gear 


In Hyde Park.

We have a flat with very thick walls – giving us problems with wireless connections. We have a mesh network (TP-Link Deco P7’s) with Powerline backhaul. The theory was that when wireless signals could not go through the walls we would fall back to running the network over the mains cables between mesh access points.

The real challenge comes from the difficulty in finding intermittent problems on the network, and the series lack of any decent admin functions on the P7’s.

The mash network has 6 nodes, where the first one is connected to main router with a Ethernet cable. The rest of the mesh is using Powerline or the wireless network between them dynamically. Unfortunately there is no real way to know how each node is communicating with the other nodes.

I’ve tried most things I could think of and feel we are in a good place with the connectivity at the moment, with the exception of my wife’s studio. And kit in the room occasionally has problems.

In the end I installed one of the oldest and first monitoring systems I ever used – Smokeping. And it’s still one of the few latency and network error measurement and login tools I can find. But it’s a very difficult install under OsX – even though I had done it before. So this time I went modern, and downloaded a pre-made setup in a Docker container – and started configuring the monitoring tools.

It now looks like this


And look at the packet loss line – 10% packet loss on average. And it was even worse for the printer :


Average packet loss of 93% – its a wonder it ever works! But both these devices are connected to the same Access point – the Printer using a Ethernet cable – and the AppleTV using wireless.

So now I have a starting point – the cable between the access point and the printer is now the next thing to be inspected – but that’s for another day.

So SmokePing works very well for this type of investigation.

Btw. Here is the page for all access points :


And here it is :

I started using Ikea’s Trådfri smart lighting soon after it was launched in the UK, and so far I have motion sensor, lightbulbs, control outlet, a light panel and their LED Drivers.

It all works, sort of. It’s not a bad idea, and when it works it’s ideal for the kind of flat we now have, where the living room has multiple lighting circuits and > 24 light points.

But here comes the challenges – at some stage you want to automate your system with one of the IOT control system from for example Apple – their Home system. So I bought a Trådri gateway, plugged it into the house via Ethernet and configured it.


It all worked well for a period of time, but then it lost contact with Apple Home, and I tried to add it in again. And I tried everything I could find, including resetting both the gateway and Apple home, removing all bulbs and remote controls, resetting all remote controls etc. I even changed the names of all bulbs to something very simple and using just English language – as it was clear it struggled with Scandinavian characters and special characters.

This went on for more than a month, and after having read all Reddits I could and tried all the solutions other users had found I went for the last ditch one – and bought a new gateway.

This worked – and now I have a system working, after manually adding 28 bulbs, 4 remote controls, 2 outlets and 2 motion sensors. And they all had to be added in both Tradfri and in Apple Home, but it works so far.

Ikea – this is not good enough, and this is possibly why new additions to the Trådfri family has been delayed. The idea is good – but the execution is not good enough.

From The Times – quoting Jeremy Paxman – and I find myself agreeing with him unfortunately. British politics baffles me at the moment


For the first time ever I discovered that Ikea has installed a public WiFi network. Welcome to our century :