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

This is a discussion on no ntp synchronisation: 2s to 6s time shift ! - NTP ; Hi Thierry, Thierry MARTIN wrote: > Maybe I should look for a pci board that is able to keep good time - > even with offset but limited drift- with no external time source... > If anyone has ever heard ...

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

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

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

    Hi Thierry,

    Thierry MARTIN wrote:
    > Maybe I should look for a pci board that is able to keep good time -
    > even with offset but limited drift- with no external time source...
    > If anyone has ever heard of this...


    http://www.meinberg.de/english/products/gps170pci.htm
    http://www.meinberg.de/english/products/tcr167pci.htm

    OK, I'm biased ;-) ...

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

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

    Thierry MARTIN wrote:
    > Hello Serge,
    >
    > You're right! I missed the -b option in ntpdate.
    >
    > > That's very doable, but requires some amounts of efforts. ;-)

    > I understand that.
    >
    > The system is a "transportable" system. It is used to mesure some
    > transmission time over a network (packets contain utc timestamp
    > themselves). It can be moved to different sites in the network.
    >


    >
    > Maybe I should look for a pci board that is able to keep good time -
    > even with offset but limited drift- with no external time source...
    > If anyone has ever heard of this...




    Both Meinburg Funkuhren and Symmetricomm offer PCI cards with "super
    clocks". An Oven Controlled Crystal Oscillator (OCXO) is available on
    these cards for a premium price. The oscillator can, I believe, be GPS
    disciplined on either card.

    Be prepared for "sticker shock"! These cards cost around $1200 US the
    last time I looked and they may cost more now. I have occasionally seen
    them for less on e-Bay but that's not something you can count on finding
    when you want it.


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

    Hi Martin,

    It seems that once again, you're about to save me ;-) !
    So, ok my system has a Meinberg gps170pci board.

    As far as I can remember, when GPS signal is not there, NTP does not use
    GPS refclock as a timesource.

    So i guess, you suggest that I use the DCF77 emulation or some other
    feature from the board?
    Could you please enlight me about this?

    Thanks!
    Thierry MARTIN



    Martin Burnicki a écrit :
    > Hi Thierry,
    >
    > Thierry MARTIN wrote:
    >> Maybe I should look for a pci board that is able to keep good time -
    >> even with offset but limited drift- with no external time source...
    >> If anyone has ever heard of this...

    >
    > http://www.meinberg.de/english/products/gps170pci.htm
    > http://www.meinberg.de/english/products/tcr167pci.htm
    >
    > OK, I'm biased ;-) ...
    >
    > Martin


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

    Thierry,

    Thierry MARTIN wrote:
    > Hi Martin,
    >
    > It seems that once again, you're about to save me ;-) !


    ;-))

    > So, ok my system has a Meinberg gps170pci board.
    >
    > As far as I can remember, when GPS signal is not there, NTP does not use
    > GPS refclock as a timesource.


    By default not. This is because ntpd sees the board's "not synchronized"
    status.

    > So i guess, you suggest that I use the DCF77 emulation or some other
    > feature from the board?
    > Could you please enlight me about this?


    It's much easier. You run Linux, don't you?

    The kernel module which lets ntpd use the card as reference time source can
    be loaded with a parameter which overrides the real board status and always
    tells ntpd the card is synchronized. Just load the module with the
    following parameter:

    modprobe mbgclock pretend_sync=1

    Of course this parameter should only be used for testing.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

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

    I will try this.


    Martin Burnicki a écrit :
    > Thierry,
    >
    > Thierry MARTIN wrote:
    >> Hi Martin,
    >>
    >> It seems that once again, you're about to save me ;-) !

    >
    > ;-))
    >
    >> So, ok my system has a Meinberg gps170pci board.
    >>
    >> As far as I can remember, when GPS signal is not there, NTP does not use
    >> GPS refclock as a timesource.

    >
    > By default not. This is because ntpd sees the board's "not synchronized"
    > status.
    >
    >> So i guess, you suggest that I use the DCF77 emulation or some other
    >> feature from the board?
    >> Could you please enlight me about this?

    >
    > It's much easier. You run Linux, don't you?
    >
    > The kernel module which lets ntpd use the card as reference time source can
    > be loaded with a parameter which overrides the real board status and always
    > tells ntpd the card is synchronized. Just load the module with the
    > following parameter:
    >
    > modprobe mbgclock pretend_sync=1
    >
    > Of course this parameter should only be used for testing.
    >
    > Martin


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

    Ryan Malayter wrote:
    > 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.


    No need to look. I haven't had the bandwidth to get much done in the
    last few months. Needless to say it will be much easier to implement on
    Windows than on Unix machines as Windows uses threads so there's no
    issue with the transfer of information between processes.

    Danny

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

    On Sat, 23 Feb 2008 23:38:09 GMT, Danny Mayer wrote:
    >
    > No need to look. I haven't had the bandwidth to get much done in the
    > last few months. Needless to say it will be much easier to implement on
    > Windows than on Unix machines as Windows uses threads so there's no
    > issue with the transfer of information between processes.


    Why are threads not used on UNIX?
    /hjj

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

    Hans Jørgen Jakobsen wrote:
    > On Sat, 23 Feb 2008 23:38:09 GMT, Danny Mayer wrote:
    >
    >>No need to look. I haven't had the bandwidth to get much done in the
    >>last few months. Needless to say it will be much easier to implement on
    >>Windows than on Unix machines as Windows uses threads so there's no
    >>issue with the transfer of information between processes.

    >
    >
    > Why are threads not used on UNIX?
    > /hjj


    I've never used them but I believe that Solaris supports threads.


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

    In article <47C19D56.9010305@comcast.net>,
    "Richard B. Gilbert" wrote:

    > Hans Jørgen Jakobsen wrote:
    > > On Sat, 23 Feb 2008 23:38:09 GMT, Danny Mayer wrote:
    > >
    > >>No need to look. I haven't had the bandwidth to get much done in the
    > >>last few months. Needless to say it will be much easier to implement on
    > >>Windows than on Unix machines as Windows uses threads so there's no
    > >>issue with the transfer of information between processes.

    > >
    > >
    > > Why are threads not used on UNIX?
    > > /hjj

    >
    > I've never used them but I believe that Solaris supports threads.


    True. IRIX (SGI) and AIX (IBM) also support threaded applications.

    The Solaris kernel is also itself threaded. I think this is true of
    IRIX and AIX. The HP-UX kernel is not threaded, although threaded
    applications are supported.

    These are the OSs I know something of.

    Joe Gwinn

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

    Hans Jørgen Jakobsen wrote:
    > On Sat, 23 Feb 2008 23:38:09 GMT, Danny Mayer wrote:
    >> No need to look. I haven't had the bandwidth to get much done in the


    >> last few months. Needless to say it will be much easier to implement on


    >> Windows than on Unix machines as Windows uses threads so there's no


    >> issue with the transfer of information between processes.

    >


    > Why are threads not used on UNIX?
    > /hjj


    The experience with BIND 9 shows that various implementations of

    pthreads are flawed and therefore compiling BIND9 with threads remains

    an option. While I am willing to undertake the work to use threads it's

    a much harder problem to make it optional.

    Danny

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

    Danny Mayer wrote:
    > Hans Jørgen Jakobsen wrote:
    >> Why are threads not used on UNIX?
    >> /hjj

    >
    > The experience with BIND 9 shows that various implementations of
    > pthreads are flawed and therefore compiling BIND9 with threads remains
    > an option. While I am willing to undertake the work to use threads it's
    > a much harder problem to make it optional.


    Hm, I'd really like to know what the limitations/problems with pthread are.

    I'm assuming BIND would make heavy usage of threads, whereas ntpd would
    basically only have to start one other thread to do the DNS lookups (except
    the special Windows things, which have already been implemented as
    threads).

    There are no special requirements except for blocking critical sections
    while some parameters are updated.

    This would also simplify a fix for bug #987: http://bugs.ntp.org/987


    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

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

    Martin Burnicki wrote:
    > Danny Mayer wrote:
    >> Hans Jørgen Jakobsen wrote:
    >>> Why are threads not used on UNIX?
    >>> /hjj

    >> The experience with BIND 9 shows that various implementations of
    >> pthreads are flawed and therefore compiling BIND9 with threads remains
    >> an option. While I am willing to undertake the work to use threads it's
    >> a much harder problem to make it optional.

    >


    > Hm, I'd really like to know what the limitations/problems with pthread ar

    e.
    >


    > I'm assuming BIND would make heavy usage of threads, whereas ntpd would
    > basically only have to start one other thread to do the DNS lookups (exce

    pt
    > the special Windows things, which have already been implemented as
    > threads).
    >



    Yes.

    > There are no special requirements except for blocking critical sections
    > while some parameters are updated.


    >



    Yes.

    > This would also simplify a fix for bug #987: http://bugs.ntp.org/987
    >



    Yes.

    Danny
    >


    > Martin


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2