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