As mentioned in our previous post, we have patched a Raspberry Pi kernel to support the use of the RADclock software. Since Pi is new to us, first things first. We wanted to get a feel for how stable its oscillator is, and what the NIC noise looks like. Clearly, it is a tiny device, so we expect to see bad temperature impact on the oscillator stability. It also has become apparant that the ethernet controller is combined with the USB controller. This does not appear to be a good sign for the timing world... or is it?
Raspberry Pi Setup
We have a Raspberry Pi Model B from October 2012, the one which provides 512MB of RAM. Our Pi is running Raspbian Linux. The existing x86 Linux 3.2.2 patch for RADclock only needed a few ARM conversions. With thoes in place, we were up and running a 3.2.27 Raspian Linux kernel with RADclock. See my previous post for the details.
We placed the Pi in our testbed and applied our NIC noise estimation methodology. Here the RADclock daemon on the Pi is synchronising over NTP to a SyncServer S350 on the LAN (thanks to Symmetricom for hooking us up). RADclock is essentially used in this setup to collect data to understand the Pi characteristics, we were not looking at RADclock performance (don't worry we will do that soon).
Before I get started, much of this analysis is from Julien, and I reworded a bunch of what he wrote to fit the context of this posting. Some of the words are his, some are mine, and the others are from the voices in our heads.
The graphic below shows the system noise on the Pi. This is the Pi-to-DAG component of the RTT, we call this value "RTThost". The timeseries and corresponding histogram show a median RTThost at about 285 microseconds, and a large Inter-Quartile Range (IQR) of about 62 microseconds.
A "good card" would show a median RTThost at about 30 microseconds and an IQR of 2-3 microseconds (see Intel PRO 1000 on this page for example). We see here that the Pi adds a fair bit of latency and with large variability to the packet timestamping. The Ethernet controller used on the Pi is connected to the SoC via USB, that is likely the cause of this large latency. Consequently, the Pi is good enough to do packet timestamping over WAN (with RTT > 5ms, that's a timestamping error below 5%). However, do not expect anything meaningful for a 1Gbps LAN (the RTT over a couple of switches being usually around 300 microseconds).
The Raspberry Pi does not ship with a TSC or HPET counter to use as clocksource. Instead it relies on the STC that raspbian presents as a clocksource. Based on the source code, "STC: a free running counter that increments at the rate of 1MHz".
Already, this tells us that the smallest meaningful timestamp resolution on the Pi is 1 microsecond. But how stable is that counter (or more accurately, the oscillator the counter is built upon)?
Here we have measured the Allan deviation somewhat indirectly using a few combinations of hardware / software measurements (understand, no oscilloscope has been harmed during this capture). Good news, the STC shows very good stability, equivalent to most measurements we have made on desktop / server x86 hosts. This is especially good knowing that the Pi was in a server room with a very-nastily-over-provisionned-A/C-system. Tick of approval for the tiny board!
The STC counter on the Pi shows a pretty stable characteristic, and definitely equivalent to common NTP servers out there. The Pi should then behave as a decent NTP client, and can definitely serve time over the network for others.
The network stack characteristic is pretty noisy however. The high variability of the packet timestamping will definitely impact the final clock performance of the Pi and puts a limit on the accuracy that can be achieved.
RADclock is pretty good at filtering noise from NTP packets, so it should be able to do some magic here. Wait for our next post to see what we can achieve :).