Debian/Ubuntu, systemd, NTP, and something called timesyncd

Unix, for years, has had a program called ntpd to use the NTP (Network Time Protocol) service to set time.  The ntpd service is a pretty advanced thing – it can do basic “set your workstation’s time” type of tasks, but it can also do things like talking to atomic clocks, providing time service to other machines via multicast or broadcast, and doing some pretty sophisticated network time synchronization which tries to avoid one or two bad network server clocks from impacting your local time. It also allows for authentication, which is a hard requirement in some environments.  For instane, PCI, the standard for processing credit cards, says, “time data must be protected.”  This is section 10.4.2 of the PCI-DSS, which while not explicitly requiring authentication, is clearly not a bad thing to have authentication.

I love ntpd.

The systemd people on the other hand, apparently hate it.  They went the same direction as some other popular mass-market operating systems and decided NTP is too complex to implement.  So they implemented SNTP (Simple NTP) only, and only in client mode. So it doesn’t function as a server. It doesn’t do authentication. It doesn’t track jitter and delay over time. It doesn’t try to make time jumps only in a forward direction.  It doesn’t do any number of other things to keep your time accurate.

Sure, it was easier for the systemd people’s world view. When a new network interface comes up, this service tries to fetch the proper time based on that network interface’s configuration. That’s cool – but the same thing can be done with NTP fairly easily. And there is a place for SNTP – embedded systems with limited resources. Not on computers with enough processing power to run, say, Unity (Ubuntu’s default GUI).

So here’s how to do replace it with real ntpd:

First, remove the systemd-timesyncd.service startup script:

rm /etc/systemd/system/systemd-timesyncd.service

Next, create /lib/systemd/system/ntp.service with the following contents:

[Unit]
Description=NTP
After=network.target auditd.service

[Service]
EnvironmentFile=-/etc/default/ntp
ExecStart=/usr/sbin/ntpd -n $NTPD_OPTS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure

[Install]
WantedBy=multi-user.target
Alias=ntpd.service

Then link this to /etc/systemd/system/ntp.service:

ln -s /lib/systemd/system/ntp.service /etc/systemd/system/ntp.service

Then restart systemd:

systemctl daemon-reload

Now you can start NTP normally:

systemctl start ntp

Now you have workable NTP!

How Much Power Does a Raspberry Pi Draw?

There’s been an interesting, albeit somewhat off-topic, discussion on the NANOG mailing list about a theoretical project consisting of thousands of Raspberry Pis networked together, presumably doing some sort of clustered computing task.  I’m not sure this is actually efficient (I’m thinking a high end video card is probably a better use of money, power, and time), unless of course someone is doing it merely for the joy of doing it (in which case, I want to see pictures of it when done).

One of the obvious things you need to do is to power and cool such a beast – while one Pi puts out negligible heat, hundreds or thousands start to put out real heat.

So how much does a Pi draw?  I didn’t pull out my newer Pi’s but I pulled out an older one and hooked it to a lab power supply, as shown:

Setup of Pi for power usage  monitoring

Setup of Pi for power usage monitoring

I apologize that the board is a bit out of focus, but essentially I just powered the Pi via the expansion header pin 2 (5V) and the shield of the USB port (for 0V). It wasn’t hooked up to a USB supply.  I use a USB stick for my root file system (I just use the SD card for boot) because it performs significantly better than an SD card – I’ll write an article sometime on how to do this. However, that USB stick has some power draw, so a typical Raspberry Pi Model B will probably draw slightly less without that external storage. That said, I think I’m in the ballpark.

I read idle power (sitting at a Linux prompt) and power at load (CPU in a busy loop along with a “ping -f” from another host on the LAN towards the Pi, to exercise the CPU, the USB subsystem, and the network system). Power usage was roughly 2.0 watts at idle and 2.3 watts at load.  I imagine it would be a bit higher if I also exercised the GPU.

100 of these would draw roughly 2,300 watts at load – that converts to nearly 8,000 BTU/hr, which is a healthy sized space heater (in the USA, a space heater that plugs into a standard outlet will be about 1,800 watts) you are putting in your datacenter.  Put 1,000 into your datacenter, and you’re talking 13 space heaters!

So, it’s not a trivial amount of power at scale – nor is it trivial when you have to run them on battery.  I run one of these in a motorcycle trailer (don’t ask, I’ll explain some other time!) off of batteries, and it can drain the small trailer battery (designed primarily for emergency breakaway brake activation) fairly quick. The trailer battery is a 7AH 12V lead acid battery – assuming a nominal voltage of 12.5V, and a perfectly efficient 12V to 5V power converter, we’re in the neighborhood of 200ma of draw from the battery – or 35 hours of runtime. In reality, it’s hard to draw that last bit out of the battery, and while my converter is efficient, it’s not perfect, so I assume more like 24 hours. Of course the Pi in the trailer is running some other things (namely some wifi interfaces), so actual runtime is significantly less than that – but as you can see, you start to need real batteries to run this thing. It’s not the low-power (at least at idle) electronics that sit in our phones.

Regardless, whether you are running a rack full of Raspberry Pi computers or just one off of battery, heat and power are actual, real concerns anytime you are looking at doing something at scale or on batteries.