Rob Weir [EMAIL PROTECTED] [2002-12-25 04:20:20 +1100]:
Chrony is designed to work with intermittent connections.
ntpd works well with intermittent connections too.
No idea...chrony is a lot smarter than ntpdate though; it gradually
moves your clock back and forth so that running apps don't
Bill Moseley writes:
I don't really understand how chrony maintains the hardware clock. I
know chrony can deal with a slow or fast rtc, but it seems like a good
idea to update the rtc to the real time every once in a while.
I agree. File a wishlist bug so I don't forget and I'll send it
On Tue, Dec 24, 2002 at 06:36:22AM -0800, Bill Moseley wrote:
Any idea why it conflicts with ntpdate? Installing it remvoed ntpdate.
ntp didn't conflict with ntpdate.
Because chrony is a ntpdate replacement as well. ntpdate, thus,
conflicts with chrony.
--
.''`. Baloo [EMAIL PROTECTED]
On Sun, Dec 22, 2002 at 06:46:50PM -0600, Adam Majer wrote:
On Sun, Dec 22, 2002 at 10:32:43AM -0800, Bill Moseley wrote:
On Sun, 22 Dec 2002, Shawn Lamson wrote:
Maybe it's because the CD-R is so fast? Let's do the time warp again!
This is why I installed rdate, I think it is b/c
On Tue, 24 Dec 2002, Rob Weir wrote:
I'd say this is the sort of thing people mean when people say 'IDE
sucks!'; the CPU has to babysit the burner through the entire process...
It's hard for me to believe that can be the only problem. The clock falls
behind almost a minute during a 4 minute
Bill Moseley writes:
I just don't think it unreasonable that there could be periods of time
when ntp can't connect to the remote hosts -- and that should not stop
ntp.
Chrony is designed to work with intermittent connections.
--
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
On 24 Dec 2002, John Hasler wrote:
Bill Moseley writes:
I just don't think it unreasonable that there could be periods of time
when ntp can't connect to the remote hosts -- and that should not stop
ntp.
Chrony is designed to work with intermittent connections.
Any idea why it conflicts
On Tue, 24 Dec 2002 13:19:35 +1100
Rob Weir [EMAIL PROTECTED] wrote:
I'd say this is the sort of thing people mean when people say 'IDE
sucks!'; the CPU has to babysit the burner through the entire process...
It's actually probably even more subtle. My experience has been that
cdrdao causes
On Tue, Dec 24, 2002 at 06:36:22AM -0800, Bill Moseley wrote:
On 24 Dec 2002, John Hasler wrote:
Bill Moseley writes:
I just don't think it unreasonable that there could be periods of time
when ntp can't connect to the remote hosts -- and that should not stop
ntp.
Chrony is
On Wed, 25 Dec 2002, Rob Weir wrote:
On Tue, Dec 24, 2002 at 06:36:22AM -0800, Bill Moseley wrote:
On 24 Dec 2002, John Hasler wrote:
Bill Moseley writes:
I just don't think it unreasonable that there could be periods of time
when ntp can't connect to the remote hosts -- and that
On Tue, Dec 24, 2002 at 09:44:23AM -0800, Bill Moseley wrote:
On Wed, 25 Dec 2002, Rob Weir wrote:
On Tue, Dec 24, 2002 at 06:36:22AM -0800, Bill Moseley wrote:
On 24 Dec 2002, John Hasler wrote:
Bill Moseley writes:
I just don't think it unreasonable that there could be
On Tue, 24 Dec 2002, Bob Nielsen wrote:
On Tue, Dec 24, 2002 at 09:44:23AM -0800, Bill Moseley wrote:
On Wed, 25 Dec 2002, Rob Weir wrote:
On Tue, Dec 24, 2002 at 06:36:22AM -0800, Bill Moseley wrote:
On 24 Dec 2002, John Hasler wrote:
Bill Moseley writes:
I just
Bill Moseley writes:
Any idea why [Chrony] conflicts with ntpdate?
I didn't think it was a good idea to have two programs yanking on the
system clock at the same time. As far as I know chronyc lets you do
everything that ntpdate does.
--
John Hasler
[EMAIL PROTECTED]
Dancing Horse Hill
On Sat, 21 Dec 2002 22:46:34 -0800 (PST)
Bill Moseley [EMAIL PROTECTED] wrote:
I had somene run:
date; burn-cd.sh; date
and burning the CD using cdrdao (48x drive -- about 4 minutes to burn a
CD) caused the system clock to fall behind about *50* seconds.
Maybe it's because the CD-R
On Sun, 22 Dec 2002, Shawn Lamson wrote:
date; burn-cd.sh; date
and burning the CD using cdrdao (48x drive -- about 4 minutes to burn a
CD) caused the system clock to fall behind about *50* seconds.
Maybe it's because the CD-R is so fast? Let's do the time warp again!
This is
On Sun, Dec 22, 2002 at 10:32:43AM -0800, Bill Moseley wrote:
On Sun, 22 Dec 2002, Shawn Lamson wrote:
date; burn-cd.sh; date
and burning the CD using cdrdao (48x drive -- about 4 minutes to burn a
CD) caused the system clock to fall behind about *50* seconds.
Maybe it's
I had somene run:
date; burn-cd.sh; date
and burning the CD using cdrdao (48x drive -- about 4 minutes to burn a
CD) caused the system clock to fall behind about *50* seconds.
Maybe it's because the CD-R is so fast? Let's do the time warp again!
They are running testing with 2.4.18 and xfs
17 matches
Mail list logo
