no ntp synchronisation: 2s to 6s time shift ! - NTP

This is a discussion on no ntp synchronisation: 2s to 6s time shift ! - NTP ; Hello, Can anyone tell me if a time shift greater than 2s per day is ""normal"" on a linux system that has no "external" synchronisation (ntp)? I tryied "adjtimex -a" which gives unreliable results: it worked fine on one machine ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 32

Thread: no ntp synchronisation: 2s to 6s time shift !

  1. no ntp synchronisation: 2s to 6s time shift !

    Hello,

    Can anyone tell me if a time shift greater than 2s per day is ""normal""
    on a linux system that has no "external" synchronisation (ntp)?

    I tryied "adjtimex -a" which gives unreliable results: it worked fine on
    one machine (less than 1s shift / day) and badly on another one
    (several seconds shift / day)

    Any info about this subject would help me.

    Regards
    Thierry MARTIN

  2. Re: no ntp synchronisation: 2s to 6s time shift !

    Thierry,

    Thierry MARTIN wrote:
    > Hello,
    >
    > Can anyone tell me if a time shift greater than 2s per day is ""normal""
    > on a linux system that has no "external" synchronisation (ntp)?
    >
    > I tryied "adjtimex -a" which gives unreliable results: it worked fine on
    > one machine (less than 1s shift / day) and badly on another one
    > (several seconds shift / day)
    >
    > Any info about this subject would help me.


    Which kernel version are you running? Starting with ~2.6.22 a new clock
    model has made its way into the Linux kernel. There are different modules
    which can use different hardware timers for timekeeping, and there seem to
    be some problems with certain modules on certain hardware (i.e. chipsets on
    the motherboard).

    To list available clock sources under kernel ~2.6.22 or newer:

    # cat /sys/devices/system/clocksource/clocksource0/available_clocksource
    hpet acpi_pm pit jiffies tsc

    Check which clocksource is currently being used:

    # cat /sys/devices/system/clocksource/clocksource0/current_clocksource
    tsc

    Change the clock source:

    # echo tsc > \
    /sys/devices/system/clocksource/clocksource0/current_clocksource

    For a test it is also possible to override the default clock source using a
    boot parameter, e.g.:

    clocksource=jiffies

    You may want to try if some other of the available modules does a better job
    in timekeeping. If the active module doesn't work correctly then the
    frequency drift often exceeds the maximum drift ntpd can handle.


    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  3. Re: no ntp synchronisation: 2s to 6s time shift !

    Thierry MARTIN wrote:
    > Hello,
    >
    > Can anyone tell me if a time shift greater than 2s per day is ""normal""
    > on a linux system that has no "external" synchronisation (ntp)?


    I would say 2s/day is in the upper class for PCs,
    and it probably exceeds 10s/day in the average.

    Other architectures/manufacturers most likely do
    better.

    --
    François Meyer

  4. Re: no ntp synchronisation: 2s to 6s time shift !


    Thanks François. That is what I experience.

    François Meyer a écrit :
    > Thierry MARTIN wrote:
    >> Hello,
    >>
    >> Can anyone tell me if a time shift greater than 2s per day is ""normal""
    >> on a linux system that has no "external" synchronisation (ntp)?

    >
    > I would say 2s/day is in the upper class for PCs,
    > and it probably exceeds 10s/day in the average.
    >
    > Other architectures/manufacturers most likely do
    > better.
    >


  5. Re: no ntp synchronisation: 2s to 6s time shift !

    Hello again Thierry,

    On Tuesday, February 12, 2008 at 10:58:32 +0100, Thierry MARTIN wrote:

    > Can anyone tell me if a time shift greater than 2s per day is
    > ""normal"" on a linux system that has no "external" synchronisation
    > (ntp)?


    Absolutely normal: that's only 23 PPM, nothing. I have seen machines
    that do better, and some that do much worse. As long as it's stable,
    2 secs/day every day, and below 500 PPM, it's zeroifiable via the kernel
    clock frequency setting. Even above 500 PPM, with help from --tick.


    > I tryied "adjtimex -a" which gives unreliable results


    This --adjust thing is quite reliable, easely to the single PPM (less
    than 0.1 secs/day), provided you already carefully calibrated its
    reference: The RTC, via hwclock and /etc/adjtime.

    There are plenty of other methods to get an accurate kernel clock
    frequency. I'll propose one: run ntpd on the machine during some hours
    or a day, with a good connection to (a) good server(s). Then the
    following days restore the wanted kernel frequency via:

    | # ntptime -f $(cat /var/lib/ntp/ntp.drift) > /dev/null

    Or via:

    | # adjtimex --frequency $(awk '{printf "%.0f", $1 * 65536; exit}' /var/lib/ntp/ntp.drift)


    Cordialement, Serge.
    --
    Serge point Bets arobase laposte point net

  6. Re: no ntp synchronisation: 2s to 6s time shift !

    Thierry MARTIN writes:

    >Hello,


    >Can anyone tell me if a time shift greater than 2s per day is ""normal""
    >on a linux system that has no "external" synchronisation (ntp)?


    Sure. In fact that is small. 2s/day is 20PPM , and I have machines which
    have a 80PPM drift. Also some with a 6PPM drift. So 2s/d is certainly
    within the range.


    >I tryied "adjtimex -a" which gives unreliable results: it worked fine on
    > one machine (less than 1s shift / day) and badly on another one
    >(several seconds shift / day)


    >Any info about this subject would help me.


    Use ntp to synchronize externally.

    With no external sync, ntp and your computer has no way of knowing what the
    "right" time is. And depending on the use your computer gets, fluctuations in
    the drift of seconds per day are certainly possible (unusual but possible) from Temp variations
    within the machine.


  7. Re: no ntp synchronisation: 2s to 6s time shift !

    Any place where these different clock models is described?
    And defined (what is tsc?)

    Martin Burnicki writes:

    >Thierry,


    >Thierry MARTIN wrote:
    >> Hello,
    >>
    >> Can anyone tell me if a time shift greater than 2s per day is ""normal""
    >> on a linux system that has no "external" synchronisation (ntp)?
    >>
    >> I tryied "adjtimex -a" which gives unreliable results: it worked fine on
    >> one machine (less than 1s shift / day) and badly on another one
    >> (several seconds shift / day)
    >>
    >> Any info about this subject would help me.


    >Which kernel version are you running? Starting with ~2.6.22 a new clock
    >model has made its way into the Linux kernel. There are different modules
    >which can use different hardware timers for timekeeping, and there seem to
    >be some problems with certain modules on certain hardware (i.e. chipsets on
    >the motherboard).


    >To list available clock sources under kernel ~2.6.22 or newer:


    ># cat /sys/devices/system/clocksource/clocksource0/available_clocksource
    >hpet acpi_pm pit jiffies tsc


    >Check which clocksource is currently being used:


    ># cat /sys/devices/system/clocksource/clocksource0/current_clocksource
    >tsc


    >Change the clock source:


    ># echo tsc > \
    >/sys/devices/system/clocksource/clocksource0/current_clocksource


    >For a test it is also possible to override the default clock source using a
    >boot parameter, e.g.:


    >clocksource=jiffies


    >You may want to try if some other of the available modules does a better job
    >in timekeeping. If the active module doesn't work correctly then the
    >frequency drift often exceeds the maximum drift ntpd can handle.



    >Martin
    >--
    >Martin Burnicki


    >Meinberg Funkuhren
    >Bad Pyrmont
    >Germany


  8. Re: no ntp synchronisation: 2s to 6s time shift !

    Unruh wrote:
    > Any place where these different clock models is described?
    > And defined (what is tsc?)
    >

    tsc refers to the counter in recent Intel Architecture chips that counts
    the processor clock cycles. It is somewhat vulnerable to power management.

  9. Re: no ntp synchronisation: 2s to 6s time shift !

    Unruh wrote:
    > Any place where these different clock models is described?


    Hm, I think "clock models" in the sense of NTP is not correct in this
    context. AFAIK there is only one "clock model" in the Linux kernel which
    uses one of those "clocksource" modules as its base for timekeeping,
    similar to the way ntpd uses a refclock as time source.

    Each of the clocksource modules deals with a dedicated timer or counter
    which may or may not be available on a specific hardware architecture, i.e.
    the x86_64 hardware may provide different timers in its chipset than the
    i386 architecture.

    > And defined (what is tsc?)


    The only place I've found to get an overview is the file
    Documentation/kernel-parameters.txt which is part of the Linux kernel
    sources. This also lists which clocksource modules may be available for
    which hardware architecture.

    Here's the relevant part from a 2.6.22 kernel:

    clocksource= [GENERIC_TIME] Override the default clocksource
    Format:
    Override the default clocksource and use the clocksource
    with the name specified.
    Some clocksource names to choose from, depending on
    the platform:
    [all] jiffies (this is the base, fallback clocksource)
    [ACPI] acpi_pm
    [ARM] imx_timer1,OSTS,netx_timer,mpu_timer2,
    pxa_timer,timer3,32k_counter,timer0_1
    [AVR32] avr32
    [IA-32] pit,hpet,tsc,vmi-timer;
    scx200_hrt on Geode; cyclone on IBM x440
    [MIPS] MIPS
    [PARISC] cr16
    [S390] tod
    [SH] SuperH
    [SPARC64] tick
    [X86-64] hpet,tsc


    As already mentioned by David Woolley the TSC counter is a register inside
    Pentium CPUs or higher. The tick rate corresponds to the CPU clock, so if
    the CPU clock changes due to power saving efforts this has to be taken into
    account when measuring time intervals.

    The acpi_pm module uses the ACPI Power Management timer which is available
    on every PC which supports ACPI services.

    The hpet module uses the High Precision Event Timers indroduced by recent
    Intel chip sets. AFAIK it's a replacement for the old Periodic Interrupt
    Timer from the original IBM PC architecture which used to generate periodic
    interrupts at 18.2 Hz under DOS.

    I don't know the exact details or advantages/disadvantages of those timers.
    However, from several postings here in the NG and elsewhere I've seen that
    certain modules may not work properly on certain chipsets. This must not
    necessarily be due to the modules, AFAIK there are also chipsets out there
    where the timers don't work properly and would require specific
    workarounds.


    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  10. Re: no ntp synchronisation: 2s to 6s time shift !


    Hi all,

    Just a few word to keep you informed...

    I have been trying acpi_pm clocksource for a few days now and the
    results are quite good :-).

    The time drift is less than 1s per day (I would even say less that 500ms
    but this has to be confirmed) which is much better than the default
    config with tsc (>2s /day).

    Honestly, I am a bit surprised / worried about these results: I would
    expect that people doing distribution would have the best clocksource
    detected / configured automatically.
    Might be because my FC5 base is too old, or ... I Hope I won't find side
    effects...

    Have a nice day!
    Thierry MARTIN


    Martin Burnicki a écrit :
    > Unruh wrote:
    >> Any place where these different clock models is described?

    >
    > Hm, I think "clock models" in the sense of NTP is not correct in this
    > context. AFAIK there is only one "clock model" in the Linux kernel which
    > uses one of those "clocksource" modules as its base for timekeeping,
    > similar to the way ntpd uses a refclock as time source.
    >
    > Each of the clocksource modules deals with a dedicated timer or counter
    > which may or may not be available on a specific hardware architecture, i.e.
    > the x86_64 hardware may provide different timers in its chipset than the
    > i386 architecture.
    >
    >> And defined (what is tsc?)

    >
    > The only place I've found to get an overview is the file
    > Documentation/kernel-parameters.txt which is part of the Linux kernel
    > sources. This also lists which clocksource modules may be available for
    > which hardware architecture.
    >
    > Here's the relevant part from a 2.6.22 kernel:
    >
    > clocksource= [GENERIC_TIME] Override the default clocksource
    > Format:
    > Override the default clocksource and use the clocksource
    > with the name specified.
    > Some clocksource names to choose from, depending on
    > the platform:
    > [all] jiffies (this is the base, fallback clocksource)
    > [ACPI] acpi_pm
    > [ARM] imx_timer1,OSTS,netx_timer,mpu_timer2,
    > pxa_timer,timer3,32k_counter,timer0_1
    > [AVR32] avr32
    > [IA-32] pit,hpet,tsc,vmi-timer;
    > scx200_hrt on Geode; cyclone on IBM x440
    > [MIPS] MIPS
    > [PARISC] cr16
    > [S390] tod
    > [SH] SuperH
    > [SPARC64] tick
    > [X86-64] hpet,tsc
    >
    >
    > As already mentioned by David Woolley the TSC counter is a register inside
    > Pentium CPUs or higher. The tick rate corresponds to the CPU clock, so if
    > the CPU clock changes due to power saving efforts this has to be taken into
    > account when measuring time intervals.
    >
    > The acpi_pm module uses the ACPI Power Management timer which is available
    > on every PC which supports ACPI services.
    >
    > The hpet module uses the High Precision Event Timers indroduced by recent
    > Intel chip sets. AFAIK it's a replacement for the old Periodic Interrupt
    > Timer from the original IBM PC architecture which used to generate periodic
    > interrupts at 18.2 Hz under DOS.
    >
    > I don't know the exact details or advantages/disadvantages of those timers.
    > However, from several postings here in the NG and elsewhere I've seen that
    > certain modules may not work properly on certain chipsets. This must not
    > necessarily be due to the modules, AFAIK there are also chipsets out there
    > where the timers don't work properly and would require specific
    > workarounds.
    >
    >
    > Martin


  11. Re: no ntp synchronisation: 2s to 6s time shift !

    Thierry MARTIN wrote:

    > I have been trying acpi_pm clocksource for a few days now and the
    > results are quite good :-).
    >
    > The time drift is less than 1s per day (I would even say less that 500ms
    > but this has to be confirmed) which is much better than the default
    > config with tsc (>2s /day).


    It's almost certain that the same hardware time source is used for both,
    so discrepancies are likely to be attributable to software issues
    (although those may include problems in calibrating the frequency of
    various sources empirically, rather than by knowing how they derive from
    the common source).

  12. Re: no ntp synchronisation: 2s to 6s time shift !

    Oups?

    If I understand your post, tsc is the same as acpi_pm ?

    Was I just a lucky guy with this config?

    (:- You've just killed my enthousiasm ... :-)



    David Woolley a écrit :
    > Thierry MARTIN wrote:
    >
    >> I have been trying acpi_pm clocksource for a few days now and the
    >> results are quite good :-).
    >>
    >> The time drift is less than 1s per day (I would even say less that
    >> 500ms but this has to be confirmed) which is much better than the
    >> default config with tsc (>2s /day).

    >
    > It's almost certain that the same hardware time source is used for both,
    > so discrepancies are likely to be attributable to software issues
    > (although those may include problems in calibrating the frequency of
    > various sources empirically, rather than by knowing how they derive from
    > the common source).


  13. Re: no ntp synchronisation: 2s to 6s time shift !

    David,

    David Woolley wrote:
    > Thierry MARTIN wrote:
    >
    >> I have been trying acpi_pm clocksource for a few days now and the
    >> results are quite good :-).
    >>
    >> The time drift is less than 1s per day (I would even say less that 500ms
    >> but this has to be confirmed) which is much better than the default
    >> config with tsc (>2s /day).

    >
    > It's almost certain that the same hardware time source is used for both,
    > so discrepancies are likely to be attributable to software issues
    > (although those may include problems in calibrating the frequency of
    > various sources empirically, rather than by knowing how they derive from
    > the common source).


    If you mean the same base oscillator on the motherboard then this may be the
    case.

    However, a bunch of clock signals with different clock rates are derived
    from those oscillators, and the fact that different clocksource modules
    yield different results make me assume that the problems are not with the
    base oscillator but with the different types of counters and/or the
    implementations of the modudules which use thos specific counters.

    See also
    http://bugzilla.kernel.org/show_bug.cgi?id=7963

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  14. Re: no ntp synchronisation: 2s to 6s time shift !

    On Feb 12, 4:40 pm, David Woolley
    wrote:
    >
    > tsc refers to the counter in recent Intel Architecture chips that counts
    > the processor clock cycles. It is somewhat vulnerable to power management.


    Not only PM, but also differences between processor cores. Some
    models of multi-core processors from AMD or Intel provide one TSC per
    core, which may cause discrepancies when the TSC is read on one core
    at a time tick and on another core at the next time tick. This is
    also true for multi-processor systems: TSCs are not guaranteed to be
    correlated among processors, not even their relative monotonicity.

    The Linux kernel goes through hoops to account for such discrepancies
    among the several TSC instances, but it's never 100% successful
    neither 100% accurate.

    Using the TSC as a time reference is tempting because reading it takes
    just a few CPU cycles to read it. Other time references, such as ACPI-
    PM and HPET, take much longer to read, even 1000X longer, though they
    provide consistent reads and accuracy no matter from which processor
    or core.

    The speed to get the time-of-day from the kernel may be important when
    running some applications, such as data-base servers, when every
    transaction is time-tagged and the time it takes to get the time-of-
    day can contribute significantly to its performance.

    Therefore, for time-keeping purposes, it's better to avoid the kernel
    from using the TSC as its time-reference, in favor of other timers
    available in the system, unless running an application whose
    performance may be gated by getting the time-of-day.

    HTH

  15. Re: no ntp synchronisation: 2s to 6s time shift !

    Thierry MARTIN wrote:
    > Oups?
    >
    > If I understand your post, tsc is the same as acpi_pm ?


    No. TSC, acpi_pm, the CTC based software clock that PCs have always
    had, etc., are all fed from the same crystal, but run at different
    multiples of that crystal's frequency. Only the battery backed clock
    normally runs from a different crystal.

    Software can get the readings wrong by missing ticks, or in the case of
    the TSC counter, at least, by trying to work out the processor clock
    speed, rather than being told it; typically they time the TSC clock
    against the CTC one, during startup, and use that to calculate effective
    CPU clock frequency.

    The CPU clock frequency is slowed down by power management, so the TSC
    rate can vary.

  16. Re: no ntp synchronisation: 2s to 6s time shift !

    Hi All,

    Sorry for beeing too enthousiastic about my initial test...

    I launched another test with clocksource=acpi_pm, on the same machine.
    The results are bad now (> 500ms in a few hours).

    FYI, the command I launched:
    # rm /etc/adjtime;
    # ntpdate ntp.cines.fr;
    # hwclock --systohc;
    # adjtimex -a

    Then I watch:
    # ntpdate -q ntp.cines.fr

    Keeping a linux system with the correct time without any external
    synchronisation really seems hard...

    Best regards
    Thierry.





    Thierry MARTIN a écrit :
    > Oups?
    >
    > If I understand your post, tsc is the same as acpi_pm ?
    >
    > Was I just a lucky guy with this config?
    >
    > (:- You've just killed my enthousiasm ... :-)
    >
    >
    >
    > David Woolley a écrit :
    >> Thierry MARTIN wrote:
    >>
    >>> I have been trying acpi_pm clocksource for a few days now and the
    >>> results are quite good :-).
    >>>
    >>> The time drift is less than 1s per day (I would even say less that
    >>> 500ms but this has to be confirmed) which is much better than the
    >>> default config with tsc (>2s /day).

    >>
    >> It's almost certain that the same hardware time source is used for
    >> both, so discrepancies are likely to be attributable to software
    >> issues (although those may include problems in calibrating the
    >> frequency of various sources empirically, rather than by knowing how
    >> they derive from the common source).


  17. Re: no ntp synchronisation: 2s to 6s time shift !

    Hi Serge,

    My investigations might lead me to choose your solution ;-).

    The system I have is a (trans)portable machine. I wonder wether these
    parameters will be ok, wherever I place it (what is the influnce of
    temperature differences or things like that)?

    Regards
    Thierry MARTIN


    Serge Bets a écrit :
    > Hello again Thierry,
    >
    > On Tuesday, February 12, 2008 at 10:58:32 +0100, Thierry MARTIN wrote:
    >
    >> Can anyone tell me if a time shift greater than 2s per day is
    >> ""normal"" on a linux system that has no "external" synchronisation
    >> (ntp)?

    >
    > Absolutely normal: that's only 23 PPM, nothing. I have seen machines
    > that do better, and some that do much worse. As long as it's stable,
    > 2 secs/day every day, and below 500 PPM, it's zeroifiable via the kernel
    > clock frequency setting. Even above 500 PPM, with help from --tick.
    >
    >
    >> I tryied "adjtimex -a" which gives unreliable results

    >
    > This --adjust thing is quite reliable, easely to the single PPM (less
    > than 0.1 secs/day), provided you already carefully calibrated its
    > reference: The RTC, via hwclock and /etc/adjtime.
    >
    > There are plenty of other methods to get an accurate kernel clock
    > frequency. I'll propose one: run ntpd on the machine during some hours
    > or a day, with a good connection to (a) good server(s). Then the
    > following days restore the wanted kernel frequency via:
    >
    > | # ntptime -f $(cat /var/lib/ntp/ntp.drift) > /dev/null
    >
    > Or via:
    >
    > | # adjtimex --frequency $(awk '{printf "%.0f", $1 * 65536; exit}' /var/lib/ntp/ntp.drift)
    >
    >
    > Cordialement, Serge.


  18. Re: no ntp synchronisation: 2s to 6s time shift !

    Thierry MARTIN writes:

    >Hi All,


    >Sorry for beeing too enthousiastic about my initial test...


    >I launched another test with clocksource=acpi_pm, on the same machine.
    >The results are bad now (> 500ms in a few hours).


    >FYI, the command I launched:
    ># rm /etc/adjtime;
    ># ntpdate ntp.cines.fr;
    ># hwclock --systohc;
    ># adjtimex -a


    >Then I watch:
    ># ntpdate -q ntp.cines.fr


    >Keeping a linux system with the correct time without any external
    >synchronisation really seems hard...


    Yes. YOu expected something else?
    If you use chrony, you can enter in the time by hand now and then again in
    8 hours. chrony will use that data to estimate the drift of the oscillator
    and use that drift info to try to keep the clock on better time. You CANNOT
    expect a PC oscillator to keep good time without drift compensation. They
    were never designed for that. Note that 1 sec in 10 hours is a drift rate
    of only 30PPM. which is well within the error budget of most crystals. With
    hand setting you can probably reduce that by a factor of 10 but not much
    better due to temp variations, etc.



    >Best regards
    >Thierry.






    >Thierry MARTIN a écrit :
    >> Oups?
    >>
    >> If I understand your post, tsc is the same as acpi_pm ?
    >>
    >> Was I just a lucky guy with this config?
    >>
    >> (:- You've just killed my enthousiasm ... :-)
    >>
    >>
    >>
    >> David Woolley a écrit :
    >>> Thierry MARTIN wrote:
    >>>
    >>>> I have been trying acpi_pm clocksource for a few days now and the
    >>>> results are quite good :-).
    >>>>
    >>>> The time drift is less than 1s per day (I would even say less that
    >>>> 500ms but this has to be confirmed) which is much better than the
    >>>> default config with tsc (>2s /day).
    >>>
    >>> It's almost certain that the same hardware time source is used for
    >>> both, so discrepancies are likely to be attributable to software
    >>> issues (although those may include problems in calibrating the
    >>> frequency of various sources empirically, rather than by knowing how
    >>> they derive from the common source).


  19. Re: no ntp synchronisation: 2s to 6s time shift !

    On Tuesday, February 19, 2008 at 17:45:59 +0100, Thierry MARTIN wrote:

    > The system I have is a (trans)portable machine. I wonder wether these
    > parameters will be ok, wherever I place it (what is the influnce of
    > temperature differences or things like that)?


    Of course the temperature influences the drift of the clocks. When you
    run ntpd continuously and graph the kernel frequency, you clearly see
    night and day cycles, seasonal cycles, "accidents" like the heater
    stopped during 2 hours, periods where the computer is iddle or does
    heavy work, and days where the sun shines. Ntpd compensates those
    variations continuously, correcting the frequency to stay in phase with
    The Real UTC Thing.

    The frequency difference between a winter night and a summer day depends
    on the machine and various conditions, but I seem to typically see
    around 2 PPMs. When ntpd is not there to compensate in real time, your
    goal is to calculate a mean frequency, that will suit your own usage of
    the machine. On a 24/7 server, pick the mean over 24 hours. On a
    workstation, pick mean of work hours. And so on.


    The temperature influences also the RTC drift rate. And there is there
    a major additional source of temperature variation: is the machine on,
    or off? One also has to calculate a mean drift, but more to suit the
    *non-usage* of the machine. Let me explain:

    An accurate RTC is important at one occasion: The boot sequence, when
    hwclock --hctosys reads the RTC, applies the drift correction, and
    initialises the system clock. The RTC has then drifted since the last
    time hwclock --systohc had set it. Typically, this happend during the
    previous shutdown. In those conditions, to have a good correction factor
    to apply at boot, one should evaluate the drift during power-off time.
    This could be schematically:

    | at the end of the day:
    | # ntpdate -b ntp.cines.fr
    | # hwclock --systohc --nodrift
    | # shutdown -h now
    | wait next morning, then restart the machine, and soon after:
    | # ntpdate -b ntp.cines.fr
    | # hwclock --systohc

    This is important, as bad procedures evaluating the RTC drift wrongly
    during runtime are a major source of error, maybe a dozen PPMs, one
    entire second/day, resulting in several hundreds of milliseconds offset
    on the next morning.

    Note that the default setup of many Linux distributions doesn't do that
    well. They evaluate the RTC drift from shutdown to shutdown, over mixed
    periods of half runtime and half poweroff. I fear the difference to be
    so big that such a compromise can suit nearly noone.

    I wonder how Chrony behaves with the RTC?


    Cordialement, Serge.
    --
    Serge point Bets arobase laposte point net

  20. Re: no ntp synchronisation: 2s to 6s time shift !

    On Feb 19, 10:45*am, Thierry MARTIN
    wrote:
    > The system I have is a (trans)portable machine. I wonder wether these
    > parameters will be ok, wherever I place it (what is the influnce of
    > temperature differences or things like that)?
    >


    In my experience, laptops, especially the newer "ultra-thin" models,
    experience wide temparature swings, even when going from high CPU load
    to idle. Therefore environmental factors will likely make any "fixed"
    frequency correction you might make pretty useless.

    If you need good time, you pretty much have to use the reference ntpd
    (or another full ntp daemon) on a machine that experiences high
    temperature variations.

    Of course, ntpd requires an external reference. Unfortunately, most
    ntpd versions out there in the wild do not handle the changing network
    connectivity that laptops typically experience very well. They expect
    the network to be available on ntpd startup, and not change much
    thereafter. A typical suggestion to wrok around this is to setup a
    script or something to restart ntpd when your network connectivity
    changes. How this is done varies from OS to OS, and even from
    distribution to distribution on say Linux.

    Improvements are being made to the most recent development versions of
    ntpd in this area (re-doing DNS lookups periodically for example). I'm
    not sure of the state of those changes, last I checked a few months
    ago they were still in the latter stages of design.

+ Reply to Thread
Page 1 of 2 1 2 LastLast