Local Time - NTP

This is a discussion on Local Time - NTP ; Can NTP be configured to serve the local time to hosts on our network? I understand that this isn't something we "want" to do... but it really is. Is there some type of offset or something similar to do this. ...

+ Reply to Thread
Results 1 to 19 of 19

Thread: Local Time

  1. Local Time

    Can NTP be configured to serve the local time to hosts on our network?

    I understand that this isn't something we "want" to do... but it
    really is.

    Is there some type of offset or something similar to do this. I
    haven't found anything in my perusal of the docs.


  2. Re: Local Time

    wiechman.spam@gmail.com wrote:
    > Can NTP be configured to serve the local time to hosts on our network?


    > I understand that this isn't something we "want" to do... but it
    > really is.


    > Is there some type of offset or something similar to do this. I
    > haven't found anything in my perusal of the docs.


    NTP uses UTC period.

    Most systems keep internal time in UTC and I am hard pressed to think
    of any recent system that doesn't.

    It is up to the system to convert UTC to local time.

    --
    Jim Pennino

    Remove .spam.sux to reply.

  3. Re: Local Time

    > From: wiechman.spam@gmail.com
    > Date: 14 Mar 2007 10:09:22 -0700
    > Sender: questions-bounces+oberman=es.net@lists.ntp.isc.org
    >
    > Can NTP be configured to serve the local time to hosts on our network?
    >
    > I understand that this isn't something we "want" to do... but it
    > really is.
    >
    > Is there some type of offset or something similar to do this. I
    > haven't found anything in my perusal of the docs.


    Ack! I can't imagine a reason good enough to do this, but you could use
    fudge, I suppose, and some clocks have the capability of having a time
    zone set into them.
    --
    R. Kevin Oberman, Network Engineer
    Energy Sciences Network (ESnet)
    Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
    E-mail: oberman@es.net Phone: +1 510 486-8634
    Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751

    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (FreeBSD)
    Comment: Exmh version 2.5 06/03/2002

    iD8DBQFF+C6Hkn3rs5h7N1ERApTDAKCA3alpQucPjOfllnxU+F Hwt6VL8QCdHdxr
    b/VmCZIJw+qJ4YzkVNev3cE=
    =p1be
    -----END PGP SIGNATURE-----


  4. Re: Local Time


    > Most systems keep internal time in UTC and I am hard pressed to think
    > of any recent system that doesn't.


    Just for the record.

    Unfortunately linux (at least the fedora flavor of it) has a bit or
    wrong-think creeping in, in this regard. The clock chip defaults to
    local time and the kernel knows the TZ offfset and has some
    compensation. Uhg.

    Obviously, for the sake of keeping sane, I've elected to have my
    system (virtually) located in England.

    -wolfgang
    --
    Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/

  5. Re: Local Time

    > From: "Wolfgang S. Rupprecht"
    > Date: Wed, 14 Mar 2007 11:18:23 -0700
    > Sender: questions-bounces+oberman=es.net@lists.ntp.isc.org
    >
    >
    > > Most systems keep internal time in UTC and I am hard pressed to think
    > > of any recent system that doesn't.

    >
    > Just for the record.
    >
    > Unfortunately linux (at least the fedora flavor of it) has a bit or
    > wrong-think creeping in, in this regard. The clock chip defaults to
    > local time and the kernel knows the TZ offfset and has some
    > compensation. Uhg.
    >
    > Obviously, for the sake of keeping sane, I've elected to have my
    > system (virtually) located in England.


    If Fedora keeps time anything like BSD, there is a flag that indicates
    that the hardware clock is set to local time and not UTC. But the kernel
    still operates on UTC. It simply uses the time zone information to set
    the hardware clock. (In FreeBSD it is dependent on the existence of
    /etc/wall_cmos_clock on the system.)

    But the system still uses UTC for everything except reading and writing
    the hardware clock and the offsets used are still controlled by the zone
    files.

    This was done for dual boot systems which need to boot Windows which
    sets the hardware clock to local time. I have this only for my laptop
    (which is dual boot) and all Unix-only systems have the hardware clock
    set to UTC.
    --
    R. Kevin Oberman, Network Engineer
    Energy Sciences Network (ESnet)
    Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
    E-mail: oberman@es.net Phone: +1 510 486-8634
    Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751

    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (FreeBSD)
    Comment: Exmh version 2.5 06/03/2002

    iD8DBQFF+EeBkn3rs5h7N1ERAp9ZAKCY1AkEF6Ro1tuLPKXgSF dFy9KtkQCdH6sJ
    hwuCnl3L1A9nNJoGUT4ECYk=
    =iCwk
    -----END PGP SIGNATURE-----


  6. Re: Local Time

    On Mar 14, 2:05 pm, ober...@es.net (Kevin Oberman) wrote:
    > > From: "Wolfgang S. Rupprecht"
    > > Date: Wed, 14 Mar 2007 11:18:23 -0700
    > > Sender: questions-bounces+oberman=es....@lists.ntp.isc.org

    >
    > > > Most systems keep internal time in UTC and I am hard pressed to think
    > > > of any recent system that doesn't.

    >
    > > Just for the record.

    >
    > > Unfortunately linux (at least the fedora flavor of it) has a bit or
    > > wrong-think creeping in, in this regard. The clock chip defaults to
    > > local time and the kernel knows the TZ offfset and has some
    > > compensation. Uhg.

    >
    > > Obviously, for the sake of keeping sane, I've elected to have my
    > > system (virtually) located in England.

    >
    > If Fedora keeps time anything like BSD, there is a flag that indicates
    > that the hardware clock is set to local time and not UTC. But the kernel
    > still operates on UTC. It simply uses the time zone information to set
    > the hardware clock. (In FreeBSD it is dependent on the existence of
    > /etc/wall_cmos_clock on the system.)
    >
    > But the system still uses UTC for everything except reading and writing
    > the hardware clock and the offsets used are still controlled by the zone
    > files.
    >
    > This was done for dual boot systems which need to boot Windows which
    > sets the hardware clock to local time. I have this only for my laptop
    > (which is dual boot) and all Unix-only systems have the hardware clock
    > set to UTC.
    > --
    > R. Kevin Oberman, Network Engineer
    > Energy Sciences Network (ESnet)
    > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
    > E-mail: ober...@es.net Phone: +1 510 486-8634
    > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
    >
    > application_pgp-signature_part
    > 1KDownload
    >
    > _______________________________________________
    > questions mailing list
    > questi...@lists.ntp.isc.orghttps://lists.ntp.isc.org/mailman/listinfo/questions


    We need ntp to serve out the local time. We have around 1500 wireless
    radios that don't provide the ability to set an offset. Not the end of
    the world, but then everything in the logs and elsewhere is dated in
    UTC which is a real pita - confuses the hell out of some of our
    installers.

    When you say use fudge... you mean what exactly?


  7. Re: Local Time

    On 2007-03-14, wiechman.spam@gmail.com wrote:
    > On Mar 14, 2:05 pm, ober...@es.net (Kevin Oberman) wrote:
    > [---=| Quote block shrinked by t-prot: 34 lines snipped |=---]




    Please think of the readers and trim the quoted material in your reply.

    > We need ntp to serve out the local time. We have around 1500 wireless
    > radios that don't provide the ability to set an offset. Not the end of
    > the world, but then everything in the logs and elsewhere is dated in
    > UTC which is a real pita - confuses the hell out of some of our
    > installers.


    NTP synchronizes computer clocks to a timebase.

    The most commonly used NTP timebase is UTC ("traceable to NIST") which
    is obtained from reference clocks (e.g. GPS, or WWVB) or from remote
    time servers (which are ultimately syncronized, possibly through other
    remote time servers, to a reference clock).

    But UTC is not the only timebase that you can use. Some applications use
    the Undisciplined Local Clock, or LocalCLK, as the timebase.

    One solution to your problem is to set up a dedicated (i.e. performs no
    other function) time server (on UNIX or a Unix-like OS) and set your
    hardware clock to the local time and then "synchronize" your ntpd to
    the LocalCLK.

    Prior to putting this system in to production I would calibrate the
    clock by allowing that ntpd to synchronize to some remote time servers
    (form several days) and calculate the correct PLL offset frequency
    (for the drift.file). During the calibration procedure it is important
    that the system is exposed to the ambient conditions of its operating
    environment.

    --
    Steve Kostecke
    NTP Public Services Project - http://ntp.isc.org/

  8. Re: Local Time

    Thanks... I'll try that. I am less worried about the time being
    correct within several milliseconds than I am with the local time
    being displayed in the logs as this helps our installers greatly when
    it comes to troubleshooting so this should work.


  9. Re: Local Time

    wiechman.spam@gmail.com wrote:

    > but then everything in the logs and elsewhere is dated in
    > UTC which is a real pita - confuses the hell out of some of our
    > installers.


    It all depends on your particular field I guess. In networking, I
    routinely encounter logs in local time (implicit and undocumented of
    course), which is a pita and confuses the hell out of me ;-)

    N

  10. Re: Local Time

    On 2007-03-14, wiechman.spam@gmail.com wrote:

    > Thanks... I'll try that. I am less worried about the time being
    > correct within several milliseconds


    Hardware clocks are well known to be less stable than a quartz wrist
    watch.

    Calibrating your clock for stand-alone operation is all about making
    sure that you have a stable timebase (i.e. 1 second is 1 second).

    --
    Steve Kostecke
    NTP Public Services Project - http://ntp.isc.org/

  11. Re: Local Time


    Steve Kostecke writes:
    > Hardware clocks are well known to be less stable than a quartz wrist
    > watch.


    Quartz wrist watches have their own temperature controlled oven. ;-)

    -wolfgang
    --
    Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/

  12. Re: Local Time

    wiechman.spam@gmail.com wrote:
    > Thanks... I'll try that. I am less worried about the time being
    > correct within several milliseconds than I am with the local time
    > being displayed in the logs as this helps our installers greatly when
    > it comes to troubleshooting so this should work.


    Usually logs show time in the local time, making use of the TZ settting
    to convert from internal time (UTC) to local time. Or you could just log
    in UTC. Don't get so hung up by local time, it's only meaningfull locally.

    Danny
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  13. Re: Local Time

    To re-phrase and amplify Steve's comments:

    Let's get back to basic principles. NTP propagates time through a
    pyramid of
    servers that are interconnected via a jittery network.

    If you feed in UTC at the top of the pyramid, then all the NTP servers
    tick
    to the UTC clock. This is generally considered to be the most common
    scenario.

    If you use a computer configured with LCL-CLK as the stratum-1 server
    at the top
    of the pyramid, then all the NTP servers synchronize to that LCL-CLK.
    Questions
    relating to this scenario pop up often in this newsgroup.

    But there's nothing at all in NTP that prevents you from feeding in
    your own
    flavour of time at the top of the pyramid. It's your decision. The
    only conditions
    are: firstly, your timesource should run at a rate close to 1 sec/sec;
    secondly,
    you must be absolutely certain that your NTP pyramid will never come
    into contact
    with other NTP servers that are running UTC (or vice versa; NTP
    servers that are
    running UTC should never come into contact with your 'contaminated'
    time).

    Statements like "NTP runs UTC - period" require qualification.

    Paul




  14. Re: Local Time

    > When you say use fudge... you mean what exactly?

    See http://en.wikipedia.org/wiki/Fudge_factor


  15. Re: Local Time

    wrote:
    >But there's nothing at all in NTP that prevents you from feeding in
    >your own
    >flavour of time at the top of the pyramid. It's your decision.


    If local time is used instead of UTC, DST change can be a small problem. If
    you kill ntp server, change time by 1 hour at the right moment, and restart
    ntpd, clients will not follow immediately. And in the autumn there could
    be ambiguous time stamps for one hour: you would not know if they refer to
    time before or after DST change.

  16. Re: Local Time

    On 15 Mrz., 11:26, kaukasoina703n7ds...@sci.fi (Petri Kaukasoina)
    wrote:

    > If local time is used instead of UTC, DST change can be a small problem. If
    > you kill ntp server, change time by 1 hour at the right moment, and restart
    > ntpd, clients will not follow immediately. And in the autumn there could
    > be ambiguous time stamps for one hour: you would not know if they refer to
    > time before or after DST change.


    I said that the timesource should advance at a rate close to 1 sec/
    sec.
    That rules out large (3,600 second), sudden discontinuities.

    Paul


  17. Re: Local Time

    On Wednesday 14 March 2007 20:51, wiechman.spam@gmail.com wrote:
    > We need ntp to serve out the local time. We have around 1500 wireless
    > radios that don't provide the ability to set an offset. Not the end of
    > the world, but then everything in the logs and elsewhere is dated in
    > UTC which is a real pita - confuses the hell out of some of our
    > installers.
    >


    In this situation I would personally hack the syslogger and do the offset
    there. That would be my personal choice. The syslogger can then read the
    offset from its etc or can receive it via a udp broadcast from the server.

    Different strokes for different folks, but remember, awful things happen to
    wizards who meddle with time. The odds that your decision will come back and
    bite you is rather large.




    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  18. Re: Local Time

    Paul.Croome@softwareag.com wrote:
    > To re-phrase and amplify Steve's comments:
    >
    > Let's get back to basic principles. NTP propagates time through a
    > pyramid of
    > servers that are interconnected via a jittery network.
    >
    > If you feed in UTC at the top of the pyramid, then all the NTP servers
    > tick
    > to the UTC clock. This is generally considered to be the most common
    > scenario.
    >
    > If you use a computer configured with LCL-CLK as the stratum-1 server
    > at the top
    > of the pyramid, then all the NTP servers synchronize to that LCL-CLK.
    > Questions
    > relating to this scenario pop up often in this newsgroup.
    >
    > But there's nothing at all in NTP that prevents you from feeding in
    > your own
    > flavour of time at the top of the pyramid. It's your decision. The
    > only conditions
    > are: firstly, your timesource should run at a rate close to 1 sec/sec;
    > secondly,
    > you must be absolutely certain that your NTP pyramid will never come
    > into contact
    > with other NTP servers that are running UTC (or vice versa; NTP
    > servers that are
    > running UTC should never come into contact with your 'contaminated'
    > time).
    >
    > Statements like "NTP runs UTC - period" require qualification.
    >
    > Paul
    >
    >
    >


    NTP "BELIEVES" that the time it is getting is UTC. If you feed it
    Eastern Slobovia Daylight Savings Time, that's what you will get. This
    is generally a REALLY BAD IDEA but someone might want to do it for
    reasons I have trouble imagining. If you do it, be careful to NEVER
    connect your network to a public network.


  19. Re: Local Time

    In article ,
    kaukasoina703n7dsjr7@sci.fi (Petri Kaukasoina) wrote:

    > If local time is used instead of UTC, DST change can be a small problem. If
    > you kill ntp server, change time by 1 hour at the right moment, and restart
    > ntpd, clients will not follow immediately. And in the autumn there could


    They won't follow at all. All the client NTP daemons will terminate because
    their only server is in error by more than 1000 seconds.

+ Reply to Thread