On Tue, 03 Jul 2012 14:10:55 +0100 Mauro Santos <registo.mailling@xxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
