Remco.org

Seductive serendipity / Verleidende serendipiteit

December 31st, 2008

Thermostat for PLL system clock on Time.remco.org

Short version of this post: look/click at/on the pictures.

difference1 thermostaat

Long(er) version of this post: read below ; -)

Recently a friend of mine offered me rack space in his colocation facility. This facility is connected directly to AMSIX, the nr. 1  internet exchange in the World, located in Amsterdam.
He also donated a surplus server, provided that I prepared the server for precision timekeeping.

First I had ‘bad ideas’ of ‘beating’ Poul-Henning Kamp‘s gps.dix.dk by using my FE-5680A Rb-standard, programmed for 14.31818 MHz, as reference for the system clock PLL, in combination with a GPS receiver.
Secondly, I thought that I could never beat the combination of PHK, a Soekris, and -presumably- his own ntp server software ntpns. So, I defined offering time stamps within +/- 1 us as my goal.
Thirdly, I thought of locking the 14.31818 MHz PLL reference to GPS, but what should I gain, relative to my goal?
Fourthly, I am more into hardware than into (recent) software, remember?

The donated server has an ASUS TUSI-M P1266 motherboard with 1024 MB memory.
I chose FreeBSD (rel-7.0) as OS because LinuxPPS does not support the time_pps_kcbind() option (yet), and compiled a new kernel with PPS_SYNC enabled. My experience is that FreeBSD PPS-implementation reacts more ‘smoothly’ on temperature changes than LinuxPPS.

Here, at home, the ntp kernel PLL offset remained within +/- 5 us limits due to the central heating system switching on and off (it is winter now and people are skating ; -).
So, this was not enough, although I knew that my server shall be located in a temperature controlled area.
Before considering ‘the GPS-locked system clock option’, I was curious how the system clock would behave in a more stable temperature environment, i.e. its temperature sensitivity.

I decided to ‘thermostatise’ the 14.31818 MHz PLL reference crystal, and built a thermostat around a ‘good old’ uA723, a power transistor, and two diodes as temperature sensor. I mounted the power transistor, and diodes on folded copper foil, and soldered the copper foil directly on the 14.31818 MHz crystal near the ICS PLL chip to achieve optimal conduction.
The temperature converged to approx. 45 Celsius and remained stable within ca. 0.1 C.

The difference between ‘before’ and ‘after’ can be seen in the first picture of this post, acquired by the Utrecht University (I studied there, and obtained my PhD there), which is monitoring my server out of curiousity. The result of the thermostat is almost a flat line, and the kernel PLL offset stays within +/- 1 us with this setup!

freebsd-standard freebsd-thermostat

Normal performance (left), and performance with ‘thermostatised’ system clock PLL reference crystal (right).

Want to look the inside of Time.remco.org?
Here is a picture of its ‘thermostat Mk1′, and this is a picture of its built-in Rockwell Jupiter GPS receiver.

Within the colocation area a special coaxial cable has been routed towards the roof of the building for the Time.remco.org GPS antenna. Therefore, for future expansions and/or experiments I created a DC blocked HF GPS out, to connect more GPS receivers to one antenna, and a 1 PPS output (synchronised to GPS), to offer PPS to other (timing) machines in the colocation area. Ntpd can run perfectly with PPS only, provided that you have a networked time reference.

Pictures of the installation of Time.remco.org will appear later (in a separate posting)!!

Note: the above mentioned server is disconnected, ready to be shipped to the colocation facility. You can use/monitor another ‘themostatised’ FreeBSD machine: ntp.remco.org, member of the NTP pool. Its behaviour is somewhat less, due to less optimal hardware, but its PLL offset remains within +/- 2 us limits.

December 31st, 2008

Today is leapsecond day!

Today the 34th leapsecond will be inserted in ‘our time’ by adding a 60th second in the last minute of this year.
This was announced by the International Earth Rotation and Reference System Service (IERS) in July this year.

Dr. Daniel Gambis, director of the Earth Orientation Centre, explains precisely why insertion of leapseconds is necessary.

Of course I wanted to see whether my NTP servers followed this procedure. In August I downloaded the official leapsecond file and added it to my ntp.conf. This means that when you do not have a time reference capable of announcing leapseconds, this file informs ntpd accordingly.

Today around 01.00 local time (00.00 UTC) ntpd informed itself about the insertion of a leapsecond:

ntp.remco.org (FreeBSD):
31 Dec 00:59:46 ntpd[778]: crypto: leap epoch 1.0 days
31 Dec 01:00:02 ntpd[778]: kernel time sync status change 2117
31 Dec 01:00:02 ntpd[778]: crypto: leap epoch 1.0 days

ntpdc -c kern for this machine yields:
remco@time [/home/remco]> ntpdc -c kern freebsd
pll offset:           -6.7e-08 s
pll frequency:        -50.244 ppm
maximum error:        0.000236 s
estimated error:      1e-06 s
status:               2117  pll ppsfreq ppstime ins ppssignal nano
pll time constant:    4
precision:            1e-09 s
frequency tolerance:  496 ppm
pps frequency:        -50.244 ppm
pps stability:        0.003 ppm
pps jitter:           1.026e-06 s
calibration interval: 256 s
calibration cycles:   2869
jitter exceeded:      1383
stability exceeded:   0
calibration errors:   3

ntp2.remco.org (LinuxPPS):
31 Dec 00:59:53 ntpd[22455]: crypto: leap epoch 1.0 days
31 Dec 01:00:09 ntpd[22455]: kernel time sync status change 2011
31 Dec 01:00:09 ntpd[22455]: crypto: leap epoch 1.0 days

where ntpdc -c kern outputs:
remco@time [/home/remco]> ntpdc -c kern ntp2
pll offset: 1.017e-06 s
pll frequency: 5.571 ppm
maximum error: 0.00775 s
estimated error: 7e-06 s
status: 2011 pll ins nano
pll time constant: 4
precision: 1e-09 s
frequency tolerance: 500 ppm

DCF77 transmits leapsecond information, as can be seen in the logfile after restarting ntpd on a machine which has no leapsecond file:

31 Dec 11:19:45 ntpd[20791]: PARSE receiver #0: interval for following error message class is at least 00:01:00
31 Dec 11:19:45 ntpd[20791]: PARSE receiver #0: no data from device within poll interval (check receiver / wiring)
31 Dec 11:20:03 ntpd[20791]: synchronized to GENERIC(0), stratum 1
31 Dec 11:20:03 ntpd[20791]: kernel time sync status change 0001
31 Dec 11:21:55 ntpd[20791]: kernel time sync status change 0011

So at least I now know that ‘I am in time’ with my leapseconds! :- )

Update Jan 1st 2009:

Yesterday friends and family asked me: “What are the effects of not heeding the leapsecond insertions, anyway, when it is so important, why don’t we hear about it in the news?” My answer was: “Wait until tomorrow, then you’ll hear and read enough”.  Some URLs:

But the most intriguing discovery I just made was that the Russian Institute of Metrology for Time and Space (IMVP/VNIIFTRI) did not insert the 34th leapsecond yesterday (!):

remco@lithium [/home/remco]> ntpdate -q ntp1.imvp.ru
server 62.117.76.142, stratum 1, offset 1.002066, delay 0.08249
1 Jan 13:49:14 ntpdate[27913]: step time server 62.117.76.142 offset 1.002066 sec

remco@lithium [/home/remco]> ntpdate -q ntp2.imvp.ru
server 62.117.76.141, stratum 1, offset 1.001125, delay 0.08253
1 Jan 13:29:45 ntpdate[27803]: step time server 62.117.76.141 offset 1.001125 sec

remco@lithium [/home/remco]> ntpdate -q ntp3.imvp.ru
server 62.117.76.138, stratum 1, offset 1.001030, delay 0.08250
1 Jan 13:29:50 ntpdate[27804]: step time server 62.117.76.138 offset 1.001030 sec

remco@lithium [/home/remco]> ntpdate -q ntp4.imvp.ru
server 62.117.76.140, stratum 1, offset 2.001320, delay 0.08302
1 Jan 13:30:04 ntpdate[27808]: step time server 62.117.76.140 offset 2.001320 sec <- 2s ??

I won’t draw any conclusions, but I fear the next satellite/space mission or rocket launch on Russian territory ; -)

|