drift file set to -500 - NTP

This is a discussion on drift file set to -500 - NTP ; Much easier still, forget about the initial set and just add -g to the flag list when starting ntpd. If you need to have the clock in a "stable/sync'd" state before starting certain other servers, put a call to ntp-wait ...

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

Thread: drift file set to -500

  1. Re: drift file set to -500

    Much easier still, forget about the initial set and just add -g to the flag
    list when starting ntpd.

    If you need to have the clock in a "stable/sync'd" state before starting
    certain other servers, put a call to ntp-wait just before you want the
    sensitive processes started.

    H

  2. Re: drift file set to -500

    Kev,

    Do I recall you said you were using HZ=60? If so, I recommend trying HZ=100
    instead.

    If you look at your logfile output, are you seeing time steps of
    approximately the same amount at approximately the same time intervals?

    If not, you probably have interrupt or BIOS or some other external problem,
    because your time "skews" are non-uniform.

    If so, you want to look at the 'tickadj' program. There is also a script in
    the NTP distribution called calc_tickadj that might be helpful.

    H

  3. Re: drift file set to -500

    Aggie wrote:
    > David,
    >
    >> That sounds like a permissions error. I did see something similar in
    >> Windows some time back. On Windows, at least, you can read the
    >> ntp.drift file almost any time.

    >
    > Thank you very much. But I don't think it is a permission error,
    > because I'm using "target server" thing which allow me to connect to a
    > PC from my board, and then read and write files to the PC.
    >
    > Cheers,
    > Kev


    It was just a suggestion. By the way, I'm not at all sure what you mean
    by "target server" thing. Something which allows you to view files, I
    guess. Might want to check it opens files with read-only access.

    Cheers,
    David



  4. Re: drift file set to -500

    Harlan,

    I have been usign the -g option everytime i run ntpd.

    > Do I recall you said you were using HZ=60? If so, I recommend trying HZ=100 instead.


    Ok, I will try that tomorrow. I'm testing how many second I gain
    without runninig ntpd. Btw, what is the HZ for? what does it do?

    > If you look at your logfile output, are you seeing time steps of approximately the same amount at approximately the same time intervals?


    Where do I check the time step? please give me know instruction for
    this.

    ===
    Thanks Harlan, I will look into the tickadj function. Oh, I'm
    wondering if the statistics files are correct when the drift file
    reached 500 and then back to -500.

    I have been recording the statistics file over the past couple days,
    but the value in the drift change from 500 to -500. I do not believe
    it's a gradual increase/decrease. It seems to me it's a jump, because
    i didn't have ntp.drift when i ran ntpd, but once ntp.drift was
    created, it had a value of 500.

    Thanks,
    Kev.




  5. Re: drift file set to -500

    Aggie wrote:
    > David,
    >> What happens if you delete the drift file and leave it for a few hours?

    >
    > After I deleted the drift file and left it run overnight, the drift
    > file was not created in the first couple hours and when I checked this
    > morning. ntp.drift and ntp.drift.TEMP were created. ntp.drift couldn't
    > be opened because ntp was using it. ntp.drifti.TEMP had a value of
    > +500. And NTPD is still running. But I believe NTPD will stop
    > eventually, same as what happened before.
    >
    > Thanks,
    > Kev.
    >


    Sounds as though you had 2 copies of ntpd running. Not sure how, but
    that seems like what you are describing here.

  6. Re: drift file set to -500


    >I don't think it's a hardware product defect. Because we have two of
    >them, and we had run the same test on both of the board, we still got
    >the same error. Thanks,


    There are two kinds of hardware (or software) errors. One is a design
    error. The problem happens all the time on all units. The other type
    is something like a broken something. If you use that something, you
    will get the wrong answer.

    Getting the same result on two board doesn't rule out design errors.
    Neither does it help you determine if the problem is hardware or
    software.


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


  7. Re: drift file set to -500

    Aggie,

    Aggie wrote:
    > Harlan,
    >
    > I have been usign the -g option everytime i run ntpd.


    This is only to allow a large initial time offset to be accepted by ntpd.
    Normally ntpd stops itself if the time offset exceeds ~1000 seconds, and
    adds a warning to the syslog saying you should first set the system time
    manually to approximately the right time.

    >> Do I recall you said you were using HZ=60? If so, I recommend trying
    >> HZ=100 instead.

    >
    > Ok, I will try that tomorrow. I'm testing how many second I gain
    > without runninig ntpd. Btw, what is the HZ for? what does it do?


    HZ is a constant value indicating how many timer tick interrupts occur per
    second. On a Unix-like system you can modify that value and recompile the
    kernel to change the timer tick rate according to your needs.

    HZ=60 should yield a timer tick interval of 16.667 ms. Many Linux systems
    run with HZ=100, and Windows usually has a timer tick interval of 15.625 ms
    which is ~1/64Hz. I'm absolutely not familiar with VxWorks, so I don't know
    whether it's more like Windows, more like Unix, or whatever, and whether
    the timer tick rate can be changed in VxWorks.

    >> If you look at your logfile output, are you seeing time steps of
    >> approximately the same amount at approximately the same time intervals?

    >
    > Where do I check the time step? please give me know instruction for
    > this.


    If VxWorks provides a logging mechanism like syslog under Unix, or the event
    log under Windows, you should see the log messages there. If you have
    configured ntpd to write to its own log file (if that's supported under
    VxWorks) then you should look at that file.

    Every time ntpd steps the time a "time reset" message is generated, followed
    by a "synchronization lost" message because ntpd resets its internal
    filters.

    Having a look at the loopstats, and how the offset develops, might give us
    more clues ...

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  8. Re: drift file set to -500

    Harlan,

    I changed hz to 100 and ran it overnight yesterday. It seemed like it
    had affect on the drift file problem, because normally the drift file
    would have already been created after 10 hrs, and complained about 500
    value in the drift file. But now the drift file still has not been
    created yet, and I haven't seen any complain.

    I'm wondering when drift file will be created. //I have been running
    it for ~ 24 hrs.

    Thanks,
    Kevin Lam

  9. Re: drift file set to -500

    Aggie wrote:
    > Harlan,
    >
    > I changed hz to 100 and ran it overnight yesterday. It seemed like it
    > had affect on the drift file problem, because normally the drift file
    > would have already been created after 10 hrs, and complained about 500
    > value in the drift file. But now the drift file still has not been
    > created yet, and I haven't seen any complain.
    >
    > I'm wondering when drift file will be created. //I have been running
    > it for ~ 24 hrs.
    >
    > Thanks,
    > Kevin Lam


    I though it was about one hour before the drift file was created? Perhaps
    you have identified another symptom?

    Cheers,
    David



  10. Re: drift file set to -500

    Aggie wrote:
    > Harlan,
    >
    > I changed hz to 100 and ran it overnight yesterday. It seemed like it
    > had affect on the drift file problem, because normally the drift file
    > would have already been created after 10 hrs, and complained about 500
    > value in the drift file. But now the drift file still has not been
    > created yet, and I haven't seen any complain.
    >
    > I'm wondering when drift file will be created. //I have been running
    > it for ~ 24 hrs.
    >
    > Thanks,
    > Kevin Lam


    The reference implementation of ntpd is supposed to create/write a drift
    file at intervals of one hour. Be certain that the account you use to
    run ntp has the necessary rights to create a file and/or that the
    directory you specified as the location for the file has permissions set
    to allow writing such a file. It works for me, has for years now!


  11. Re: drift file set to -500

    I think I found out where the problem is.

    VxWorks doesn't have adjtime( ), and the one we wrote wasn't doing
    anything. That's what makes the drift to increase to +500 (I think).
    Does that make sense??

    We would like to know what adjtime( ) actually does, so we can rewrite
    it for VxWorks correctly.

    Thanks,
    Kev.

  12. Re: drift file set to -500

    Aggie wrote:
    > I think I found out where the problem is.
    >
    > VxWorks doesn't have adjtime( ), and the one we wrote wasn't doing
    > anything. That's what makes the drift to increase to +500 (I think).
    > Does that make sense??
    >
    > We would like to know what adjtime( ) actually does, so we can rewrite
    > it for VxWorks correctly.
    >
    > Thanks,
    > Kev.


    Here is a man page for adjtime(2) from one OS. On Linux see adjtimex(2).

    NAME

    adjtime - Correct the time to allow synchronization of the system clock

    SYNOPSIS

    #include

    int adjtime(
    struct timeval *delta,
    struct timeval *old_delta );

    PARAMETERS

    delta
    Points to the amount of time to be altered.

    old_delta
    Points to the number of nanoseconds still to be corrected from an ear-
    lier call.
    DESCRIPTION

    The adjtime() function makes small adjustments to the system time (as
    returned by the gettimer() function), advancing or decreasing it by the
    time specified by the delta parameter of the timeval structure. If delta is
    negative, the clock is slowed down by incrementing it more slowly than nor-
    mal until the correction is complete. If delta is positive, a larger incre-
    ment than normal is used until the correction is complete.

    The skew used to perform the correction is generally a fraction of one per-
    cent. Thus, the time is always a monotonically increasing function.

    A time correction from an earlier call to adjtime() may not be finished
    when adjtime() is called again. In this case, the delta remaining from the
    original call is replaced by the delta of the current call. If the
    old_delta parameter is nonzero, then when the adjtime() function returns,
    the structure pointed to will contain the time remaining from the earlier
    call.

    This call may be used by time servers that synchronize the clocks of com-
    puters in a local area network. Such time servers would slow down the
    clocks of some machines and speed up the clocks of others to bring them to
    the average network time. The adjtime() function is restricted to users
    with the superuser privilege.

    NOTES

    In BSD, system time is defined in units of seconds and microseconds, while
    in POSIX real time extensions, the units are seconds and nanoseconds. How-
    ever, the adjtime() function is not specified by POSIX. Therefore, the
    existing BSD interface is preserved.

    RETURN VALUES

    On successful completion, the adjtime() function returns 0 (zero). If the
    adjtime() function fails, it returns -1 and sets errno to indicate the
    error.

    ERRORS

    If the adjtime() function fails, errno may be set to one of the following
    values:

    [EFAULT]
    An argument address referenced invalid memory.
    [EPERM]
    The process's effective user ID does not have appropriate system
    privilege.

    SEE ALSO

    Functions: gettimeofday(2), gettimer(3)


  13. Re: drift file set to -500

    >>> In article <179636c7-4680-4369-870c-bc3f01c1800b@e6g2000prf.googlegroups.com>, Aggie writes:

    Aggie> Harlan, I changed hz to 100 and ran it overnight yesterday. It seemed
    Aggie> like it had affect on the drift file problem, because normally the
    Aggie> drift file would have already been created after 10 hrs, and
    Aggie> complained about 500 value in the drift file. But now the drift file
    Aggie> still has not been created yet, and I haven't seen any complain.

    Kevin,

    The drift file should be created within an hour.

    If it is not, it means your ntpd has not sync'd, as with recent -dev
    releases the drift file will not be written if the clock is not sync'd.

    What does 'ntpq -p' show?

    H
    --
    http://ntpforum.isc.org - be a member!

  14. Re: drift file set to -500

    >>> In article , Aggie writes:

    Aggie> I think I found out where the problem is. VxWorks doesn't have
    Aggie> adjtime( ), and the one we wrote wasn't doing anything. That's what
    Aggie> makes the drift to increase to +500 (I think). Does that make
    Aggie> sense??

    It makes perfect sense.

    Aggie> We would like to know what adjtime( ) actually does, so we can
    Aggie> rewrite it for VxWorks correctly.

    Have you seen http://support.ntp.org/Dev/VxWorksPortingIssues ?

    H
    --
    http://ntpforum.isc.org - be a member!

  15. Re: drift file set to -500


    >Yes. And one missing step:
    >
    >After stopping ntpd, "ntpdate -b [server]".
    >
    >The single most common cause of a large negative drift value
    >is a system whose clock has not been initialized before starting
    >ntpd (or has been stopped during a large time adjustment).


    What vintage of ntpd are you using?

    I've never had any problems starting ntpd when using the -g switch.


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


  16. Re: drift file set to -500

    Aggie wrote:
    > I think I found out where the problem is.
    >
    > VxWorks doesn't have adjtime( ), and the one we wrote wasn't doing
    > anything. That's what makes the drift to increase to +500 (I think).
    > Does that make sense??
    >
    > We would like to know what adjtime( ) actually does, so we can rewrite
    > it for VxWorks correctly.
    >


    As I said in a previous post there is an implementation of adjtime() in
    the distribution. Why not just use that?

    Danny
    > Thanks,
    > Kev.


  17. Re: drift file set to -500

    Hal Murray wrote:
    >> Yes. And one missing step:
    >>
    >> After stopping ntpd, "ntpdate -b [server]".
    >>
    >> The single most common cause of a large negative drift value
    >> is a system whose clock has not been initialized before starting
    >> ntpd (or has been stopped during a large time adjustment).

    >
    > What vintage of ntpd are you using?
    >
    > I've never had any problems starting ntpd when using the -g switch.
    >
    >


    Every vintage from 3.4.x to 4.2.x, but the earlier ones get stuck at
    values beyond +-500.

  18. Re: drift file set to -500

    On Nov 30, 11:24 pm, Harlan Stenn wrote:
    > >>> In article , Aggie writes:

    >
    > Aggie> I think I found out where the problem is. VxWorks doesn't have
    > Aggie> adjtime( ), and the one we wrote wasn't doing anything. That's what
    > Aggie> makes the drift to increase to +500 (I think). Does that make
    > Aggie> sense??
    >
    > It makes perfect sense.
    >
    > Aggie> We would like to know what adjtime( ) actually does, so we can
    > Aggie> rewrite it for VxWorks correctly.
    >
    > Have you seenhttp://support.ntp.org/Dev/VxWorksPortingIssues?
    >
    > H
    > --http://ntpforum.isc.org - be a member!


    Harlan,
    I have seen the VxWorks Porting Issues on ntp.org. I have used the
    adjtime() in the package, but it doesn't do anything. Do anyone have
    successfully use this adjtime() in vxworks?

    Thanks,
    K

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2