The BeagleBone Black & Raspberry Pi as NTP servers

Introduction

This a revised version of a page which tries to answer the question of how much better an NTP server for remote PCs the Beagle Bone Black would make than a Raspberry Pi.  They are both simple but powerful Linux computers on a card powered from a single +5V supply (over USB) and have an Ethernet and other ports.

So the major hardware difference which people have discussed is the direct connected Ethernet port on the BBB (BeagleBone Black) versus the USB-hosted Ethernet port on the RPi (Raspberry Pi).  All three cards were similarly configured, although the OS on the RPI was compiled locally and the other two were the most recent current downloadable versions at the time.  As far as I know, no similar comparison has been published.
 

BBB OS comparison and RPi Ethernet Latency tweaks

Two minor optimisations were made - choice of the BBB Linux variant and reduction of the RPi Ethernet latency.

BeagleBone Black OS version

The full BBB OS enables many unnecessary services for this application by default.  Here are graphs showing the difference in CPU loading between full (up to 14:00 March 22) and console (after 16:00 March 22) Linux builds.  In this display of the results, the offset is sampled at five minute intervals by MRTG.

Another set of data from which results can be displayed is the loopstats reported by NTP itself, if you enable that in the ntp.conf file.  Here are plots of what data was available before and after the change of OS.  The offset reported by NTP shows a more spiky nature with the full OS, and that spikiness is not as not as easily seen in the MRTG data.  The one-hour RMS jitter (black line in the graph below) is always under 2 microseconds with the console OS, but varied up to over 4 microseconds with the full OS.

The jitter is also less spiky, although possibly at a slightly higher base level.  Even the 2-hour averaged jitter show much less variation.

Raspberry Pi - reducing the Ethernet latency

I was delighted to receive a note from Philip Gladstone about reducing the Ethernet latency on the RPi.  Details are here.  I was able to put this to the test recently, and from a Raspberry Pi which had been running for a while, I made the change to cmdline.txt and rebooted, with the following effect on NTP delay as reported by a remote PPS-locked server:

The delay has been reduced from ~0.51 to ~0.35 milliseconds.  Linux ping times showed a similar improvement:

For comparison, here is a similar plot from the BBB, which does not have the Ethernet via USB configuration, and hence a considerably smaller peer delay:

Configuration note

Both BBB & RPi were fitted with similar GPS units which were to hand (Adafruit), but the locations were different.  Examination of the loopstats shows that the poll interval remained at 16 for both systems, so the PPS signal was adequate at all times.  However, on powering up the BBB it was noticed that its GPS didn't lock, and a short while later it was noticed that an adjacent RPi's GPS wasn't locking either.  To get the BBB working it was necessary to add a separate magnetic mount GPS antenna, as the board itself seems to produce enough interference to block nearby GPS reception.  The BBB was subsequently relocated away from other GPS receivers.  

This interference issue could be a serious problem if a compact unit is desired, whereas mounting a GPS card on the RPi presents no such problems.  The best performing GPS receiver I have found to date is the ublox 8Q unit, such as used in the HAB supplies card.
 

Individual performance

CPU usage and reported NTP offset

The NTP offset as reported by the BBB is rather worse than that of the RPi.  Both systems are using GPS/PPS sources with kernel-mode PPS interrupt handling, but without the kernel PLL timekeeping.

BBB Console OS
RPi 1

 
NTP status reports

Using the command   ntpq -crv -ckerninfo <node-name>   we get:

associd=0 status=0115 leap_none, sync_pps, 1 event, clock_sync,
version="ntpd 4.3.10@1.2483 Sun Mar 22 14:54:01 UTC 2015 (1)",
processor="armv7l", system="Linux/3.8.13-bone70", leap=00, stratum=1,
precision=-19, rootdelay=0.000, rootdisp=1.120, refid=kPPS,
reftime=d8ba3db1.e817e0f9 Mon, Mar 23 2015 7:22:25.906,
clock=d8ba3dba.9c377a3f Mon, Mar 23 2015 7:22:34.610, peer=59576, tc=4,
mintc=3, offset=0.001402, frequency=-45.784, sys_jitter=0.002778,
clk_jitter=0.003, clk_wander=0.001

associd=0 status=0115 leap_none, sync_pps, 1 event, clock_sync,
pll offset: 0.001216
pll frequency: -45.7837
maximum error: 0.0055
estimated error: 2e-06
kernel status: pll nano
pll time constant: 4
precision: 1e-06
frequency tolerance: 500
pps frequency: 0
pps stability: 0
pps jitter: 0
calibration interval 0
calibration cycles: 0
jitter exceeded: 0
stability exceeded: 0
calibration errors: 0

associd=0 status=0118 leap_none, sync_pps, 1 event, no_sys_peer,
version="ntpd 4.3.10@1.2483 Sun Mar 22 11:48:29 UTC 2015 (1)",
processor="armv6l", system="Linux/3.6.11", leap=00, stratum=1,
precision=-19, rootdelay=0.000, rootdisp=1.045, refid=KPPS,
reftime=d8bfec66.e85b463b  Fri, Mar 27 2015 14:49:10.907,
clock=d8bfec6a.cafe8569  Fri, Mar 27 2015 14:49:14.792, peer=17152, tc=4,
mintc=3, offset=-0.000039, frequency=-52.747, sys_jitter=0.001907,
clk_jitter=0.002, clk_wander=0.000, tai=35, leapsec=201507010000,
expire=201512280000

associd=0 status=0118 leap_none, sync_pps, 1 event, no_sys_peer,
pll offset:            -3.6e-05
pll frequency:         -52.747
maximum error:         0.003
estimated error:       1e-06
kernel status:         pll nano
pll time constant:     4
precision:             1e-06
frequency tolerance:   500
pps frequency:         0
pps stability:         0
pps jitter:            0.000
calibration interval   4
calibration cycles:    0
jitter exceeded:       0
stability exceeded:    0
calibration errors:    0

 
The view from afar

The question is more whether the USB connection of Ethernet produces a degradation of the time offered to a remote PC, so a Linux PC also with a GPS/PPS source was configured to measure the peerstats of each of these three devices, with the following results.  The results, for the day of 2015-Mar-26, are presented sorted in two ways: ascending RMS offset, and ascending RMS jitter.

Using BBB Console Linux

Sorted by RMS offset

Peer           Number   Mean    RMS    Minimum Maximum  Mean  Minimum  Maximum   Mean   Mean RMS
                of     Offset  Offset   Offset Offset  Delay   Delay    Delay Dispersion jitter
              entries   (ms)    (ms)     (ms)   (ms)    (ms)    (ms)	(ms)    (ms)    (ms)
127.127.22.0 	5400 	0.000 	0.002 	-0.005 	0.007 	0.000 	0.000 	0.000 	0.233 	0.002 
192.168.0.73 	581 	-0.001 	0.009 	-0.028 	0.035 	0.394 	0.341 	0.430 	1.316 	0.020 
192.168.0.83 	646 	-0.016 	0.018 	-0.035 	0.008 	0.173 	0.130 	0.193 	1.323 	0.007 
192.168.0.7 	597 	0.019 	0.029 	-0.076 	0.072 	0.209 	0.151 	0.259 	1.321 	0.021 
192.168.0.71 	600 	-0.038 	0.039 	-0.079 	-0.007 	0.352 	0.303 	0.423 	1.425 	0.029 
192.168.0.8 	583 	0.024 	0.045 	-0.083 	0.121 	0.201 	0.132 	0.315 	1.335 	0.031 
192.168.0.1 	583 	-0.005 	0.049 	-0.152 	0.128 	0.167 	0.113 	0.240 	1.282 	0.065 
127.127.28.0 	5400 	-1.526 	4.500 	-11.064 9.622 	0.000 	0.000 	0.000 	1.271 	3.217 

BBB:    192.168.0.83    0.018 ms
RPi 1:  192.168.0.71    0.039 ms

Sorted by mean RMS jitter

Peer           Number   Mean    RMS    Minimum Maximum  Mean  Minimum  Maximum   Mean   Mean RMS
                of     Offset  Offset   Offset Offset  Delay   Delay    Delay Dispersion jitter
              entries   (ms)    (ms)     (ms)   (ms)    (ms)    (ms)	(ms)    (ms)    (ms)
127.127.22.0 	5400 	0.000 	0.002 	-0.005 	0.007 	0.000 	0.000 	0.000 	0.233 	0.002 
192.168.0.83 	646 	-0.016 	0.018 	-0.035 	0.008 	0.173 	0.130 	0.193 	1.323 	0.007 
192.168.0.73 	581 	-0.001 	0.009 	-0.028 	0.035 	0.394 	0.341 	0.430 	1.316 	0.020 
192.168.0.7 	597 	0.019 	0.029 	-0.076 	0.072 	0.209 	0.151 	0.259 	1.321 	0.021 
192.168.0.71 	600 	-0.038 	0.039 	-0.079 	-0.007 	0.352 	0.303 	0.423 	1.425 	0.029 
192.168.0.8 	583 	0.024 	0.045 	-0.083 	0.121 	0.201 	0.132 	0.315 	1.335 	0.031 
192.168.0.1 	583 	-0.005 	0.049 	-0.152 	0.128 	0.167 	0.113 	0.240 	1.282 	0.065 
127.127.28.0 	5400 	-1.526 	4.500 	-11.064 9.622 	0.000 	0.000 	0.000 	1.271 	3.217

BBB:     192.168.0.83    0.007 ms
RPi 1:   192.168.0.71    0.029 ms

Should you wish to analyse the original peerstats and loopstats you can download them here.

IP addresses and locations

Conclusion

On the basis of this fairly simple test, the BBB is the better server when measured either in terms of the RMS offset or the RMS jitter seen at a remote node on the same LAN.  However, both card computers are more than adequate as an NTP server for a large majority of environments, and if you really want to do better you need to attach a PPS source to your PC.  Be aware of the potential interference to GPS which a BeagleBone Black may create.  Support is arguably better for the much more popular Raspberry Pi, and this is a factor which should not be overlooked.

The base BBB Linux is supplied with far too many services enabled and running (e.g. Apache Web server) to make the best NTP server, so the much stripped down Console variant is recommended instead.  Note that with this variant you will need to add quite a few utilities such as a compiler before you can even build NTP.

I would welcome further comments, which may be quoted and acknowledged here.

My thanks to those who have more experience than me with these small card computers and the Linux operating system they run.
 

Comments via Twitter and the time-nuts list

@PaulM: I've had words with PCB layout experts about the BBB PCB layout. "Better" was not among them.

@2e0sql: I was never impressed with mine (BBB).

@asridge: Interesting read David, thanks!! was looking at the BB as an alt(ernative) to a Pi ... on the list of things to do, but you beat me to it.

Attila kinali: The BBB is known to have a bad EMI (RF interference) behaviour. You should not put any sensitive RF components near it, without proper shielding.

Update

During 2019 I acquired a couple of Raspberry Pi 4B cards, where the Ethernet is gigabit, and with a more direct connection to the CPU, so I thought it would be interesting to compare.  Unfortunately the LAN configuration has changed, so the results are not directly comparable.

New configuration:

Results - 2019-Nov-08

Peer           Number   Mean    RMS    Minimum Maximum  Mean  Minimum  Maximum   Mean   Mean RMS
                of     Offset  Offset   Offset Offset  Delay   Delay    Delay Dispersion jitter
              entries   (ms)    (ms)     (ms)   (ms)    (ms)    (ms)	(ms)    (ms)    (ms)
192.168.0.93 	1696 	0.025 	0.056 	-0.105 	1.205 	0.254 	0.200 	0.287 	10.787 	0.009 
192.168.0.71 	1696 	0.006 	0.055 	-0.051 	1.272 	0.464 	0.361 	0.528 	10.443 	0.016 

Previously, the model B had a mean delay of 0.352 ms, it now reports 0.464 ms.
The model 4B currently reports 0.254 ms, so 0.21 ms better.

 

Copyright © David Taylor, Edinburgh

@gm8arv on Twitter

Last modified: 2019 Nov 08 at 20:08