[arch-general] Leap seconds ntp and chrony?
There has been a fair amount of disruption to systems over a widespread geographic area due to the mutex leap second bug from midnight Saturday, and from what I read this was triggered by ntpd calling specific routines from the kernel - does anyone know if the same bug has also hit systems using chrony if that was in use instead of ntp? I guess that the kernel patches being written by John Stulz at https://lkml.org/lkml/2012/7/1/203 will filter through to a kernel update at some point? -- mike c
On 02/07/12 19:09, mike cloaked wrote:
There has been a fair amount of disruption to systems over a widespread geographic area due to the mutex leap second bug from midnight Saturday, and from what I read this was triggered by ntpd calling specific routines from the kernel - does anyone know if the same bug has also hit systems using chrony if that was in use instead of ntp?
I guess that the kernel patches being written by John Stulz at https://lkml.org/lkml/2012/7/1/203 will filter through to a kernel update at some point?
If you don't have problems now, you don't even need to worry. Else just reboot -- Jelle van der Waa
On 07/02/2012 12:13 PM, Jelle van der Waa wrote:
On 02/07/12 19:09, mike cloaked wrote:
There has been a fair amount of disruption to systems over a widespread geographic area due to the mutex leap second bug from midnight Saturday, and from what I read this was triggered by ntpd calling specific routines from the kernel - does anyone know if the same bug has also hit systems using chrony if that was in use instead of ntp?
I guess that the kernel patches being written by John Stulz at https://lkml.org/lkml/2012/7/1/203 will filter through to a kernel update at some point?
If you don't have problems now, you don't even need to worry. Else just reboot
The biggest problems I saw were with java based apps. I was running a couple of minecraft servers for my kids and as soon as the leap second was inserted: /var/log/kernel.log.1:Jun 30 18:59:59 archangel kernel: [268959.468848] Clock: inserting leap second 23:59:60 UTC minecraft servers on both boxes errored out with "Has system time changed -- unable to keep up" errors. Simply stopping and starting the applications was _not_ enough, it required a complete reboot of the system before minecraft_server in particular would run again. I wondered how widespread the disruption would be, but just judging from my 2 boxes -- I knew it would be fairly widespread. My setup was with dcron and ntp. -- David C. Rankin, J.D.,P.E.
My setup was with dcron and ntp.
Considering servers don't get chance to run the RTC battery down. I've never understood why everyone uses NTP which is an unneeded security risk anyway (OpenBSDs ain't bad). Do we think, in 1938-1945 men couldn't synchronise watches without NTP? Saves checking I suppose but that's it or does it? -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________
My setup was with dcron and ntp.
Considering servers don't get chance to run the RTC battery down. I've never understood why everyone uses NTP which is an unneeded security risk anyway (OpenBSDs ain't bad). Do we think, in 1938-1945 men couldn't synchronise watches without NTP? Saves checking I suppose but that's it or does it?
I accept there are some dodgy RTCs or perhaps old unreliable ones but do you run NTP or replace the server? -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________
On 02-07-2012 23:58, Kevin Chadwick wrote:
My setup was with dcron and ntp.
Considering servers don't get chance to run the RTC battery down. I've never understood why everyone uses NTP which is an unneeded security risk anyway (OpenBSDs ain't bad). Do we think, in 1938-1945 men couldn't synchronise watches without NTP? Saves checking I suppose but that's it or does it?
I accept there are some dodgy RTCs or perhaps old unreliable ones but do you run NTP or replace the server?
I'm not sure that the RTC, even in servers, is made to be very stable with temperature changes and aging, it sure isn't for consumer hardware. Google does run ntp on their network to keep all the machines in sync, otherwise stuff stops working, so i guess ntp is not that evil or at least it has its uses. -- Mauro Santos
On Tue, Jul 3, 2012 at 1:37 AM, Mauro Santos <registo.mailling@gmail.com> wrote:
Google does run ntp on their network to keep all the machines in sync, otherwise stuff stops working, so i guess ntp is not that evil or at least it has its uses.
http://www.h-online.com/open/news/item/Leap-second-Linux-can-freeze-1629805.... In view of the recurring leap second disruptions in its own server farms, Google took the motto "prevention is better than cure" to heart and established a "leap smear" process: using modified NTP servers, Google ensures that every NTP update on the day of the leap second inserts a few milliseconds that add up to a second by the time the leap second is actually inserted. Such minor system time differences are usually tolerated by operating systems.
it sure isn't for consumer hardware.
They could use better use of crystals in the main like watches but I think they are good enough for all except corner cases. One guy on the android list said research had come out with an average of two second slide sqew per week or something rediculous and which I don't believe for one second. I'll start my own tests sometime and find out, including software slide. Either way NTP is irrelevent to me, my servers seem in sync too. So I'd still say the best solution for most purposes is not to use NTP at all. -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________
On 03-07-2012 12:07, Kevin Chadwick wrote:
it sure isn't for consumer hardware.
They could use better use of crystals in the main like watches but I think they are good enough for all except corner cases. One guy on the android list said research had come out with an average of two second slide sqew per week or something rediculous and which I don't believe for one second. I'll start my own tests sometime and find out, including software slide. Either way NTP is irrelevent to me, my servers seem in sync too. So I'd still say the best solution for most purposes is not to use NTP at all.
The problem is that the crystal isn't the only thing that affects the stability of a clock. Without looking at it in-depth I would dare say that the crystal is what contributes less to instabilities. I would say that temperature and voltage dependencies, manufacturing process variations and noise immunity in the RTC electronics might account for more variation than the variation that comes from the crystals. Better electronics and means a more complex circuit thus more silicon area and cost per chip, a more complex circuit probably means more power usage thus it will drain backup batteries or capacitors faster, so unless there is a strong requirement for it there is no incentive to use really circuits with an higher accuracy or better drift characteristics or to provide good supply voltage filtering and implement EMI shielding, all these things add to cost and the area/volume required on the PCB. For most usages the RTC is accurate enough, when more precision is desired you either source parts that specifically comply with your requirements or you can always use some ntp client to sync from a time server, you most probably have to use some ntp client to sync from a time server when you have more than one machine running and want to have consistent time stamps between machines. Like everything else ntpd has to be properly secured and configured, if properly done I suppose it isn't a bigger security problem than anything else with network access. This problem about the leap second and programs going awry is due to a bug in the kernel and not a problem with ntp itself, the only fault that can be attributed to ntp is to expose that bug. -- Mauro Santos
On Tue, 03 Jul 2012 14:10:55 +0100 Mauro Santos <registo.mailling@gmail.com> wrote:
On 03-07-2012 12:07, Kevin Chadwick wrote:
it sure isn't for consumer hardware.
They could use better use of crystals in the main like watches but I think they are good enough for all except corner cases. One guy on the android list said research had come out with an average of two second slide sqew per week or something rediculous and which I don't believe for one second. I'll start my own tests sometime and find out, including software slide. Either way NTP is irrelevent to me, my servers seem in sync too. So I'd still say the best solution for most purposes is not to use NTP at all.
The problem is that the crystal isn't the only thing that affects the stability of a clock. Without looking at it in-depth I would dare say that the crystal is what contributes less to instabilities. I would say that temperature and voltage dependencies, manufacturing process variations and noise immunity in the RTC electronics might account for more variation than the variation that comes from the crystals.
Better electronics and means a more complex circuit thus more silicon area and cost per chip, a more complex circuit probably means more power usage thus it will drain backup batteries or capacitors faster, so unless there is a strong requirement for it there is no incentive to use really circuits with an higher accuracy or better drift characteristics or to provide good supply voltage filtering and implement EMI shielding, all these things add to cost and the area/volume required on the PCB.
For most usages the RTC is accurate enough, when more precision is desired you either source parts that specifically comply with your requirements or you can always use some ntp client to sync from a time server, you most probably have to use some ntp client to sync from a time server when you have more than one machine running and want to have consistent time stamps between machines.
RTC was never designed to be precise. These days OS kernels use ~ 10 nanosecond resolution, so RTC are not fit for the job simply because they run from battery which looses charge over time. A proper use for RTC is as a reference point to start off your kernel time. Besides, most modern devices (routers, cable modems, ARM/MIPS-based PC) do not even have an RTC -- they start from Jan 1 1970 and then sync clock over web.
Like everything else ntpd has to be properly secured and configured, if properly done I suppose it isn't a bigger security problem than anything else with network access. This problem about the leap second and programs going awry is due to a bug in the kernel and not a problem with ntp itself, the only fault that can be attributed to ntp is to expose that bug.
Exactly. Also, ntp doesn't even use TCP -- all ports involved are UDP. -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Watches are perfectly acceptable time keepers especially considering I have a cheap watch stuffed in a drawer that I was surprised hasn't lost seconds in years. RTC: I'm fairly sure many older ones don't even have crystals but are probably still good enough, though I have no accurate quantification yet.
Like everything else ntpd has to be properly secured and configured, if properly done I suppose it isn't a bigger security problem than anything else with network access. This problem about the leap second and programs going awry is due to a bug in the kernel and not a problem with ntp itself, the only fault that can be attributed to ntp is to expose that bug.
Attacker controlled or influenced time is actually more serious than you would think for crypto, logging etc., which is why OpenBSD put so much effort into it and don't allow the clock to go backwards. So do the benefits of ntp outweigh the risk. I'm simply saying in most scenarios no. I'm not saying ntp is at fault, however manually setting the date fixes this problem. So the easiest and in my opinion best solution for most users that wasn't put forward for most users is to disable ntp and set the clock to mr atomic. -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________
On Jul 3, 2012 6:33 PM, "Kevin Chadwick" <ma1l1ists@yahoo.co.uk> wrote:
Watches are perfectly acceptable time keepers especially considering I have a cheap watch stuffed in a drawer that I was surprised hasn't lost seconds in years. RTC: I'm fairly sure many older ones don't even have crystals but are probably still good enough, though I have no accurate quantification yet.
Like everything else ntpd has to be properly secured and configured, if properly done I suppose it isn't a bigger security problem than anything else with network access. This problem about the leap second and programs going awry is due to a bug in the kernel and not a problem with ntp itself, the only fault that can be attributed to ntp is to expose that bug.
Attacker controlled or influenced time is actually more serious than you would think for crypto, logging etc., which is why OpenBSD put so much effort into it and don't allow the clock to go backwards.
Are you claiming that the security problem of ntp is that it might cause time to jump backwards? In that case we are lucky, because that's not how it works. Unless you specifically tell it to, the time will still be monotone and (almost) continuous while adjusted by ntp on Linux. I suggest checking how things work before worrying about imaginary security threats. Also, read up on the drift rates of RTCs, they are generally really bad. Tom
Attacker controlled or influenced time is actually more serious than you would think for crypto, logging etc., which is why OpenBSD put so much effort into it and don't allow the clock to go backwards.
Are you claiming that the security problem of ntp is that it might cause time to jump backwards?
I think I've been quite clear, similar to negative coding. OpenBSD has a security measure called securelevel which if raised from one to two prevents even root setting the clock backwards or near overflow as this can have consequences for the entropy pool. They also put in place measures to reduce client time leakage. The obvious point I ignored is network exploits as clock adjustment is a root process, which is why OpenBSDs implements priviledge seperation and chroot. http://www.openbsd.org/papers/ntpd_sucon04/index.html
In that case we are lucky, because that's not how it works. Unless you specifically tell it to, the time will still be monotone and (almost) continuous while adjusted by ntp on Linux.
I suggest checking how things work before worrying about imaginary security threats. Also, read up on the drift rates of RTCs, they are generally really bad.
Explain why that matters for the usual case which is logging. I have servers some offline from which I can cross reference the logs. Do you... can you.. would you check your logs to the nanosecond and who said I worried. requirements, benefits and threats. Quas dederis solas semper habebis opes. -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________
On Wed, 2012-07-04 at 00:21 +0100, Kevin Chadwick wrote:
I've never seen a system crash even due to a wildly drifting clock
There's still the paradox, that using a kernel-rt we get relatively good timing for some apps, while the "real real time" might be completely out of timing (>= 10 seconds). Btw. I'm running ntpdate and sntp manually (regarding to the distro) and even when there was "negative delay" for the clock, no Linux ever crashed. -- Classical Latin sucks :( Extra fortunam est quidquid donatur amicis Quas dederis, solas semper habebis opes.
[2012-07-04 00:22:25 +0100] Kevin Chadwick:
I think I've been quite clear, similar to negative coding.
You haven't, similar to people spreading FUD. Feel free to share your deep knowledge and thorough understanding of NTP with us ignorants by contributing to this neat little project you might have heard of, Wikipedia: http://en.wikipedia.org/wiki/Network_Time_Protocol#Security_concerns
OpenBSD has a security measure called securelevel which if raised from one to two prevents even root setting the clock backwards or near overflow as this can have consequences for the entropy pool. They also put in place measures to reduce client time leakage. The obvious point I ignored is network exploits as clock adjustment is a root process, which is why OpenBSDs implements priviledge seperation and chroot.
So what? You want to switch to OpenBSD? Please do.
Explain why that matters for the usual case which is logging. I have servers some offline from which I can cross reference the logs. Do you... can you.. would you check your logs to the nanosecond and who said I worried. requirements, benefits and threats.
So because you don't need NTP nobody does? Educate yourself at: http://en.wikipedia.org/wiki/Clock_synchronization#Problems
Quas dederis solas semper habebis opes.
Subsiste sermonem statim. -- Gaetan
I think I've been quite clear, similar to negative coding.
You haven't, similar to people spreading FUD.
Feel free to share your deep knowledge and thorough understanding of NTP with us ignorants by contributing to this neat little project you might have heard of, Wikipedia:
http://en.wikipedia.org/wiki/Network_Time_Protocol#Security_concerns
Funny how people read what they will. I guess you haven't looked up negative coding. What I mean by similar to is if it doesn't benefit you, you will have less bugs and a more stable and secure system by reducing code usage. Therefore I wouldn't even need to know about ntp details, or the work of some very clever people who have looked at the details to make the right choice for me. Some security books say code redcution is pointless, I guess rop attacks have put a pin in that but aside from rop it has served me very well. Disabling ipv6 for example. One of about the two remote root exploits (so far) for OpenBSD was in ipv6 ages ago and more recently this. http://www.hackingipv6networks.com/past-trainings/hip2011-hacking-ipv6-netwo... I guess I regurgitate too many thoughts at once without enough explanation. I Wish I hadn't mentioned the alternative that would certainly not negatively affect most users now. Who knows maybe the bug fix will break something too. Though I'm sure they will test very well considering.
OpenBSD has a security measure called securelevel which if raised from one to two prevents even root setting the clock backwards or near overflow as this can have consequences for the entropy pool. They also put in place measures to reduce client time leakage. The obvious point I ignored is network exploits as clock adjustment is a root process, which is why OpenBSDs implements priviledge seperation and chroot.
So what? You want to switch to OpenBSD? Please do.
I use OpenBSD more than arch actually, almost entirely for servers. -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________
I think I've been quite clear, similar to negative coding.
You haven't, similar to people spreading FUD.
Feel free to share your deep knowledge and thorough understanding of NTP with us ignorants by contributing to this neat little project you might have heard of, Wikipedia:
http://en.wikipedia.org/wiki/Network_Time_Protocol#Security_concerns
http://osvdb.org/search?search%5Bvuln_title%5D=ntp&search%5Btext_type%5D=alltext I'm sure some Windows ones are missing and probably others too. Other concerns like securelevel 2 on OpenBSD prevents are very unlikely to hit those lists. I should probably mention Securelevel 2 isn't recommended by the devs on OpenBSD though for usability reasons. This doesn't mean I am saying ntp is insecure or to be considered a risk but what's BEST for you. -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________
[2012-07-04 12:05:18 +0100] Kevin Chadwick:
What I mean by similar to is if it doesn't benefit you, you will have less bugs and a more stable and secure system by reducing code usage.
Are you just saying that people who don't need an NTP daemon are better off not running one? [2012-07-04 12:19:03 +0100] Kevin Chadwick:
http://osvdb.org/search?search%5Bvuln_title%5D=ntp&search%5Btext_type%5D=alltext
Those ten issues have been fixed for years... -- Gaetan
What I mean by similar to is if it doesn't benefit you, you will have less bugs and a more stable and secure system by reducing code usage.
Are you just saying that people who don't need an NTP daemon are better off not running one?
Yep and many who think they do need one may well not need one. I think stories of RTC inaccuracy are exaggerated due to those who really need very accurate clocks and so getting rather annoyed. PC hardware is designed with just it's RTC and no ntp in mind after all. Some distros like Ubuntu seem to assume (or did) that no one would ever want to switch ntp off. I wonder if any ubuntu server users have had any issues there recently. I guess they wouldn't have known until it was too late though? -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________
On Wed, 4 Jul 2012 16:42:04 +0100 Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
What I mean by similar to is if it doesn't benefit you, you will have less bugs and a more stable and secure system by reducing code usage.
Are you just saying that people who don't need an NTP daemon are better off not running one?
Yep and many who think they do need one may well not need one. I think stories of RTC inaccuracy are exaggerated due to those who really need very accurate clocks and so getting rather annoyed. PC hardware is designed with just it's RTC and no ntp in mind after all.
But the goal of ntp is not only timekeeping, but mainly syncronization. Potentially everyone needs precise timesync, unless you exist in a lab isolated from the world. For example, kerberos 5 needs time syncronization between clients and a server. I can imagine that dhcp leases do too, especially on busy networks like those deployed in universities. If you have a mercurial/git installation even in a small group, I am sure you'll prefer accurate timestamps in your commit history. And the list goes on...
Some distros like Ubuntu seem to assume (or did) that no one would ever want to switch ntp off. I wonder if any ubuntu server users have had any issues there recently. I guess they wouldn't have known until it was too late though?
That is a reasonable assumption (windows vista/7 makes it too, btw). The only downside may be CPU wakeups caused by ntp, but that's the chrony story. Regarding ubuntu servers and leap seconds, they were not any more or less vulnerable than others. Whether or not you were affected depended on particular applications which were run atm. For example, on my machine leap second addition was completely seemless. -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
If you have a mercurial/git installation even in a small group, I am sure you'll prefer accurate timestamps in your commit history. And the list goes on...
I believe an RTC is perfectly capable of that.
Some distros like Ubuntu seem to assume (or did) that no one would ever want to switch ntp off. I wonder if any ubuntu server users have had any issues there recently. I guess they wouldn't have known until it was too late though?
That is a reasonable assumption (windows vista/7 makes it too, btw). The only downside may be CPU wakeups caused by ntp, but that's the chrony story.
On systems where lots is enabled by default it is perhaps a reasonable assumption to run ntp by default, if it truly wakes the cpu then I'd say that default is wrong too. It is not reasonable to force users to chmod 000 ntp because init configuration is being ignored which was the case for atleast one Ubuntu release. Windows 7 does the same as XP, enabled by default but can be switched off in atleast three places. Time config, Windows Time service and Group policy. -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________
On Wed, Jul 4, 2012 at 9:06 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
If you have a mercurial/git installation even in a small group, I am sure you'll prefer accurate timestamps in your commit history. And the list goes on...
I believe an RTC is perfectly capable of that.
I tried to find some data on what to expect from RTC's. I was not very successful, except finding people citing 80-100PPM as typical drift rates (~8 secs/day). Having a look at my own machine (a reasonably new Dell laptop) I don't see values quite that bad. I lose about 14 PPM, which amounts to roughly seven minutes in a year. Having that kind of discrepancies on a network doing distributed development would wreck absolute havoc. -t
On 04-07-2012 21:00, Tom Gundersen wrote:
On Wed, Jul 4, 2012 at 9:06 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
If you have a mercurial/git installation even in a small group, I am sure you'll prefer accurate timestamps in your commit history. And the list goes on...
I believe an RTC is perfectly capable of that.
I tried to find some data on what to expect from RTC's. I was not very successful, except finding people citing 80-100PPM as typical drift rates (~8 secs/day).
From data I have access to, taken from machines running ntpd, I can say the following about the drift in PPM stored in ntpd's drift file:
my laptop: -9.699 machine 1: -8.762 machine 2: -443.266 machine 3: -35.417 Machine 1 is the newest and machine 3 is the oldest.
Having a look at my own machine (a reasonably new Dell laptop) I don't see values quite that bad. I lose about 14 PPM, which amounts to roughly seven minutes in a year.
Having that kind of discrepancies on a network doing distributed development would wreck absolute havoc.
-t
-- Mauro Santos
On Wed, Jul 4, 2012 at 11:06 PM, Mauro Santos <registo.mailling@gmail.com> wrote:
On 04-07-2012 21:00, Tom Gundersen wrote:
On Wed, Jul 4, 2012 at 9:06 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
If you have a mercurial/git installation even in a small group, I am sure you'll prefer accurate timestamps in your commit history. And the list goes on...
I believe an RTC is perfectly capable of that.
I tried to find some data on what to expect from RTC's. I was not very successful, except finding people citing 80-100PPM as typical drift rates (~8 secs/day).
From data I have access to, taken from machines running ntpd, I can say the following about the drift in PPM stored in ntpd's drift file:
my laptop: -9.699 machine 1: -8.762 machine 2: -443.266 machine 3: -35.417
Machine 1 is the newest and machine 3 is the oldest.
One more data point: my wrist watch is off by about 20ppm (unless I forget to wind it, then it is more ;-) ). -t
On Wed, 04 Jul 2012 22:06:27 +0100 Mauro Santos <registo.mailling@gmail.com> wrote:
On 04-07-2012 21:00, Tom Gundersen wrote:
On Wed, Jul 4, 2012 at 9:06 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
If you have a mercurial/git installation even in a small group, I am sure you'll prefer accurate timestamps in your commit history. And the list goes on...
I believe an RTC is perfectly capable of that.
I tried to find some data on what to expect from RTC's. I was not very successful, except finding people citing 80-100PPM as typical drift rates (~8 secs/day).
From data I have access to, taken from machines running ntpd, I can say the following about the drift in PPM stored in ntpd's drift file:
my laptop: -9.699 machine 1: -8.762 machine 2: -443.266 machine 3: -35.417
Machine 1 is the newest and machine 3 is the oldest.
AFAIK comparing RTCs on different machines is meaningless because there seem to be no quality handle for RTC. So, RTC may exist or not, but you can't choose (and therefore guarantee) to have a good RTC, at least on consumer (not server) motherboards. NTPD on the other hand implements a protocol $\equiv$ standard. FWIW, my driftfile yields +6.982ppm which I guess is good compared to yours. Re machine 2 -- I bet your CMOS battery is dying.
Having a look at my own machine (a reasonably new Dell laptop) I don't see values quite that bad. I lose about 14 PPM, which amounts to roughly seven minutes in a year.
Having that kind of discrepancies on a network doing distributed development would wreck absolute havoc.
-t
-- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Wed, Jul 4, 2012 at 6:11 PM, Leonid Isaev <lisaev@umail.iu.edu> wrote:
On Wed, 04 Jul 2012 22:06:27 +0100 Mauro Santos <registo.mailling@gmail.com> wrote:
From data I have access to, taken from machines running ntpd, I can say the following about the drift in PPM stored in ntpd's drift file:
my laptop: -9.699 machine 1: -8.762 machine 2: -443.266 machine 3: -35.417
Machine 1 is the newest and machine 3 is the oldest.
AFAIK comparing RTCs on different machines is meaningless because there seem to be no quality handle for RTC. So, RTC may exist or not, but you can't choose (and therefore guarantee) to have a good RTC, at least on consumer (not server) motherboards. NTPD on the other hand implements a protocol $\equiv$ standard.
FWIW, my driftfile yields +6.982ppm which I guess is good compared to yours.
Re machine 2 -- I bet your CMOS battery is dying.
per NTP FAQ, as basis for estimate: http://www.ntp.org/ntpfaq/NTP-s-sw-clocks-quality.htm#AEN1220 "[...] I'll simply state that 12 PPM correspond to one second per day roughly." ... actual value is (1/86400)*1000000 = 11.574. -9.375 = local server (never off/moved) -22.538 = docked laptop (never off/moved) -65.089 = remote server (linode.com [xen]) so my local clocks run a wee bit hot (and xen clocksource sucks?). since kerberos clockskew defaults to 300 seconds, i would begin to perm fail authentication (local -> remote server) after ... p = ppm, s = sec, d = day s / ( p / ( p / ( s / d ) ) ) s / ( p * ( ( s / d ) / p ) ) s / ( s / d ) s * ( d / s ) d skew-sec-max / ( ABS(skew-ppm-var) / skew-ppm-per-sec-per-day ) 300 / (( 65 - 9 ) / 12 ) ... 62.32 days, or ~2 months [annoying] ... yay for NTP! ... (and also math! if it's correct!) clearly i went a bit overboard, but it seems like the only thing you can depend on is RTC failing you 0-12 times-per-year, depending on your gear and sensitivity to time variance. although, it would be cool if authenticated NTP were more widespread/ubiquitous -- a la Windows time service [signed packets] -- but since i've never cared much about it i'm probably just not aware ... -- C Anthony
"[...] I'll simply state that 12 PPM correspond to one second per day roughly.
I'm skeptical and am more inclined to think ntp has measurement problems or a decimal has been missed or something but it's easy to check with real world direct simple data which I always prefer, so we shall see. The reason I am skeptical is I have lots of machines that don't use ntp and I'd expect but of course could be very wrong that I would have noticed if I had to fix the clocks by 8 minutes per year. I'll mark this mail and let the list know. What I am less likely to get around to is comparing this data to what ntp would suggest the skew is for each machine, but no matter for now. -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________
On Thu, Jul 5, 2012 at 1:16 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
"[...] I'll simply state that 12 PPM correspond to one second per day roughly.
I'm skeptical and am more inclined to think ntp has measurement problems or a decimal has been missed or something but it's easy to check with real world direct simple data which I always prefer, so we shall see.
that value [12ppm] is correct -- `ppm` is a dimensionless ratio between 0 and 1; units *must* cancel, leaving only a pure coefficient which is then scaled to X/1,000,000 by multiplying by some N/N scaling factor. since there are 86400 seconds in one day, expressing a 1 second loss per day is the same as saying a 1 second loss per 86400 seconds, or: 0.0000115 = 1/86400 0.0000115 = 1/86400 * (11.57/11.57) 0.0000115 = 11.57/1000000 0.0000115 = 11.57 ppm ... even Wikipedia says: "One part per million (ppm) denotes one part per 1,000,000 parts [...] or about 32 seconds out of a year." ... if 1 ppm is ~32 seconds per year, then 12 ppm is ~384 per year: a little over 1 per day :-) -- C Anthony
On 05-07-2012 00:11, Leonid Isaev wrote:
Re machine 2 -- I bet your CMOS battery is dying.
That may well be the case, but it is an always on machine with ups backup, and it hasn't been shutdown for a good while now. I thought that while the system is powered on the rtc would get power from the mains and not from the battery, at least that is the experience I have with machines where the battery has died for good. -- Mauro Santos
I lose about 14 PPM, which amounts to roughly seven minutes in a year.
Try disabling ntp for a week. Set your clock to atomic manually. By your reckoning you should be out by over eight seconds in a week. Let's see?
Having that kind of discrepancies on a network doing distributed development would wreck absolute havoc.
Why? -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________
On Tue, 3 Jul 2012 17:32:40 +0100 Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
Watches are perfectly acceptable time keepers especially considering I have a cheap watch stuffed in a drawer that I was surprised hasn't lost seconds in years. RTC: I'm fairly sure many older ones don't even have crystals but are probably still good enough, though I have no accurate quantification yet.
Noone cares about seconds -- we talk about a 10ns resolution. This is cool, especially if you consider the time scale on which the current propagates inside your motherboard.
Like everything else ntpd has to be properly secured and configured, if properly done I suppose it isn't a bigger security problem than anything else with network access. This problem about the leap second and programs going awry is due to a bug in the kernel and not a problem with ntp itself, the only fault that can be attributed to ntp is to expose that bug.
Attacker controlled or influenced time is actually more serious than you would think for crypto, logging etc., which is why OpenBSD put so much effort into it and don't allow the clock to go backwards. So do the benefits of ntp outweigh the risk. I'm simply saying in most scenarios no.
While I respect OpenBSD, sometimes I think they create too much buzz around their "security". I have never seen a clear case when OpenNTPD was a winner security-wise (i.e. not after a default installation). Are you telling me that if my clock is in the future, openntpd is not going to adjust it backwards? This certainly happened to me across DST when my clock was on localtime. NTPD also does this, see man ntpd. As with any networking protocol, any NTPD implementation opens you to yet another attack vector -- yes. However, there are also countermeasures, see http://www.eecis.udel.edu/~mills/security.html. Have you seen the movie Entrapment (http://en.wikipedia.org/wiki/Entrapment_(film))? This is roughly how attacks over NTP can be carried out...
I'm not saying ntp is at fault, however manually setting the date fixes this problem. So the easiest and in my opinion best solution for most users that wasn't put forward for most users is to disable ntp and set the clock to mr atomic.
Again, RTCs are usually crap -- by design. My understanding that it's not the drift which troubles, it's the unpredictibility which renders them useless for event coordination. So if you want good timing you'll have to use ntpd because OpenNTPD is less accurate, has fewer features and is long unsupported on Linux.
-- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Tue, 3 Jul 2012 17:32:40 +0100 Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
Watches are perfectly acceptable time keepers especially considering I have a cheap watch stuffed in a drawer that I was surprised hasn't lost seconds in years. RTC: I'm fairly sure many older ones don't even have crystals but are probably still good enough, though I have no accurate quantification yet.
Noone cares about seconds -- we talk about a 10ns resolution. This is cool, especially if you consider the time scale on which the current propagates inside your motherboard.
ns resolution like rtos is a requirement for certain and few applications. Who'd have thought such a simple rational mind resting suggestion not involving a reboot, would cause all this. I've never seen a system crash even due to a wildly drifting clock, yet many have it seems using ntp. So can that talk possibly be relevant not that I wouldn't be interested in what comes to your mind when saying that. Do you mean voltage?
Like everything else ntpd has to be properly secured and configured, if properly done I suppose it isn't a bigger security problem than anything else with network access. This problem about the leap second and programs going awry is due to a bug in the kernel and not a problem with ntp itself, the only fault that can be attributed to ntp is to expose that bug.
Attacker controlled or influenced time is actually more serious than you would think for crypto, logging etc., which is why OpenBSD put so much effort into it and don't allow the clock to go backwards. So do the benefits of ntp outweigh the risk. I'm simply saying in most scenarios no.
While I respect OpenBSD, sometimes I think they create too much buzz around their "security". I have never seen a clear case when OpenNTPD was a winner security-wise (i.e. not after a default installation).
What does that mean. You know OpenBSD is the only OS to be banned from a certain security competition, right? Like ninjitsu from MMA, it just spoilt the game.
Are you telling me that if my clock is in the future, openntpd is not going to adjust it backwards? This certainly happened to me across DST when my clock was on localtime. NTPD also does this, see man ntpd.
You would need to defeat the kernel if OpenBSD is booted to securelevel 2. It's rediculously more bug free than linux too as this problem demonstrates.
As with any networking protocol, any NTPD implementation opens you to yet another attack vector -- yes. However, there are also countermeasures, see http://www.eecis.udel.edu/~mills/security.html.
Have you seen the movie Entrapment (http://en.wikipedia.org/wiki/Entrapment_(film))? This is roughly how attacks over NTP can be carried out...
I'm not saying ntp is at fault, however manually setting the date fixes this problem. So the easiest and in my opinion best solution for most users that wasn't put forward for most users is to disable ntp and set the clock to mr atomic.
Again, RTCs are usually crap -- by design. My understanding that it's not the drift which troubles, it's the unpredictibility which renders them useless for event coordination. So if you want good timing you'll have to use ntpd because OpenNTPD is less accurate, has fewer features and is long unsupported on Linux.
Accuracy wasn't the priority, though it was obviously a goal and Linux isn't a realtime OS. Define good timing and why the average users needs it. As I have said ntp has it's uses as does GPS time if not taken on face value (OpenBSD avoids the spoofing problem). I wonder if the Linux variants do, I hear they are full of features as usual, what about consideration?
Useless for event coordination
are you talking a missile strike because my cron runs just fine? I believe the main reason for ntp in the main is to ensure avoidance of broken clocks like an old tv system of mine that used to keep good time has. If you take personal care of your systems it is likely just unneeded risk. -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________
I believe the main reason for ntp in the main is to ensure avoidance of broken clocks like an old tv system of mine that used to keep good time has. If you take personal care of your systems it is likely just unneeded risk.
Maybe I should add that if I was Google I would certainly use ntp every time as they have like 1000 servers per engineer. -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________
On Mon, 2 Jul 2012 23:58:24 +0100 Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
My setup was with dcron and ntp.
Considering servers don't get chance to run the RTC battery down. I've never understood why everyone uses NTP which is an unneeded security risk anyway (OpenBSDs ain't bad). Do we think, in 1938-1945 men couldn't synchronise watches without NTP? Saves checking I suppose but that's it or does it?
I accept there are some dodgy RTCs or perhaps old unreliable ones but do you run NTP or replace the server?
It's very simple Run NTP . Is your system of national importance NO do you have top secret millitary info on your system NO , So what is with this continual whimpering about security risks that are almost non existant Pete . -- Linux 7-of-9 3.4.4-2-ARCH #1 SMP PREEMPT Sun Jun 24 18:59:47 CEST 2012 x86_64 GNU/Linux
On Tue, 2012-07-03 at 08:40 +0100, P .NIKOLIC wrote:
Is your system of national importance NO do you have top secret millitary info on your system NO
You're mistaken Pete, if we would talk about our orders we would have to kill you ;). Greetings from my Mossad-PC, Ralf # ntpdate ntp.favey.ch 3 Jul 18:48:10 ntpdate[6687]: step time server 195.34.89.227 offset -1.147282 sec
On Tue, 03 Jul 2012 18:48:44 +0200 Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
On Tue, 2012-07-03 at 08:40 +0100, P .NIKOLIC wrote:
Is your system of national importance NO do you have top secret millitary info on your system NO
You're mistaken Pete,
if we would talk about our orders we would have to kill you ;).
Greetings from my Mossad-PC, Ralf
# ntpdate ntp.favey.ch 3 Jul 18:48:10 ntpdate[6687]: step time server 195.34.89.227 offset -1.147282 sec
I very much doubt that know what i mean Pete click bang -- Linux 7-of-9 3.4.4-2-ARCH #1 SMP PREEMPT Sun Jun 24 18:59:47 CEST 2012 x86_64 GNU/Linux
On Tue, 2012-07-03 at 20:14 +0100, P .NIKOLIC wrote:
On Tue, 03 Jul 2012 18:48:44 +0200 Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
On Tue, 2012-07-03 at 08:40 +0100, P .NIKOLIC wrote:
Is your system of national importance NO do you have top secret millitary info on your system NO
You're mistaken Pete,
if we would talk about our orders we would have to kill you ;).
Greetings from my Mossad-PC, Ralf
# ntpdate ntp.favey.ch 3 Jul 18:48:10 ntpdate[6687]: step time server 195.34.89.227 offset -1.147282 sec
I very much doubt that know what i mean
Pete click bang
:) I completely agree with your statement. However we sync time for our Linux computers, it's not a very important security risk. And yes, I got the notice to terminate from my side job at the Mossad some seconds after I send my last mail to the list. - Ralf
On Tue, 2012-07-03 at 22:15 +0200, Ralf Mardorf wrote:
On Tue, 2012-07-03 at 20:14 +0100, P .NIKOLIC wrote:
On Tue, 03 Jul 2012 18:48:44 +0200 Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
On Tue, 2012-07-03 at 08:40 +0100, P .NIKOLIC wrote:
Is your system of national importance NO do you have top secret millitary info on your system NO
You're mistaken Pete,
if we would talk about our orders we would have to kill you ;).
Greetings from my Mossad-PC, Ralf
# ntpdate ntp.favey.ch 3 Jul 18:48:10 ntpdate[6687]: step time server 195.34.89.227 offset -1.147282 sec
I very much doubt that know what i mean
Pete click bang
:) I completely agree with your statement. However we sync time for our Linux computers, it's not a very important security risk. And yes, I got the notice to terminate from my side job at the Mossad some seconds after I send my last mail to the list.
- Ralf
Last time somebody on this list mentioned Kim Jong-il as an anonymous Arch package builder, Kim Jong-il died some days or weeks later :). Regarding to the Wiki he died at 17 December 2011. I'm sure around this time there was a joke about security too, before this idiot died. Nostradamus you're subscribed to this list, http://upload.wikimedia.org/wikipedia/commons/thumb/c/c6/Nostradamus_by_Cesa... Who are you? http://upload.wikimedia.org/wikipedia/en/thumb/7/75/Who_Are_You_album_cover....
My setup was with dcron and ntp.
Considering servers don't get chance to run the RTC battery down. I've never understood why everyone uses NTP
RTC is only read on boot-up on all Linux systems. And from what I've seen they are fairly inaccurate. Otherwise, the Linux kernel counts its own time in software, but that time could drift very easily too. -- дамјан
participants (13)
-
C Anthony Risinger
-
Damjan
-
David C. Rankin
-
Gaetan Bisson
-
Jelle van der Waa
-
Karol Blazewicz
-
Kevin Chadwick
-
Leonid Isaev
-
Mauro Santos
-
mike cloaked
-
P .NIKOLIC
-
Ralf Mardorf
-
Tom Gundersen