Re: [chrony-dev] Chrony freezing |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
On Fri, Nov 13, 2009 at 08:19:27AM -0800, Bill Unruh wrote:
> On Fri, 13 Nov 2009, Miroslav Lichvar wrote:
> >Where do you propose we should add it? If it is right before the
> >second read, it will solve the problem with blocking forever, but
> >chronyd will still be unresponsive for the second which I'm worried
> >about more as it degrades NTP performance.
>
> This is only used for reading the rtc and for determining the rate and offset
> of the rtc. Ie, it does not impact ntp performance, except insofar as it make
> characterising rtc more difficult.
I meant performance for NTP clients, if the request hits chrony just
when it's in the blocking read, the reply will be extremely
asymmetric. This might be mitigated by the SO_TIMESTAMP support we've
recently added.
> But most systems ignore chrony's rtc
> anyway, and start the system using hwclock to set the system time from the
> rtc. And the newer hwclock's also have an ability to roughly determine the
> rate of the rtc and offset and correct for those. Ie, the rtc performance of
> chrony is to some extent becoming superfluous.
Yeah, that's why I don't use the feature, I'd have to hack the system
scripts. And most of my machines run 24/7 anyway.
> >What about making always two readings, i.e. don't disable the interrupt
> >after first one, wait for the interrupt again and use that? (see the patch)
>
> Precisely what it does now. And that freezes the system sometimes.
> It only needs to do this in "normal" operation.
Ok, please try the patch. It should never freeze in the read, it will
just stop tracking rtc if it stops generating the interrupts.
Does the early interrupt happen always? If yes we could use a
heuristic, if the first interrupt is repeatedly 1 second +- 10% from
the second one, we can turn the hack off.
--
Miroslav Lichvar
---
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.