Tualha Khan wrote:
Now, the problem part. Under my test conditions, i have both servers
configured as follows:
I feel you are well out of your depth with this complexity of timing
topology.
#crypto pw abc123
#keysdir D:\Program Files (x86)\NTP\etc\keys
server
Hello Serge,
You're right! I missed the -b option in ntpdate.
That's very doable, but requires some amounts of efforts. ;-)
I understand that.
The system is a transportable system. It is used to mesure some
transmission time over a network (packets contain utc timestamp
themselves). It can
Thierry MARTIN wrote:
Hello Serge,
You're right! I missed the -b option in ntpdate.
That's very doable, but requires some amounts of efforts. ;-)
I understand that.
The system is a transportable system. It is used to mesure some
transmission time over a network (packets contain utc
Hi Martin,
It seems that once again, you're about to save me ;-) !
So, ok my system has a Meinberg gps170pci board.
As far as I can remember, when GPS signal is not there, NTP does not use
GPS refclock as a timesource.
So i guess, you suggest that I use the DCF77 emulation or some other
Unruh wrote:
There seems to be a conflict between ntp 3 and ntp 4 in the handling of the
polling interval if the server does not respond. In the rfc for ntp 3 it
says that the polling interval decreases if the server does not respond,
while ntp 4 rfc states
A client SHOULD increase the
David Woolley wrote:
4p4's ntpd/ntp_loopfilter.c:
/*
* Set the leap bits in the status word, but
* only on the last day of June or December.
*/
tstamp =
Danny Mayer wrote:
}
That comment is wrong. IIRC it can nominally be set at the last day of
The comment matches the code, which should be the most recent released
version. Someone has already said that it is a known bug, and I think
they said it is fixed in the
Danny,
That snapshot is older than I thought. That particular botch of code
along with other botches was vulnerable to whimsical errors, like server
leap bits popping up and down or leapsecond file update. The current
code here can leap at the end of any month, which seems to be the
Hi,
I have had issues keeping accurate time on W32tm using an Active
Directory based network with just Windows servers. I have a Linux
workstation, and NTP on that workstation keeps loosing the time, and
going to Stratum 16. Similarly, there are Cisco routers on the
network, which also
[EMAIL PROTECTED] (Danny Mayer) writes:
Unruh wrote:
David J Taylor [EMAIL PROTECTED] writes:
Unruh wrote:
Note that leap seconds have been happening so rarely that almost noone has
seen one happen, or watched the system as the clock goes through that.
I guess you weren't around in
Greg Hennessy [EMAIL PROTECTED] writes:
On 2008-02-20, Unruh [EMAIL PROTECTED] wrote:
No orbital dynamics obeys Newton's ( or Einstein's) law of gravitation only
in TAI not in UTC ot UT1.
High precision orbital dynamics, such as the JPL's DE405, are done in
Barycentric Dynamic Time, which
David Woolley [EMAIL PROTECTED] writes:
You are asking for the impossible! Leap seconds keep time in synch with
That was the intention. I was pointing out that you can only use true
time to represent historic civil times, you cannot calculate the true
time of a future civil time beyond
Andrew Hodgson wrote:
Hi,
I have had issues keeping accurate time on W32tm using an Active
Directory based network with just Windows servers. I have a Linux
workstation, and NTP on that workstation keeps loosing the time, and
going to Stratum 16. Similarly, there are Cisco routers
Danny Mayer wrote:
[]
Yes. w32time needs to be disabled, you cannot run both. The Meinberg
installer does this for you and if you choose to uninstall NTP I
believe it will reenable it.
[]
Danny
FYI, that's at:
http://www.meinberg.de/english/sw/ntp.htm
Cheers,
David
14 matches
Mail list logo
