News items for tag time - Koos van den Hout

2017-01-01 Leaped into 2017! 2 months ago
Jan  1 00:59:59 greenblatt kernel: [2538111.748198] Clock: inserting leap second 23:59:60 UTC
I usually distribute the leap second file to all servers I control to make sure there are no strange problems around it.

I wish everyone a good 2017!

Tags: , ,
2016-03-31 Interesting report from pskreporter 11 months ago
PSKreporter negative time Interesting report from pskreporter psk map today: a negative time at which the signal was reported. I guess the reported time is taken from the original spotter, I had EB4DDQ in the log at 18:12 UTC, he had me in the log at 19:12 UTC.

Tags: , , ,
2016-01-28 Shodan using the IPv6 ntp pool to find active IPv6 addresses 1 year ago
Recently posted: shodan.io actively infiltrating ntp.org IPv6 pools for scanning purposes. So I tried:
ntpdate -d -u 2a03:b0c0:3:d0::18:b001
And indeed:
Jan 28 14:42:25 server kernel: [1187976.106758] FW reject: IN=ppp0 OUT= MAC= SRC=2604:a880:0800:0010:0000:0000:00fe:d001 DST=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx LEN=60 TC=0 HOPLIMIT=55 FLOWLBL=0 PROTO=TCP SPT=49717 DPT=55554 WINDOW=54358 RES=0x00 SYN URGP=0 
Jan 28 14:42:25 server kernel: [1187976.107191] FW reject: IN=ppp0 OUT= MAC= SRC=2604:a880:0800:0010:0000:0000:00fe:d001 DST=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx LEN=60 TC=0 HOPLIMIT=55 FLOWLBL=0 PROTO=TCP SPT=34680 DPT=50070 WINDOW=26315 RES=0x00 SYN URGP=0 
Jan 28 14:42:25 server kernel: [1187976.107256] FW reject: IN=ppp0 OUT= MAC= SRC=2604:a880:0800:0010:0000:0000:00fe:d001 DST=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx LEN=60 TC=0 HOPLIMIT=55 FLOWLBL=0 PROTO=TCP SPT=49717 DPT=32764 WINDOW=15398 RES=0x00 SYN URGP=0 
Jan 28 14:42:25 server kernel: [1187976.107309] FW reject: IN=ppp0 OUT= MAC= SRC=2604:a880:0800:0010:0000:0000:00fe:d001 DST=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx LEN=60 TC=0 HOPLIMIT=55 FLOWLBL=0 PROTO=TCP SPT=41249 DPT=44818 WINDOW=15146 RES=0x00 SYN URGP=0 
Jan 28 14:42:25 server kernel: [1187976.107380] FW dropped: IN=ppp0 OUT= MAC= SRC=2604:a880:0800:0010:0000:0000:00fe:d001 DST=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx LEN=52 TC=0 HOPLIMIT=55 FLOWLBL=0 PROTO=UDP SPT=13864 DPT=30718 LEN=12 
Jan 28 14:42:25 server kernel: [1187976.107427] FW reject: IN=ppp0 OUT= MAC= SRC=2604:a880:0800:0010:0000:0000:00fe:d001 DST=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx LEN=60 TC=0 HOPLIMIT=55 FLOWLBL=0 PROTO=TCP SPT=59140 DPT=25565 WINDOW=53087 RES=0x00 SYN URGP=0 
Jan 28 14:42:25 server kernel: [1187976.108613] FW dropped: IN=ppp0 OUT= MAC= SRC=2604:a880:0800:0010:0000:0000:00fe:d001 DST=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx LEN=55 TC=0 HOPLIMIT=55 FLOWLBL=0 PROTO=UDP SPT=32950 DPT=8888 LEN=15 
Jan 28 14:42:25 server kernel: [1187976.110197] FW dropped: IN=ppp0 OUT= MAC= SRC=2604:a880:0800:0010:0000:0000:00fe:d001 DST=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx LEN=60 TC=0 HOPLIMIT=55 FLOWLBL=0 PROTO=UDP SPT=39721 DPT=64738 LEN=20 
Jan 28 14:42:25 server kernel: [1187976.110315] FW dropped: IN=ppp0 OUT= MAC= SRC=2604:a880:0800:0010:0000:0000:00fe:d001 DST=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx LEN=50 TC=0 HOPLIMIT=55 FLOWLBL=0 PROTO=UDP SPT=46499 DPT=5632 LEN=10 
Jan 28 14:42:25 server kernel: [1187976.110405] FW dropped: IN=ppp0 OUT= MAC= SRC=2604:a880:0800:0010:0000:0000:00fe:d001 DST=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx LEN=65 TC=0 HOPLIMIT=55 FLOWLBL=0 PROTO=UDP SPT=21934 DPT=47808 LEN=25 
Jan 28 14:42:31 server kernel: [1187981.938880] FW reject: IN=ppp0 OUT= MAC= SRC=2604:a880:0800:0010:0000:0000:00fe:d001 DST=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx LEN=60 TC=0 HOPLIMIT=55 FLOWLBL=0 PROTO=TCP SPT=34235 DPT=993 WINDOW=0 RES=0x00 RST URGP=0 
Jan 28 14:42:31 server kernel: [1187982.030058] FW reject: IN=ppp0 OUT= MAC= SRC=2604:a880:0800:0010:0000:0000:00fe:d001 DST=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx LEN=60 TC=0 HOPLIMIT=55 FLOWLBL=0 PROTO=TCP SPT=34235 DPT=993 WINDOW=0 RES=0x00 RST URGP=0 
Jan 28 14:42:31 server kernel: [1187982.197203] FW reject: IN=ppp0 OUT= MAC= SRC=2604:a880:0800:0010:0000:0000:00fe:d001 DST=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx LEN=60 TC=0 HOPLIMIT=55 FLOWLBL=0 PROTO=TCP SPT=34237 DPT=993 WINDOW=0 RES=0x00 RST URGP=0 
Jan 28 14:42:33 server kernel: [1187984.398977] FW reject: IN=ppp0 OUT= MAC= SRC=2604:a880:0800:0010:0000:0000:00fe:d001 DST=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx LEN=60 TC=0 HOPLIMIT=55 FLOWLBL=0 PROTO=TCP SPT=34245 DPT=993 WINDOW=0 RES=0x00 RST URGP=0 
Jan 28 14:42:34 server kernel: [1187984.620836] FW reject: IN=ppp0 OUT= MAC= SRC=2604:a880:0800:0010:0000:0000:00fe:d001 DST=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx LEN=60 TC=0 HOPLIMIT=55 FLOWLBL=0 PROTO=TCP SPT=34244 DPT=993 WINDOW=0 RES=0x00 RST URGP=0 
I would have expected more ports tested.

Tags: , , ,
2015-07-01 And the leap second leaped fine 1 year ago
The world did not fall apart at the leap second...
Jul  1 01:59:59 greenblatt kernel: [5562265.176016] Clock: inserting leap second 23:59:60 UTC
Jul  1 01:37:53 ritchie ntpd[14950]: local_clock: ntp_loopfilter.c line 688: kernel reports positive leap second warning state
Jul  1 01:59:59 ritchie kernel: [5807507.207473] Clock: inserting leap second 23:59:60 UTC
Jul  1 02:13:11 ritchie ntpd[14950]: local_clock: ntp_loopfilter.c line 688: kernel reports leap second has occured

Tags: ,
2015-06-30 Incoming leap second... 1 year ago
Previous there was just an announcement:
associd=0 status=0119 leap_none, sync_pps, 1 event, leap_armed
But the current state is that it's less than 24 hours until the leap second:
ntpq -nc readvar
associd=0 status=4619 leap_add_sec, sync_ntp, 1 event, leap_armed,
version="ntpd 4.2.6p3@1.2290-o Mon Apr 13 13:41:30 UTC 2015 (1)",
processor="x86_64", system="Linux/3.2.0-80-generic", leap=01, stratum=2,
precision=-20, rootdelay=21.302, rootdisp=962.377, refid=131.211.8.244,
reftime=d93ccb6a.5bf9c564  Tue, Jun 30 2015 10:01:46.359,
clock=d93ccb70.10208b70  Tue, Jun 30 2015 10:01:52.062, peer=21283, tc=6,
mintc=3, offset=-23.354, frequency=7.280, sys_jitter=0.205,
clk_jitter=8.257, clk_wander=0.087, tai=35, leapsec=201507010000,

Tags: ,
2015-01-05 Leap second announcement 2 years ago
Promptly after fixing the previus leapsecond file I get the IERS Bulletin C number 49 today which states:
                                   UTC TIME STEP
                            on the 1st of July 2015


 A positive leap second will be introduced at the end of June 2015.
 The sequence of dates of the UTC second markers will be:

                          2015 June 30,     23h 59m 59s
                          2015 June 30,     23h 59m 60s
                          2015 July  1,      0h  0m  0s
And I notice the IETF seems to update the canonical leap-seconds file about two months after the decision is made by the IERS.

It's a good thing ntpd starts complaining when the file is about to expire.

Update 2015-01-06: An update was available from ftp://time.nist.gov/ but only when I connected over IPv6. An interesting form of IPv6 promotion. Notice the difference in messages between the old file and the new file loading:
Jan  5 13:54:33 ritchie ntpd[13710]: leapsecond file ('/etc/ntp/leap-seconds.3644438400'): good hash signature
Jan  5 13:54:33 ritchie ntpd[13710]: leapsecond file ('/etc/ntp/leap-seconds.3644438400'): loaded, expire=2015-06-28T00:00Z ofs=35 (no entries after build date)
Jan  6 10:14:17 ritchie ntpd[26348]: leapsecond file ('/etc/ntp/leap-seconds.3629404800'): good hash signature
Jan  6 10:14:17 ritchie ntpd[26348]: leapsecond file ('/etc/ntp/leap-seconds.3629404800'): loaded, expire=2015-12-28T00:00Z last=2015-07-01T00:00Z ofs=36

Tags: , ,
2014-12-29 Time to update the leapsecond file 2 years ago
I recently upgraded ntpd due to the vulnerabilities found in ntpd prior to version 4.2.8. This version is also a bit better in error logging, and I started seeing in the logs:
Dec 21 20:53:06 ritchie ntpd[6918]: leapsecond file ('/etc/ntp/leap-seconds.3535228800'): loaded, expire=2014-12-28T00:00Z ofs=35 (no entries after build date)
Dec 21 20:53:06 ritchie ntpd[6918]: leapsecond file ('/etc/ntp/leap-seconds.3535228800'): will expire in less than 7 days
Dec 22 20:53:06 ritchie ntpd[6918]: leapsecond file ('/etc/ntp/leap-seconds.3535228800'): will expire in less than 6 days
Dec 23 20:53:06 ritchie ntpd[6918]: leapsecond file ('/etc/ntp/leap-seconds.3535228800'): will expire in less than 5 days

Dec 28 00:53:06 ritchie ntpd[6918]: leapsecond file ('/etc/ntp/leap-seconds.3535228800'): will expire in less than one day
So I followed the documentation in ConfiguringNTP: 6.14. Using the NIST Leap Second File and upgraded to leap-seconds.3644438400 which now loads fine:
Dec 29 11:25:29 ritchie ntpd[28281]: leapsecond file ('/etc/ntp/leap-seconds.3644438400'): good hash signature
Dec 29 11:25:29 ritchie ntpd[28281]: leapsecond file ('/etc/ntp/leap-seconds.3644438400'): loaded, expire=2015-06-28T00:00Z ofs=35 (no entries after build date)

Tags: , ,
2014-10-04 (#) 2 years ago
It seems the Garmin GPS 18 LVC for timekeeping in the ntp server on ritchie.idefix.net is having weird issues. It stops responding with the carrier high and sometimes restarts.
$GPGSA,A,1,,,,,,,,,,,,,,,*1E
$GPGSV,3,1,11,01,00,098,00,02,57,048,00,24,00,210,00,25,47,265,00*77
$GPGSV,3,2,11,26,05,15�
On such a 'hang' the carrier detect is high. Weird problem.

Tags: ,
2014-05-25 (#) 2 years ago
After testing the gps sky view it's now time to test with ntpd. First step was to recompile ntpd because the debian default package had no pps support. Recompiling on a 500 MHz AMD Geode takes a bit of time.

Results look ok for a first test:
root@ritchie:~# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+greenblatt.idef 131.211.8.244    2 u   17   64  377    1.177  101.732  63.403
*metronoom.dmz.c .PPS.            1 u   17   64  377   19.499  100.512   6.722
+auth1.xs4all.nl 193.67.79.202    2 u   11   64  377   18.403  104.008   3.669
oGPS_NMEA(0)     .GPS.            0 l    6    8  377    0.000  114.073   7.364
root@ritchie:~# ntpdc -c loopi
offset:               0.001986 s
frequency:            94.434 ppm
poll adjust:          -30
watchdog timer:       342 s
root@ritchie:~# ntpdc -c kerni
pll offset:           3.3e-08 s
pll frequency:        94.434 ppm
maximum error:        0.175258 s
estimated error:      2e-06 s
status:               2007  pll ppsfreq ppstime nano
pll time constant:    3
precision:            1e-09 s
frequency tolerance:  500 ppm
root@ritchie:~# ntpdc -c sysi
system peer:          GPS_NMEA(0)
system peer mode:     client
leap indicator:       00
stratum:              1
precision:            -19
root distance:        0.00000 s
root dispersion:      0.00749 s
reference ID:         [GPS]
reference time:       d72cb010.dc91595e  Sun, May 25 2014 20:08:16.861
system flags:         auth monitor ntp kernel stats pps 
jitter:               0.006714 s
stability:            0.000 ppm
broadcastdelay:       0.000000 s
authdelay:            0.000000 s
It will need some more calibration probably.

Update: It keeps looking nice after some calibration. Stats gathered at NTP server ritchie.idefix.net stats.

This does mean one of the old project sundial goals has been met: the weather station computer in the shed is now also a time server.

Tags: , , ,
2014-02-18 (#) 3 years ago
After getting the gps running in the shed I noticed a bit of variation in the output location as logged from the NMEA $GPGGA strings in the clockstats file. And reading Tom van Baak testing the MG1613S GPS Receiver noting the variation in location made me decide to do a bit of plotting of location on my own. As Tom notes, plotting distance in meters gives a better idea of scale. So I wrote a bit of perl to massage the lat/long pairs into X/Y meters from a starting point. I was lazy: I used the first measurement as starting point. The resulting X/Y pairs are graphed using gnuplot.

Update: I'm a security specialist, not a programmer: I found some errors in the routines that convert output from the GPS to degrees to meters. Fixed them, so the first graph has been redrawn using data from 17 and 18 Februari.

Tags: , ,
2014-02-16 (#) 3 years ago
Since the old gpskit gps was showing problems in ntp tests earlier I decided now that the weatherstation computer is up and running on the alix.1c board to try a different gps unit: The Holux GR-213 GPS I still have from earlier wardriving. holux 213 gps

Not much of a succes sofar. First the GPS did not get a lock at all. I was expecting a delay in acquiring a lock since it hadn't been used in over a year but after a day and a half it still wasn't locking. So I moved it a bit which led to a lock (blinking led). But ntpd was still not using the GPS_NMEA driver. When I had time to have more of a look than just the graphs at NTP server ritchie.idefix.net stats I noticed ntpd was still seeing GPS_NMEA as a falseticker. Which is about right, when I look at the peer stats the GPS_NMEA clock has an offset of about 500 milliseconds(!!) compared to the rest.

To my best knowledge I can find the right offset with 'enable calibrate'. But documentation is very minimal on this matter: Reference clock drivers - ntp 4.0.99k documentation has:
The recommended procedure is to enable the function, let it run for an hour or so, then edit the configuration file using the time1 values displayed by the ntpq utility and clockvar command.
With 'enable calibrate' on I see after a long run:
ntpq> peer
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+greenblatt.idef 131.211.8.244    2 u  137  512  377    1.012    1.780  87.722
*metronoom.dmz.c .PPS.            1 u  166  512  377   18.297   -1.207  46.401
+auth1.xs4all.nl 193.67.79.202    2 u  119  512  377   16.604   -1.104  27.267
xGPS_NMEA(0)     .GPS.            0 l    4   16  377    0.000  -529.94   3.286
ntpq> clockvar
associd=0 status=0000 , no events, clk_unspec,
device="NMEA GPS Clock",
timecode="$GPGGA,210752.000,5206.6230,N,00507.0976,E,1,06,1.5,-0.1,M,47.1,M,,0000*7F",
poll=762, noreply=0, badformat=0, baddata=0, fudgetime1=0.000, stratum=0,
refid=GPS, flags=0
So even after running for a long time with clearly an offset between the other clocks and the reference clock there is no change in the suggestion for the time1 factor, still showing 0.000.

Remarks in [ntp:questions] enable calibrate? suggest 'enable calibrate' will only work when there is a PPS signal available, and confirm the lack of documentation and samples I found.

The Holux GR-213 also does not have a PPS signal to the outside at all, so I can't use a PPS signal anyway.

Update: Some sleep, thinking and reading later: first of all, time1 is the PPS time offset and time2 is the gps message offset, found by reading ntpd documentation Generic NMEA GPS driver.

So I started looking for the right offset with the 127.127.20.0 driver in noselect mode. After some testing I found a reasonable answer with:
# GPS as time source without pps
server 127.127.20.0 minpoll 1 maxpoll 4
fudge 127.127.20.0 time2 +0.544
And now things look better:
ntpq> peer
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+greenblatt.idef 131.211.8.244    2 u    2   64   77    0.956   -2.252  41.400
*metronoom.dmz.c .PPS.            1 u    5   64   77   17.921   -2.236   1.190
-auth1.xs4all.nl 193.67.79.202    2 u    3   64   77   16.254   -2.750   0.880
+GPS_NMEA(0)     .GPS.            0 l    2    8  377    0.000   -5.916   1.100

Tags: ,
2013-12-30 The wonderful world of week number standards 3 years ago
The wonderful thing about standards:
$ date "+%u %w %U %V %W"
1 1 52 01 52
And the explanations:

%u day of week (1..7); 1 is Monday

%w day of week (0..6); 0 is Sunday

%U week number of year, with Sunday as first day of week (00..53)

%V ISO week number, with Monday as first day of week (01..53)

%W week number of year, with Monday as first day of week (00..53)

And it's easy to find days with 3 different week numbers:
31 dec 1990 is 52 01 53
03 jan 1993 is 01 53 00
02 jan 1994 is 01 52 00
01 jan 1995 is 01 52 00
30 dec 1996 is 52 01 53
31 dec 1996 is 52 01 53
03 jan 1999 is 01 53 00
02 jan 2000 is 01 52 00
02 jan 2005 is 01 53 00
01 jan 2006 is 01 52 00
31 dec 2007 is 52 01 53
03 jan 2010 is 01 53 00
02 jan 2011 is 01 52 00
01 jan 2012 is 01 52 00
03 jan 2016 is 01 53 00
01 jan 2017 is 01 52 00
31 dec 2018 is 52 01 53
03 jan 2021 is 01 53 00
02 jan 2022 is 01 52 00
01 jan 2023 is 01 52 00
30 dec 2024 is 52 01 53
31 dec 2024 is 52 01 53
03 jan 2027 is 01 53 00
02 jan 2028 is 01 52 00
31 dec 2029 is 52 01 53
Calendering software, including the one from a software developer quite known for not following standards has converged on the ISO week number.

Tags: , ,
2013-12-24 (#) 3 years ago
Modelled after the ntp server statistics at cs.uu.nl I created years ago I recently started gathering stats on my own. Today I had some time to spare to actually create some graphs from those ntp stats: NTP server stats.

Tags: , ,
2013-12-17 (#) 3 years ago
I looked up the details of the right configuration for ntpd to allow a reset of the packet counters without restarting ntpd for the ntp server project. Relevant part of /etc/ntp.conf:
keys /etc/ntp/ntp.keys
trustedkey 10
requestkey 10
controlkey 10
And in /etc/ntp/ntp.keys is one key 10. And it works:
ntpdc> syss
time since restart:     12
time since reset:       12
packets received:       10
packets processed:      8
current version:        8
previous version:       0
..
ntpdc> reset sys
Keyid: 10
MD5 Password: 
done!
ntpdc> syss
time since restart:     19
time since reset:       3
packets received:       2
packets processed:      1
current version:        1
previous version:       0
..
Learned from How do I configure remote administration - ntp faq and miscellaneous commands and options - ntpd.

Tags: , ,
2013-12-17 (#) 3 years ago
End of an era: just shut down doei.cs.uu.nl which was timeserver for cs.uu.nl from August 2003 to August 2006 and still saw active ntp traffic today. The complete history of timekeeping at cs.uu.nl is at Ntp events log - helpdesk.cs.uu.nl.

Tags: ,
2013-05-14 (#) 3 years ago
Update to the NTP server project: I took pictures of the hardware and all the crystals I saw on the mainboard, visible at NTP server set on flickr. And the crystal involved in timing was easy to find: the standard timing crystal in PCs uses a 14.318 MHz crystal, the fourth crystal in the pictures.

Tags: ,
2013-05-13 (#) 3 years ago
I found the old rockwell jupiter gps board which I had not used in years and hooked it up to the NTP server project system. I was used to this GPS taking ages to get a location fix and being very finicky about reception. Not this time: between hooking it up to the system and walking back to my laptop and checking the gps output with minicom it already had enough of a location fix to start sending PPS pulses. And next..
# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*xxxxxxxxxxxxxxx .PPS.            1 u    1   16    7   15.570   -6.927   9.294
 xxxxxxxxxxxxxxx .INIT.          16 u    -   64    0    0.000    0.000   0.000
 chime1.surfnet. 194.171.167.130  2 u   35   64    1   18.643   -7.491   0.000
 chime2.surfnet. .GPS.            1 u   34   64    1   19.214   -6.526   0.000
oPPS(0)          .PPS.            0 l    1   16    3    0.000   15.431   1.227

Update: But the situation isn't ideal, the PPS is voted falseticker after a while. Looking at the NMEA data, specifically the $GPRMC messages I notice there is no fix at all, but the PPS indicator (carrier detect) keeps ticking so minicom keeps switching between 'Online' and 'Offline'. At least this means all the bits are working.

Tags: , ,
2013-05-12 (#) 3 years ago
Update for the NTP server project: the SATA cables arrived and I managed to fit everything in the case. I think I removed and replaced the central fan in the case about 15 times, it is always in the way whenever anything happens in the front area of the 1U case. Ubuntu 12.04 LTS is now happily installing on a linux software raid.

Interestingly, when I copy the Ubuntu 12.04 LTS .iso to an USB stick as-is it boots and works fine, when I use usb-creator-gtk on an Ubuntu 10.04.4 LTS system with the Ubuntu 12.04 LTS .iso (amd64) it creates an USB stick which hangs during boot. I guess Ubuntu is also using isohybrid for .iso images now but usb-creator-gtk doesn't recognize those somehow.

Update: The ntp package from Ubuntu 12.04 includes no ATOM refclock support (refclock 22). So I removed the package again and built ntpd from sources, using the hints from LinuxPPS NTPD support on how to make sure the right timepps.h is available. The first tests look good:
# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*xxxxxxxxxxxxxxx .PPS.            1 u   11   16  377   15.920   -2.472  35.941
 xxxxxxxxxxxxxxx .INIT.          16 u    -   64    0    0.000    0.000   0.000
+chime1.surfnet. 192.87.106.3     2 u   39   64  177   14.826   -1.898  28.043
+chime2.surfnet. .GPS.            1 u   30   64  177   18.103   -3.296   1.623
 PPS(0)          .PPS.            0 l    -   16    0    0.000    0.000   0.000
I have a rockwell jupiter gps board with PPS support available to test with.

Tags: , ,
2013-05-04 (#) 3 years ago
Some more tries to get the server running which I've been working on a few times. To keep all my notes together I started a webpage about it: NTP server.

From PLD linux I was able to reset the IPMI config so I could manage the system remotely (away from the fan noise!). In the Ubuntu and Debian installers the remote keyboard access was unavailable so I still had to walk up to the system from time to time to answer installer questions, but I could view the progress bars from a different room.

Tags: , ,
2012-06-30 (#) 4 years ago
This day (30 June 2012) will have a leap-second at the end of the (UTC) day. I installed the iers bulletin on ntp.cs.uu.nl months ago, but the leap indicator in the outgoing ntp answers switched on at 00:00 UTC today (2012-06-30T00:00:00 UTC).
metronoom# ntpq -c rv
status=411d leap_add_sec, sync_atomic, 1 event, event_13,
version="ntpd 4.2.6@1.2089-o Fri Jan 15 14:31:14 UTC 2010 (1)",
processor="i386", system="FreeBSD/5.4-RELEASE-p13", leap=01, stratum=1,
precision=-19, rootdelay=0.000, rootdisp=1.140, refid=PPS,
reftime=d399c71c.6e6e43bf  Sat, Jun 30 2012 18:42:36.431,
clock=d399c72a.fee93d22  Sat, Jun 30 2012 18:42:50.995, peer=32717,
tc=6, mintc=3, offset=0.000, frequency=15.707, sys_jitter=0.002,
clk_jitter=0.002, clk_wander=0.004, tai=34, leapsec=201207010000,
expire=201212280000
The interesting side-effect is that since the leap indicator went on the rate of requests went up. From a rate which is the last year average around 850 requests per second it went to a peak of 24488 requests per second. Stats for ntp.cs.uu.nl. My theory is that the infamous Turkish ntp pool clients have a problem with ntp answers with a leap indicator. Although ntp.cs.uu.nl isn't in Turkey, it is a volunteer server for tr.pool.ntp.org to help with the load from that country.

The great part is that ntpd is using over 50% cpu time on the system but the load of requests has absolutely no influence on the stability of the timekeeping.

Update: The leap second was processed correctly everywhere:
Jul  1 01:59:59 doei kernel: TIME_INS: inserting second 23:59:60 UTC
Jun 30 02:10:18 greenblatt ntpd[6856]: kernel time sync status change 0011
Jul  1 01:59:59 greenblatt kernel: [2817910.960085] Clock: inserting leap second 23:59:60 UTC
Jul  1 02:04:34 greenblatt ntpd[6856]: kernel time sync status change 0001
Jul  1 01:59:59 abaris kernel: [9788209.066779] Clock: inserting leap second 23:59:60 UTC

Tags: , ,
  Older news items for tag time ⇒
, reachable as koos+website@idefix.net. PGP encrypted e-mail preferred.

PGP key 2C66 3B5D F0D7 C263 local copy PGP key 2C66 3B5D F0D7 C263 via keyservers pgp key statistics for 0x2C663B5DF0D7C263 Koos van den Hout
RSS
Other webprojects: Camp Wireless, wireless Internet access at campsites, The Virtual Bookcase, book reviews, Weather maps