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
