philip@beeblebrox.dle.dg.com (Philip Gladstone) (06/06/91)
I found a nasty bug this morning in the clock selection code in xntp
1.3. It turns out that the casting out of outlying clocks is just done
wrong. This results in incorrect clock selections. I enclose the
(trivial) patch.
Apply in the xntpd directory with 'patch < filename'
Good luck.
Philip
---cut here
*** orig_ntp_proto.c Thu Jun 6 12:14:15 1991
--- ntp_proto.c Thu Jun 6 12:49:06 1991
***************
*** 1561,1566 ****
--- 1561,1568 ----
*/
for (i = 0; i < j; i++)
d = (d>>1) + (d>>2);
+
+ peer_badness[n] += d;
}
break;
***************
*** 1600,1605 ****
--- 1602,1609 ----
else
d = (d>>1) + (d>>2);
}
+
+ peer_badness[n] += d;
}
break;
***************
*** 1638,1643 ****
--- 1642,1649 ----
else
d = (d>>1) + (d>>2);
}
+
+ peer_badness[n] += d;
}
break;
***************
*** 1659,1664 ****
--- 1665,1672 ----
*/
for (i = 0; i < j; i++)
d = (d>>1) + (d>>3) + (d>>4);
+
+ peer_badness[n] += d;
}
break;
***************
*** 1680,1685 ****
--- 1688,1695 ----
*/
for (i = 0; i < j; i++)
d = (d>>1) + (d>>3);
+
+ peer_badness[n] += d;
}
break;
***************
*** 1692,1698 ****
sys_select_algorithm);
exit(1);
}
- peer_badness[n] += d;
}
/*
--- 1702,1707 ----
--- end of patch
--
Philip Gladstone Dev Lab Europe, Data General, Cambridge, UK
I seem to be having this tremendous difficulty with my lifestyle.philip@beeblebrox.dle.dg.com (Philip Gladstone) (06/06/91)
I found a nasty bug this morning in the clock selection code in xntp
1.3. It turns out that the casting out of outlying clocks is just done
wrong. This results in incorrect clock selections. I enclose the
(trivial) patch.
Apply in the xntpd directory with 'patch < filename'
Good luck.
Philip
---cut here
*** orig_ntp_proto.c Thu Jun 6 12:14:15 1991
--- ntp_proto.c Thu Jun 6 12:49:06 1991
***************
*** 1561,1566 ****
--- 1561,1568 ----
*/
for (i = 0; i < j; i++)
d = (d>>1) + (d>>2);
+
+ peer_badness[n] += d;
}
break;
***************
*** 1600,1605 ****
--- 1602,1609 ----
else
d = (d>>1) + (d>>2);
}
+
+ peer_badness[n] += d;
}
break;
***************
*** 1638,1643 ****
--- 1642,1649 ----
else
d = (d>>1) + (d>>2);
}
+
+ peer_badness[n] += d;
}
break;
***************
*** 1659,1664 ****
--- 1665,1672 ----
*/
for (i = 0; i < j; i++)
d = (d>>1) + (d>>3) + (d>>4);
+
+ peer_badness[n] += d;
}
break;
***************
*** 1680,1685 ****
--- 1688,1695 ----
*/
for (i = 0; i < j; i++)
d = (d>>1) + (d>>3);
+
+ peer_badness[n] += d;
}
break;
***************
*** 1692,1698 ****
sys_select_algorithm);
exit(1);
}
- peer_badness[n] += d;
}
/*
--- 1702,1707 ----
--- end of patch
--
Philip Gladstone Dev Lab Europe, Data General, Cambridge, UK
I seem to be having this tremendous difficulty with my lifestyle.
***WARNING: This article may be a duplicate....ramus@WINDSAIL.NERSC.GOV (Joe Ramus) (06/07/91)
>> I found a nasty bug this morning in the clock selection code in xntp >> 1.3. It turns out that the casting out of outlying clocks is just done >> wrong. This results in incorrect clock selections. I enclose the >> (trivial) patch. >> >> Apply in the xntpd directory with 'patch < filename' >> How does one determine what version? What is the version now available on louie.udel.edu ?? I wonder if the bug is fixed in the source on louie.udel.edu
maj@cl.cam.ac.uk (Martyn Johnson) (06/07/91)
> How does one determine what version? It's in the file "version.c". > What is the version now available on louie.udel.edu ?? 1.3, I believe. But somebody recently posted something referring to 1.4 - where is this I wonder? > I wonder if the bug is fixed in the source on louie.udel.edu I acquired my copy fairly recently, and it definitely has this bug. While we're here, a couple of other minor problems with xntp 1.3 1. A misfeature: It UNCONDITIONALLY sets its "nice" value to -12. This defeats any attempt to run it at even more negative nice levels. This caught me out because I have other daemons running at nice -15 and want to run xntpd at even higher priority. 2. The log message generated when the local clock is stepped only prints the offset to one significant figure. At least, that's what it does for me - since this is caused by a missing argument to a function, it could have different effects on different systems. Here's a patch: *** 1.1 1991/06/03 09:18:13 --- ntp_loopfilter.c 1991/06/03 09:19:31 *************** *** 117,123 **** if (tmp_ui > CLOCK_MAX_I || (tmp_ui == CLOCK_MAX_I && (u_long)tmp_uf >= (u_long)CLOCK_MAX_F)) { syslog(LOG_DEBUG, "adjust: STEP %s offset %s\n", ! ntoa(from), lfptoa(fp_offset)); step_systime(fp_offset); clock_adjust = 0; --- 117,123 ---- if (tmp_ui > CLOCK_MAX_I || (tmp_ui == CLOCK_MAX_I && (u_long)tmp_uf >= (u_long)CLOCK_MAX_F)) { syslog(LOG_DEBUG, "adjust: STEP %s offset %s\n", ! ntoa(from), lfptoa(fp_offset, 9)); step_systime(fp_offset); clock_adjust = 0; ---------- Martyn Johnson maj@cl.cam.ac.uk University of Cambridge Computer Lab Cambridge UK
philip@beeblebrox.dle.dg.com (Philip Gladstone) (06/07/91)
>>>>> On 6 Jun 91 18:25:23 GMT, ramus@WINDSAIL.NERSC.GOV (Joe Ramus) said:
[clockhopping (prevention of) patch removed]
Joe> How does one determine what version?
Joe> What is the version now available on louie.udel.edu ??
Joe> I wonder if the bug is fixed in the source on louie.udel.edu
The version on louie.udel.edu is still 1.3 (look in the version.c file
in the xntpd directory). Even if someone has forgotten to update the
version.c file, the bug is still present in that version!
This might also fix the problem experienced by
net@opal.cs.tu-berlin.de (Oliver Laumann) in the Sun. I found this
problem when my network became rather delayed and unpredictable. This
caused xntp to keep chaning its mind about which clocks were 'good'.
Even though my system has a radio clock on it, it would still try and
switch to synching on a remote stratum-1.
You can check to see if you have problems. If you use ntpq to
interrogate your server, then the symbols in column 1 (*.+) mean
* The current clock source
+ A possible source. These should have low offsets and/or low dispersions
. A candidate. These will be 'worse' than the '+' peers.
If these symbols 'look wrong' then you may suffer from clockhopping
and all the other bad things that flow from this.
Philip
--
Philip Gladstone Dev Lab Europe, Data General, Cambridge, UK
There did, however, remain the question of both the mysterious 60,000
Altairian dollars paid yearly into his Brantisvogan bank account, and
Zaphod Beeblebrox's highly profitable second-hand biro business.net@opal.cs.tu-berlin.de (Oliver Laumann) (06/08/91)
maj@cl.cam.ac.uk (Martyn Johnson) writes: > 1.3, I believe. But somebody recently posted something referring > to 1.4 - where is this I wonder? I mistakenly referred to a non-existing version 1.4 in a recent posting; sorry for the confusion. I didn't know that the `version' command of `xntpdc' reports only the version of xntpdc itself, not the version of the entire package. -- Oliver Laumann net@tub.cs.tu-berlin.de net@tub.UUCP