On 23/08/13 14:27, Martin Burnicki wrote:
Windows machine, and watch how the reported offset (which is in
milliseconds) decreases until it reaches and then stays at some minimum.
There should be no minimum. It should end up varying randomly around zero.
On Friday, August 23, 2013 10:55:06 AM UTC-5, David Woolley wrote:
Unless ntpd is failing to converge to an average offset of zero
It's converging to an average time offset of zero, but an average frequency
offset of +2.5PPM.
(accounting for signs), the question is of marginal academic
On Friday, August 23, 2013 12:09:03 PM UTC-5, unruh wrote:
Your measurement procedure is HIGHLY suspect.
Ok, perhaps. Could you suggest a better measurement procedure?
BR,
James
___
questions mailing list
questions@lists.ntp.org
On 8/24/2013 9:46 AM, james.perou...@gmail.com wrote:
So, are you saying that the PPM value returned by NTP is to be
ignored, is purely for information purposes, and is not to be
interpreted as having any real-world meaning? istinfo/questions
Yes and no. The value displayed is the adjustment
On 24/08/13 14:46, james.perou...@gmail.com wrote:
So, are you saying that the PPM value returned by NTP is to be ignored, is
purely for information purposes, and is not to be interpreted as having any
real-world meaning?
It can be ignored, as long as it is fairly stable and not too close
On 2013-08-24, james.perou...@gmail.com james.perou...@gmail.com wrote:
On Friday, August 23, 2013 10:55:06 AM UTC-5, David Woolley wrote:
Unless ntpd is failing to converge to an average offset of zero
It's converging to an average time offset of zero, but an average frequency
offset of
On 2013-08-24, james.perou...@gmail.com james.perou...@gmail.com wrote:
On Friday, August 23, 2013 12:09:03 PM UTC-5, unruh wrote:
Your measurement procedure is HIGHLY suspect.
Ok, perhaps. Could you suggest a better measurement procedure?
You have not told us what yours was.
On 23/08/2013 15:08, Martin Burnicki wrote:
[]
Indeed. I've just enabled the SHM refclock in the config.h file for
Windows, tried to build it with VS2008, and found that it builds after I
had fixed a tiny bug, a missing semicolon.
However, I have also no idea if it works.
David, if you want to
I think it means FYLWHEEL. ie the device has lost its GPS signal. Bad antenna?,
Rollover hit???
Le 23 août 2013 à 17:48, Michael Dolan a écrit :
172.17.172.74
___
questions mailing list
questions@lists.ntp.org
I should maybe add a little.
The reason you are seeing an unstable offset will be that as the server has
lost access to its GPS receiver, it is now serving time using just its now
unlocked oscillator, which, if you can see the offset changing, is certainly
quartz. If it was rb, it would be a
Michael Dolan dolanm...@gmail.com wrote:
Long time reader first time writer…
I've exhausted my search for refid .FLY. and its meaning.
Our stratum 2 client reported Stratum 1 172.17.172.74 appliance (Symmetricon
S200) initialized with .GPS. but after ~ 24 hours the refid switched to .FLY.
On 2013-08-23, Michael Dolan dolanm...@gmail.com wrote:
I've exhausted my search for refid .FLY. and its meaning.
Our stratum 2 client reported Stratum 1 172.17.172.74 appliance
(Symmetricon S200) initialized with .GPS. but after ~ 24 hours the
refid switched to .FLY. and the offset has been
David Woolley wrote:
On 23/08/13 14:27, Martin Burnicki wrote:
Windows machine, and watch how the reported offset (which is in
milliseconds) decreases until it reaches and then stays at some minimum.
There should be no minimum. It should end up varying randomly around zero.
Agreed. But
David Taylor wrote:
On 23/08/2013 15:08, Martin Burnicki wrote:
[]
Indeed. I've just enabled the SHM refclock in the config.h file for
Windows, tried to build it with VS2008, and found that it builds after I
had fixed a tiny bug, a missing semicolon.
However, I have also no idea if it works.
14 matches
Mail list logo
