Dual-core systems - AMD - Windows Vista - NTP

This is a discussion on Dual-core systems - AMD - Windows Vista - NTP ; Martin Burnicki wrote: > Danny Mayer wrote: >> David J Taylor wrote: >>> Thanks for your reply. Perhaps my recollection is at fault here, but I >>> recall that NTP on Windows uses some interpolation technique to overcome >>> timer ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 56

Thread: Dual-core systems - AMD - Windows Vista

  1. Re: Dual-core systems - AMD - Windows Vista

    Martin Burnicki wrote:
    > Danny Mayer wrote:
    >> David J Taylor wrote:
    >>> Thanks for your reply. Perhaps my recollection is at fault here, but I
    >>> recall that NTP on Windows uses some interpolation technique to overcome
    >>> timer granularity, and that the interpolation used a CPU counter.

    >> We are intending to implement that but we haven't done so yet.

    >
    > Huh? Danny you should know the code is already there for many years ...


    No, I was talking about Peter and Terje's additional interpolation code.

    >> There is one other thing that needs to be considered. This is a 64-bit
    >> system> In that case it's possible that the code may need to be changed
    >> to deal with it properly. For example using the VS 2005 compiler I have
    >> found that it uses a 64-bit integer instead of 32-bit integer for
    >> time_t. This could affect the quality of the results, it's hard to say.

    >
    > Shouldn't this only matter when the 32 bit time_t overflows?


    It's hard to know. I first ran into the issue when I compiled BIND with
    VS 2005 and it fell over almost immediately and it wasn't an overflow
    issue. However on a 32-bit O/S on 64-bit hardware the results are really
    uncertain.

    Danny

  2. Re: Dual-core systems - AMD - Windows Vista

    Danny,

    Danny Mayer wrote:
    > David J Taylor wrote:
    >> The version I'm testing is the 32-bit version of Vista, albeit on a
    >> 64-bit
    >> capable CPU. 64-bit can be a pain though for subtle errors, I
    >> appreciate.
    >>

    >
    > That's a problem. There are even more subtle issues when you run a
    > 32-bit O/S on a 64-bit system. I don't think we can even try to support
    > that since there are likely to be too many unknowns. It's a very nasty
    > mix.


    I don't think there's a basic problem if you run a 32 bit OS on a 64 bit
    hardware. AFAIK the AMD64 platform is backward compatible with 32 bit OSs.
    W2k is running fine on a AMD64 machine here, and there are absolutely no
    problems.

    In one of his earlier posts David mentioned that there were no problems when
    he was running WXP on that machine.

    I would rather expect some possible problems if you run a 64 bit OS (WXP x64
    or Vista x64) on a 64 bit hardware, and then run a 32 bit application under
    that 64 bit OS, if the 32 bit compatibility layer of the OS has not been
    implemented properly.

    >> I didn't think that a 64-bit version of NTP was included in the Meinberg
    >> distribution.


    I don't think it would make much sense (or would be even possible) to run a
    program compiled for a 64 bit target OS on a 32 bit OS, just because the
    hardware is 64 bit.


    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  3. Re: Dual-core systems - AMD - Windows Vista

    Danny Mayer wrote:
    []
    > With VS 2005, just open the dsw file and tell it to convert all the
    > project files. I recently add the necessary macros to the dsp files so
    > that I don't have to add a bunch of macros every time I pull in a new
    > tarball. I'm only building on VS 2005 these days. Building on VS 6 I
    > reserve for releasing builds.
    >
    > We don't ship the OpenSSL sources due to possible export regulations.
    > You can download that yourself from the openssl.org site. Just follow
    > the build instructions for Windows. I use the nt suboption.


    Thanks, Danny.

    I have now downloaded the OpenSSL sources, however, the file
    openssl/evp.h which ntp needs is not in a directory called "openssl", but
    in a directory called "crypto". Confusingly, in the project options you
    have a directory setting of: "$(OPENSSL)\inc32", and I see no inc32
    directory in the OpenSSL tree. I also seem to have trouble finding the
    build instructions you mentioned.

    Cheers,
    David



  4. Re: Dual-core systems - AMD - Windows Vista

    Martin Burnicki wrote:
    > Danny,
    >
    > Danny Mayer wrote:
    >> David J Taylor wrote:
    >>> The version I'm testing is the 32-bit version of Vista, albeit on a
    >>> 64-bit
    >>> capable CPU. 64-bit can be a pain though for subtle errors, I
    >>> appreciate.
    >>>

    >>
    >> That's a problem. There are even more subtle issues when you run a
    >> 32-bit O/S on a 64-bit system. I don't think we can even try to
    >> support that since there are likely to be too many unknowns. It's a
    >> very nasty mix.

    >
    > I don't think there's a basic problem if you run a 32 bit OS on a 64
    > bit hardware. AFAIK the AMD64 platform is backward compatible with 32
    > bit OSs. W2k is running fine on a AMD64 machine here, and there are
    > absolutely no problems.


    Agreed.

    > In one of his earlier posts David mentioned that there were no
    > problems when he was running WXP on that machine.


    Correct.

    > I would rather expect some possible problems if you run a 64 bit OS
    > (WXP x64 or Vista x64) on a 64 bit hardware, and then run a 32 bit
    > application under that 64 bit OS, if the 32 bit compatibility layer
    > of the OS has not been implemented properly.
    >
    >>> I didn't think that a 64-bit version of NTP was included in the
    >>> Meinberg distribution.

    >
    > I don't think it would make much sense (or would be even possible) to
    > run a program compiled for a 64 bit target OS on a 32 bit OS, just
    > because the hardware is 64 bit.
    >
    >
    > Martin


    No, I was meaning a native 64-bit version of ntp to run under 64-bit Vista
    (or XP). I would suspect that the extra OS layer implementing the 32-bit
    calls on the 64-bit native OS would lose some accuracy. But that's not
    the order of magnitude of the error I'm seeing.

    Thanks,
    David



  5. Re: Dual-core systems - AMD - Windows Vista

    David,

    David J Taylor wrote:
    > Martin Burnicki wrote:
    >> While on legacy multiprocessor systems the CPU clocks (and thus the
    >> TSC) may differ for each CPU, I'm _assuming_ that multicore CPUs are
    >> clocked by the same source, so the TSCs should runs synchrounously.

    >
    > This assumption is probably wrong, as AMD (at least) have needed to issue
    > a fix to synchronise the counters on the two cores (if I understand this
    > correctly):
    >
    >

    http://www.amd.com/us-en/Processors/..._13118,00.html
    > => AMD Dual-Core Optimizer


    Seems you're right ;-)

    > There's an implication that the OS may do this providing you don't call
    > RDTSC.
    >
    >> Finally, the Windows port of ntpd also calls a Windows API to set the
    >> thread affinty for the clock interpolation thread to the first CPU,
    >> so it should not be required to specify a certain CPU to run on, as
    >> proposed by Ryan.
    >>
    >> Martin

    >
    > Thanks for that clarification, Martin. Host helpful. Looking at the
    > ntpd.exe process with Windows Task Manager under Vista, right-click Set
    > Affinity, shows both CPU0 and CPU1 as being checked. I can't see how to
    > confirm this using SysInternals Process Explorer.



    Hm, the process CPU affinity is not restricted to a single CPU. Ntpd has 4
    active threads, and only the CPU affinity of the clock interpolation thread
    is restricted to the first CPU since this is the only thread which calls
    QueryPerformanceCounter() and thus potentially reads the TSC of the CPU it
    is running on. The other threads may still run on either CPU.

    I'm not aware of a tool which displays the CPU affinity of a single thread,
    so I don't know right now how you can verify this, except by looking at the
    source code.

    > I'd welcome any performance comparison with my own data, or insight as to
    > why the same system performs so much more poorly under Vista than under
    > XP.


    I've just set up a new test under Vista, so let's see.

    What I can say right now is that the default tick adjustment value is 156001
    instead of 156250 which it used to be on earlier Windows versions. Also the
    granularity of the system clock has changed from 15.625 ms to 1 ms.

    Maybe the timer tick interpolation code is not quite appropriate for these
    settings.


    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  6. Re: Dual-core systems - AMD - Windows Vista

    Martin Burnicki wrote:
    []
    > I've just set up a new test under Vista, so let's see.
    >
    > What I can say right now is that the default tick adjustment value is
    > 156001 instead of 156250 which it used to be on earlier Windows
    > versions. Also the granularity of the system clock has changed from
    > 15.625 ms to 1 ms.
    >
    > Maybe the timer tick interpolation code is not quite appropriate for
    > these settings.
    >
    >
    > Martin


    Martin, thanks for that interesting information. I'd love to know if you
    see similar offsets to me, or if it's just a quirk of the system here.
    It's a test system and not a production one, so if you need anything
    tested just shout. As you may have seen, I have been trying to get ntpd
    to compile here, but with little joy so far.

    Cheers,
    David



  7. Re: Dual-core systems - AMD - Windows Vista

    Evandro,

    Yes, the nanocode is aware that individual CPU clock rates can differ
    and vary over time. Since the only purpose is to interpolate between
    timer interrupts (Alpha) or second overflows (FreeBSD), all the code
    does is count the number of PCC cycles since the last interrupt to
    construct a divisor to scale the PCC accordinly. It does this once each
    second for every CPU.

    The important thing to realize in this process is that all basic time
    functions rely on timer interrupts, where the kernel time variable is
    disciplined in phase and frequency by system calls such as adjtime() or
    ntp_adjtime(). The PCC frequency can vary due to core temperature rather
    more than the timer frequency, which (used to be and hopefully now is)
    on a different chip with constant temperature. This is why the PCC is
    used only for interpolation, not as the reference oscillator as in some
    designs.

    Dave

    Evandro Menezes wrote:

    > On Dec 1, 10:42 am, "David L. Mills" wrote:
    >
    >
    >>The multiple-CPU nanokernel code that left here and is in the Alpha
    >>kernel assumes each CPU has an individual cycle counter and the timer
    >>interupts are vectored to a designated CPU. There is a data structure
    >>associated with each CPU that holds the measured current cycle counter
    >>scaling and offset, which is updated once each second by interprocessor
    >>interrrupt. A call to read the system clock lands on a j-random CPU,
    >>which reads the global time maintained by timer interrupts and
    >>interpolates according to the current CPU values.

    >
    >
    > Just curious, but is it aware that the CPU clock frequency may change
    > on the fly and differently for each processor for power-management
    > purposes? As a result, the rate of the count by RDTSC may vary. For
    > example, all multi-core AMD Opteron processors, both Barcelona
    > generation and the previous one.
    >
    > Thanks.


  8. Re: Dual-core systems - AMD - Windows Vista

    David,

    David J Taylor wrote:
    > Martin Burnicki wrote:
    > []
    >> I've just set up a new test under Vista, so let's see.
    >>
    >> What I can say right now is that the default tick adjustment value is
    >> 156001 instead of 156250 which it used to be on earlier Windows
    >> versions. Also the granularity of the system clock has changed from
    >> 15.625 ms to 1 ms.
    >>
    >> Maybe the timer tick interpolation code is not quite appropriate for
    >> these settings.
    >>
    >>
    >> Martin

    >
    > Martin, thanks for that interesting information. I'd love to know if you
    > see similar offsets to me, or if it's just a quirk of the system here.
    > It's a test system and not a production one, so if you need anything
    > tested just shout. As you may have seen, I have been trying to get ntpd
    > to compile here, but with little joy so far.


    I had made a fresh installation of Vista and forgot to disable automatic
    sleep mode, so my overnight test failed and I had to run it once more over
    the last hours.

    The test machine is a Intel Pentium D 3 GHz (dual core) with Windows Vista
    x64. Data of the time synchronization performance was collected by the time
    adjustment service which comes with the Meinberg driver package for
    Windows. That service computes the difference between the Windows system
    time and a built-in GPS170PCI card and normally disiplines the system time.
    However, in order to test the accuracy of NTP the Meinberg time service was
    configured just to collect data and not to apply any correnctions to the
    system time.

    I have run both the current NTP stable version ntp-4.2.4p4, and the current
    ntp-dev version ntp-dev-4.2.5p104, configured to get the time from a GPS
    controlled NTP server on the local network, which provides magnitues more
    accuracy than we can see here.

    Both versions of NTP showed similar dissatisfying results. The offset varies
    from about 20 to more than 50 milliseconds, so there's a bias of about 30
    to 40 milliseconds. See the following graph:
    http://www.meinberg.de/download/ntp/...-vista-x64.pdf

    In order to show that it's possible to yield better results even on a 64 bit
    platform I have disabled the NTP service and enabled our time adjustment
    service start to discipline the system time. The results can be seen at the
    end of the graph.

    In order to make the results better visible I've also generated another
    graph with different scaling of the time offset:
    http://www.meinberg.de/download/ntp/...64-details.pdf

    Please note both NTP and our time adjustment service are simple 32 bit apps
    compiled with VC6, so as a conclusion we can say that there is neither a
    general problem with the 64 bit OS nor with the 64 bit hardware
    architecture.

    As already mentioned earlier I _assume_ there is a glitch in the NTP code
    which doesn't convert or interpolate the Windows time stamps properly under
    Vista.

    I'll try to find out more.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  9. Re: Dual-core systems - AMD - Windows Vista

    Martin Burnicki wrote:
    > David,

    []
    > I had made a fresh installation of Vista and forgot to disable
    > automatic sleep mode, so my overnight test failed and I had to run it
    > once more over the last hours.


    Been there, done that!

    > The test machine is a Intel Pentium D 3 GHz (dual core) with Windows
    > Vista x64. Data of the time synchronization performance was collected
    > by the time adjustment service which comes with the Meinberg driver
    > package for Windows. That service computes the difference between the
    > Windows system time and a built-in GPS170PCI card and normally
    > disiplines the system time. However, in order to test the accuracy of
    > NTP the Meinberg time service was configured just to collect data and
    > not to apply any correnctions to the system time.


    Understood.

    > I have run both the current NTP stable version ntp-4.2.4p4, and the
    > current ntp-dev version ntp-dev-4.2.5p104, configured to get the time
    > from a GPS controlled NTP server on the local network, which provides
    > magnitues more accuracy than we can see here.
    >
    > Both versions of NTP showed similar dissatisfying results. The offset
    > varies from about 20 to more than 50 milliseconds, so there's a bias
    > of about 30 to 40 milliseconds. See the following graph:
    > http://www.meinberg.de/download/ntp/...-vista-x64.pdf
    >
    > In order to show that it's possible to yield better results even on a
    > 64 bit platform I have disabled the NTP service and enabled our time
    > adjustment service start to discipline the system time. The results
    > can be seen at the end of the graph.


    OK, I see both versions.

    > In order to make the results better visible I've also generated
    > another graph with different scaling of the time offset:
    > http://www.meinberg.de/download/ntp/...64-details.pdf
    >
    > Please note both NTP and our time adjustment service are simple 32
    > bit apps compiled with VC6, so as a conclusion we can say that there
    > is neither a general problem with the 64 bit OS nor with the 64 bit
    > hardware architecture.
    >
    > As already mentioned earlier I _assume_ there is a glitch in the NTP
    > code which doesn't convert or interpolate the Windows time stamps
    > properly under Vista.
    >
    > I'll try to find out more.
    >
    > Martin


    I find it difficult to judge the results in comparison with mine as the
    timescales cover a rather different range, but the message is clear -
    under Vista (your 64-bit or my 32-bit) timekeeping with NTP is orders of
    magnitude worse than it should be. It might be interesting to try
    disabling the interpolation, and see if that improves things. I'd try
    that here is only I could get NTP to compile with Visual Studio 2005! If
    you have a version you want me to test on Vista 32-bits here, just let me
    know.

    I do appreciate your efforts with this.

    Cheers,
    David



  10. Re: Dual-core systems - AMD - Windows Vista

    David J Taylor wrote:
    > Danny Mayer wrote:
    > []
    >> With VS 2005, just open the dsw file and tell it to convert all the
    >> project files. I recently add the necessary macros to the dsp files so
    >> that I don't have to add a bunch of macros every time I pull in a new
    >> tarball. I'm only building on VS 2005 these days. Building on VS 6 I
    >> reserve for releasing builds.
    >>
    >> We don't ship the OpenSSL sources due to possible export regulations.
    >> You can download that yourself from the openssl.org site. Just follow
    >> the build instructions for Windows. I use the nt suboption.

    >
    > Thanks, Danny.
    >
    > I have now downloaded the OpenSSL sources, however, the file
    > openssl/evp.h which ntp needs is not in a directory called "openssl", but
    > in a directory called "crypto". Confusingly, in the project options you
    > have a directory setting of: "$(OPENSSL)\inc32", and I see no inc32
    > directory in the OpenSSL tree. I also seem to have trouble finding the
    > build instructions you mentioned.
    >


    You need to run the OpenSSL build first to create that directory. Just
    follow the instructions.

    Danny
    > Cheers,
    > David


  11. Re: Dual-core systems - AMD - Windows Vista

    Martin Burnicki wrote:
    >
    > Hm, the process CPU affinity is not restricted to a single CPU. Ntpd has 4
    > active threads, and only the CPU affinity of the clock interpolation thread
    > is restricted to the first CPU since this is the only thread which calls
    > QueryPerformanceCounter() and thus potentially reads the TSC of the CPU it
    > is running on. The other threads may still run on either CPU.
    >
    > I'm not aware of a tool which displays the CPU affinity of a single thread,
    > so I don't know right now how you can verify this, except by looking at the
    > source code.
    >


    I have a vague recollection of seeing one, but I don't remember where.
    I'll try and see what I can dig up.

    Danny

  12. Re: Dual-core systems - AMD - Windows Vista

    Danny Mayer wrote:
    []
    > You need to run the OpenSSL build first to create that directory. Just
    > follow the instructions.
    >
    > Danny


    Danny,

    I'm afraid the build didn't work for me, so I tried creating a directory
    "openssl" in the ntp tree, and copied 33 header files from the OpenSSL
    tree. Having done that, I got hundreds of compiler warnings about a
    variety of topics (but not missing files), however, a .LIB file was
    missing presumably because of the failed buld.

    I find this in so many C/C++ projects - warnings which the author says to
    "ignore those". But the missing Lib file is a fatal error. I really
    would prefer not to write this off, so can you please:

    - tell me how the environment should be defined so that there is no need
    to create the "openssl" directory and copy the headers there (I had
    expected an entry in the ntp project definition). What is $(OPENSSL) on
    your system? Perhaps I can match it on mine?

    - send the missing LIB file? It's \out32dll\libeay32.lib

    I'd love to help on this, but I am struggling!

    Cheers,
    David



  13. Re: Dual-core systems - AMD - Windows Vista

    Martin Burnicki writes:

    [...]
    > The test machine is a Intel Pentium D 3 GHz (dual core) with Windows Vista
    > x64. Data of the time synchronization performance was collected by the time
    > adjustment service which comes with the Meinberg driver package for
    > Windows. That service computes the difference between the Windows system
    > time and a built-in GPS170PCI card and normally disiplines the system time.
    > However, in order to test the accuracy of NTP the Meinberg time service was
    > configured just to collect data and not to apply any correnctions to the
    > system time.

    [...]
    What you probably need in addition is a random burst of CPU load (These new
    cores change voltage and clock rate depending on the load). I don't know
    a script for that, but manipulating a larger image in some image processor
    usually does the job...

    Regards,
    Ulrich

  14. Re: Dual-core systems - AMD - Windows Vista

    David,

    David J Taylor wrote:
    > I find it difficult to judge the results in comparison with mine as the
    > timescales cover a rather different range, but the message is clear -
    > under Vista (your 64-bit or my 32-bit) timekeeping with NTP is orders of
    > magnitude worse than it should be. It might be interesting to try
    > disabling the interpolation, and see if that improves things. I'd try
    > that here is only I could get NTP to compile with Visual Studio 2005! If
    > you have a version you want me to test on Vista 32-bits here, just let me
    > know.


    There's now a new graph recorded under 32 bit Vista:
    http://www.meinberg.de/download/ntp/...s-vista-32.pdf

    The first section is with maxpoll 6, and in the second part maxpoll has been
    reduced to 4, which does not seem to eliminate the reason for the jitter,
    but the magnitude.

    > I do appreciate your efforts with this.


    Thanks. We all want NTP to discipline even the Windows system time as good
    as possible.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  15. Re: Dual-core systems - AMD - Windows Vista

    Hi Ulrich,

    Ulrich Windl wrote:
    > Martin Burnicki writes:
    >
    > [...]
    >> The test machine is a Intel Pentium D 3 GHz (dual core) with Windows
    >> Vista x64. Data of the time synchronization performance was collected by
    >> the time adjustment service which comes with the Meinberg driver package
    >> for Windows. That service computes the difference between the Windows
    >> system time and a built-in GPS170PCI card and normally disiplines the
    >> system time. However, in order to test the accuracy of NTP the Meinberg
    >> time service was configured just to collect data and not to apply any
    >> correnctions to the system time.

    > [...]
    > What you probably need in addition is a random burst of CPU load (These
    > new cores change voltage and clock rate depending on the load). I don't
    > know a script for that, but manipulating a larger image in some image
    > processor usually does the job...


    You're right. That's an additional constraint which has to be taken into
    account. The bad thing is that those tests are pretty time-consuming ...

    Regards,

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  16. Re: Dual-core systems - AMD - Windows Vista

    Martin Burnicki wrote:
    []
    > There's now a new graph recorded under 32 bit Vista:
    > http://www.meinberg.de/download/ntp/...s-vista-32.pdf
    >
    > The first section is with maxpoll 6, and in the second part maxpoll
    > has been reduced to 4, which does not seem to eliminate the reason
    > for the jitter, but the magnitude.
    >
    >> I do appreciate your efforts with this.

    >
    > Thanks. We all want NTP to discipline even the Windows system time as
    > good as possible.
    >
    > Martin


    Thanks, Martin. The graph looks a little more like mine now - almost like
    two frequencies beating together with periods of large swing followed by
    periods of stability. It surprises me that in the maxpoll = 6 part, the
    "tick" value doesn't swing more. I would have thought that once an offset
    near zero was reached, the tick value would start to swing between the two
    best values.

    Can you try with the interpolation removed, in case it shows anything?

    Cheers,
    David



  17. Re: Dual-core systems - AMD - Windows Vista

    David,

    Don't look in the NTP distribution for interpolation code; that's in the
    kernel, for the Alpha the nanokernel code. All the code there, by the
    way, is in C for portability. By the way, I see that code is no longer
    available via http, only anonymous ftp.

    Dave

    David J Taylor wrote:
    > David L. Mills wrote:
    >
    >>David,
    >>
    >>The multiple-CPU nanokernel code that left here and is in the Alpha
    >>kernel assumes each CPU has an individual cycle counter and the timer
    >>interupts are vectored to a designated CPU. There is a data structure
    >>associated with each CPU that holds the measured current cycle counter
    >>scaling and offset, which is updated once each second by
    >>interprocessor interrrupt. A call to read the system clock lands on a
    >>j-random CPU, which reads the global time maintained by timer
    >>interrupts and interpolates according to the current CPU values.
    >>
    >>I don't know if Vista attempts to provide granularity within the tick;
    >>but if it does, I would expect it to use a similar strategy.
    >>
    >>Dave

    >
    >
    > Thanks for that, Dave. I haven't needed to touch assembler for a little
    > wile now, so I'm not up to speed on whether the various Intel and AMD
    > architectures (hyper-threading, dual/quad-core, and physical
    > multi-processor etc.) provide access to every cycle counter from a single
    > CPU or executing thread.
    >
    > The Windows implementation does try to provide granularity within the
    > tick, but I have no idea how the Meinberg port I'm using handles
    > multi-processors. Checking. I see the routine: nt_clockstuff.c mentions
    > that how to handle multi-processors is not yet decided, but that seems
    > very old code (year 2000). I can't find the RDTSC instruction anywhere in
    > version ntp-4.2.4p4. So I'm a bit stuck right now!
    >
    > Cheers,
    > David
    >
    >


  18. Re: Dual-core systems - AMD - Windows Vista

    David L. Mills wrote:
    > David,
    >
    > Don't look in the NTP distribution for interpolation code; that's in
    > the kernel, for the Alpha the nanokernel code. All the code there, by
    > the way, is in C for portability. By the way, I see that code is no
    > longer available via http, only anonymous ftp.
    >
    > Dave


    Dave,

    There is /an/ interpolation in the Windows code as well - in
    nt_clockstuff.c. Obviously not what you have in the Alpha kernel.

    I got the source from Udel via http:

    http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/
    => ntp-4.2.4p4.tar.gz

    Cheers,
    David



  19. Re: Dual-core systems - AMD - Windows Vista

    David J Taylor wrote:
    > David L. Mills wrote:
    >> David,
    >>
    >> Don't look in the NTP distribution for interpolation code; that's in
    >> the kernel, for the Alpha the nanokernel code. All the code there, by
    >> the way, is in C for portability. By the way, I see that code is no
    >> longer available via http, only anonymous ftp.
    >>
    >> Dave

    >
    > Dave,
    >
    > There is /an/ interpolation in the Windows code as well - in
    > nt_clockstuff.c. Obviously not what you have in the Alpha kernel.


    David (J. Taylor),

    Please take care. You and Dave (L. Mills) are talking about completely
    different things here.

    In most cases the OS system clock is counting timer ticks to keep the time.
    When an application reads the system time then a good OS returns the
    current time with a higher resolution than the timer tick interval, i.e. it
    returns a time based on the current timer tick count plus the current value
    of the time counter register which gives an idea whether time is at the
    beginning or the end of a timer tick interval, and thus is responsible for
    the resolution of the system clock, depending on the clock rate of that
    counter.

    The details depend on which time counter register is used for this purpose.
    If there's just a single register, e.g. in the chipset, then it's pretty
    easy to deal with it.

    If a CPU register is used to determine the time between 2 timer ticks and
    you have a SMP or multicore system then you must take care that either the
    time stamp is always taken from the same CPU/core, or the timers in all
    CPUs/cores are synchronized to each other so that it doesn't matter which
    CPU is being read.

    The nanokernel code mentioned by Dave takes care about registers in multiple
    CPUs, but as its name implies it is some code which needs to run in the
    kernel to be able to access the registers and provide a proper API to the
    application.

    If the M$ developers would pick up Dave's code and integrate it into the
    Windows kernel then Windows would probably be a good time keeper as well.

    However, Windows does not evaluate the current counter value at all, so the
    system time is just derived from the number of timer ticks, increases only
    when a timer tick occurs, and thus the resolution of the clock is limited
    to the timer tick interval (Vista seems to be slightly different, though).

    Since the Windows kernel source is not available, we can not apply Dave's
    code to increase the resolution of the Windows system clock since we are
    unable to modify the timekeeping code in the Windows kernel.

    That's why NTP uses a hack to try to increase the resolution from user
    space. Of course this is not as reliable and exact as a proper
    implementation in the kernel could be. However, it's better than just use
    the resolution provided by Windows. Also, as-is, the interpolated system
    time is not available to other applications.

    The clock interpolation code for Windows can only use standard API calls,
    e.g. the PerformanceCounter API. How this API behaves in detail depends on
    how it is implemented in the HAL. It can either use the CPUs' TSC
    registers, or use any other register which may be available with certain
    chipsets. This code does not try to synchronize the TSCs on different CPUs,
    it just tries to run always on the same CPU in order to avoid glitches due
    to different TSC values on different CPUs.


    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  20. Re: Dual-core systems - AMD - Windows Vista

    Martin Burnicki wrote:
    []
    > David (J. Taylor),
    >
    > Please take care. You and Dave (L. Mills) are talking about completely
    > different things here.

    []
    > Martin


    Thanks, Martin. Yes, I'm aware of the difference, but as both topics
    currently have the same name the source of the confusion remains. Perhaps
    we need a new name for what's done in Windows - "user-mode tick
    interpolation" perhaps as opposed to "kernel-mode interpolation"?

    Cheers,
    David



+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast