I noticed requests for port 37/udp in our firewall to our ntp server. That is the 'daytime' protocol which is absolutely ancient in an Internet timescale. I opened the port and started the service as an experiment and started tcpdump on it. The results are interesting:09:50:09.749723 IP xx.xx.178.51.37 > 18.104.22.168.123: NTPv4 client, strat 2, poll 7, prec -20 09:50:09.749782 IP 22.214.171.124.123 > xx.xx.178.51.37: NTPv4 server, strat 2, poll 7, prec -19 09:52:19.808243 IP xx.xx.178.51.37 > 126.96.36.199.123: NTPv4 client, strat 3, poll 7, prec -20 09:52:19.808301 IP 188.8.131.52.123 > xx.xx.178.51.37: NTPv4 server, strat 2, poll 7, prec -19 09:53:08.511939 IP xx.xxx.183.183.34505 > 184.108.40.206.37: UDP, length: 0 09:53:08.513364 IP 220.127.116.11.37 > xx.xxx.183.183.34505: UDP, length: 4Most traffic seen by 'tcpdump port 37' is from source port 37. Which is an artifact of certain NAT devices translating privileged ports (< 1024) to other privileged ports. Certain versions ntpd seem to ignore these requests. But there are real clients using the 'daytime' protocol.
The firewall at work got adjusted to not keep NAT state (cisco-term: xlates) for non-NAT sessions. So now I can run our ntp pool server at maximum speed again without the firewall overflowing its state tables. If you ever run into this problem, the right command is xlate-bypass.
Just seen in the ntp stats: A peak of 3271 packets/second of ntp traffic on ntp.cs.uu.nl.
New record in ntp.cs.uu.nl traffic: 2429 packets/second of ntp traffic. At that level the server does seem to miss some traffic: according to the pool.ntp.org: Stats for 18.104.22.168 it missed one request from the monitoring system completely, which drops the score several points at once.
You can check out of the NTP Pool anytime, but you can never leave...
Two years after we removed a server from the ntp pool we still see regular traffic to that IP. Documented in the NTP events log, we still have over a hundred regular clients.
With regards to the Eagles.
More ntp fun: I now have multicast ntp time working and documented. With the listed ntp key clients can use the multicasted network time from ntp.cs.uu.nl. The outgoing timestamps look like this in tcpdump:14:45:06.821419 IP (tos 0x0, ttl 30, id 6195, offset 0, flags [none], proto 17, length: 96) 22.214.171.124.ntp > 126.96.36.199.ntp: NTPv4, length 68 Broadcast, Leap indicator: (0), Stratum 2, poll 6s, precision -19 Root Delay: 0.000000, Root dispersion: 0.001724, Reference-ID: 127.127.22.0 Reference Timestamp: 3424077852.817587474 (2008/07/03 14:44:12) Originator Timestamp: 0.000000000 Receive Timestamp: 0.000000000 Transmit Timestamp: 3424077906.819248263 (2008/07/03 14:45:06) Originator - Receive Timestamp: 0.000000000 Originator - Transmit Timestamp: 3424077906.819248263 (2008/07/03 14:45:06)I also see multicasted time from 188.8.131.52 (time2.stupi.se) but I can't find a key for it.
A new peak in ntpd traffic on ntp.cs.uu.nl : 1986 packets/second. From a very limited peek at the IP numbers it seems the 'friends' at turkish telecom were quite interested in the correct time.
I found a really neat description of a project to build an accurate NTP stratum-0 server with the garmin gps 18 lvc.
At work we now graph several temperatures in the serverroom (results are not public). We joked (or not..) last Friday that we could add a lot of sensors inside and outside the serverroom (that is where my thinking about 1-wire systems came in again) and have someone research this micro-climate and correlate the micro-climate with the ntp statistics. We did see the influence of the cold wind from the east on the pll stats of several ntp servers.
About one and a half hour later, ntp.cs.uu.nl peaked at 1000.60 packets/second.
I'm a timegeek, and part of that is making our timeserver at work perform great in the NTP Pool project. With the recently updated pool dns system, servers that have more upstream bandwidth get more clients. We have been ogling our ntp stats for ntp.cs.uu.nl a lot seeing how the client count is through the roof (the internal data structures of ntp can't count beyond 3500 clients without serious hacking) and traffic is rising seriously lately. Still waiting for the first time we get over 1000 packets/second ntp traffic. Our ntp server has no problem at all dealing with this.
Timegeeks who can make the serious commitment towards being a long-time ntp pool member but don't have the hardware available to pick that last nanosecond of precision from the sky should peek at this announcement: Meinberg is donating some really great timekeeping equipment to the ntp pool project and it will be available to a pool member.
I played with Asterisk scripting last evening. Started out with an empty extensions.conf and went from there to create a speaking clock. I was trying to copy the old Dutch ptt telecom 002 experience, with a Dutch voice I found at VoIP wiki nl: Asterisk en taal afhankelijke sound files. I run this ofcourse on a ntp-synchronized server, a talking clock has to be correct! I tried to make it run on intervals of 10 seconds, but that doesn't work completely yet.
Sometimes you run into a very oooh, shiny! subject when looking for something else. I visited David Taylor's pages looking for his writeup of FreeBSD NTP server with an external GPS mainly to 'compare notes' with my own FreeBSD ntpd PPS setup (PPS slave) writeup. No surprises there, but one click led to the other, when I found out that David Taylor is also interested in receiving weather information and dove into that. He has a nice overview of his experiments in weather satellite receiving and decoding and I found out about EUMETCast data where you can receive weather satellite images via a satellite dish. Which uses a 'data' PID on a transponder, which is implemented as multicast data streams. Several personal interests for me and work-related stuff comes together in this. It's good to know this exists, but I won't be running out to buy a satellite weather map receiver now.
I've been thinking about building a weather-station / ntp server with solar power for a while, and decided to start documenting the design, the ideas and the (lack of) progress. Named project sundial because it uses the sun to tell time, just in a somewhat convoluted way.
I set up a new ntp server at work, and it is coupled to the meinberg gps timestandard. The meinberg is a very reliable time source but I don't want to invite the entire Internet to come over and bash it.
So an 'old' (2001) Dell PowerEdge 2550 got repurposed as FreeBSD ntp server. A lot nicer than it's previous role: windows domain controller.
FreeBSD metronoom 5.4-RELEASE-p13 FreeBSD 5.4-RELEASE-p13 #2: Fri Apr 21 16:09:21 UTC 2006 root@metronoom:/usr/obj/usr/src/sys/METRONOOM i386
The special bit in the kernel config isoptions PPS_SYNC # for ntpdin devfs.conf I link cuaa0 (first serial port) to pps0, so ntpd can open /dev/pps0 which is for clockdriver 22:link cuaa0 pps0And ntp.conf:# get time from stardate server stardate.cs.uu.nl prefer iburst driftfile /var/ntp/ntp.drift # fudge a local clock at stratum 10 server 127.127.1.0 fudge 127.127.1.0 stratum 10 # talk pps enable pps kernel auth server 127.127.22.0 # minpoll 4 maxpoll 4 version 4 fudge 127.127.22.0 flag3 1 fudge 127.127.22.0 refid PPS # access restrictions . localhost and staff can check everything. rest can # get the time restrict 127.0.0.1 restrict 184.108.40.206 mask 255.255.254.0 restrict default kod notrap nopeer noquery keys /etc/ntp.keys trustedkey 3 # moeltiepaas! broadcast 220.127.116.11 ttl 2 key 3 # announce policy setvar access_policy="experimental server not suitable for production" default
Speaking of FreeBSD and ntp: yesterday at work I set up a Dell Poweredge 2550 as ntp server. FreeBSD 5.4, a kernel with PPS support (the PPS bits will arrive when I have time to make a cable). It now runs over the weekend to see how stable ntpd will get.
Another problem with a public NTP server: Poul-Henning Kamp runs an NTP server on the Danish internet exchange DIX. He found out D-link routers all hammer on that NTP server (and lots of others) without any prior agreement. Read his Open Letter to D-Link about their NTP vandalism and Richard Clayton's write-up on how he researched the problem and found the source in the D-Link equipment. NTP was one of the last services that you could run cooperatively and assume your clients would play nice, now with 'home broadband routers' everywhere out in the world who like to keep the right time (and use sloppy-programmed client software to get that time), this trust in cooperative clients has been broken several times. Yes, this looks a lot like the former case with the University of Wisconsin - Madison and Netgear routers. At least, that case was solved with a good fix and an apology from Netgear.
I watched the leap second on my rikaline gps and .. nothing happened. It just jumps from 2005-12-31 23:59:59 UTC to 2006-01-01 00:00:00 with nothing in between. Other sources did show a real leap second or an adjustment after the fact.