On Jun 30, 8:15 pm, David Woolley <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] 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 _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
