drift modeling question - NTP

This is a discussion on drift modeling question - NTP ; Unruh wrote: > Uwe Klein writes: > > >>Unruh wrote: >> >>>Under Linux support is a mess. For example if you turn on an interrupt, the >>>system returns immediately even though the conditions of the interrupt have >>>not been met. ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 24 of 24

Thread: drift modeling question

  1. Re: drift modeling question

    Unruh wrote:
    > Uwe Klein writes:
    >
    >
    >>Unruh wrote:
    >>
    >>>Under Linux support is a mess. For example if you turn on an interrupt, the
    >>>system returns immediately even though the conditions of the interrupt have
    >>>not been met. Some bug in the code.
    >>>

    >>
    >>could you be more specific?

    >
    >
    > Sure
    > bugzilla.kernel.org bug 11112
    > On more recent systems (eg systems with HPET) the kernel code was not


    snip..............snip
    > very bad hpet/bios behaviour.)


    Thank you very much for the explanation.

    I had played around ( er, actually I use it
    for a scripted userland driver framwork for
    instrumentation we have )
    This uses a userland interrupt patch to
    have selected interrupts signal unserland.

    I had some issues with edge/level irq handling.

    uwe

  2. Re: drift modeling question

    Unruh wrote:
    > Martin Burnicki writes:
    >
    >>David and Hal,

    >
    >>David Woolley wrote:
    >>> Hal Murray wrote:
    >>>>
    >>>> Most PCs have 2 xtals. One at 14.xxx MHz (cheap, 4X color burst)
    >>>> that drives the CPU and most motherboard logic through a magic clock
    >>>> generator (PLL) chip, and another that is a 32 KHz watch crystal for
    >>>> keeping time when the CPU is off. The latter also makes interrupts
    >>>> for the scheduler.
    >>>
    >>> Historically interrupts from the 32kHz clock have not been used, except,
    >>> possibly, in powered down states to initiate a restart from suspend or
    >>> hibernate. It is possible that has changed very recently, but they
    >>> certainly weren't used historically.

    >
    >>About which operating system(s) are you talking?

    >
    >>The PC's standard RTC chip can certainly generate cyclic interrupts.
    >>However, if a cyclic interrupt from the RTC or from another timer chip is
    >>used to drive the scheduler depends on the type and eventually on the
    >>version of an operating system, isn't it?

    >
    >>So one system may be using the RTC's interrupts and another one may not.

    >
    > So the question is, do you know of any operating systems which use the RTC
    > to drive the scheduler?


    No, I just found the statements to which I did respond very general.

    One person claimed the RTC interrupt was used by the scheduler, and the
    other one claimed it is not used at all by the scheduler, but none of them
    mentioned the scheduler of which OS they were talking.

    Since the RTC's interrupt output is wired to the PC's interrupt controller
    it's just a matter of the implementation whether the RTC interrupt is used
    by a scheduler, or not. E.g. some old Linux version could have done so
    whereas recent versions don't.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  3. Re: drift modeling question

    David Woolley wrote:
    > Martin Burnicki wrote:
    >>
    >> About which operating system(s) are you talking?

    >
    > For powered up timing, MS-DOS, its predecessors if they implemented a
    > software clock at all, the MS-DOS Windows (3.0, 3.1, 95, 98, ME, 98SE),
    > most, if not all of the NT Windows (NT 3.5, NT 4.0, Windows 2000,
    > Windows XP, probably Windows 2003), Linux from start to 2.4, and mostly
    > for 2.6, SCO OpenServer.......
    >
    > (The tick rate for MS-DOS family systems is a good clue to which timer
    > they use.)


    Yes of course. I'm familiar with those old DOS systems and timers.

    >> The PC's standard RTC chip can certainly generate cyclic interrupts.
    >> However, if a cyclic interrupt from the RTC or from another timer chip is

    >
    > But generally isn't used for that. ISTR that some early PCs didn't have
    > an RTC and had to be set when booted.


    Yes, the PC/AT was the first IBM PC which had an RTC built-in by default.

    As mentioned in my other reply I just wanted you to be more specific.

    >> used to drive the scheduler depends on the type and eventually on the
    >> version of an operating system, isn't it?

    >
    > Divergence into alternative periodic sources on IBM PC type machines is
    > very recent.


    Ack.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  4. Re: drift modeling question


    >> So the question is, do you know of any operating systems which use the RTC
    >> to drive the scheduler?

    >
    >No, I just found the statements to which I did respond very general.
    >
    >One person claimed the RTC interrupt was used by the scheduler, and the
    >other one claimed it is not used at all by the scheduler, but none of them
    >mentioned the scheduler of which OS they were talking.
    >
    >Since the RTC's interrupt output is wired to the PC's interrupt controller
    >it's just a matter of the implementation whether the RTC interrupt is used
    >by a scheduler, or not. E.g. some old Linux version could have done so
    >whereas recent versions don't.


    I was probably mixed up in that discussion.

    I'm running a Linux 2.4 kernel.

    The key observation is that the temperature of the 32 KHz crystal tracks
    the NTP drift much better than the temperature of the CPU crystal.

    I was expecting that time would run off the main CPU crystal. I'm
    not really familiar with all the PC timing hardware. Most systems
    I've worked with have some instruction that quickly reads a counter.
    It's useful for low level timing hacks. I think Intel calls it the TSC.
    I was expecting the kernel to use it and thus was confused when the temperature
    of that crystal didn't track the drift very well. Dave Mills pointed
    out that the kernel time keeping code he wrote which was ported to many
    systems was driven off what I'm calling the scheduler interrupt
    from the RTC. Doing things that way makes more sense if you consider
    systems with multiplc CPUs. (which may be running off separate crystals)

    I've looked at the code, but I won't claim to be a wizard and it was
    a while ago. All that I remember is considtent with the time being
    derived from scheduler interrupts using the TSC to interpolate between ticks.

    Recent Linux kernels seem to use the TSC like I expected.
    Actually, that's the default. They have a collection of options.
    I got that far because the calibration for the TSC doesn't get
    the same answer. It's close, but easily visible as jumps in
    the drift when you reboot. (I'll say more if anybody wants.)


    --
    These are my opinions, not necessarily my employer's. I hate spam.


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2