On Mon, Feb 16, 2015 at 1:11 AM, William Unruh un...@invalid.ca wrote:
But that is not what you said. When I asked how ntimed works you
answered that it disciplines the computer clock.
BZZT!
You said: Be interesting to see how and what it does.
To which I replied: Since I've told you how
On Sat, Feb 14, 2015 at 11:21 PM, William Unruh un...@invalid.ca wrote:
If you demand that I give
detailed explanation
You started off down the ntpd versus chrony path again.
To get the discussion started, lets compare some of the differences
between chrony and ntpd
That's not useful.
Harlan Stenn wrote:
David Lord writes:
... The one big flaw with ntpd is that when motherboard temperature
changes too quickly the ntpd control loop is broken and ntp offset can
rise from 300u to 10ms.
That might have been a false alarm.
I've not yet been able to search all the logs.
In article mbqnu5$f15$3...@dont-email.me,
William Unruh un...@invalid.ca wrote:
I bring up chrony not to discuss it as a program but todiscuss its
philosophy of clock control and its design. It presents an alternative
to the approach of ntpd, which ntimed appears to be following.
There is
On 2015-02-15, Philip Homburg phi...@ue.aioy.eu wrote:
In article mbqnu5$f15$3...@dont-email.me,
William Unruh un...@invalid.ca wrote:
I bring up chrony not to discuss it as a program but todiscuss its
philosophy of clock control and its design. It presents an alternative
to the approach of
On 2015-02-15, Paul tik-...@bodosom.net wrote:
On Sat, Feb 14, 2015 at 11:21 PM, William Unruh un...@invalid.ca wrote:
If you demand that I give
detailed explanation
You started off down the ntpd versus chrony path again.
To get the discussion started, lets compare some of the
In article mbqt2f$b9i$1...@dont-email.me,
William Unruh un...@invalid.ca wrote:
The documentation has some, but much is in the code.
I think that's bad situation if you want the ideas embedded in the code
to be adopted by other implementations.
--
We just programmed the computers to revive
On Sun, Feb 15, 2015 at 1:18 PM, William Unruh un...@invalid.ca wrote:
Thank you. I had no idea what the new version was called, and saw
someone call it timed. Sorry if it confused you.
This means you're not paying attention to details. It also means you're
not reading PHK's notes.
I
On 2015-02-16, Paul tik-...@bodosom.net wrote:
On Sun, Feb 15, 2015 at 1:18 PM, William Unruh un...@invalid.ca wrote:
It I say to someone-- I hear you are trying out the new
Subaru, I wonder how it works
If you ask me how my new Subaru works I'd say fine. If you ask me how much
But that
On 2015-02-15, David Lord sn...@lordynet.org wrote:
William Unruh wrote:
On 2015-02-14, Paul tik-...@bodosom.net wrote:
On Sat, Feb 14, 2015 at 2:09 PM, William Unruh un...@invalid.ca wrote:
Yes but you said
This means that if you are using say a PPS source, which gives
microsecond long
On Fri, Feb 13, 2015 at 8:48 PM, William Unruh un...@invalid.ca wrote:
I had a properly set up PPS source to do the comparison.
As did I.
Ooops, I see that the text/plain part of the message was damaged. I was
quoting you saying:
I had a properly set up PPS source and my response was we
On 2015-02-14, Paul tik-...@bodosom.net wrote:
On Fri, Feb 13, 2015 at 8:48 PM, William Unruh un...@invalid.ca wrote:
However you've not responded to my question regarding your deep concerns.
For years you've complained about the ntpd pll and on occasion suggested
chrony. Now a replacement
On Sat, Feb 14, 2015 at 2:09 PM, William Unruh un...@invalid.ca wrote:
Because ntpd is what I know.
Except you've admitted you don't know NTPd.
If you are saying that this is all up in the air again with
the new replacement, that would be great. But I have seen no evidence
thereof in
On 2015-02-14, Paul tik-...@bodosom.net wrote:
On Sat, Feb 14, 2015 at 2:09 PM, William Unruh un...@invalid.ca wrote:
Yes but you said
This means that if you are using say a PPS source, which gives
microsecond long term offset, it can take many hours to get there
and I was responding to
William Unruh wrote:
On 2015-02-14, Paul tik-...@bodosom.net wrote:
On Sat, Feb 14, 2015 at 2:09 PM, William Unruh un...@invalid.ca wrote:
Yes but you said
This means that if you are using say a PPS source, which gives
microsecond long term offset, it can take many hours to get there
and I
On Sat, Feb 14, 2015 at 6:38 PM, William Unruh un...@invalid.ca wrote:
When timed is actually out I may be interested in testing it again.
Ntimed-client. Again? So you've installed the code?
https://github.com/bsdphk/Ntimed
That seems unlikely. Read this:
David Lord writes:
... The one big flaw with ntpd is that when motherboard temperature
changes too quickly the ntpd control loop is broken and ntp offset can
rise from 300u to 10ms.
Assuming the above is true (and I have no reason to doubt David's
numbers) I have to wonder if it would be an
Terje Mathisen terje.mathi...@tmsw.no wrote:
Charles Swiger wrote:
On Feb 12, 2015, at 1:56 AM, Rob nom...@example.com wrote:
However, what I observe is that the plots of the offset show the derivative
of the environment temperature, which unfortunately cannot be controlled
any better. I am
William Unruh un...@invalid.ca wrote:
No, that is a hardware solution. There are software solutions-- a
termistor to meaure the temperature of the crystal ( or somethign
nearby) which feeds that measurement to the OS. the revised ntp then
reads the temperature, and corrects the drift rate as a
On Fri, Feb 13, 2015 at 05:42:54AM +, William Unruh wrote:
On 2015-02-13, Paul tik-...@bodosom.net wrote:
On Thu, Feb 12, 2015 at 7:27 PM, William Unruh un...@invalid.ca wrote:
It was based on measurements I made with ntpd
Are you assuming the numbers I provided are based on theory
David Lord wrote:
Solutions that measure the temperature require calibration
for the individual crystal as with the cheap crystals used
the drift per deg C can be either positive or negative and
also depending on cut of the crystal can follow a
parabolic or lazy S curve.
The only reasonable
Rob wrote:
Terje Mathisen terje.mathi...@tmsw.no wrote:
Charles Swiger wrote:
On Feb 12, 2015, at 1:56 AM, Rob nom...@example.com wrote:
However, what I observe is that the plots of the offset show the derivative
of the environment temperature, which unfortunately cannot be controlled
any
On Fri, Feb 13, 2015 at 12:42 AM, William Unruh un...@invalid.ca wrote:
OK, so we seem to have two different sets of experiments with very
different results. Note that I did not erase the drift file, or restart
ntpd after my perturbation.
Okay, I offset my clock by 100ms without restarting
On Feb 12, 2015, at 11:21 PM, Terje Mathisen terje.mathi...@tmsw.no wrote:
I've considered packing some insulation around the crystal, this would tend
to stabilize (while also increasing) the temperature, but this would also be
likely to reduce its lifetime, and the motherboard would probably
David Lord sn...@lordynet.org wrote:
Rob wrote:
Terje Mathisen terje.mathi...@tmsw.no wrote:
Charles Swiger wrote:
On Feb 12, 2015, at 1:56 AM, Rob nom...@example.com wrote:
However, what I observe is that the plots of the offset show the
derivative
of the environment temperature, which
On 2015-02-13, Paul tik-...@bodosom.net wrote:
On Fri, Feb 13, 2015 at 12:42 AM, William Unruh un...@invalid.ca wrote:
OK, so we seem to have two different sets of experiments with very
different results. Note that I did not erase the drift file, or restart
ntpd after my perturbation.
On 12/02/2015 17:00, William Unruh wrote:
[]
This means that if you are using say a PPS source, which gives
microsecond long term offset, it can take many hours to get there, even
if you or I looking at the offsets could see that it is off by ms after
the first few poll intervals.
[]
Almost
On Feb 12, 2015, at 12:49 AM, William Unruh un...@invalid.ca wrote:
On 2015-02-11, Charles Swiger cswi...@mac.com mailto:cswi...@mac.com
wrote:
On Feb 11, 2015, at 7:23 AM, Rob nom...@example.com
mailto:nom...@example.com wrote:
But I see it has also been explained elsewhere in the thread:
On Feb 12, 2015, at 1:56 AM, Rob nom...@example.com wrote:
Charles Swiger cswi...@mac.com wrote:
On Feb 11, 2015, at 7:23 AM, Rob nom...@example.com wrote:
But I see it has also been explained elsewhere in the thread: ntpd has
a maximum on the momentary drift of 500ppm, no matter if it is
Bill,
So you believe:
- the broken linux kernel behavior is an acceptable (or at least
excusable) fact of life,
- that should have been predicted and accommodated by stable-running
software and algorithms that have been around for decades,
- where no other kernel has ever misbehaved in
On 2015-02-12, Rob nom...@example.com wrote:
William Unruh un...@invalid.ca wrote:
On 2015-02-12, Rob nom...@example.com wrote:
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
On 2015-02-12 03:00, Rob wrote:
catherine.wei1...@gmail.com catherine.wei1...@gmail.com wrote:
Yes,I just tested
In article mbinbu$a5r$1...@dont-email.me,
William Unruh un...@invalid.ca wrote:
The complaint of the ntpd people is not the stability of the machine
itself, but the stability of the network, where for example A could use
B and B use A in determining its own time. Is the whole network stable
under
On 2015-02-11, Charles Swiger cswi...@mac.com wrote:
On Feb 11, 2015, at 7:23 AM, Rob nom...@example.com wrote:
But I see it has also been explained elsewhere in the thread: ntpd has
a maximum on the momentary drift of 500ppm, no matter if it is static
or dynamic or the sum of two. I think
On 2015-02-11, Paul tik-...@bodosom.net wrote:
On Wed, Feb 11, 2015 at 4:32 PM, Harlan Stenn st...@ntp.org wrote:
There are times repair is perfectly acceptable, and we do that.
There are times replace is better, and we do that.
My point is a long drawn-out discussion of changes to the
On Wednesday, February 11, 2015 at 12:55:02 AM UTC+8, Jochen Bern wrote:
On 02/10/2015 06:15 AM, catherine.wei1...@gmail.com wrote:
However, when I wait for several minutes, the time can be adjusted to
the right time. I couldn't see the gradual changes of offset. Is that
normal?
Assuming
catherine.wei1...@gmail.com catherine.wei1...@gmail.com wrote:
Yes,I just tested it and found that the synchronization of NTP is really slow.
That is because ntpd is not designed to correct arbitrary errors that
you have applied externally. It is designed to lock to the correct time
and stay
Charles Swiger cswi...@mac.com wrote:
On Feb 11, 2015, at 7:23 AM, Rob nom...@example.com wrote:
But I see it has also been explained elsewhere in the thread: ntpd has
a maximum on the momentary drift of 500ppm, no matter if it is static
or dynamic or the sum of two. I think that is not
On 2015-02-12 03:00, Rob wrote:
catherine.wei1...@gmail.com catherine.wei1...@gmail.com wrote:
Yes,I just tested it and found that the synchronization of NTP is really slow.
That is because ntpd is not designed to correct arbitrary errors that
you have applied externally. It is designed to
On 2015-02-12, Charles Swiger cswi...@mac.com wrote:
On Feb 12, 2015, at 12:49 AM, William Unruh un...@invalid.ca wrote:
On 2015-02-11, Charles Swiger cswi...@mac.com mailto:cswi...@mac.com
wrote:
On Feb 11, 2015, at 7:23 AM, Rob nom...@example.com
mailto:nom...@example.com wrote:
But I
On Thu, Feb 12, 2015 at 12:00 PM, William Unruh un...@invalid.ca wrote:
This means that if you are using say a PPS source, which gives
microsecond long term offset, it can take many hours to get there
This has been asserted and corrected before -- as in years ago*. A
properly configured
William Unruh writes:
... And what happens to B when A suddenly begins to
slew at 2000PPM?
And how often does this happen? Why does it happen?
I'm pretty sure that ntpd will notice this and declare that source a
falseticker quickly enough.
Chrony and ntpd have fundamentally different
David Taylor david-tay...@blueyonder.co.uk.invalid wrote:
On 12/02/2015 17:00, William Unruh wrote:
[]
This means that if you are using say a PPS source, which gives
microsecond long term offset, it can take many hours to get there, even
if you or I looking at the offsets could see that it is
catherine.wei1...@gmail.com writes:
Yes,I just tested it and found that the synchronization of NTP is
really slow.
It's well documented. Adjustments are made at the rate of 500ppm. By
default that will happen for corrections of up to 128ms.
500ppm is about 43 seconds/day, and a correction of
On 2015-02-12, Charles Swiger cswi...@mac.com wrote:
On Feb 12, 2015, at 1:56 AM, Rob nom...@example.com wrote:
Charles Swiger cswi...@mac.com wrote:
On Feb 11, 2015, at 7:23 AM, Rob nom...@example.com wrote:
However, what I observe is that the plots of the offset show the derivative
of the
William Unruh wrote:
On 2015-02-12, Charles Swiger cswi...@mac.com wrote:
On Feb 12, 2015, at 1:56 AM, Rob nom...@example.com wrote:
Charles Swiger cswi...@mac.com wrote:
On Feb 11, 2015, at 7:23 AM, Rob nom...@example.com wrote:
However, what I observe is that the plots of the offset show
On 2015-02-12, Harlan Stenn st...@ntp.org wrote:
Bill,
So you believe:
- the broken linux kernel behavior is an acceptable (or at least
excusable) fact of life,
Of course not. However, it IS a fact of life, and I have to live in the
real world. nptd spends many lines of code correcting
On 2015-02-12, Harlan Stenn st...@ntp.org wrote:
William Unruh writes:
... And what happens to B when A suddenly begins to
slew at 2000PPM?
And how often does this happen? Why does it happen?
I'm pretty sure that ntpd will notice this and declare that source a
falseticker quickly enough.
On Feb 12, 2015, at 4:02 PM, William Unruh un...@invalid.ca wrote:
You're describing a TCXO; using a temperature sensor to compensate for
thermal
drift would gain perhaps a factor of 5 accuracy.
No, that is a hardware solution. There are software solutions-- a
termistor to meaure the
On 2015-02-12, Paul tik-...@bodosom.net wrote:
On Thu, Feb 12, 2015 at 12:00 PM, William Unruh un...@invalid.ca wrote:
This means that if you are using say a PPS source, which gives
microsecond long term offset, it can take many hours to get there
This has been asserted and corrected before
On 2015-02-13, Harlan Stenn st...@ntp.org wrote:
William Unruh writes:
On 2015-02-12, Harlan Stenn st...@ntp.org wrote:
It would have been far better for folks with those broken kernels to
have simply removed any drift file before starting ntpd. The code to
remove the drift file could have
William Unruh writes:
On 2015-02-12, Harlan Stenn st...@ntp.org wrote:
Bill,
So you believe:
- the broken linux kernel behavior is an acceptable (or at least
excusable) fact of life,
Of course not. However, it IS a fact of life, and I have to live in the
real world. nptd spends
On Thu, Feb 12, 2015 at 7:27 PM, William Unruh un...@invalid.ca wrote:
It was based on measurements I made with ntpd
Are you assuming the numbers I provided are based on theory or were you
looking over my shoulder when I perturbed system time by two milliseconds
and watched it converge to
William Unruh writes:
Chrony and ntpd have fundamentally different definitions of what it
means to provide good time.
Not really. But it should be distrubing that chrony disciplines clocks
much better ( lower jitter) than does ntpd in normal situations. Why?
And does that have lessons
On Thu, Feb 12, 2015 at 7:16 PM, William Unruh un...@invalid.ca wrote:
Not really. But it should be distrubing that chrony disciplines clocks
much better ( lower jitter) than does ntpd in normal situations. Why?
And does that have lessons that ntpd could learn from?
If you don't stop
Charles Swiger cswi...@mac.com wrote:
However, what I observe is that the plots of the offset show the derivative
of the environment temperature, which unfortunately cannot be controlled
any better. I am considering to locate the crystal that is responsible
for the timing and see if it could
William Unruh writes:
... (Ie something equivalent to ntpd's arbitrary 1000 sec rule-- ie if
the clock is out by 1000 sec ntpd gives up). But whether or not it
should give up, or try its best is something that should be left to
the user, not to some arbitrary rules by the designer.
Statement
Charles Swiger wrote:
On Feb 12, 2015, at 1:56 AM, Rob nom...@example.com wrote:
However, what I observe is that the plots of the offset show the derivative
of the environment temperature, which unfortunately cannot be controlled
any better. I am considering to locate the crystal that is
On 2015-02-13, Paul tik-...@bodosom.net wrote:
On Thu, Feb 12, 2015 at 7:27 PM, William Unruh un...@invalid.ca wrote:
It was based on measurements I made with ntpd
Are you assuming the numbers I provided are based on theory or were you
looking over my shoulder when I perturbed system time
On Thu, Feb 12, 2015 at 3:43 AM, William Unruh un...@invalid.ca wrote:
It is hard to complain about a non-existant product.
As has been previously mentioned ntimed(-client) is in early release. I've
been running it since late December.
___
questions
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
On 2015-02-12 03:00, Rob wrote:
catherine.wei1...@gmail.com catherine.wei1...@gmail.com wrote:
Yes,I just tested it and found that the synchronization of NTP is really
slow.
That is because ntpd is not designed to correct arbitrary errors
In article 54db57a8.4030...@oracle.com,
brian utterback brian.utterb...@oracle.com wrote:
Dr. Mills crafted a wonderful piece of software, amazing for its time,
but he no longer actively engages us much at all. I understand, that
isn't his fault. But no one who does actively engage really
On 2015-02-12, catherine.wei1...@gmail.com catherine.wei1...@gmail.com wrote:
On Wednesday, February 11, 2015 at 12:55:02 AM UTC+8, Jochen Bern wrote:
On 02/10/2015 06:15 AM, catherine.wei1...@gmail.com wrote:
However, when I wait for several minutes, the time can be adjusted to
the right
On 2015-02-12, Philip Homburg phi...@ue.aioy.eu wrote:
In article 54db57a8.4030...@oracle.com,
brian utterback brian.utterb...@oracle.com wrote:
Dr. Mills crafted a wonderful piece of software, amazing for its time,
but he no longer actively engages us much at all. I understand, that
isn't his
On 2015-02-12, Rob nom...@example.com wrote:
Charles Swiger cswi...@mac.com wrote:
On Feb 11, 2015, at 7:23 AM, Rob nom...@example.com wrote:
Yes I would prefer that, but chrony does not support local references
so it is useless to me.
Yes, it does and has for about 3 or 4 years now.
In
William Unruh un...@invalid.ca wrote:
On 2015-02-12, Rob nom...@example.com wrote:
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
On 2015-02-12 03:00, Rob wrote:
catherine.wei1...@gmail.com catherine.wei1...@gmail.com wrote:
Yes,I just tested it and found that the synchronization of NTP
On 2015-02-11, Jochen Bern jochen.b...@linworks.de wrote:
On 02/11/2015 10:01 AM, Rob wrote:
Terje Mathisen terje.mathi...@tmsw.no wrote:
The 500 ppm limit is not at all arbitrary!
In fact, it was originally just 100 ppm, but when too many systems
turned up with a system clock which was a
On 2015-02-11, Harlan Stenn st...@ntp.org wrote:
William Unruh writes:
On 2015-02-11, Harlan Stenn st...@ntp.org wrote:
It's one thing if a system rarely steps. It's a bit different if those
steps happen more frequently.
Yes. And it is either equally rare that the system will go over
On 2015-02-11, Terje Mathisen terje.mathi...@tmsw.no wrote:
William Unruh wrote:
On 2015-02-11, Harlan Stenn st...@ntp.org wrote:
William Unruh writes:
On 2015-02-10, Terje Mathisen terje.mathi...@tmsw.no wrote:
And as far as I can see, 500 or 5000 makes little
difference to the control
Jochen Bern jochen.b...@linworks.de wrote:
However, I've also seen hardware occasionally flip-flopping from -900 to
+1100 and back, complete with the developers of the firmware blaming a
bug in ntpd for failure to discipline *that*.
Ok that is different, it is not a static drift.
But I see it
On 02/11/2015 10:01 AM, Rob wrote:
Terje Mathisen terje.mathi...@tmsw.no wrote:
The 500 ppm limit is not at all arbitrary!
In fact, it was originally just 100 ppm, but when too many systems
turned up with a system clock which was a bit too far out, Prof Mills
redid the control loop to
Paul writes:
On Wed, Feb 11, 2015 at 8:22 AM, brian utterback brian.utterb...@oracle.com
wrote:
But no one who does actively engage really understands
it or knows how to improve it. Unruh has a point, we don't know if there
isn't a better way built on statistical analysis.
Since it
Paul writes:
On Wed, Feb 11, 2015 at 4:32 PM, Harlan Stenn st...@ntp.org wrote:
There are times repair is perfectly acceptable, and we do that.
There are times replace is better, and we do that.
My point is a long drawn-out discussion of changes to the core of ntp seem
less than
On Feb 11, 2015, at 7:23 AM, Rob nom...@example.com wrote:
But I see it has also been explained elsewhere in the thread: ntpd has
a maximum on the momentary drift of 500ppm, no matter if it is static
or dynamic or the sum of two. I think that is not warranted.
Do you believe that a clock
On Wed, Feb 11, 2015 at 4:32 PM, Harlan Stenn st...@ntp.org wrote:
There are times repair is perfectly acceptable, and we do that.
There are times replace is better, and we do that.
My point is a long drawn-out discussion of changes to the core of ntp seem
less than productive when the
William Unruh writes:
On 2015-02-11, Harlan Stenn st...@ntp.org wrote:
It's one thing if a system rarely steps. It's a bit different if those
steps happen more frequently.
Yes. And it is either equally rare that the system will go over 500PPM,
but sometimes a computer can have a large
Terje Mathisen terje.mathi...@tmsw.no wrote:
The 500 ppm limit is not at all arbitrary!
In fact, it was originally just 100 ppm, but when too many systems
turned up with a system clock which was a bit too far out, Prof Mills
redid the control loop to allow a 500 ppm range.
It could have
On 2015-02-11, Harlan Stenn st...@ntp.org wrote:
William Unruh writes:
On 2015-02-10, Terje Mathisen terje.mathi...@tmsw.no wrote:
William Unruh wrote:
No. It only does that for offsets from Hades. The Ones from Hell, ntpd
abandons all hope and quits. ( Hades is 128ms to 1000 sec, Hell is
On 2/11/2015 2:12 AM, Harlan Stenn wrote:
William Unruh writes:
On 2015-02-10, Terje Mathisen terje.mathi...@tmsw.no wrote:
William Unruh wrote:
No. It only does that for offsets from Hades. The Ones from Hell,
ntpd
abandons all hope and quits. ( Hades is 128ms to 1000 sec, Hell
William Unruh wrote:
On 2015-02-11, Harlan Stenn st...@ntp.org wrote:
William Unruh writes:
On 2015-02-10, Terje Mathisen terje.mathi...@tmsw.no wrote:
And as far as I can see, 500 or 5000 makes little
difference to the control loop. Yes, it is harder for other systems to
follow one with a
On Wed, Feb 11, 2015 at 8:22 AM, brian utterback brian.utterb...@oracle.com
wrote:
But no one who does actively engage really understands
it or knows how to improve it. Unruh has a point, we don't know if there
isn't a better way built on statistical analysis.
Since it seems the NTF
On 02/10/2015 06:15 AM, catherine.wei1...@gmail.com wrote:
However, when I wait for several minutes, the time can be adjusted to
the right time. I couldn't see the gradual changes of offset. Is that
normal?
Assuming that you're using a minimalistic configuration: Yes.
ntpd would take almost
catherine.wei1...@gmail.com catherine.wei1...@gmail.com wrote:
Hi, I'm using the ntpd to sync time. When I change the current date for
exampe to 0210020215 (2015-02-10 02:02), the actually current time is
2015-02-10 03:02, then I run ntpq -p for several times, the offset doesn't
change at
On 10/02/15 05:15, catherine.wei1...@gmail.com wrote:
Hi, I'm using the ntpd to sync time. When I change the current date for exampe to
0210020215 (2015-02-10 02:02), the actually current time is 2015-02-10 03:02, then I run
ntpq -p for several times, the offset doesn't change at all.
On 2015-02-10 13:26, William Unruh wrote:
However if this is the first time this running of ntpd has encountered
this, eg at startup, if you use -x option it will jump the time even if the
-g (panicGate)
offset is 1000 sec.
--
Take care. Thanks, Brian Inglis
William Unruh wrote:
On 2015-02-10, Jochen Bern jochen.b...@linworks.de wrote:
On 02/10/2015 06:15 AM, catherine.wei1...@gmail.com wrote:
However, when I wait for several minutes, the time can be adjusted to
the right time. I couldn't see the gradual changes of offset. Is that
normal?
On 2015-02-10, Jochen Bern jochen.b...@linworks.de wrote:
On 02/10/2015 06:15 AM, catherine.wei1...@gmail.com wrote:
However, when I wait for several minutes, the time can be adjusted to
the right time. I couldn't see the gradual changes of offset. Is that
normal?
Assuming that you're using
William Unruh writes:
On 2015-02-10, Terje Mathisen terje.mathi...@tmsw.no wrote:
William Unruh wrote:
No. It only does that for offsets from Hades. The Ones from Hell, ntpd
abandons all hope and quits. ( Hades is 128ms to 1000 sec, Hell is
1000 sec)
Ie, for 128ms, ntp will try to
On 2015-02-10, Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
On 2015-02-10 13:26, William Unruh wrote:
However if this is the first time this running of ntpd has encountered
this, eg at startup, if you use -x option it will jump the time even if the
-g
On 2015-02-10, Terje Mathisen terje.mathi...@tmsw.no wrote:
William Unruh wrote:
On 2015-02-10, Jochen Bern jochen.b...@linworks.de wrote:
On 02/10/2015 06:15 AM, catherine.wei1...@gmail.com wrote:
However, when I wait for several minutes, the time can be adjusted to
the right time. I
By the way, the ntp version I'm using is 4.2.8p1.
Catherine.
On Tuesday, February 10, 2015 at 1:15:21 PM UTC+8, catherin...@gmail.com wrote:
Hi, I'm using the ntpd to sync time. When I change the current date for
exampe to 0210020215 (2015-02-10 02:02), the actually current time is
Hi, I'm using the ntpd to sync time. When I change the current date for exampe
to 0210020215 (2015-02-10 02:02), the actually current time is 2015-02-10
03:02, then I run ntpq -p for several times, the offset doesn't change at all.
~ # ntpq -p
remote refid st t when poll
91 matches
Mail list logo
