Re: [ntp:questions] Reference clock driver for /dev/rtc

Kalle, Calling settimeofday() is completely transparent to the kernel and ntpd state variables, including the UNSYNC bit; however, the actions in Linux might violate this design. Setting the RTC is a byproduct of settimeofday(), but in general setting the time to the current time is a no-op,

Re: [ntp:questions] Reference clock driver for /dev/rtc

unruh wrote: > The VM is liable to have large and violent > timing swings, sometimes loosing may ticks ( and probably regularly > exceeding the 500PPM that ntp handles) with the VM clock > rate with respect to real time fluctuating wildly. That is NOT a > situation ntp is designed to handle. Over

Re: [ntp:questions] Reference clock driver for /dev/rtc

On 2010-06-26, Rob wrote: > unruh wrote: >> On 2010-06-26, David Woolley wrote: >>> unruh wrote: Linux, depending on the setting of a flag in the adjtimex setup, sets the rtc from the system time once every 11 min. . This is a disaster if >>> >>> I think you missed Dave Mills' p

Re: [ntp:questions] Reference clock driver for /dev/rtc

Bill, Another case in which the engineering model in Linux and NTP are not compatible. Neither is necessarily wrong, just different. The following issues are known to me. 1. The Linux kernel discipline code adapted from my Alpha code of the 1990s does not account for the frequency gain at ot

Re: [ntp:questions] Reference clock driver for /dev/rtc

unruh wrote: > On 2010-06-26, David Woolley wrote: >> unruh wrote: >>> >>> Linux, depending on the setting of a flag in the adjtimex setup, sets >>> the rtc from the system time once every 11 min. . This is a disaster if >> >> I think you missed Dave Mills' point that ntpd does this every 60 >

Re: [ntp:questions] Reference clock driver for /dev/rtc

On 2010-06-26, David Woolley wrote: > unruh wrote: >> >> Linux, depending on the setting of a flag in the adjtimex setup, sets >> the rtc from the system time once every 11 min. . This is a disaster if > > I think you missed Dave Mills' point that ntpd does this every 60 > minutes, so will also

Re: [ntp:questions] Reference clock driver for /dev/rtc

On Sat, Jun 26, 2010 at 11:48, David Woolley wrote: > I think you missed Dave Mills' point that ntpd does this every 60 minutes, > so will also break mechanisms for compensating for RTC drift whilst the > processor is powered down. I don't understand. Settimeofday() isn't about updating the RTC

Re: [ntp:questions] Fwd: [ntpwg] RFC 5905 on Network Time Protocol Version 4: Protocol and Algorithms Specification

E-Mail Sent to this address will be added to the BlackLists wrote: unruh wrote: If in the future, MTC is defined (Mars Time Coordinate) ntp will work equally well there without UTC. Nor should a new RFC be needed simply to have ntp defined with MTC. I could see some issues if e.g. the length o

Re: [ntp:questions] Reference clock driver for /dev/rtc

unruh wrote: Linux, depending on the setting of a flag in the adjtimex setup, sets the rtc from the system time once every 11 min. . This is a disaster if I think you missed Dave Mills' point that ntpd does this every 60 minutes, so will also break mechanisms for compensating for RTC drift

Re: [ntp:questions] Fwd: [ntpwg] RFC 5905 on Network Time Protocol Version 4: Protocol and Algorithms Specification

unruh wrote: > If in the future, MTC is defined (Mars Time Coordinate) ntp will > work equally well there without UTC. Nor should a new RFC be needed > simply to have ntp defined with MTC. I could see some issues if e.g. the length of years, days, were different?

Re: [ntp:questions] Reference clock driver for /dev/rtc

On 2010-06-23, David L. Mills wrote: > Pavel, > > Linux has many, many times broken the NTP model compatible with other > systems such as Solaris and FreeBSD, among others. I have no trouble > with that as long as whatever modifications are required in NTP to make > the RTC driver work remain p

Re: [ntp:questions] Fwd: [ntpwg] RFC 5905 on Network Time Protocol Version 4: Protocol and Algorithms Specification

On 2010-06-25, Richard B. Gilbert wrote: > pc wrote: >> At risk of stirring up a hornets' nest: >> >> The RFC unequivocally states that "A primary server is >> synchronized to a reference clock directly traceable to >> UTC." >> >> IMO, that is not a necessary condition. If I have a >> hierarchy