Slashdot Mirror

I have been a member of the NTP Hackers team for 25+ years: As many of you probably know most reference clocks on the Internet are based on GPS timing receivers. The last time we had a week rollover a small percentage of Stratum 1 servers went temporarily offline, or they were marked as "falsetickers" due to announcing a date which was nearly 20 years wrong. Most servers were either unaffected or got back online shortly after.

The key here is that 1024 weeks is a short enough time span that most competent developers will realize that their (embedded or otherwise) product might still be in operation during the next rollover so they have to handle this, while a 13-bit week counter is so long (8192 weeks or 157.5 years) that it is likely that many will simply forget about the issue until it comes back to bite everyone in 2137. :-(

BTW, there are _many_ ways to handle rollovers like this, the easiest is probably to compile in the build date in your firmware and then simply make sure that the date calculated from the week number is greater than this, adding blocks of 1024 (or 8192) weeks if needed. Another option, if you have any kind of non-volatile memory, is to write the current date to permanent storage regularly, like once a month or once a year.

Terje

See my subject & this link: No denying it /https://it.slashdot.org/comments.pl?sid=9995967&cid=53488785b [slashdot.org] & it's FAR from a complete list (even though it shows 100's of router security + inefficiency issues).

Your argument is so old and tired I get a /. 404 error, seriously I do. That said anyone who is using the factory provided firmware on a consumer router/firewall is dumb. OpenWRT or DDWRT are much better choices that offer better security and better options. Or if you prefer go and drop pfSense on some "powerful" but inexpensive hardware. As you will have a device like these between your computer and the internet I don't see how an argument about cost is an issue as you have your modem connected to the internet (DSL or Cable) and then either a router or firewall that your other gear sits behind. Depending on what hardware you have and layout your setup behind the router or firewall will vary greatly. * LMAO - again, that's you "networking menials" (that can't program their OWN solutions because you're limited) to a tee

Not a millennial (I assume that it what you meant) by a long shot I do actually program and have through my employer contributed to a number of open source projects. You may have heard of a few of them.

WRONG! I don't understand "layered-security"/"defense-in-depth"? I wrote guides on it that even GOT ME PAID https://www.google.com/search?... [google.com]

Guess what I have contributed to guides on securing systems and am paid by my employer to do so when new versions and updates are sought. The difference is that what I have contributed to are respected and well known.

Also it looks like you are a bit to copy/paste happy as I see you are getting frustrated and double posting (see above and below). You really should look into getting treatment for your ails as something does appear to be wrong.

Do we really need it anymore now that we have NTP running on most of our smartphones, computers, etc.?

The question is - do the people who are calling the time number actually know that the time on their phone is set automatically? And probably not just for cell phones... our last land line phone, back when we still had a land line, would synchronize its time whenever an incoming or outgoing call occurred.

I have this mental image of some elderly woman dialing the time number and then dutifully setting the time on her fifteen-year-old Nokia cell phone.

Do we really need it anymore now that we have NTP running on most of our smartphones, computers, etc.?

I do miss the "time lady" though. Or "popcorn" - (767-2676, or 767-1111). "At the tone, the time will be, 9:38am. *BEEP*"

I was just thinking yesterday about an automated telephone game system I used to call when I was growing up in the 80's. 573-3400. I forget what it was called, but there were 3 games you could play all by 'choose your own adventure' touch-tone style choices. One was a cowboy type game, one was a vampire, and I forget what the third one was. It was all free to play for us latch-key kids. Heh. Now get off my lawn!

NTP authentication

Yes that might help. In the 'near' future.

NTP authentication

Recent Vulnerabilities --- October 2015 NTP Security Vulnerability Announcement (Medium)

The freeware ntpd at http://www.ntp.org/downloads.h... was extremely stable code. It's greatest problems have been with subtle configuration issues, not with the old daemon itself. Unfortunately, the service is now merged into systemd itself, which means that support for it from that large part of the Linux world will no longer apply to any other operating system.

The main codeline at http://www.eecis.udel.edu/~ntp... shows that it is in active development, mostly to support new operating systems and hardware.

When a fix for CVE-2014-9295 was already available to build and install on the day, I sent support.ntp.org $100 without hesitation. And was vaguely hoping the rest of civilization -- the part for whom the whole of that sentence was meaningful, anyway -- might do the same. I'm glad a little light is being thrown on some of the infrastructure we take for granted ... worth consideration if you support the FOSS model philosophically, and have a few $ to spare to back it up.

So it's fair to say that Chrony isn't suitable for running on stratum 1 servers, of which there are a few hundred, maybe up to at most a few thousand publically available in the world[1]. For the millions of Linux servers, laptops and desktops that aren't and will never be stratum 1 NTP servers Chrony should be just fine, shouldn't it?

[1] ntp.org currently lists 304 publcically available stratum 1 servers http://support.ntp.org/bin/vie...

Chrony is a complete working implementation of the NTP protocol.

You mean complete except for broadcast/multicast mode, or authentication based on public-key cryptography. Some basically it's a good client and a unauthenticated / inefficient (network) server.

It also makes some pretty misleading claims; Chrony can usually synchronise the system clock faster and with better time accuracy except it never explains how it can possibly achieve better time accuracy than NTPd.

Chrony does handle a number of client usage scenarios better than NTPD (namely non-permanent network connection, and laptop-like environments) as far as I know, but it does not achieve better accuracy for the usage scenarios NTPD was primarily designed for (e.g. network connected servers).

NTPD gets its knickers in a twist at the slightest excuse and sometimes ends up stepping the time even though it has perfectly good Internet connectivity and a reasonably good internal clock.

Yet chrony can't detect rouge or fix broken time servers. Beyond possibly having better handling for clients of dynamic clock frequencies (i.e. SpeedStep, and various other power saving features that modify one or more of the several frequency oscillators in a computer.). I say possibly because I am not certain of the state of affairs in the current NTPD code base, I know it was lacking when dynamic clock frequencies originally appeared in systems, but I am not sure that it still is naive about that.

Chrony keeps steady time even if Internet access is intermittent. It never gets confused and picks a falseticker pretending to be stratum one instead of a stratum 3 with correct time, unlike NTPD.

While it does appear Chrony has improved greatly from a simple SNTP client for intermittent network connectivity it was when I first heard about it, that is still its forté, and likely the best client for many end-users' cases. Still it is not a robust general purpose replacement of NTPD.

It even has interfaces to GPS clocks or other hardware clocks, so you can run your stratum 1 server on Chrony if you want.

And YouTube is full of people doing stupid, reckless, and/or unwise things too. That's perhaps too harsh, but that's those "features" are quite incomplete.

Having PPS (Pulse Per Second) optional support is a good start, it is not a comprehensive solution to running a quality stratum 1 server. I expect a stratum 1 server to have improved or at least quantified oscillator ("clock") parameters, such as ideally TCXO (Temperature-Compensated crystal Oscillators) or OCXO (Oven-Controlled crystal Oscillator) for the stratum 1 system's time-keeping. For commercial systems I would suggest looking at a professional NTP server network appliance, there are several vendors including Spectracom, Symmetricom, Meinberg, and others.

imo, when you go for that last nanosecond of accuracy as the highest priority

That's kind of the whole point of a timeserver. If you're just running a typical client that doesn't need precision there are a multitude of SNTP implementations that you can use, including the one built into Windows. If you're running something that demands precision or wish to share your time with others (random plug: NTP Pool) you're going to need a little bit more accuracy than that.

and lower the priority of writing secure software to the point where it is no longer a priority, then you have ntp.

ntpd has been around since the 80s. Contrast it against other system daemons that have been around that long (sendmail) and you'll see that it has a solid security record. The recent "exploits" only impacted a small subset of servers that were using the cryptographic functionality of ntpd, which is primarily used for remote management and peering relationships and was a non-issue for the lion's share of configurations. Configurations to work around the issues were released immediately and a patch to solve them entirely was available within days. What more do you want? This was all discussed on the NTP Pool mailing lists and the consensus was "meh." I'm not aware of any NTP server that has been compromised because of these exploits.

The biggest issue that's hit ntpd in the last year was the ease with which you could use the 'monlist' command for amplification attacks. This too was easily solved with a configuration change and in any event did not compromise the integrity of the servers running ntpd. It's symbolic of a larger problem that has hit other protocols (DNS) and which will never go entirely away until network operators get off their lazy asses and implement the recommendations of BCP38.

huh ? a smartphone can display atomic accurate time, defined in 3 dimensions if needed, it can even directly consult the people who define time (ntp,npl,nasa,gps), correct deviations to the clock cycle, whose time do you want?
http://ntp.org/

The pool.ntp.org project is a big virtual cluster of timeservers providing reliable easy to use NTP service for millions of clients. [...] All Pool Servers 3810

Getting the right time these days is easy, you have NTP, GPS, DCF77 and Time from NPL to name a few sources in Europe.

If you saw this problem, your NTP time sources were not properly configured and diverse.

Consider using the NTP pool and not relying on so few sources to properly sync your time. Read 5.3.3 and 5.3.4 from http://support.ntp.org/bin/view/Support/SelectingOffsiteNTPServers for help to correct your NTP setup.

For a general user or most office users RS232 could go die in a gutter but it seems there are functions that it provides that USB doesn't. The one I am most familiar with is NTP PPS for accurate timing. USB does not support this so for applications that need accurate timing from a clock device they need to have an old fashion serial port. I am sure there are others but I am unaware of those. Also how much legacy stuff needs to come along with it, its not like we are talking about HP-IB here.

I've always wondered about the defaults to have every RH/Debian/Suse/Ubuntu/etc. box talk directly to the pool. I know that for years, the pool has been considered fully sufficient to meet these needs, but it just always struck me as more efficient for an organization to run its own NTP server--one machine talking to the pool--and have other machines in the organization talk to that, rather than having all the machines in the organization talk to the pool.

They actually talk to a "vendor" subdomain of the pool: 0.rhel.pool.ntp.org, 1.rhel.pool.ntp.org, 2.rhel.pool.ntp.org, etc.

They provide vendor-specific subdomains and encourage vendors to provide NTP servers to the pool. Thus, if there's some abuse or misconfiguration that results in excessive traffic they can change the vendor-specific subdomain to prevent that traffic from flooding NTP servers without inconveniencing clients that use the general pool.

Anyway, yes: it's better for an organization to have one or two local time servers communicate with the pool (or other sources of time) and then provide time service to the local network. Still, talking to the pool is a reasonably sane "general purpose" default.

The OP was asking if the NIST time servers were part of the pool.ntp.org group.

They aren't. However, NIST does have Stratum 1 Servers.

Yeah, you really oughtn't try to volunteer your DSL connection. If you have a dedicated server somewhere, though, it's pretty simple to configure ntpd and register yourself as part of the pool. I've been doing my part for a few years (whoops - I rebooted yesterday). The traffic really is negligible and the load is practically nil. If you've got the resources, help the cause!

Virtual machines cannot be used for NTP:

http://support.ntp.org/bin/view/Support/KnownOsIssues#Section_9.2.2.

NTP was not designed to run inside of a virtual machine. It requires a high resolution system clock, with response times to clock interrupts that are serviced with a high level of accuracy. No known virtual machine is capable of meeting these requirements.
Run NTP on the base OS of the machine, and then have your various guest OSes take advantage of the good clock that is created on the system. Even that may not be enough, as there may be additional tools or kernel options that you need to enable so that virtual machine clients can adequately synchronize their virtual clocks to the physical system clock.

The NTP Internet client on my PC synchronizes my clock every hour, a setting that I can change to minute increments. I can also manually cause it to synchronize my clock at any time.

It alerts me to pending leap-seconds. Since it synchronizes in UTC, however, that alert is for information only. If a leap-second causes a failure to synchronize, I get a different alert and can manually request synchronization again. If a leap-second causes an inappropriate synchronization, that will be corrected an hour later (or sooner if I recognize it and manually request another synchronization).

Effectively, a hospital or other institution should have only one operating NTP Internet client that is used to synchronize a local NTP server to external servers. Then the institution's LAN should provide clients that synchronize to that local server. Not only would this ensure consistency, but it would also prevent flooding external NTP servers. Such a setup -- a network with a single internal NTP server without each platform doing its own external NTP synchronization -- is strongly recommended at http://support.ntp.org/bin/view/Servers/RulesOfEngagement.

For a hospital, it is indeed necessary to have not only consistent clocks but also accurate clocks. Otherwise records from outside ambulance services cannot be correlated with records from inside emergency rooms.

OpenNTPD just ignored the leap second

OpenNTPD has clearly been written by someone who doesn't understand NTP. For example, it advertises incorrect root delay and disperson values, which can cause clients to fail to achieve a majority vote, or to pick the wrong peer to synchronise against. (Earlier versions were even worse, they advertised themselves as being at stratum 0, which could cause synchronisation loops; this has thankfully been fixed, but it doesn't inspire much confidence in the authors' competence.)

I've also found OpenNTP to fail to regulate the local clock on dodgy hardware (it would oscillate wildly, with an amplitude of 3 seconds or so), in situations where the reference ntpd coped just fine.

Folks, do yourself and everyone a favour -- run the reference NTP, run chrony, heck, run some SNTP client, but please avoid OpenNTPD.

I thought that was the reason for the NTP server.

What gave you that idea? Do you know what NTP is?

Since you've got real stratum-1 NTP servers, you could skip the pool altogether and add them to the official NTP time server list.

AFAIU, the NTP pool is meant more for lower-stratum servers, like users on static-IP cable modems, so your machines wouldn't be doing as much good there.

Any NTP server at any stratum is welcome to join the pool. The only actual requirement is that the server should have a static IP address. The how do I join page has further information. If you already have a functioning NTP server, all you have to do is to log in and add your server's DNS name/IP address and its available bandwidth (for load balancing purposes). I'd say it's a rather simple process.

The NTP pool (which probably needs even more NTP servers, btw) was recently changed so that the project's DNS servers return a list of nearest available NTP servers when queried. If you change your settings to use Google's DNS servers, the pool will now respond with a list of NTP servers close to Google's DNS servers, which may not be what you wanted.

NTPD isn't good enough for me -- bad weather on the Internet has caused my server to loose synchronization one too many times,

Your NTP setup is misconfigured if this is the case.

The NTP daemon has many algorithms built in to measure jitter (how "off" a clock is from what NTP thinks is the realtime) and factors in network delay as well. (Run ntpq -p to see a list of time servers that your NTP client is accessing and their associated jitter/delay/offset values.)

NTP's primary job is to poll various time servers, figure out which ones are good and use that data to set your clock. This so called "bad weather" you refer to should not be a problem for NTP if it is setup correctly.

As others have mentioned in this thread, you should set up one or two primary NTP servers that probe external servers (preferably from the pool.) and then have your interval servers probe those site-local time servers.

Thomas

Anything with non-monotonic timing should be avoided in any system that has sub second timing issues. Such as system might be a robot that drives a car. That means that windows derived products should never be used in real time sensitive systems. Microsoft knows this and doesn't pretend otherwise. Microsoft products are simply unusable for many embedded applications.

I just turned 50 this summer, and I've never felt more appreciated as an engineer than the last couple of years.

As other people here have commented, the real secret is to simply be _very_ good at what you do: Keep up your old skills, and make sure you learn (i.e. teach yourself) something brand new every year or two.

Over the last 5+ years I've been the "IT Fire Brigade Chief" in the Fortune 500 company I work for, i.e. I get all the really interesting problems, all the cases that none of the others can figure out, and all the bleeding edge stuff that doesn't fit nicely into one of the existing departments.

I also get to spend discretionary time writing and optimizing system code, so I really don't see any reason to complain. (I've worked on one of AES contenders http://www.adastral.ucl.ac.uk/~helger/research/aes/, the windows port of NTP http://ntp.org/, HD-DVD decoding, Ogg Vorbis optimization as well as lots of other kinds of code. I am also the Scandinavian coordinator of the Confluence Project http://confluence.org/.)

My role model within the company retired a few years ago, 67 years old, and he's still enthusiastic about brand new technology.

OTOH, living in Norway I also know that it would be effectively impossible to fire me, unless I completely stopped coming into work, and started doing drugs instead.

Terje

NTP uses UTC as reference time

"how many servers does it take to tell you what time it is?"

Just one. On the other hand, how many servers does it take for *you* to be confident about the info recieved? That's a different -and pointy, problem. After all, even an stopped watch will tell you what time is it -only, it will tell you wrongly.

"Isn't it more likely that some of 1000 servers somehow report wrong information instead of one single atomic clock?"

Yes. But then, ask yourself what the effect will be for tens of thousands of clients asking time data to a single atomic clock on its network. What would happen if every single bypasser asks you the time as you go?

"Seriously, what's wrong with one atomic clock? I hear they're KINDA accurate"

Even if they are KINDA accurate, they are no accurate ENOUGH for current standards. For a countrie's official time it usually takes about three atomic clocks to be sure. But, again, the problem here is not about accuracy, but bandwith considerations. That's true both for public Stratum 1 NTP servers as well as for the ntp.pool.org network.

"Can someone please explain this whole concept for us?"

Go to http://www.pool.ntp.org/ and you will find enough information to satisfy your curiosity.

You should install the ntp-doc package and then check out /usr/share/doc/ntp-doc/html/ntpq.html:

peers Obtains a current list peers of the server, along with a summary of each peer's state. Summary information includes the address of the remote peer, the reference ID (0.0.0.0 if this is unknown), the stratum of the remote peer, the type of the peer (local, unicast, multicast or broadcast), when the last packet was received, the polling interval, in seconds, the reachability register, in octal, and the current estimated delay, offset and dispersion of the peer, all in milliseconds. The character at the left margin of each line shows the synchronization status of the association and is a valuable diagnostic tool. The encoding and meaning of this character, called the tally code, is given later in this page.

Furthermore, note that you will get a more accurate reading if you switch from using the generic worldwide 'debian' pool, to a country specific one, as described on How do I setup NTP to use the pool?.

http://www.pool.ntp.org/join.html

Use OpenNTPd! No seriously, there's a bug on ntpd's bugzilla asking for this that has been opened in 2003 and it's still not fixed. ntpd is so badly written that no one dares to write a patch.

And people wonder why I hate every program written by ISC...

The NTP protocol gives very limited ways of limiting it, so short of just closing down if we can't add servers as fast as traffic is added, no - there isn't much we can do.

The vendor program is one way we're trying to get more control, but all else being equal - more servers helps.

I must mention that right now by signing up for the pool now you also have a chance to get some really cool time keeping equipment. :-)

NTP.org" maintains a pool of public NTP servers that are accessible via the hostname "pool.ntp.org", so perhaps something similar would work for a global DTD repository. An industry organization with a vested interest, the W3C seems like the most logical, could maintain the DNS zone and organizations could volunteer some server space and bandwidth to host a mirror of the collected pool of DTDs. Volunteering organizations might come and go, but when that happens it's just a matter of updating the DNS zone to reflect the change and everyone using DTDs just needs to know a single generic hostname will always provide a copy of the required DTD.

Just a thought...

The Network Time Protocol hasn't sued anyone.

Ask Dave Mills, he's right down the road at the University of Delaware!

And there isn't any other NTP that matters.

Don't let these NTP boobs get you down! Contribute to the pool at the real NTP and help keep computer clocks accurate across the globe.

First, my credentials: I've been working with NTP for more than 10 years, my personal web server, which you can find via http://www.ntp.org/ (I won't link directly to try to avoid the /. effect.) have hosted windows binaries of the official NTP distribution for some years now.

Since the original article didn't mention this, I would like to warn NTP users against ever configuring two servers! The reason is that NTP by design requires a plurality of all sources to agree on what the time is, before it will believe any of them.

This means that if you have two sources that disagree slightly, you can relatively easily get into a situation where your local machine decides to distrust both and simply start drifting away. I have actually seen this happen multiple times.

This means that you need to configure either a single or at least three servers, and if you want fault tolerance you actually need four, since that will leave three even when one of them fails.

Terje

They point to pool.ntp.org, which is designed expressly for this purpose.

As another example, many Linux distributions point to a download site for Microsoft msttcorefonts. Do you think they have permission?

They universally point to SourceForge, which was specifically designed for this exact purpose.

Any other examples?

• Failure to obey the Stratum structure of the NTP system
• Failure to follow the permisions structure of the NTP system
• Failure to properly impliment the NTP connection protocol
  

as a member of the NTP pool
[...]
At this moment, I'm supporting roughly 1500 clients

Somehow, I find this value flawed. On my server, also in the pool, I logged requests from 161683 different IPs within just the first 24 hours after joining the pool; thus, only those who just resolved the name accessed it. Most NTP clients do a DNS lookup only once during the startup, thus I expect the usage to increase over time.

I'm in the pool for just over a month; I'll turn on logging for another day to gather the new data.

On the other hand, the percentage values about abusers are roughly the same here.

There is now a way for vendors to use the NTP pool. See http://www.pool.ntp.org/vendors.html for details.

Perhaps then, if it still seems ok, you should do a little reading instead of trying to apply uninformed logic to the question.

http://en.wikipedia.org/wiki/NTP_vandalism
http://www.oreillynet.com/onlamp/blog/2006/02/help _save_the_endangered_time.html
http://www.pool.ntp.org/

Stratum 1 is to be only used by stratum 2. Joe Blow worldwide is not stratum 2. Clear violation of access policies here.

These situations make no sense to me. The NTP system is very easy to use properly.

There's a great little website about how to use ntp.org servers properly.

For the quick-fix people, point your NTP capable system at pool.ntp.org.

If you live in north america, you can use the north-america.pool.ntp.org dns name instead, for only north american servers. The same applies to other continents and several country codes.

Basically, there's no excuse for hard-coding a time server in almost any situation, unless your client is completely incapable of DNS and has no access to external DNS servers.

These situations make no sense to me. The NTP system is very easy to use properly.

There's a great little website about how to use ntp.org servers properly.

For the quick-fix people, point your NTP capable system at pool.ntp.org.

If you live in north america, you can use the north-america.pool.ntp.org dns name instead, for only north american servers. The same applies to other continents and several country codes.

Basically, there's no excuse for hard-coding a time server in almost any situation, unless your client is completely incapable of DNS and has no access to external DNS servers.

Glad to hear. This is a bit off topic, but what kind of bandwidth usage do you experience? I've been wanting to join the NTP pool for a few months now. Their web site mentions something in the range 10-20Kbit/sec, but is that sustained, like an average over a month? I'll subscribe to the mailing list to start getting a feel.

While looking at the join page, they give the apache config fragment. That's great.

<VirtualHost *:80>
ServerName pool.ntp.org
ServerAlias *.pool.ntp.org
Redirect permanent / http://www.pool.ntp.org/
</VirtualHost>

Thanks for the feedback.