Re: [ntp:questions] How often does ntpd refresh its DNS lookup?
On 8/3/2019 11:38 AM, Jason Rabel wrote: For server-entries in ntp.conf, how does ntpd (4.2.8p13) time refreshing of hostnames? As far as I know, for regular server entries once it's done the initial lookup on startup, that's it... I believe for pool entries it will do a lookup to grab new IPs if a pool server goes silent. Maybe that's what you were referring to? After 20-years, we need to change the address of our time server. I was hoping I could just update DNS and all the clients would eventually notice the change. That hope is dashed. Thanks for the information, though. The answer wasn't what I hoped, but I can work with this. -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Garmin LVC 18x jitter problem
By now I hacked ntpd for allowing to override the lower jitter bound,
which fixes the problem properly. The attached patch shows the current
state.
Good: It works! ntpd no longer drops the GPS as false ticker, which in
turn does not drop PPS that depends on the preferred peer, so everything
works as beautiful as with "tos mindist 0.1", but without the negative
effect on the root dispersion that is caused by increasing the minimum
distance.
Bad: I don't see the modified jitter with "ntpq -c peers" and I have
no idea why. I verified it is modified. Perhaps there is duplicated
code somewhere I missed to modify as well? I should add a flag, but that
would run out of bits, and I am not certain if I may need to change other
struct members or variables storing flags as well, because much data is
being copied instead of referenced. I would appeciate some help here.
IMHO the minimum distance should only be set in case of multiple
reference clocks that unfortunately have no overlap of offset and jitter,
so increasing the distance allows to use them at the logical price of a
higher root dispersion. Using it to fix the wrong jitter estimation of
a single clock with not statistically distributed jitter is not what it
is intended for. Overriding the jitter of that clock is what is really
required, and checking past mailing lists, this topic came up quite a
few times. Obviously that allows to set mindist to 0, which reduces
the root dispersion to the actual value, which is below 1 ms for me.
Michael
diff -u -r ntp-dev-4.3.99-orig/ntpd/ntp_refclock.c
ntp-dev-4.3.99/ntpd/ntp_refclock.c
--- ntp-dev-4.3.99-orig/ntpd/ntp_refclock.c 2019-06-07 09:42:47.0
+0200
+++ ntp-dev-4.3.99/ntpd/ntp_refclock.c 2019-08-07 19:17:08.947049304 +0200
@@ -494,6 +494,7 @@
}
pp->offset /= m;
pp->jitter = max(SQRT(pp->jitter / m), LOGTOD(sys_precision));
+ pp->jitter = max(pp->jitter, pp->fudgeminjitter);
#ifdef DEBUG
if (debug)
printf(
@@ -1080,6 +1081,7 @@
pp->sloppyclockflag &= ~CLK_FLAG4;
pp->sloppyclockflag |= in->flags & CLK_FLAG4;
}
+ pp->fudgeminjitter = in->fudgeminjitter;
}
/*
diff -u -r ntp-dev-4.3.99-orig/include/ntp_refclock.h
ntp-dev-4.3.99/include/ntp_refclock.h
--- ntp-dev-4.3.99-orig/include/ntp_refclock.h 2016-03-27 23:59:49.0
+0200
+++ ntp-dev-4.3.99/include/ntp_refclock.h 2019-08-07 19:07:13.902963553
+0200
@@ -81,6 +81,7 @@
double fudgetime2; /* configure fudge time2 */
int32 fudgeval1; /* configure fudge value1 */
u_int32 fudgeval2; /* configure fudge value2 */
+ double fudgeminjitter; /* configure fudge minjitter */
u_char currentstatus; /* clock status */
u_char lastevent; /* last exception event */
u_char leap; /* leap bits */
@@ -176,6 +177,7 @@
*/
double fudgetime1; /* fudge time1 */
double fudgetime2; /* fudge time2 */
+ double fudgeminjitter; /* manually set lower bound for jitter */
u_char stratum;/* server stratum */
u_int32 refid; /* reference identifier */
u_char sloppyclockflag; /* fudge flags */
diff -u -r ntp-dev-4.3.99-orig/ntpd/keyword-gen.c
ntp-dev-4.3.99/ntpd/keyword-gen.c
--- ntp-dev-4.3.99-orig/ntpd/keyword-gen.c 2019-06-07 05:54:31.0
+0200
+++ ntp-dev-4.3.99/ntpd/keyword-gen.c 2019-08-06 19:54:05.362952788 +0200
@@ -199,6 +199,7 @@
{ "stratum", T_Stratum, FOLLBY_TOKEN },
{ "time1", T_Time1,FOLLBY_TOKEN },
{ "time2", T_Time2,FOLLBY_TOKEN },
+{ "minjitter", T_Minjitter,FOLLBY_TOKEN },
/* system_option */
{ "auth", T_Auth, FOLLBY_TOKEN },
{ "bclient", T_Bclient, FOLLBY_TOKEN },
diff -u -r ntp-dev-4.3.99-orig/ntpd/ntp_config.c
ntp-dev-4.3.99/ntpd/ntp_config.c
--- ntp-dev-4.3.99-orig/ntpd/ntp_config.c 2019-06-07 10:59:13.0
+0200
+++ ntp-dev-4.3.99/ntpd/ntp_config.c2019-08-07 19:04:12.254768986 +0200
@@ -3703,6 +3703,13 @@
clock_stat.flags &= ~CLK_FLAG4;
break;
+ case T_Minjitter:
+#if 0
+ clock_stat.haveflags |= CLK_HAVEMINJITTER;
+#endif
+ clock_stat.fudgeminjitter = curr_opt->value.d;
+ break;
+
default:
msyslog(LOG_ERR,
"Unexpected fudge flag %s (%d) for %s",
diff -u -r ntp-dev-4.3.99-orig/ntpd/ntp_parser.y
ntp-dev-4.3.99/ntpd/ntp_parser.y
--- ntp-dev-4.3.99-orig/ntpd/ntp_parser.y 2019-06-07 09:42:47.0
+0200
+++ ntp-dev-4.3.99/ntpd/ntp_parser.y2019-08-06 1
Re: [ntp:questions] Garmin LVC 18x jitter problem
Minor issue 1: You seem not to initialize fudgeminjitter if not
configured. Probably to 0.0
Wishlist issue 2: Maybe also make fudgeminjitter available for network
clocks, e.g. to describe a non-uniform packet jitter in a network path
or non-uniform hardware jitter in a preferred site local higher stratum
server.
On 10/08/2019 08:58, Michael Haardt wrote:
By now I hacked ntpd for allowing to override the lower jitter bound,
which fixes the problem properly. The attached patch shows the current
state.
Good: It works! ntpd no longer drops the GPS as false ticker, which in
turn does not drop PPS that depends on the preferred peer, so everything
works as beautiful as with "tos mindist 0.1", but without the negative
effect on the root dispersion that is caused by increasing the minimum
distance.
Bad: I don't see the modified jitter with "ntpq -c peers" and I have
no idea why. I verified it is modified. Perhaps there is duplicated
code somewhere I missed to modify as well? I should add a flag, but that
would run out of bits, and I am not certain if I may need to change other
struct members or variables storing flags as well, because much data is
being copied instead of referenced. I would appeciate some help here.
IMHO the minimum distance should only be set in case of multiple
reference clocks that unfortunately have no overlap of offset and jitter,
so increasing the distance allows to use them at the logical price of a
higher root dispersion. Using it to fix the wrong jitter estimation of
a single clock with not statistically distributed jitter is not what it
is intended for. Overriding the jitter of that clock is what is really
required, and checking past mailing lists, this topic came up quite a
few times. Obviously that allows to set mindist to 0, which reduces
the root dispersion to the actual value, which is below 1 ms for me.
Michael
diff -u -r ntp-dev-4.3.99-orig/ntpd/ntp_refclock.c
ntp-dev-4.3.99/ntpd/ntp_refclock.c
--- ntp-dev-4.3.99-orig/ntpd/ntp_refclock.c 2019-06-07 09:42:47.0
+0200
+++ ntp-dev-4.3.99/ntpd/ntp_refclock.c 2019-08-07 19:17:08.947049304 +0200
@@ -494,6 +494,7 @@
}
pp->offset /= m;
pp->jitter = max(SQRT(pp->jitter / m), LOGTOD(sys_precision));
+ pp->jitter = max(pp->jitter, pp->fudgeminjitter);
#ifdef DEBUG
if (debug)
printf(
@@ -1080,6 +1081,7 @@
pp->sloppyclockflag &= ~CLK_FLAG4;
pp->sloppyclockflag |= in->flags & CLK_FLAG4;
}
+ pp->fudgeminjitter = in->fudgeminjitter;
}
/*
diff -u -r ntp-dev-4.3.99-orig/include/ntp_refclock.h
ntp-dev-4.3.99/include/ntp_refclock.h
--- ntp-dev-4.3.99-orig/include/ntp_refclock.h 2016-03-27 23:59:49.0
+0200
+++ ntp-dev-4.3.99/include/ntp_refclock.h 2019-08-07 19:07:13.902963553
+0200
@@ -81,6 +81,7 @@
double fudgetime2; /* configure fudge time2 */
int32 fudgeval1; /* configure fudge value1 */
u_int32 fudgeval2; /* configure fudge value2 */
+ double fudgeminjitter; /* configure fudge minjitter */
u_char currentstatus; /* clock status */
u_char lastevent; /* last exception event */
u_char leap; /* leap bits */
@@ -176,6 +177,7 @@
*/
double fudgetime1; /* fudge time1 */
double fudgetime2; /* fudge time2 */
+ double fudgeminjitter; /* manually set lower bound for jitter */
u_char stratum;/* server stratum */
u_int32 refid; /* reference identifier */
u_char sloppyclockflag; /* fudge flags */
diff -u -r ntp-dev-4.3.99-orig/ntpd/keyword-gen.c
ntp-dev-4.3.99/ntpd/keyword-gen.c
--- ntp-dev-4.3.99-orig/ntpd/keyword-gen.c 2019-06-07 05:54:31.0
+0200
+++ ntp-dev-4.3.99/ntpd/keyword-gen.c 2019-08-06 19:54:05.362952788 +0200
@@ -199,6 +199,7 @@
{ "stratum",T_Stratum, FOLLBY_TOKEN },
{ "time1", T_Time1,FOLLBY_TOKEN },
{ "time2", T_Time2,FOLLBY_TOKEN },
+{ "minjitter", T_Minjitter,FOLLBY_TOKEN },
/* system_option */
{ "auth", T_Auth, FOLLBY_TOKEN },
{ "bclient",T_Bclient, FOLLBY_TOKEN },
diff -u -r ntp-dev-4.3.99-orig/ntpd/ntp_config.c
ntp-dev-4.3.99/ntpd/ntp_config.c
--- ntp-dev-4.3.99-orig/ntpd/ntp_config.c 2019-06-07 10:59:13.0
+0200
+++ ntp-dev-4.3.99/ntpd/ntp_config.c2019-08-07 19:04:12.254768986 +0200
@@ -3703,6 +3703,13 @@
clock_stat.flags &= ~CLK_FLAG4;
break;
+ case T_Minjitter:
+#if 0
+ clock_stat.haveflags |= CLK_HAVEMINJITTER;
+#endif
+ clock_stat.fudgeminjitter = curr_opt->value.d;
+ break;
+
defa
Re: [ntp:questions] symmetricom tp1100 stratum and leap indicator behavior
Just wanted to say thanks to all the responders to my thread. Just to close the loop, I was obviously wrong in my assessment. Since I was at the point where I was thinking it might be a bug in ntpd, I started from scratch and began the steps to reproduce and document my results from the ground up. In doing so, I figure what I had done was to leave the Symmetricom in the wrong mode (SSU mode vs. PRR mode) while I was doing my testing and packet tracing. I twiddled so many knobs on that thing I obviously lost track. So, to summarize, when the Symmetricom is in PRR mode, even when there is a problem with the GPS input, it will intentionally keep on advertising itself as a stratum 1 outwardly, falling back to holdover mode using its internal oscillator for its time source. Since that oscillator keeps reasonably high quality time (we don't have the rubidium oscillator, but still, it keeps decent time), I can only imagine how long it would take for it to be perceived by the clients as weak enough for them to switch to another source. I've written a health check script that will connect in, look for alarms and quality level and such, then on discovering any problems, knocks the Symmetricom out of PRR mode into SSU mode and disables the GPS input. Once that happens, the Symmetricom stops reporting time and its stratum level in its responses, then, as expected, the reachability drops and clients select another source. Given this, I hesitate to call this a bug in ntpd. I mean, _maybe_ it'd be nice if it handled a source ceasing to report it's stratum level, but I think it should be the Symmetricom that reports it's stratum level correctly. Since this is an EOL device, I'm not holding my breath for any firmware updates any time soon. I appreciate you all taking the time and your informative responses. Thanks! -- Andrew ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
