In search of ways to improve Raspberry Pi stratum 1 server
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:
./configure --enable-linuxcaps --enable-ATOM --enable-NMEA --disable-ipv6 --disable-all-clocks --disable-parse-clocks --disable-debugging
and with my ntp.conf file set up thus:
logfile /var/log/ntp.log
driftfile /var/lib/ntp/ntp.drift
statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats protostats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
filegen protostats file protostats type day enable
leapfile /home/time/leap-seconds.3629404800
server ntp0.catn.com iburst
server ntp2c.mcc.ac.uk iburst
server ntp1.luns.net.uk iburst
server ntp1.uk.uu.net iburst
server ntp.colinbarrett.co.uk iburst
server 127.127.20.0 mode 17 minpoll 4 maxpoll 4 prefer
fudge 127.127.20.0 flag1 0 flag2 0 flag3 0 flag4 0 time1 0.00000 time2 0.1137
server 127.127.22.0 minpoll 4 maxpoll 4
fudge 127.127.22.0 refid PPS time1 0.000 flag2 0 flag3 1
restrict default limited kod nomodify notrap nopeer
restrict 127.0.0.1
After an hour or so, "ntpq -crv -pn; ntptime; ntpq -c clockvar" shows:
associd=0 status=011d leap_none, sync_pps, 1 event, kern,
version="ntpd 4.2.8p1-beta5@1.3265-o Sun Jan 11 19:10:22 UTC 2015 (1)",
processor="armv6l", system="Linux/3.12.35", leap=00, stratum=1,
precision=-19, rootdelay=0.000, rootdisp=1.015, refid=PPS,
reftime=d85e39b2.e1489c74 Mon, Jan 12 2015 12:16:50.880,
clock=d85e39b4.0ea565be Mon, Jan 12 2015 12:16:52.057, peer=4258, tc=4,
mintc=3, offset=-0.000466, frequency=-17.209, sys_jitter=0.001907,
clk_jitter=0.001, clk_wander=0.000, tai=35, leapsec=201507010000,
expire=201512280000
remote refid st t when poll reach delay offset jitter
---============
*127.127.20.0 .GPS. 0 l 3 16 377 0.000 -1.066 2.801
o127.127.22.0 .PPS. 0 l 2 16 377 0.000 0.000 0.002
-87.124.126.49 195.66.241.3 2 u 34 64 377 29.758 8.186 0.977
-130.88.200.6 130.88.200.4 3 u 14 64 377 17.783 1.952 0.580
+217.114.59.3 158.43.192.66 2 u 7 64 377 15.947 4.033 0.814
+158.43.128.66 193.67.79.202 2 u 15 64 377 10.319 1.873 0.553
81.174.247.243 .INIT. 16 u - 1024 0 0.000 0.000 0.000
ntp_gettime() returns code 0 (OK)
time d85e39b4.49e7c8d4 Mon, Jan 12 2015 12:16:52.288, (.288693882),
maximum error 2000 us, estimated error 1 us, TAI offset 35
ntp_adjtime() returns code 0 (OK)
modes 0x0 (),
offset 0.000 us, frequency -17.209 ppm, interval 256 s,
maximum error 2000 us, estimated error 1 us,
status 0x2107 (PLL,PPSFREQ,PPSTIME,PPSSIGNAL,NANO),
time constant 4, precision 0.001 us, tolerance 500 ppm,
pps frequency -17.207 ppm, stability 0.004 ppm, jitter 0.507 us,
intervals 73, jitter exceeded 45, stability exceeded 0, errors 0.
associd=0 status=0000 no events, clk_unspec,
device="PPS Clock Discipline", timecode=, poll=828, noreply=0,
badformat=0, baddata=0, stratum=16, refid=80.80.83.0, flags=4
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.
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@blueyonder.co.uk
Neil
Welcome to time-nuts. You say that your antenna is less then ideal. OK on
time-nuts your going to find out details matter. So what does that mean?
Typically the antenna needs to be high enough to have a clear view of the
sky and it does matter.
But there have been posts in the past about the Pi and I think there are
internal issues with the Pi itself that may limit its use. Not an expert
and maybe one day I will build a Pi NTP server. To many other things
cooking.
Regards
Paul
WB8TSL
On Mon, Jan 12, 2015 at 7:30 AM, Neil Green ncguk@hotmail.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:
./configure --enable-linuxcaps --enable-ATOM --enable-NMEA --disable-ipv6
--disable-all-clocks --disable-parse-clocks --disable-debugging
and with my ntp.conf file set up thus:
logfile /var/log/ntp.log
driftfile /var/lib/ntp/ntp.drift
statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats protostats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
filegen protostats file protostats type day enable
leapfile /home/time/leap-seconds.3629404800
server ntp0.catn.com iburst
server ntp2c.mcc.ac.uk iburst
server ntp1.luns.net.uk iburst
server ntp1.uk.uu.net iburst
server ntp.colinbarrett.co.uk iburst
server 127.127.20.0 mode 17 minpoll 4 maxpoll 4 prefer
fudge 127.127.20.0 flag1 0 flag2 0 flag3 0 flag4 0 time1 0.00000 time2
0.1137
server 127.127.22.0 minpoll 4 maxpoll 4
fudge 127.127.22.0 refid PPS time1 0.000 flag2 0 flag3 1
restrict default limited kod nomodify notrap nopeer
restrict 127.0.0.1
After an hour or so, "ntpq -crv -pn; ntptime; ntpq -c clockvar" shows:
associd=0 status=011d leap_none, sync_pps, 1 event, kern,
version="ntpd 4.2.8p1-beta5@1.3265-o Sun Jan 11 19:10:22 UTC 2015 (1)",
processor="armv6l", system="Linux/3.12.35", leap=00, stratum=1,
precision=-19, rootdelay=0.000, rootdisp=1.015, refid=PPS,
reftime=d85e39b2.e1489c74 Mon, Jan 12 2015 12:16:50.880,
clock=d85e39b4.0ea565be Mon, Jan 12 2015 12:16:52.057, peer=4258, tc=4,
mintc=3, offset=-0.000466, frequency=-17.209, sys_jitter=0.001907,
clk_jitter=0.001, clk_wander=0.000, tai=35, leapsec=201507010000,
expire=201512280000
remote refid st t when poll reach delay offset
jitter
---============
*127.127.20.0 .GPS. 0 l 3 16 377 0.000 -1.066
2.801
o127.127.22.0 .PPS. 0 l 2 16 377 0.000 0.000
0.002
-87.124.126.49 195.66.241.3 2 u 34 64 377 29.758 8.186
0.977
-130.88.200.6 130.88.200.4 3 u 14 64 377 17.783 1.952
0.580
+217.114.59.3 158.43.192.66 2 u 7 64 377 15.947 4.033
0.814
+158.43.128.66 193.67.79.202 2 u 15 64 377 10.319 1.873
0.553
81.174.247.243 .INIT. 16 u - 1024 0 0.000 0.000
0.000
ntp_gettime() returns code 0 (OK)
time d85e39b4.49e7c8d4 Mon, Jan 12 2015 12:16:52.288, (.288693882),
maximum error 2000 us, estimated error 1 us, TAI offset 35
ntp_adjtime() returns code 0 (OK)
modes 0x0 (),
offset 0.000 us, frequency -17.209 ppm, interval 256 s,
maximum error 2000 us, estimated error 1 us,
status 0x2107 (PLL,PPSFREQ,PPSTIME,PPSSIGNAL,NANO),
time constant 4, precision 0.001 us, tolerance 500 ppm,
pps frequency -17.207 ppm, stability 0.004 ppm, jitter 0.507 us,
intervals 73, jitter exceeded 45, stability exceeded 0, errors 0.
associd=0 status=0000 no events, clk_unspec,
device="PPS Clock Discipline", timecode=, poll=828, noreply=0,
badformat=0, baddata=0, stratum=16, refid=80.80.83.0, flags=4
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.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
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@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@blueyonder.co.uk
time-nuts mailing list -- time-nuts@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