On 2010-05-08, Richard B. Gilbert <[email protected]> wrote: > Rob wrote: >> Andy Helten <[email protected]> wrote: >>> Rob wrote: >>>> Kalle Pokki <[email protected]> wrote: >>>> >>>>> Yes, but reference clock drivers don't use the ntp timestamp. Take a >>>>> look at e.g. the SHM driver. There >>>>> >>>> Is this piece of code something that our friend does not want to change >>>> because he believes it is doing the right thing? Or is it merely badly >>>> written by a contributor and nobody got around to cleaning it up? >>>> >>>> I would say it is completely pointless to decompose a timeval timestamp >>>> into separate fields and then back. That only costs CPU time and induces >>>> errors. >>> You should read the discussion in the bug report that was previously >>> provided by Kalle: https://bugs.ntp.org/417 >>> >>> It includes justification from David Mills on why it works this way. I >>> don't know that his justification specifically addressed the inability >>> to even force a quick sync with a refclock when it differs by more than >>> 4 hours from system time (i.e. the CLOSETIME stuff). To me, there is no >>> justification for such behavior with respect to forcing a quick sync. >>> In such cases, ntpd is saying to the user "I know best" but it turns >>> that it doesn't. >> >> It sometimes gets a bit tiresome that mr. Mills always brings up his >> experiences with 20 year old systems to dictate what can be done with >> ntpd today. He has seen clockchips (interestingly named TOY clocks by > > TOY Clock or "Time Of Year Clock" is a Hardware clock present on, AFAIK, > all models of DEC VAX and Alpha computers. It runs on battery power > when the system is powered down. Many computers, including most PCs > feature such a clock. They generally do not keep time very well!
but the rtc on pcs do provide the year. They may not keep time well, but do keep it to better than a year. > >> him) that don't provide the year, and hence the year should not be >> used by anything. He has a clockdriver that does not provide the year >> and so no clockdriver should provide the year. >> But is this still true today? I think any reasonable clock chip in use > > The clock CHIP is not the problem. The problem is that the quartz > crystal that provides the "tick" is usually one that failed quality > control at a wristwatch factory. Who cares. It keeps time to seconds per month, and unless you switch off your computer for a century, that is 'good enough' to intialise the clock. > > If the manufacturer was willing to spend money he could build a clock > that would not gain or lose more than three or four seconds per year. > Would you pay an additional $50 per PC in order to have such a clock? > I believe that most people don't care. The only reason that most > computers need a clock is in order to get the date right when you are > using Quicken, or similar software, to write checks! I have no idea how this answers the criticism. > >> today has the year information, and a reference clock like ntpshm has >> year info within the range of 32bit time_t just as well. By the time >> that will be a problem, time_t will be 64bit I hope. >> We should not drive current users to despair (because they cannot set >> their clocks) just because of some problem that existed 20 years ago >> or will come up in 28 years time. >> >> With such an attitude against change, it often surprises me that there >> hasn't been a major fork of ntpd yet. > > The source code for NTPD is available. Fork away. Or fork off! Oh dear. A suggestion for improvement of a clear deficiency on ntpd is made and you come up with this. _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
