Bug 1260928 - RFE:- Request to have slew mode "-x" enabled by default in ntp instead of step mode.
RFE:- Request to have slew mode "-x" enabled by default in ntp instead of st...
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ntp (Show other bugs)
All Linux
medium Severity medium
: rc
: ---
Assigned To: Miroslav Lichvar
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2015-09-08 04:58 EDT by Rupesh Patel
Modified: 2015-12-15 11:00 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Cause: Consequence: Fix: Result:
Story Points: ---
Clone Of:
Last Closed: 2015-10-15 04:11:54 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Rupesh Patel 2015-09-08 04:58:57 EDT
Would it be acceptable to have slew mode enabled by default?
Comment 3 Miroslav Lichvar 2015-09-08 05:35:54 EDT
The -x option is useful to keep the clock monotonic, but the clock is inaccurate for very long time when the offset is large. That's not acceptable for default configuration. Also, it disables the kernel discipline, which usually makes the quality of the timekeeping worse.
Comment 4 Ash 2015-09-08 18:57:00 EDT
Actually the request is as per Red Hat case 01492484.

Summary Text (TL;DR)
Any method of adjusting time that relies on time stepping backwards is the worst method. Pick some other method. As long as it does not involve time stepping backwards (which is absolutely ridiculous).

Full Text: 

Request feature enhancement by Red Hat to ensure 'slew mode' of NTP clients is the default and *always* the default (e.g. during leap seconds). I know it is configurable, but what proportion of customers would ever, ever want 'step' mode during leap seconds?

Whoever decided that the correct approach to handling leap seconds should involve time 'stepping backwards' must live in a universe where transactional systems don't exist.

I'd argue that the majority of your customers don't care. However, those that do care would prefer 'slew always'.  The small percentage of your customers who want accurate time with the real world still would not use the Linux implementation of jumping time backwards.

For example: the Australian Stock Exchange:http://www.sfe.com.au/content/notices/2015/0291.15.03.pdf

ASX’s Trading platforms will Manage all transactions in the sequence they are received. Progress time forward as the time synchronisation will occur by slewing the time, not by moving the time backwards, or repeating the time.

The Linux implementation of leap seconds is absolutely ridiculous. Windows actually caused less problems simply because it ignores leap seconds.
Comment 5 Miroslav Lichvar 2015-10-15 04:11:54 EDT
I think there are basically three criteria when handling an inserted leap second:

A) for how long is the time inaccurate? (it can't be shorter than 1 second due to missing representation of the 23:59:60 UTC second on the Unix timescale)
B) is the time monotonic?
C) do clocks of computers in the network stay close to each other?

If we evaluate them for the -x option, we get:

          |  A          |   B       |   C
ntpd      |  1 second   |   no      |   yes
ntpd -x   |  >1 day     |   yes     |   no

By enabling the -x option we trade A+C for B.

In both B and C are important, it's necessary to use a leap smearing NTP server that will hide the leap second from the client ntpd and in that case it doesn't matter if it uses -x or not.

          |  A          |   B       |   C
ntpd      |  1 day      |   yes     |   yes
ntpd -x   |  1 day      |   yes     |   yes

For more information see

Even if we ignore the problems with extremely long correction of the initial offset and worse timekeeping performance due to disabled kernel discipline, the leap second behavior of -x is not always preferred and some users would need to disable it if it was enabled by default. The current default behavior is known and adding -x needs to be an informed decision. In cases where the time must be monotonic and also stay close to other hosts in the network, enabling -x wouldn't help anyway.
Comment 6 Ash 2015-10-15 06:52:54 EDT
Few points:

1. Is there not an option that will satisfy A, B and C?

2. If I were to rank A, B and C in terms of priority; most of your customers don't care. But those that do care, would rank B highest priority.

3. Again, any method of adjusting time that relies on time stepping backwards is absolutely ridiculous.

Note You need to log in before you can comment on or make changes to this bug.