unruh wrote:
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.
Please feel free to install your own "fix" for the deficiencies you
perceive in NTPD and see how well it keeps time. I know, you want
SOMEBODY ELSE to do the work! There may not be anyone else!
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
