Unruh wrote:
> "Richard B. Gilbert" writes:
>
>> Unruh wrote:
>>> Steve Kostecke writes:
>>>
On 2009-03-12, Unruh wrote:
> Ie, IF you do not want to have jumps even on bootup, want fast convergence
> to the good time,
In your haste to proselytize for chrony you've overlooked t
"Richard B. Gilbert" writes:
>Unruh wrote:
>> Steve Kostecke writes:
>>
>>> On 2009-03-12, Unruh wrote:
>>
Ie, IF you do not want to have jumps even on bootup, want fast convergence
to the good time,
>>
>>> In your haste to proselytize for chrony you've overlooked the fact the
>>>
Unruh wrote:
> Steve Kostecke writes:
>
>> On 2009-03-12, Unruh wrote:
>
>>> Ie, IF you do not want to have jumps even on bootup, want fast convergence
>>> to the good time,
>
>> In your haste to proselytize for chrony you've overlooked the fact the
>> the OP did not specify that he needs fast
>
> My plan is to read GPS messages in my own application and use them to
> discipline a simulated software clock with Windows high performance
> counter. This way I can avoid Windows scheduling issues.
Seems to me that you want to implement your application in-process with
ntpd or equivalent.
>
Matthias Fuchs wrote:
>
> I am trying to understand ntpd's -x option. From the ntpd documentation
> I expect ntpd to adjust the (system-)time in all situations when -x
> is used. The only exception I see is when the system time is totally wrong
That' not what happens. It will still step if the e
Dave Hart wrote:
[]
>> The only table I can find on the official site is:
>>
>> http://www.cis.udel.edu/~mills/ntp/html/decode.html
>>
>> where the description is: "discarded as not valid (TEST10-TEST13)"
>
> Does it also have a more detailed description of TEST12?
Yes: "peer synchronization loop
David J Taylor wrote:
> i.e. server B and C have a space rather than any other character. Those
> servers are fine, but they are both actually syncing from server A.
> Space appears to be defined as:
>
> "The peer is discarded as unreachable, synchronized to this server (synch
> loop) or outr
Dave Hart wrote:
> On Mar 11, 6:28 pm, "David J Taylor" this-bit.nor-this.co.uk> wrote:
>> Folks,
>>
>> I'm seeing an ntpq -p display like:
>>
>> * server-A 377
>> server-B 377
>> server-C 377
>>
>> i.e. server B and C have a space rather than any other character.
>> Those servers are fine, but th
Tom wrote:
> To All,
>
> How do you demonstrate the traceability of the NTP solution to BIPM
> UTC?
>
> Tom R
Most of us do not trace anything to BIPM (Bureau International des Poids
et Mesures). Those of us who live and work in the U.S.A. would usually
be satisfied to trace their time to NIS
Steve Kostecke writes:
>On 2009-03-12, Unruh wrote:
>> Ie, IF you do not want to have jumps even on bootup, want fast convergence
>> to the good time,
>In your haste to proselytize for chrony you've overlooked the fact the
>the OP did not specify that he needs fast convergence.
>In fact, in a
Dave Hart wrote:
> On Mar 12, 8:12 pm, "David J Taylor" this-bit.nor-this.co.uk> wrote:
>> Dave Hart wrote:
>>> It looks like you've found a documentation omission.
>>
>> Thanks, Dave. As you have the code to hand, could you report it as a
>> bug?
>
> Sure. Where did you find the slightly inadequ
On Mar 12, 8:28 pm, "David J Taylor" wrote:
> Dave Hart wrote:
> > On Mar 12, 8:12 pm, "David J Taylor" > this-bit.nor-this.co.uk> wrote:
> >> Dave Hart wrote:
> >>> It looks like you've found a documentation omission.
>
> >> Thanks, Dave. As you have the code to hand, could you report it as a
>
On 2009-03-12, David J Taylor wrote:
> Search Google with the exact phrase: "The peer is discarded as
> unreachable, synchronized to this server (synch loop) or outrageous
> synchronization distance." and you get three pages of hits. These
> appear to refer to the man page for ntpq(8) which I don
On Mar 12, 8:12 pm, "David J Taylor" wrote:
> Dave Hart wrote:
> > It looks like you've found a documentation omission.
>
> Thanks, Dave. As you have the code to hand, could you report it as a bug?
Sure. Where did you find the slightly inadequate description of space
in the first character of t
On 2009-03-12, Unruh wrote:
> Ie, IF you do not want to have jumps even on bootup, want fast convergence
> to the good time,
In your haste to proselytize for chrony you've overlooked the fact the
the OP did not specify that he needs fast convergence.
In fact, in a discussion on IRC he told me t
On Mar 11, 6:28 pm, "David J Taylor" wrote:
> Folks,
>
> I'm seeing an ntpq -p display like:
>
> * server-A 377
> server-B 377
> server-C 377
>
> i.e. server B and C have a space rather than any other character. Those
> servers are fine, but they are both actually syncing from server A.
On Thu, Mar 12, 2009 at 11:06 AM, Tom wrote:
> To All,
>
> How do you demonstrate the traceability of the NTP solution to BIPM
> UTC?
>
For "hard" tracability, you really need your own reference clock
(typically GPS) that you control, along with several internet based
sources as a sanity check ag
Tom writes:
>To All,
>How do you demonstrate the traceability of the NTP solution to BIPM
>UTC?
That is what the stratum is all about. It tells you how far away your clock
is, in terms of servers, from some server which claims to synchronized by a
hardware type clock to UTC. The root dispersion
Matthias Fuchs wrote:
> Hi,
>
> I am experiencing strange issues with the PARSE refclock in mode 5.
> I have a simple DCF77 recevier connected to a serial port.
> In general the refclock works with this setup and ntp syncs.
> Since this simple DCF77 receiver is not very reliable the refclock
> som
Tom wrote:
> To All,
>
> How do you demonstrate the traceability of the NTP solution to BIPM
> UTC?
>
> Tom R
You can use ntptrace to get to the stratum 1 server if that's what you
are asking. The stratum 1 server gets its time in various ways from a
refclock depending on what that server is con
Matthias Fuchs writes:
>Unruh wrote:
>> Matthias Fuchs writes:
>>
>>>Hi,
>>
>>>I am trying to understand ntpd's -x option. From the ntpd documentation
>>>I expect ntpd to adjust the (system-)time in all situations when -x
>>>is used. The only exception I see is when the system time is totally
Hi,
I am experiencing strange issues with the PARSE refclock in mode 5.
I have a simple DCF77 recevier connected to a serial port.
In general the refclock works with this setup and ntp syncs.
Since this simple DCF77 receiver is not very reliable the refclock
sometimes receives a wrong date/time. T
To All,
How do you demonstrate the traceability of the NTP solution to BIPM
UTC?
Tom R
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Unruh wrote:
> Matthias Fuchs writes:
>
>>Hi,
>
>>I am trying to understand ntpd's -x option. From the ntpd documentation
>>I expect ntpd to adjust the (system-)time in all situations when -x
>>is used. The only exception I see is when the system time is totally wrong
>>(more than 1000s) ntpd w
Uwe Klein wrote:
> Kevin Oberman wrote:
>> To get an idea of the fanaticism involved, several years ago, Kirk
>> McKusick and my former boss here in Berkeley counted the machine cycles
>> in the FreeBSD kernel for the PPS response(all done in the interrupt
>> service routine) and used that to corre
Kevin Oberman wrote:
> To get an idea of the fanaticism involved, several years ago, Kirk
> McKusick and my former boss here in Berkeley counted the machine cycles
> in the FreeBSD kernel for the PPS response(all done in the interrupt
> service routine) and used that to correct the time. Of course,
Martin Burnicki wrote:
> David J Taylor wrote:
>> David J Taylor wrote:
>> []
>>> On the Intel 6600 dual-core, 2.4GHz processor here, under XP, a
>>> RDTSC takes about 4.2ns, and a OS call to timeGetTime takes about
>>> 11.8ns. At least, they do if my measurement program is working
>>> correctly...
"David J Taylor"
wrote in message news:cpttl.5723$lc7.1...@text.news.virginmedia.com...
> Folks,
>
> I'm seeing an ntpq -p display like:
>
> * server-A 377
>server-B 377
>server-C 377
>
> i.e. server B and C have a space rather than any other character.
> Those servers are fine, but t
Augustine wrote:
> On Mar 11, 4:19 am, Terje Mathisen <"terje.mathisen at tmsw.no">
> wrote:
>>
>> I do know that Intel intends to make processor-based timers more useful
>> by setting up a counter which always runs at a fixed rate, independent
>> of any frequency power stepping. On such a cpu RDTS
Dave Hart wrote:
> On Mar 11, 8:55 am, Martin Burnicki
> wrote:
>>
>> Dave Hart wrote:
>> > I have released a new test version of 4.2.4p6 with numerous Windows-
>> > specific improvements compared to the baseline 4.2.4p6. Since my last
>> > release, the most significant change is to read the proc
David J Taylor wrote:
> David J Taylor wrote:
> []
>> On the Intel 6600 dual-core, 2.4GHz processor here, under XP, a RDTSC
>> takes about 4.2ns, and a OS call to timeGetTime takes about 11.8ns.
>> At least, they do if my measurement program is working correctly
>>
>> Haven't checked QPC.
>>
Richard B. Gilbert wrote:
> David J Taylor wrote:
>> Richard B. Gilbert wrote:
>>> David J Taylor wrote:
David Woolley wrote:
[]
> You won't get millisecond accuracy on Windows. Although the
> software clock can be disciplined to better than a millisecond,
> applications can
32 matches
Mail list logo
