[time-nuts] In search of ways to improve Raspberry Pi stratum 1server

Chris Albertson albertson.chris at gmail.com
Mon Jan 12 17:59:14 EST 2015

Your antenna could be better.  But really the bottle neck on any NTP
server is time stamping the PPS.  There is greater uncertainty in the
time stamp then of the PPS.   The best solution ever (I can't find the
link) was done using an external clock.  It was a low power Intel PC
running BSD and the system clock was an external counter running off
some kind of precision crystal oscillator.  The PPS would sample the
counter then interrupt the PC.  The PC could be as slow as it likes
responding to the interrupt because the time is already sampled.   The
OS got it's time from this earth clock too.   Yes some modification
the Kernel was required but it's simple.  This removed an unknowable
interrupt latency.

Look at the Linux PPS driver code.  It is very simple.  It samples the
internal counter then sets a flag to say a sample is received.  NTP
only has to be fast enough to read the sample before the next PPS.
What these guys did was make the counter external driven from
something like an OCXO.

On Mon, Jan 12, 2015 at 7:25 AM, David J Taylor
<david-taylor at blueyonder.co.uk> wrote:
> Hi all,
> This is my first post to the list. I have a Raspberry Pi B+ and a HAB
> Supplies U-Blox Max-M8Q set in stationary mode connected to a Virgin Media
> Superhub (broadband router) by a 0.5m cat7 ethernet cable. The GPS is
> attached to the Pi's GPIO and has an external active antenna placed on an
> inside window sill. The Pi is running Raspbian on a fast Class10 microSD
> card and has a kernel (Linux raspberrypi 3.12.35 #1 PREEMPT Sun Jan 11
> 17:40:22 GMT 2015 armv6l GNU/Linux) rebuilt to disable tickless, enable PHY
> timestamping and enable all appropriate PPS options, and has NTP
> 4.2.8p1-beta5 compiled with:
> []
> I've tried using Banana Pi and Beaglebone Black SBCs and have also used
> u-blox Max-7Q and Trimble Copernicus II GPS breakout boards with no
> improvement (The Banana Pi is the best but is stuck on the Allwinner 3.4
> kernel, which I'm not thrilled about), leading me to believe the roadblock
> to a more precise clock lies in my less than ideal antenna setup, but my
> questions are: can I improve upon this and, if so, how? Have I made any
> obvious errors? I'm relatively new to this and would appreciate any advice I
> can get.
> Thanks,
> Neil.
> ===================================
> Neil,
> I see approximately the same here, with the exception of those systems using
> a kernel which /is/ tickless where the jitter is a factor of about two
> worse.  I can see anything wrong.
> I couldn't face recompiling the kernel another time, and have asked that
> nohz=no  be accepted by the stock kernel, particularly now that it includes
> PPS support.
> Based on plotting the jitter with MRTG the Raspberry Pi cards perform at
> least as well as an Intel Atom system running Linux.
>  http://www.satsignal.eu/mrtg/performance_ntp.php
> The Intel system did work rather better with FreeBSD, so it would be
> interesting to know whether the Raspberry Pi is capable of improved
> performance using that OS.  I would be most interested to know the outcome.
> Cheers,
> David
> --
> SatSignal Software - Quality software written to your requirements
> Web: http://www.satsignal.eu
> Email: david-taylor at blueyonder.co.uk
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.


Chris Albertson
Redondo Beach, California

More information about the time-nuts mailing list