different request pattern - NTP

This is a discussion on different request pattern - NTP ; hi! when i implemented my own ntp client, i found, that modern clocks (acpi) have a quite stable drift... even when the cpu frequency changes a lot... so i could achieve quite good results with 5000 seconds between each request ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: different request pattern

  1. different request pattern

    hi!

    when i implemented my own ntp client, i found, that modern clocks
    (acpi) have a quite stable drift... even when the cpu frequency
    changes a lot...

    so i could achieve quite good results with 5000 seconds between each
    request and just one request at a time... with 5 servers i ask each
    server once in 25000 seconds... if a server is a false ticker i can c
    it when i compare the "offset per second" (ops) to previous ops of
    this server and the other servers... i c typical offsets of below 10ms
    using an adsl line with round-trip times of about 60ms...

    wouldn't that help to reduce the load on the ntp servers?
    at least if leaf nodes would do it like that (just in case that my
    algorithm leads to less accurate time)...?

    then i found that the official ntpd algorithm doesnt propagate false
    tickers to its clients fast enough, so that they start building a
    strange average offset (instead of overruling the bad source) and show
    the old (false ticker) refid or even a completely messed up refid in
    "ntpq -pn"... but possibly that server is not maintained so good,
    although it is run by a university...

    bye
    arne

  2. Re: different request pattern

    arne_woerner@yahoo.com wrote:
    >
    > when i implemented my own ntp client, i found, that modern clocks
    > (acpi) have a quite stable drift... even when the cpu frequency
    > changes a lot...


    What you are describing is an SNTP client, not an NTP one.

  3. Re: different request pattern

    arne_woerner@yahoo.com wrote:

    > it when i compare the "offset per second" (ops) to previous ops of


    What is "offset per second"?

    >
    > then i found that the official ntpd algorithm doesnt propagate false
    > tickers to its clients fast enough, so that they start building a


    I don't believe you are describing "false tickers" in the NTP sense. My
    guess is that you are assuming a lower rate of dispersion than NTP
    and/or assuming that the asymmetry of the propagation delays is limited
    to a lot less than 100%.

  4. Re: different request pattern

    On Jun 30, 8:15 pm, David Woolley
    wrote:
    > arne_woer...@yahoo.com wrote:
    > > it when i compare the "offset per second" (ops) to previous ops of

    >
    > What is "offset per second"?
    >

    oh - i mean:
    1. "offset" in the sense of "ntpq"... estimated offset to the server
    clock...
    and
    2. "offset per second" describes the estimated offset-difference after
    a second...
    i compute it like this (dont laugh :-) ):
    (adjtime_offsets + estimated_offset_to_server_X)/T
    let T be the time when the offset to server X was 0
    let adjtime_offsets be the sum of the adjtime() offsets in the last T
    seconds...

    > > then i found that the official ntpd algorithm doesnt propagate false
    > > tickers to its clients fast enough, so that they start building a

    >
    > I don't believe you are describing "false tickers" in the NTP sense. My
    > guess is that you are assuming a lower rate of dispersion than NTP
    > and/or assuming that the asymmetry of the propagation delays is limited
    > to a lot less than 100%.
    >

    hal (dot) ikw (dot) Uni (dash) Osnabrueck (dot) DE. (A) had that
    problem for some days:
    2 servers(+) had an offset of about +20ms and the *-server had an
    offset of about -10ms...
    this continued for days, even though the refid of the *-server
    referred to a false ticker
    (server marked with an "x")...
    i think A's ntpd is old...
    the consequence was that A's "ops" value was rather consistent within
    A's ops-history,
    but not consistent with the sample of the previous server...

    -arne

  5. Re: different request pattern

    arne_woerner@yahoo.com wrote:

    > 2. "offset per second" describes the estimated offset-difference after
    > a second...
    > i compute it like this (dont laugh :-) ):
    > (adjtime_offsets + estimated_offset_to_server_X)/T
    > let T be the time when the offset to server X was 0
    > let adjtime_offsets be the sum of the adjtime() offsets in the last T
    > seconds...


    That seems to me to be an estimate of the local machine's clock
    frequency, evaluated over an excessively short period in relation to
    network timing jitter. 10ms/s would be 10,000 parts per million, which
    is much much higher than you would get even from a real false ticker,
    and could only really represent the result of jitter. On a heavily
    loaded connection, traffic variations can results in offsets varying by
    hundreds of milliseconds (relative to true time).

  6. Re: different request pattern

    On Jul 1, 7:10 am, David Woolley
    wrote:
    > arne_woer...@yahoo.com wrote:
    > > 2. "offset per second" describes the estimated offset-difference after
    > > a second...
    > > i compute it like this (dont laugh :-) ):
    > > (adjtime_offsets + estimated_offset_to_server_X)/T
    > > let T be the time when the offset to server X was 0
    > > let adjtime_offsets be the sum of the adjtime() offsets in the last T
    > > seconds...

    >
    > That seems to me to be an estimate of the local machine's clock
    > frequency, evaluated over an excessively short period in relation to
    > network timing jitter. 10ms/s would be 10,000 parts per million, which
    > is much much higher than you would get even from a real false ticker,
    > and could only really represent the result of jitter. On a heavily
    > loaded connection, traffic variations can results in offsets varying by
    > hundreds of milliseconds (relative to true time).
    >

    yup... the round trip time should be assessed too... historically...

    who said something about 10ms/s? if i did it, i was wrong...

    i was talking about this: http://www.pool.ntp.org/scores/131.173.33.3
    unluckily its refids and its server's ntpq-information r not recorded,
    so that we just have my "testimony"...

    -arne

+ Reply to Thread